| 517d590dc73e5efcf7c94e2431faec2473924ca2 |
|
07-Jul-2017 |
Makoto Onuki <omakoto@google.com> |
Make CP2 low-ram friendly
- Switch to ArrayMap|Set
- No common nickname DB on lowram devices
- Don't use WAL for profile DB, ever
- Don't use WAL for contacts2.db on lowram devices
Bug 63340057
Test: adb shell am instrument -w -e package android.provider.cts.contacts \
android.provider.cts/android.support.test.runner.AndroidJUnitRunner
Test: bit ContactsProviderTests
Change-Id: I16a6b41762874590c487ac82020bd1da7d7c0a0a
/packages/providers/ContactsProvider/src/com/android/providers/contacts/TransactionContext.java
|
| 87a9fc205e3d8a61c5e53d1d281e27728b615e20 |
|
23-Dec-2015 |
Tingting Wang <tingtingw@google.com> |
Fix bugs on Lychee CP2 part.
1) If backup_id is updated (or created by sync adapter), re-notify
metadata network if there's dirty change before.
2) If backup_id is created by focus sync adapter and there's metadata
in metadata_sync table, merge them for the new backup_id.
BUG 26310045
Change-Id: I8af3e67564bd387b2417ceb6ccc353e51ff57dcd
/packages/providers/ContactsProvider/src/com/android/providers/contacts/TransactionContext.java
|
| 08fb8384ccb36de3d3d046e287fe5c43c1f85faf |
|
07-May-2015 |
Zheng Fu <zhengfu@google.com> |
Notify contact metadata changes to contact metadata authority.
Need to notify metadata changes in the following senario:
1. raw contacts insert/update with column pinned,starred or send_to_voicemail
2. data usage stats update
3. aggregation exception update/insert
4. data delete, or insert/update with is_primary or is_super_primary column
Bug:20893997
Change-Id: I7ca6ae4c1a96baa9bb887ec11869d4194398ae64
/packages/providers/ContactsProvider/src/com/android/providers/contacts/TransactionContext.java
|
| 8ed367fdc0b086d54c489f68d555e2f0a4035f63 |
|
12-Mar-2013 |
Chiao Cheng <chiaocheng@google.com> |
Adding contacts delta api.
Updates and inserts can be detected through the use of a new timestamp
field in the contacts table.
Deletes can be detected by querying the new deleted_contacts table.
Bug: 8182147
Change-Id: I5c1e596f4e1aa58528afc29396f79cb4051e229c
/packages/providers/ContactsProvider/src/com/android/providers/contacts/TransactionContext.java
|
| 0992b9d4969ed0eee6e879db94292b635229e2b7 |
|
11-Apr-2012 |
Makoto Onuki <omakoto@google.com> |
New aggregation logic
Now a raw contact can be merged into a contact containing raw contacts from
the same account if there's at least one raw contact in those raw contacts
that shares at least one email address, phone number, or identity.
Now the aggregation logic version is 3.
Also:
- Make sure changes to the identity triggers aggregation.
- Stop re-using some HashMaps/HashSets, as they don't shirink the internal
table when clear()ed. During the aggregation update we may put a bunch of
stuff into those, and we want to make sure that we don't keep unnecessarily
bit internal tables after the upgrade. This should be okay with the modern
dalvik GC.
Change-Id: I855085d334679363cf9bffb918ca2ceb0cfe77f5
/packages/providers/ContactsProvider/src/com/android/providers/contacts/TransactionContext.java
|
| 9d990d339c9e3a9e03f6fe13c260d36665f00e61 |
|
16-Dec-2011 |
Makoto Onuki <omakoto@google.com> |
Account table refactoring
- 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
/packages/providers/ContactsProvider/src/com/android/providers/contacts/TransactionContext.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/TransactionContext.java
|
| 43368a3f9e05a979e454e278d6a0e8475f08923d |
|
13-Jul-2011 |
Dave Santoro <dsantoro@google.com> |
Provider and DB changes to support data_set field.
The intent of the data set field is to provide a way for multiple
sync adapters from the same account name + type to manage separate
sets of data in the raw_contacts and groups table.
For example, this would allow for Focus groups to be synced in from
Focus via the Google Contacts sync adapter, and for Google+ Circles
to be synced in from the Google+ app, even though both are tied to
the same account name + type.
Bug 5077096
Change-Id: I641c5d233d8d4d70988d209179c4e79bdb9c7ea1
/packages/providers/ContactsProvider/src/com/android/providers/contacts/TransactionContext.java
|
| 24c1d384b45a6d3c1cc959062a9d4308335fabbf |
|
28-May-2011 |
Dave Santoro <dsantoro@google.com> |
URIs and queries to support profiles.
This change includes:
- A database upgrade to support tracking whether a contact represents the
user's profile (represented as an optional raw contact ID specified
per-account, and looked up in the various views).
- New Contact Provider URIs for retrieving profile-specific data:
- profile: To retrieve the user's profile contact.
- profile/data: To retrieve data for the user's profile contact.
- profile/data/#: To retrieve data for a specific data entry for the user's
profile entry, by data ID.
- profile/entities: To select entities for the user's profile.
- profile/as_vcard: To retrieve the profile as a VCard.
- profile/raw_contacts: To retrieve or insert raw contacts for the user's
profile.
- profile/raw_contacts/#: To retrieve a specific raw contact entry for the
user's profile, by raw contact ID.
- profile/raw_contacts/#/data: To retrieve data for a specific raw contact
entry for the user's profile, by raw contact ID.
- profile/raw_contacts/#/entity: To retrieve raw contact entities for a
specific raw contact entry for the user's profile, by raw contact ID.
- Permission checks to ensure that any access to profile data (whether
explicitly through the above URIs or directly via ID) enforces READ_PROFILE
or WRITE_PROFILE access.
- New and updated tests (including permission check cases for all of the above,
plus query checks for each).
I've also had to move a few large tests to medium to work around
b/3329504. I've also removed the database close step from contacts provider
test teardowns, as it doesn't seem to be necessary, and results in almost a 3x
performance boost on test runs.
Change-Id: I220552c26ad1eb3fbf24fdd865df2fe59fe4a688
/packages/providers/ContactsProvider/src/com/android/providers/contacts/TransactionContext.java
|
| bd9abbb6b03b4ec1e28ad3fa2fcba5d1eb8609ea |
|
10-Feb-2011 |
Dmitri Plotnikov <dplotnikov@google.com> |
Full text search: updating search index on change of visibility
When a contact becomes invisible, the search index will
be cleared. When it becomes visible, the index will be
built.
Bug: 2078420
Change-Id: I1eea88d3d9babc891d112d15d9041d01c383f22f
/packages/providers/ContactsProvider/src/com/android/providers/contacts/TransactionContext.java
|
| f262d56495ac4ea30d31bd050efb116bd4bb4235 |
|
08-Feb-2011 |
Dmitri Plotnikov <dplotnikov@google.com> |
Full text search: adding internal provider API.
Also, adding the very first data type to FTS: organization.
Bug: 2078420
Change-Id: I64d6f6a63efc838c4c2c80d4311bcc23bae23a67
/packages/providers/ContactsProvider/src/com/android/providers/contacts/TransactionContext.java
|
| d364d74ce9cc677c10362b8686d7c33fafe78beb |
|
01-Dec-2010 |
Dmitri Plotnikov <dplotnikov@google.com> |
Introducing a TransactionContext object to hold state for a single TX
This is another step in preparation for turining
DataRowHandlers into top-level classes.
Change-Id: I43cfad5cebcebd5e3c51000d1732e778f400d238
/packages/providers/ContactsProvider/src/com/android/providers/contacts/TransactionContext.java
|