38210445730ee04c351c7cc1b3800cfe23e34325 |
|
27-Jun-2012 |
Makoto Onuki <omakoto@google.com> |
Reorganize import in contacts provider Change-Id: If3afb134ea36bd93859efcd114885526e1592b91
/packages/providers/ContactsProvider/tests/src/com/android/providers/contacts/SynchronousProfileProvider.java
|
583b1364980fd46a5012825886af3160752ff19c |
|
29-Mar-2012 |
Makoto Onuki <omakoto@google.com> |
Make unit tests not crash Workaround for "Cursor window allocation of 2048 kb failed" during ContactAggregatorTest. This should be some kind of OOM because if I run only ContactAggregatorTest it passes without a crash. Couldn't figure out the root cause. Instead of spending too much time on it, decided to mark move all large tests except for ContactsProvider2Test to medium. Also did some cleanup for SynchronousContactsProvider2 and SynchronousProfileProvider. Bug 6249848 Change-Id: I51d80db1e4025ff20642bc3abf8074f882da47d8
/packages/providers/ContactsProvider/tests/src/com/android/providers/contacts/SynchronousProfileProvider.java
|
9b626252d91e451a822f48cd127aef5d609a6257 |
|
07-Mar-2012 |
Makoto Onuki <omakoto@google.com> |
Don't manually close the database. 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
/packages/providers/ContactsProvider/tests/src/com/android/providers/contacts/SynchronousProfileProvider.java
|
078f588cef389358adabc579de00747878f3c108 |
|
21-Sep-2011 |
Dave Santoro <dsantoro@google.com> |
Refactor transactions for contacts. Rather than extending SQLiteContentProvider, the profile and contacts providers now extend AbstractContactsProvider, which handles keeping track of a thread-local transaction with awareness of what databases have been enlisted in the transaction and whether it is being run in the context of a batch operation. This is intended to solve the issue of how the content provider can manage transactions that operate across multiple databases without risking deadlocks. Bug 5320369 Change-Id: I08a7d518a3eae1b0bf438402d02f1f1d8e8df7b9
/packages/providers/ContactsProvider/tests/src/com/android/providers/contacts/SynchronousProfileProvider.java
|
5d0a768b56ed4bd0dfef81b8389247ba74766659 |
|
08-Aug-2011 |
Dave Santoro <dsantoro@google.com> |
Separate the profile out into a separate database. 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
/packages/providers/ContactsProvider/tests/src/com/android/providers/contacts/SynchronousProfileProvider.java
|