| 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
|