538413376d6608f1765e0913be72ff9c5c3c9891 |
|
25-Nov-2015 |
Makoto Onuki <omakoto@google.com> |
Show per-app CP2 usage in bugreport Note we don't persist the numbers, so they're number since CP2 started. Bug 24949200 Sample output: Client activities: UID Query Insert Update Delete Batch Insert Update Delete: 10010 2 0 0 0 0 0 0 0 10011 26 0 0 0 0 0 0 0 10048 185 3 3 0 9 1013 150 1 10057 37 0 0 0 0 0 0 0 Change-Id: Ia68ea8090cc569fb4483560944db126964875458
/packages/providers/ContactsProvider/src/com/android/providers/contacts/AbstractContactsProvider.java
|
f45c0a2612c7cdf6ee29242e65a30476537cc699 |
|
24-Nov-2015 |
Makoto Onuki <omakoto@google.com> |
Show basic contacts stats in bugreport. Bug 24949200 Example output: PROVIDER ContentProviderRecord{5b986d5 u0 com.android.providers.contacts/.ContactsProvider2} pid=18434 Client: Contact aggregator type: class com.android.providers.contacts.aggregation.ContactAggregator2 FastScrollingIndex stats: request=0 miss=0 (0%) avg time=0ms Contacts stats: Database: Contacts Accounts: 1 makoto.android.6@gmail.com com.google (null) 2 makoto.android.1@gmail.com com.google (null) 3 makoto.android.1@gmail.com com.google plus Contacts: # of visible: 2343 # of invisible: 3103 Max # of raw contacts: 3 Avg # of raw contacts: 1.001933612632936 Raw contacts (per account): 1 total # of raw contacts: 2018, max # per contact: 3, avg # per contact: 1.0009920634920635 2 total # of raw contacts: 1077, max # per contact: 2, avg # per contact: 1.0009293680297398 3 total # of raw contacts: 14, max # per contact: 1, avg # per contact: 1.0 Data (per account): 1 total # of data:15763, max # per raw contact: 15, avg # per raw contact: 7.811199207135778 2 total # of data:6887, max # per raw contact: 20, avg # per raw contact: 6.394614670380687 3 total # of data:95, max # per raw contact: 10, avg # per raw contact: 6.785714285714286 Database: Profile Accounts: 1 makoto.android.1@gmail.com com.google plus Contacts: # of visible: 0 # of invisible: 1 Max # of raw contacts: 1 Avg # of raw contacts: 1.0 Raw contacts (per account): 1 total # of raw contacts: 1, max # per contact: 1, avg # per contact: 1.0 Data (per account): 1 total # of data:6, max # per raw contact: 6, avg # per raw contact: 6.0 Change-Id: Iae9f1f904b623a4f64684da99b825b2cb1127758
/packages/providers/ContactsProvider/src/com/android/providers/contacts/AbstractContactsProvider.java
|
ac86c67dc61b46e5dd13d78438deae22dc64cdbe |
|
20-Mar-2015 |
Fedrik Ålund <fredrik.alund@mimer.com> |
Don't call notifyChange() until after the transaction have been commited. If we call notifyChange() before the commit have been done clients that are listening for changes will start reloading before the transaction is finished and this will lead to unnecesarry waits. Change-Id: I404bae39ace3d7557c4b48ccf4b757f3d986dbe7 Signed-off-by: Fedrik Ålund <fredrik.alund@mimer.com>
/packages/providers/ContactsProvider/src/com/android/providers/contacts/AbstractContactsProvider.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/AbstractContactsProvider.java
|
74e8f30b3a67af4defd8f73c503e794785671fee |
|
03-Feb-2012 |
Makoto Onuki <omakoto@google.com> |
Add debug logs to applyBatch Change-Id: I646c7e091c2e778516e6287e3e91770e556ad71f
/packages/providers/ContactsProvider/src/com/android/providers/contacts/AbstractContactsProvider.java
|
b91899a113c499ef96fe5719398558b4cfd128c2 |
|
01-Nov-2011 |
Dave Santoro <dsantoro@google.com> |
Fix double-close of transactions if yields fail. This was causing the exception that caused the failed yield to be swallowed instead of propagated, as the second close was failing due to lack of a DB lock on the thread. Bug 5515111 Change-Id: Ic847801655b28301913b07b3929794b3ba16c5ae
/packages/providers/ContactsProvider/src/com/android/providers/contacts/AbstractContactsProvider.java
|
376917cea44aec4dfd68dec23522353b142535fd |
|
06-Oct-2011 |
Dave Santoro <dsantoro@google.com> |
Allow multiple inserts in bulk between yields. This should help to optimize these operations to avoid the overhead of doing lots of individual inserts when the database is very active. Bug 5353552 Change-Id: I5b3a06f41637452ec98297c66579fb7d4f81e2ec
/packages/providers/ContactsProvider/src/com/android/providers/contacts/AbstractContactsProvider.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/AbstractContactsProvider.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/AbstractContactsProvider.java
|