| f624d76a4ca27e4c80cd0f483500b0139e36c9c7 |
|
08-Oct-2014 |
Yorke Lee <yorkelee@google.com> |
Use ContactsProvider context when sending broadcast
Bug: 17879141
Change-Id: Iebc12962837ce4c7c026aa792762317d90097d9d
/packages/providers/ContactsProvider/src/com/android/providers/contacts/ProfileProvider.java
|
| 0bdbe752c3c0cbbef2acb4eca74642aec9195d88 |
|
12-Sep-2012 |
Makoto Onuki <omakoto@google.com> |
Send a broadcast when profile changes
Bug 7148705
Change-Id: I3df22b7fc18a106f221f022f222d8fee566a24af
/packages/providers/ContactsProvider/src/com/android/providers/contacts/ProfileProvider.java
|
| ae32283e7fc5b749df96523d8bb343b9068b65ba |
|
09-May-2012 |
Makoto Onuki <omakoto@google.com> |
Fix transaction handling in the provider
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
/packages/providers/ContactsProvider/src/com/android/providers/contacts/ProfileProvider.java
|
| 11c3f85ab75cd21a1975025c6d8614e710161baa |
|
08-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Move CancellationSignal to android.os package.
Bug: 6427830
Change-Id: I9e856990512253fe2ca4cc2079d195a7fa991151
/packages/providers/ContactsProvider/src/com/android/providers/contacts/ProfileProvider.java
|
| fb25f3a5a86ca15de8507baf02a357a63032af62 |
|
28-Mar-2012 |
Makoto Onuki <omakoto@google.com> |
Clear in-memory caches when rolling back transaction
Bug 6245089
Change-Id: I4fe92fbf190090b6e25a411c8c0e2f9885564952
/packages/providers/ContactsProvider/src/com/android/providers/contacts/ProfileProvider.java
|
| c65c6bd3a52ece11a7ed60c20d6bf4c000bd70c7 |
|
28-Mar-2012 |
Makoto Onuki <omakoto@google.com> |
Revert ""Rollback" mimetype cache"
This reverts commit c624ff13d5df4848a6ec605e25ea8469dd677d5d
Due to b/6123232
/packages/providers/ContactsProvider/src/com/android/providers/contacts/ProfileProvider.java
|
| c624ff13d5df4848a6ec605e25ea8469dd677d5d |
|
28-Mar-2012 |
Makoto Onuki <omakoto@google.com> |
"Rollback" mimetype cache
Bug 6239243
Change-Id: Icf473e5178a76fda66b33fc11875f00d87b36c16
/packages/providers/ContactsProvider/src/com/android/providers/contacts/ProfileProvider.java
|
| 7898a8e97722d5bf0db3c04107b2957b998c0332 |
|
03-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Rename CancellationSignal using preferred spelling.
Bug: 5943637
Change-Id: I223a5e76627cdd604ebb147832f0fb086cb4a5f3
/packages/providers/ContactsProvider/src/com/android/providers/contacts/ProfileProvider.java
|
| 15826b1a7fd6d7a5be9223a61d49c0b532ccf01e |
|
31-Jan-2012 |
Daniel Lehmann <lehmannd@google.com> |
Pass through the cancelation signal
Change-Id: I248c7817a50a257ec5c2001e529ec4453f7e11cc
/packages/providers/ContactsProvider/src/com/android/providers/contacts/ProfileProvider.java
|
| 82792ae937085bfa1f7878166e89ca4ea84fd652 |
|
10-Oct-2011 |
Dave Santoro <dsantoro@google.com> |
Detect profile VCard URIs and support tokens.
This fixes the URI matcher to interpret VCard URIs for the profile
properly, and adds support in the provider side for pre-authorizing
URIs using temporary permission tokens.
Bug 5437453
Change-Id: I37bb6f759df833a3f007faef1eb35fb1434f7df2
/packages/providers/ContactsProvider/src/com/android/providers/contacts/ProfileProvider.java
|
| 6efb7db26598b105342d02207e0ca1c8725c10da |
|
22-Sep-2011 |
Dave Santoro <dsantoro@google.com> |
Fixes and cleanup for transactions.
- Make the thread-local transaction shared between the contacts and
profile providers (as the implementation intended).
- Remove a bunch of extraneous variables from the contacts provider.
- Ensure that the profile provider switches the delegate into profile
mode before running onBegin() or onCommit().
- Port the fix for applying contact changes to the profile DB.
- Fix an issue with profile aggregation after the profile has been
deleted.
- Addressed a case in which we would create (and possibly hold onto)
a profile DB transaction erroneously.
- Ported fix for aggregation when raw contacts are deleted.
Bug 5320369
Change-Id: I1f36d4c87c6b655dfcb5e339f151d3bf1d37a437
/packages/providers/ContactsProvider/src/com/android/providers/contacts/ProfileProvider.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/src/com/android/providers/contacts/ProfileProvider.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/src/com/android/providers/contacts/ProfileProvider.java
|