| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: If3afb134ea36bd93859efcd114885526e1592b91
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Bug 6148750
Change-Id: If63219745973aa2629b95259ec692867f5197e79
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Replace raw_contacts.last_time_contacted with data_usage_stat.last_time_used
if it's bigger.
Bug 6326418
Change-Id: I052a7fb92e69cf35f8e37a9be1b074f480e96071
|
|
|
|
|
|
| |
Bug 6245089
Change-Id: I4fe92fbf190090b6e25a411c8c0e2f9885564952
|
|\ |
|
| |
| |
| |
| |
| | |
This reverts commit c624ff13d5df4848a6ec605e25ea8469dd677d5d
Due to b/6123232
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| | |
Bug 6239243
Change-Id: Icf473e5178a76fda66b33fc11875f00d87b36c16
|
|/
|
|
|
|
| |
Move aggregator related classes into it.
Change-Id: I712fe07ad2bab1e532e3822e3e2797a199329865
|
|
|
|
|
|
|
|
| |
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
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Bug 6026073
Change-Id: Ic6057aa2347d1fa4c245ad2f6644ac4d5e8ae3cf
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
| |
Bug 5884869
Change-Id: I2cbec01766883a469fb5558306d6a9b7745845b8
|
|
|
|
|
|
|
|
|
| |
The account ID column didn't exist at this point, so we should skip the
cache initialization.
Bug 5868343
Change-Id: I5fd479f882abbce2be7bf1278656e8e4b83bc106
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
When I added hasColumn I didn't realize there was already a similar method.
Bug 5545880
Change-Id: I9ba62a9ff8b3eeab8098626426a37fd84c77d679
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
| |
Also allow prefix search on name
Bug:5337763
Change-Id: I039264be0c8309224d8925ded06ab02a64a5ce1b
|
|
|
|
|
| |
Bug: 5316982
Change-Id: I2870778c8056468730d82794ddae90c74cab85fc
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Bug:5229241
Change-Id: I57cda04dbe65afc4b05ddd46dda94b812d0df6bc
|
|/
|
|
|
|
| |
Bug 5242084
Change-Id: I7c8d00701a5a20c97556bf523faf4c4b9fb8a49a
|
|\
| |
| |
| | |
number."
|
| |
| |
| |
| |
| |
| |
| | |
number.
Bug: 5197612
Change-Id: Ia38f097e1e1e8ecad9c41a15d5c7593807d13571
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Bug:5134325
Change-Id: I214f5750a9c445b2bca0cc6a448463c38519bfa1
|
|\
| |
| |
| | |
changes"
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
changes
Original CL submitted by Google TV
Bug:4485628
Change-Id: I1d964bd153cc4de1b5543970bbfd89ff89587451
|
|/
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Bug:5134325
Change-Id: Id5159a24c9a2aee58e566b9bc03719e7a6ee0f7c
|