updates into that thread as well.
This gets rid of the ANRs that happened because both threads were
holding mAllAppsListLock. Now mAllAppsList should only be touched
from within the worker thread.
Change-Id: Ifc4ac27e0c0a927ac66c456d097fd3d4ef6c5e1e
set from the ui thread.
This will help the ANR in LauncherModel.onReceive because if
we're under contention, there's a good chance that we haven't loaded
yet. It won't completely fix it, but that will take a large refactoring.
Bug 2672967
Change-Id: I2c97a416767b4bb6aac0252f02e2aa2055ae8a4e
This always reloads the workspace, because I think it's a less risky change and that only adds
~100ms.
Change-Id: I215b1f741f022e47ce06e78b9cfdd9967a8f1b9d
This change reorganizes the increasingly Byzantine loader
thread so that the order of (workspace, allapps) can be
reversed if the user is currently looking at the all apps
view. The perceptual improvement in performance is huge if
you change the Launcher's orientation while All Apps is
visible (which forces a reload/bind of everything); now that
AA doesn't have to wait behind the workspace it
(specifically, its first batch of icons) appears much, much
faster.
Bug: 2722977
Change-Id: I07a9afd5f1cff4019f2640b082872176ba0a887e
Should the Launcher's database become corrupted by
mysterious forces (e.g.: third-party launchers; botched
upgrades; smoke monsters) in such a way as to cause two
items to share the same cell, we now ignore loading the
latter.
Prevents a runtime crash (http://b/2655516).
Bug: 2655516
Change-Id: Ia514746f04f0e51b2cd07e9290589a6eab75bdd2
* Removed another redundant sort
* Correctly set the thread priority to BACKGROUND for the
all apps loading step.
* Moved batch delay to a resource
* Reduced delay between loading batches of apps to 100ms
(we really just want to sleep a tiny bit between batches
to give the UI time to react)
Bug: 2562420
Bug: 2599979 (related)
Change-Id: I1ae72a68c1a47377a9eb62827fe7666bfc50caa5
AllAppsList now maintains <data> and <added> in sorted
order, to amortize the cost of sorting the apps list over
multiple batches.
Launcher boosts thread priority on first launch, but we now
reduce thread priority to normal after the main workspace
has been drawn but before all apps are loaded.
Experimental feature: a short delay is introduced between
batches to help free up the CPU (as well as to show that we
are indeed batching apps).
Bug: 2562420
Change-Id: I2035ec3e819b4e7993a80c6d03bfad3914c95a7a
used for the workspace.
Consolidate the three icon resampling functions into one.
Ensure that the icons stored in LauncherProvider are the right size, so we don't have to resample
them each time we load them.
If we haven't even initialized yet, don't respond to app list changes.
I think this will fix that bug. It's possible that there's some other race in there somehow.
I think what's happening here is that when there is a configuration
change, we were restarting the launcher process because the driver
would hang. But now that that's fixed, we need to poke the model
to reload the icons. We were missing the bind apps call.
