diff options
| author | Ben Murdoch <benm@google.com> | 2012-05-14 16:39:50 +0100 |
|---|---|---|
| committer | Ben Murdoch <benm@google.com> | 2012-05-16 18:05:38 +0100 |
| commit | 234eadcf7d0dbf2d24f92c24f40343d518f6fe3a (patch) | |
| tree | 3c06d8f77a653ef05940c049c549826ebca0569d /src/com/android/browser/Controller.java | |
| parent | 54217b39d7d097f2f4fe9fac928a1c3bf1b9f13f (diff) | |
| download | packages_apps_Browser-234eadcf7d0dbf2d24f92c24f40343d518f6fe3a.zip packages_apps_Browser-234eadcf7d0dbf2d24f92c24f40343d518f6fe3a.tar.gz packages_apps_Browser-234eadcf7d0dbf2d24f92c24f40343d518f6fe3a.tar.bz2 | |
Don't wait on ContactsProvider
Right now during the initial WebSettings sync to native we wait
for the autofill profile to be loaded from disk so that it can
be synced. If there's no profile set, then we try to infer a
profile from the user's Me contact profile. Querying the Me
contact can be slow and in some extreme cases can cause the
settings sync on the UI thread to block long enough to show
an ANR.
Instead signal the threads (via the CountdownLatch) waiting on
the initial import before we do the Me profile lookup. Note that
we still may block the UI thread if the lookup of an already saved
profile takes an exceptionally long time. This is so that when a
user has saved a profile, we'll never resort to showing them the
"setup autofill" message. (But all ANR reports to date have shown
that we were querying the Me contact at the time of ANR).
Bug: 6371781
Change-Id: Ibb0d5e285ec3587d9f9bad3e69b79890850c2f6d
Diffstat (limited to 'src/com/android/browser/Controller.java')
0 files changed, 0 insertions, 0 deletions