summaryrefslogtreecommitdiffstats
path: root/src/com/android/providers/contacts/ContactsDatabaseHelper.java
Commit message (Collapse)AuthorAgeFilesLines
* Reorganize import in contacts providerMakoto Onuki2012-06-271-5/+5
| | | | Change-Id: If3afb134ea36bd93859efcd114885526e1592b91
* Fix transaction handling in the providerMakoto Onuki2012-06-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issues that will happen when a batch operation for applyBatch() contain operations for both the contacts db and the profile db. - Make sure to set the right transaction listener when starting a transaction. There were cases where we started a transaction on the contacts db but passsing the profile provider as the listener, and vice versa. - Make sure transaction callbacks operate on the correct DB. There were cases where ContactsProvider2.onCommit() and its sbilings would operate on the profile DB, not on the contacts db. - Change the transaction finishing order. When we start transactions on both the contacts and the profile DB, we do so on the contacts db first, and then on the profile db. But when we clsoe them, we did it in the same order, which could potentially cause a deadlock. Now we close them in the reverse order; the profile db first, then the contacts db. - Remove mActiveDb. This wasn't set in switchTo{Profile,Contact}Mode(), but was lazily initialized. But I wasn't too sure if I always set the right db at the right timing. Looks like I forgot to do so in a few cases. Let's just remove it and always explicitly get the database from the current db helper. Bug 6250673 Change-Id: Idd18fc173596c973d0ff8b6e1b2456715c0f14f8
* Remove never used SocialProvider and activity tableMakoto Onuki2012-05-031-53/+8
| | | | | | Bug 6148750 Change-Id: If63219745973aa2629b95259ec692867f5197e79
* Make names with special chars searchable.Makoto Onuki2012-04-301-1/+7
| | | | | | | | | | | | | | It's a better fix than I34bfa864, which was only a quick workaround for double barrelled names. Now names with other special characters are searchable too. Also, previously, a query "doublebarrelled" wouldn't match "double-barrelled", but now it will. Bug 5592553 Change-Id: Id1d44261f577df7abf701311ed1c86fb093547da
* Clean up Phone.NORMALIZED_NUMBERS upgraded from GBMakoto Onuki2012-04-251-1/+83
| | | | | | | | | | | | | | | | | | | If upgraded from GB, the NORMALIZED_NUMBERS column doesn't really contain the "normalized" numbers. It's some kind of stripped-out-and-reversed numbers. We can't create normalized numbers for them as we don't really know the correct country for each number (and we can't even rely on CountryDetector during the upgrade step -- the detector isn't ready at this moment), so let's just null out those bad numbers. This is how we do for invalid numbers. phone_lookup.NORMALIZED_NUMBERS also has the same issue, so let's recreate them in the way DataRowHandlerForPhoneNumber.insert() would when it can't infar the normalized number. (i.e. when the phone number is invalid.) Bug 5690851 Change-Id: I756b828e15a50a2f711c01ef22abd2cfa67bad0a
* Upgrade step to fill raw_contacts.last_time_contacted.Makoto Onuki2012-04-141-1/+17
| | | | | | | | | Replace raw_contacts.last_time_contacted with data_usage_stat.last_time_used if it's bigger. Bug 6326418 Change-Id: I052a7fb92e69cf35f8e37a9be1b074f480e96071
* Clear in-memory caches when rolling back transactionMakoto Onuki2012-03-281-4/+9
| | | | | | Bug 6245089 Change-Id: I4fe92fbf190090b6e25a411c8c0e2f9885564952
* Merge "Revert ""Rollback" mimetype cache""Makoto Onuki2012-03-281-43/+3
|\
| * Revert ""Rollback" mimetype cache"Makoto Onuki2012-03-281-43/+3
| | | | | | | | | | This reverts commit c624ff13d5df4848a6ec605e25ea8469dd677d5d Due to b/6123232
* | Merge ""Rollback" mimetype cache"Makoto Onuki2012-03-271-3/+43
|\ \ | |/
| * "Rollback" mimetype cacheMakoto Onuki2012-03-271-3/+43
| | | | | | | | | | | | Bug 6239243 Change-Id: Icf473e5178a76fda66b33fc11875f00d87b36c16
* | Add new package aggregation.utilMakoto Onuki2012-03-231-0/+1
|/ | | | | | Move aggregator related classes into it. Change-Id: I712fe07ad2bab1e532e3822e3e2797a199329865
* Use wall time instead of CPU time for performance logMakoto Onuki2012-03-081-2/+2
| | | | | | | | Apparently what currentThreadTimeMillis() returns is the CPU time, not wall time, which is not really interesting when we measure performance. Use the actual wall time instead. Change-Id: Ibe2e385ff1bdeeb1128a584c79925210dde5525a
* Merge "Don't manually close the database."Makoto Onuki2012-03-071-23/+6
|\
| * Don't manually close the database.Makoto Onuki2012-03-071-23/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't close and reopen the database in CDH.getWritableDatabase(). The reason we did this was to sqlite reload the sqlite_stat1 table, but according to the document running "ANALYZE sqlite_master" should be suffice. (See http://www.sqlite.org/lang_analyze.html) Also don't close the database helpers after upgrade in ContactsUpgradeReceiver. We don't have to do this. Also, replaced the test-only constructors of the helpers with methods with more explicit name, in order to make sure only the singleton instances are used in the main code. Bug 6104842 Change-Id: I76a7d1b8f7b6462b97f627d722feaa03967cb18f
* | Speed up VISIBLE_CONTACTS updateMakoto Onuki2012-03-071-14/+26
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The delete used to easily take >1 second with 10K contacts. Now it's just ~1ms. It's one of the slowest processes during aggregation. The old SQL looked like this: DELETE FROM visible_contacts WHERE _id NOT IN (SELECT _id FROM contacts WHERE [CONTACT_IS_VISIBLE] = 1) and _id = CONTACT_ID_IN_QUESTION The problem is the subquery, especially the [CONTACT_IS_VISIBLE] part, is pretty slow but it queries *all* visible contact IDs at once, But this really means "Remove CONTACT_ID_IN_QUESTION from visible_contacts, if it's not visible." DELETE FROM visible_contacts WHERE _id IN (SELECT _id FROM contacts WHERE _id = CONTACT_ID_IN_QUESTION and [CONTACT_IS_VISIBLE] = 0) (We use 'IN' rather than '=' here, because this method is used to update visible_contacts for *all* contacts as well, in which case we just remoev the the [_id = CONTACT_ID_IN_QUESTION] part from the selection.) Change-Id: I73d629f6b352d010eb1deabb7e23d12130be9b3d
* Move aggregator to its own packageMakoto Onuki2012-03-051-3/+1
| | | | | | | | | | | | | ... so that methods used only by ProfileAggregator don't have to be public. And fix some method visibilities that don't make sense. Needed to change the bogus ID in PhotoStoreTest; otherwise moving the aggregator test will make this test fail for some unclear reason. Bug 6118852 Change-Id: Ic0c022cbf50128f40c70559c1a7cf8e2a6c06fc8
* Don't remove default directories from directories tableMakoto Onuki2012-02-211-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The directories table should always contain the DEFAULT and LOCAL_INVISIBLE directories. Otherwise search would break. Also re-create all directoires next time the provider starts as a part of upgrade. Details: ContactDirectoryManager has two public methods to update the table: scanAllPackages() to scan all directories from all installed packages, and onPackageChanged() to scan only a specific package. scanAllPackages() is called when an account is added or removed. It always rules out the default ones when it deletes rows, so this method shouldn't possibly remove the default ones. However, onPackageChanged(), which is called when an app is installed or uninstalled, doesn't check the given package name. If this method is given the package name of the contacts provider itself, it *will* remove all the directories that belong to the contacts provider, which are the default ones, but doesn't re-create them because these are not exported from the provider like a normal directory. With this CL onPackageChanged() now checks if the given package name is of itself, and will ignore the request if so. Bug 6005231 Change-Id: Ia19dfb1890160315ef9de8aa0530978e547abf7d
* Remove in-memory account cacheMakoto Onuki2012-02-171-34/+36
| | | | | | Bug 6026073 Change-Id: Ic6057aa2347d1fa4c245ad2f6644ac4d5e8ae3cf
* Merge "Fix proguard flags"Makoto Onuki2012-01-311-0/+3
|\
| * Fix proguard flagsMakoto Onuki2012-01-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Removed the *ForTest exception. It caused issues with guava. Now that we have NeededForTesting, we don't really need it. (But didn't change method names from XxxForTest to Xxx, because I still think using this prefix for test-only methods is a good idea, as it'll make it easier to catch the use of methods in the main apk that are not supposed to be used.) Change-Id: Idccfd7175372b1a2253b19161ae572dae7e1e952
* | Remove the obsolete account columns from newly created dbMakoto Onuki2012-01-251-11/+0
|/ | | | | | Bug 5884869 Change-Id: I2cbec01766883a469fb5558306d6a9b7745845b8
* Fix crash at upgrade step 504 due to account ID cacheMakoto Onuki2012-01-171-7/+23
| | | | | | | | | The account ID column didn't exist at this point, so we should skip the cache initialization. Bug 5868343 Change-Id: I5fd479f882abbce2be7bf1278656e8e4b83bc106
* Account refactoring follow-upMakoto Onuki2012-01-111-61/+36
| | | | | | | | | | | | | - Check if there's really a new or removed account in updateAccountsInBackground() before doing everything else. If there's none, we'll skip re-scanning directories too. - Preheat the account cache when the provider starts. - Use account_id for the account filter query parameters. The contacts URI now supports the parameters too. Change-Id: I12e1116890df4c20b354618acfaee9dc009dc68e
* Account table refactoringMakoto Onuki2012-01-101-130/+383
| | | | | | | | | | | | | | | | - Remove the account columns (type, name, data_set) from the raw_contacts/groups tables and add account_id instead. - Re-create the accounts table. The new table now has the _ID column. Rows in this table now has a different lifecyle than before: -- New row is created as the provider detects a new account during a write operation to the raw_contacts and groups table. -- Stale rows are removed upon account removal. - Removed account consistency check for steam items/photos. We don't do this kind of check for other tables. Change-Id: I1ce01590aef70f417fa89426dae762a41d25d656
* More aggressive fix for phone lookup issues.Dave Santoro2011-12-201-0/+18
| | | | | | | | | | | | | Rather than relying on a trailing suffix match on the longer of the two numbers (the one from caller ID and the one in the database), this first attempts to do the full internationalized-number-aware query that we'd normally do, and if no results are returned, falls back to a comparison of the trailing 7 digits of each number, as we did in Gingerbread. Bug: 5742389 Change-Id: I085fe9df336c6d75008423163965c39d91bcd1ce
* Use ContactContract.Phone instead of internal definitionMakoto Onuki2011-12-141-5/+0
| | | | | | | | | | | PhoneColumns was just redundant, and only made it hard to find all usecases of Phone.NORMALIZED_NUMBER. Also makred GroupsTest as @MediumTest. Some methods didn't have a size annotations so they weren't executed as we always have to use the "-e size" parameter. Change-Id: I53160219e2ab6b2535cc8be61b07af6312bc92fc
* Fix for GB upgrade issue with phone lookups.Dave Santoro2011-12-131-11/+11
| | | | | | | | | | | | This just generalizes a fix that Shaopeng had for Brazilian phone numbers, in which it was possible that the caller ID number being checked was shorter than the normalized number we had stored. We essentially accept a phone number as a match if the shorter of either (caller ID, normalized number) is a trailing prefix of the other. Bug: 5638376 Change-Id: Iea81bc4163cb89169946f9a33f9e15b13e8868ad
* Remove hasColumn() and use isInProjection() instead.Makoto Onuki2011-11-181-7/+17
| | | | | | | | When I added hasColumn I didn't realize there was already a similar method. Bug 5545880 Change-Id: I9ba62a9ff8b3eeab8098626426a37fd84c77d679
* Fix search for hyphenated namesMakoto Onuki2011-11-151-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This issue was caused by the combination of the fact that we have two different imcompatible tokenizers for names, and the fact that our name-normalizer ignroes all non-letter and non-digit characters. Basically, the name tokenizer used to build index uses ' ' as the separator, and the one used to tokenize queries use all non-letter, non-digit characters. Take the name "Double-barrelled" as an example. The full-text search index for this looks like "doublebarrelled", because it's treated as one token (because there's no spaces in it), and the normalzier removes all non-letter/digits. On the other hand, the query term "double-barrelled" will be split into "double" "barrelled", and internally it becomes AND-ed prefix matches "double* AND barrelled*". Beacuse "barrelled*" doesn't match "doublebarrelled" the query doesn't hit. So (for now) let's split names with '-' when buidling the index. With this CL the index will be "double barrelled" and the query "double-barrelled" (and also "double barrelled") *will* hit this. Long-term we probably need a better fix. Bug 5592553 Change-Id: I34bfa8647eec8d203f8ff7fc8a85f42505054c7c
* Optimize STREQUENT queries and fix estimated table row countsDaniel Lehmann2011-11-141-12/+108
| | | | | | | | | | | | | - Use id instead of strings for matching mimetypes - Use inner LIMIT of 25 to prevent the extra subquery (also fixes correctness) - Reorder JOIN for data-usage-stat JOIN contacts - Defeat sqlite3's "optimization" attempt by using +0 on fields from contacts/data <-- This is huge Bug:5560534 Change-Id: I412d359afe07f32643cc2faef8735b719686741f
* Add support for looking up SIP addresses.Flavio Lerda2011-11-041-0/+17
| | | | | | | | | | | | | | | | | Current ContactsContract.PhoneLookup only support looking up phone number. As a consequence SIP address look-ups are done with a generic, expensive ContactsContract.Data query. This change adds support for doing a SIP address look-up using ContactsContract.PhoneLookup by specifying a query parameter. By doing so, we can do a trivial but crucial optimization: instead of matching against the MIME type as a string, we can use the _id of the vnd.android.cursor.item/sip_address MIME type in our database. This speeds up queries that used to take over 250ms to 1-2ms. Bug: 5529690 Change-Id: I15e7ed225927882fc0fd0958b7d2cbfede12c590
* Speed up query for group tabMakoto Onuki2011-10-271-0/+20
| | | | | | | | | | | | | | - The old query had overhead propotional to the number of groups. - The Groups.SUMMARY_WITH_PHONES column is still slow, but we don't use it. - We can use the same technique for Groups.SUMMARY_GROUP_COUNT_PER_ACCOUNT. The only downside is that, we're changing the FROM clause dynamically according to the requested column, which is something that we don't usually do. Overusing this technique could make code less maintainable... Bug 5092615 Change-Id: I79b01ae2a232bcd8e3b7186288050fed14a36a72
* Use hexadecimal collation key for name searches.Daniel Lehmann2011-10-141-1/+7
| | | | | | | | Also allow prefix search on name Bug:5337763 Change-Id: I039264be0c8309224d8925ded06ab02a64a5ce1b
* Add new column for cached formatted number.Flavio Lerda2011-10-011-3/+11
| | | | | Bug: 5316982 Change-Id: I2870778c8056468730d82794ddae90c74cab85fc
* Make search aware of names in "all other contacts"Daisuke Miyakawa2011-09-211-1/+6
| | | | | | | | | default_directory doesn't contain contacts which are in "all other contacts" group (or people who are not in any group), while in search mode we want those names. Bug: 5336673 Change-Id: Ib77acdfa6968605a66561f0925d0aa81f4522bb9
* Cast in_visible_group field as an integer.Dave Santoro2011-09-201-2/+8
| | | | | | | | | | | This is necessary to allow for queries using selection arguments for this field to work, since we always bind these as strings (and SQLite's type affinity won't kick in on function-based view fields unless we explicitly cast them). Bug 5118670 Change-Id: Ia4abe247547fbf482f187bf2db7f2df56fc9d601
* Do mimetype filtering based on ID.Daniel Lehmann2011-09-131-7/+25
| | | | | | | | | | | | Wherever the provider is doing a query based on the mimetype, we can optimize the SQL performance by switching in the (cached) mimetype ID and joining against that instead. Also fixed an issue that was likely leading to hi-res photos being blown away during photo cleanup. Bug:5289712 Change-Id: Ic51e4c6b0e5daa8b7a2440692755fd87d387f3f3
* Add data_set for Settings.Dave Santoro2011-09-091-5/+40
| | | | | | | | | | | Since data_set may be null, it can't be part of the primary key for the table, so we need to re-create the table and add provider-side protection from inserting duplicate settings records. Bug 5156004 Change-Id: I25ae53c5670087a116058f0daef5b06cb6ce372b
* Merge "Don't share SQLiteStatement between threads. Create on the fly"Daniel Lehmann2011-08-311-64/+69
|\
| * Don't share SQLiteStatement between threads. Create on the flyDaniel Lehmann2011-08-311-64/+69
| | | | | | | | | | | | Bug:5229241 Change-Id: I57cda04dbe65afc4b05ddd46dda94b812d0df6bc
* | Cleanup variable referring to removed column.Dave Santoro2011-08-311-1/+0
|/ | | | | | Bug 5242084 Change-Id: I7c8d00701a5a20c97556bf523faf4c4b9fb8a49a
* Merge "Enable contact matching for incoming calls which only contain local ↵Attila Bodis2011-08-311-0/+14
|\ | | | | | | number."
| * Enable contact matching for incoming calls which only contain localShaopeng Jia2011-08-301-0/+14
| | | | | | | | | | | | | | number. Bug: 5197612 Change-Id: Ia38f097e1e1e8ecad9c41a15d5c7593807d13571
* | Separate the profile out into a separate database.Dave Santoro2011-08-301-45/+57
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fundamentally, this works as follows: 1. A separate, structurally identical database is created for storing profile data. The view columns for identifying whether a contact or raw contact belongs to the user's profile are initialized with constant values for each database. 2. Sequence numbers in the new profile database are set to a very high value (MAX_LONG - MAX_INT) to designate an ID-space in which profile data is stored. This is important for distinguishing between contact and profile requests. 3. Contacts Provider URIs are divided into several sets, bucketed automatically by a new profile-aware URI matcher. - URIs that explicitly reference the profile. - URIs that contain IDs (which may be in the profile ID-space). - URIs that contain lookup keys (which may be a special profile lookup key). - URIs for insertion that may contain a profile ID as the parent for the inserted record (in content values). These can't be detected by the URI matcher by itself, so this mapping is maintained in the provider. By identifying whether a URI falls into one of these sets, the contacts provider can efficiently determine whether the request is intended for the profile database or contacts database. 4. The Contacts Provider holds onto two separate copies of the following, one each for contacts and profiles: - Database helper - Transaction context - Aggregator - Photo store (the profile one uses a separate directory) 5. During any query/update/insert/delete/openAssetFile operation, the URI (and content values, if applicable) are examined to determine whether the operation is intended for the Contacts DB or the profile DB. If intended for the profile DB, the provider is switched (in a thread-local manner) to a profile mode, and the operation is handed off to the profile provider. The profile provider does a permission check, substitutes the profile database as the active DB in the contacts provider, and continues the operation in the Contacts Provider by calling the in-transaction or local version of the operation, which does its normal processing, but with everything pointing at profile-specific databases, aggregators, etc. 6. If the operation isn't determined to be targeted to the profile database, the provider is similarly switched (thread-locally) into contacts mode, and the active DB is set to the contacts DB. 7. For batch operations, we only create a transaction for the contacts DB initially. If any of the operations in the batch end up targeting the profile DB, we start a transaction for the profile DB. When the batch is finished, we check for that and also commit the profile transaction if there were no errors. Bug 5204577 Bug 5161066 Bug 5155743 Bug 5087853 Bug 5031883 Bug 5198777 Bug 5230140 Change-Id: Ic43a6625cbb6edf52ea076b084647fb0656e28e5
* Add lookup_key to the StreamItemsView (it was missing in the previous CL)Daniel Lehmann2011-08-291-1/+9
| | | | | Bug:5134325 Change-Id: I214f5750a9c445b2bca0cc6a448463c38519bfa1
* Merge "Fix the creation of the search_index table when the aggregation mode ↵Daniel Lehmann2011-08-261-0/+1
|\ | | | | | | changes"
| * Fix the creation of the search_index table when the aggregation modeDaniel Lehmann2011-08-251-0/+1
| | | | | | | | | | | | | | | | | | changes Original CL submitted by Google TV Bug:4485628 Change-Id: I1d964bd153cc4de1b5543970bbfd89ff89587451
* | Add a few columns for caching to the call log.Flavio Lerda2011-08-261-1/+19
|/ | | | | | | | | | | | These columns store additional information about the contact associated with a call log entry and are needed by the new functionality present in the call log. This change matches the newly defined columns in android.provider.CallLog. Bug: 5101753 Change-Id: Ife45e7034af098bf0e1ca35d05bb389a2c47909a
* Fix ambiguity for Contacts._ID and RawContacts._ID in Stream ItemsDaniel Lehmann2011-08-251-1/+37
| | | | | | Bug:5134325 Change-Id: Id5159a24c9a2aee58e566b9bc03719e7a6ee0f7c
generated by cgit v1.1 at 2024-10-27 23:38:10 +0000