d2726582f135383e56661bc41d750966642dab45 |
04-Feb-2013 |
Maggie Benthall <mbenthall@google.com> |
Fix for SettingsProvider to query for correct user. insertForUser takes a specified user and attempts to adjust that user's settings, first looking at their existing settings to determine the difference. However it was querying the settings for the calling user, rather than for the user whose settings were being changed. Also add a test that exercises the fix. Change-Id: I6ed6fd79154ac1b6e6ab880769ac9081dfff6b80
ettingsProviderTest.java
|
78d2a66ac12e4c8f1303225514f573fb53af1dd9 |
14-Sep-2012 |
Christopher Tate <ctate@google.com> |
Fix Settings writes to a different user Oops. Stacked bugs: first, the desired user handle was not properly being passed from the call() entry point to the database operations; then on top of that, the client-side cache management was still looking in the local user's cache for the data, so a request to read a different user's settings would return the local user's instead if that key was already known to the local user's cache. Reads and writes of a different user's settings are now uncached, so they're relatively much slower. They're rare, however, so this is not something to worry about unless we encounter a real world case where it's a significant factor. This CL also adds a bit of cross-user settings read/write testing to the existing provider suite. These new tests caught both the known wrong-user-write bug and discovered the client-side cache bug, so yay. Finally, the existing wholesale mutual-exclusion approach would deadlock in certain circumstances due to the fact that the settings database creation code might have to call out to the Package Manager while populating the bookmark/shortcut table, and the Package Manager would then call back into the settings provider in the course of handling that request. The synchronization regime has been significantly tightened up now: now the database code [which is known to deal with concurrency itself] is allowed to cope with multiple parallel openers of the same db; this allows the settings provider to avoid calling out to other parts of the system even implicitly while its internal lock is held. Change-Id: Ib77d445b4a2ec658cc5c210830f6977c981f87ed
ettingsProviderTest.java
|
fe62e31914bef645851e11418ddaee279c845e99 |
18-Aug-2011 |
Brian Muramatsu <btmura@google.com> |
Test for Settings Intent Bug 4983978 Change-Id: I4d366bbcacdc12e5d86d22f5fab0e934e4ef66db
ettingsProviderTest.java
|
553a53ef9ff789dff8b5a74dfea4d6f37feeb263 |
04-Nov-2010 |
Ficus Kirkpatrick <ficus@android.com> |
Make saveRecentQuery() async. Bug: 3163612 Change-Id: Idd3c1925e0f1dc3272dd1303d8f2907c5c5fca8b
earchRecentSuggestionsProviderTest.java
estProvider.java
|
c2591c14f77366f30cc83e9c6a2abf9d9cd12a5e |
22-Apr-2010 |
Kenny Root <kroot@google.com> |
Add tests for SettingsProvider.parseProviderList Change-Id: Id5c1597cd94b80e0d20ca415b5b7ba32200c1a03
ettingsProviderTest.java
|
d0ca3379c2dd0f987af328baa3fdad69d0a8d70a |
08-Mar-2010 |
Amith Yamasani <yamasani@google.com> |
Fix a SettingsProvider test : 2377540
ettingsProviderTest.java
|
1a44d5dcabc18cd5ef111f732ccff91683a1a093 |
13-Jan-2010 |
Neal Nguyen <tommyn@google.com> |
Phase 2 of test cleanup: moving test files from AndroidTests closer to their sources. Most of these are file moves; a couple notable exceptions are the changes due to the move, and fixing up test code: - database/DatabaseCursorTest.java - database/DatabaseStatementTest.java - net/UriTest.java
ettingsProviderTest.java
msProviderTest.java
|