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
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
To do this, we invoke resolveActivity to see what activity
would result from viewing an arbitrary (but valid) URL. If
there's just one installed, or there are multiple and the
user has chosen a default handler for http:, we take that
component and launch it with CATEGORY_HOME (so as not to
upset the URL in the frontmost window/tab/what-have-you).
We also use this information to extract the localized name
of the app, which is then installed into the hotseat as the
contentDescription (for accessibility).
If there's no default and multiple options are availble,
we'll get the activity chooser instead. In this case, we
just fire off that chooser and let the user pick an app
(possibly setting a default along the way). Because the
default may change, we reload all this hotseat information
every time one of the hotseats is tapped.
Another side-effect of this approach is that until there
exists a default browser, the original URL will be sent to
the activity the user chooses from the ResolveActivity. So
we need a sensible default URL here; one can be found in
R.string.default_browser_url (similar to Browser's
R.string.homepage_base).
This change also moves the hotseat intents and icons into
arrays.xml for easier configuration.
Change-Id: I06268df8b59e0f41f1f8b0e47f823db4c44ec761
The hotseats are permanent slots on either side of the
AllApps button. Their functions are:
LEFT/BOTTOM: Phone
Launched via the hardcoded class name
com.android.contacts/.ContactsLaunchActivity.
RIGHT/TOP: Browser
Launched by querying to see which application is the
default for URLs, then starting that activity directly.
In the future, it would be ideal to allow an application
with permission to access LauncherProvider to customize
these (icons, contentDescriptions, and Intents).
Bug: 2559083
Change-Id: I56f6e745f8574aa17e28feaa9d2118fb4a715cd4
This way we can figure out how many apps to send to the grid
at a time even if the grid hasn't been instantiated yet.
Bug: 2599979
Change-Id: I7960fe1adae6976555334422335f3a4b28d0675e
The mNext* stuff in AllApps3D got reset when onNewIntent came in too fast after an
onCreate, which happened because of the configuration changed.
Change-Id: I9a358b6969ac1d17ea98f58218d47bfe983936f0
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
Somebody fixed a bug in managed dialogs where it wouldn't
create the dialog after a configuration change. This means that we
shouldn't set mWaitingForResult in createDialog, we need to set it in
onShow. This is what the add dialog was already doing.
Change-Id: I955c2f7cd4a47213f84986ec9ba251146b1ac423
Bug #2504556
This solves the issue by keeping the GL context, the RS context and
the RS scene around, across orientation changes.
Change-Id: I8e3dc6e6bf039087046d49d2826c8800c5bef582
AllAppsView is now the 2D, GridView-based version (very
similar to classic Launcher); AllApps3D is the
RenderScript/Rollo implementation.
TODO:
- some mdpi assets are not in fact mdpi
- related to above: static wallpapers not working yet
- add dynamic selection of 2D/3D AA; currently you must
choose one at build time by picking the appropriate class
in all_apps.xml (see separate CL for sapphire overlay
that does this)
Change-Id: I253d98404ea8a329a4049d2e48edd2e5129fa6ba
When in UTS test mode keys received need to be handled
by the Phone application or Contacts application to
operate properly in the test mode. When not in test mode
the search widget will handle the keys as it was before
this change.
The UTS test mode is enabled when presist.sys.uts-test-mode is 1.
bug: 2402366
Change-Id: I58e68830f9ce6905e189ecba1c04b1076799a0a0
Signed-off-by: Wink Saville <wink@google.com>
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.
The SOURCE (search source identifier) constant is moving
from hidden in android.app.SearchManager to com.android.common.Search.
Part of http://b/issue?id=2429556
Change-Id: I68fa792f2d452aadcb9216f5c780bd082ca5039f
Before, Launcher relied on a callback to a SearchManager.OnCancelListener to clear the search widget
animation. However, that doesn't get called if some other app opens the search dialog
before the Launcher is reopened. This change clears the animation in onResume().
Should fix http://b/issue?id=2246760
Activity#showDialog on CreateShortcut
I'm not sure how this can happen, but I think it's okay to just
drop the exception. It's all just trying to clean up anyway.
Now:
- When you're on the workspace and you press home, it animates back to the middle
- When you're in all apps and you press home, all apps animates out and the workspace
doesn't animate to the middle (it just jumps there)
- When you're in an app and you press home, it doesn't animate to the middle
- When you're in an app and you press back, it still goes to the page you were on.
Don't look at the evil hack to make it move without animating.
still work
I knew it was a problem with mWaitingForResult, which I'm still not convinced we need, but
Jeff Sharkey was able to find repro steps, so he's my new hero. The steps were:
1. Open add menu (long pressing or menu > add)
2. Turn off the screen
3. Turn back on & unlock
4. Poof.
The problem was that when we get ACTION_CLOSE_SYSTEM_DIALOGS intents, we're dismissing the dialogs,
not canceling them. I think we actually want to cancel them, but there's no easy way to do that
with the Activity class, so just clear mWaitingForResult by hand in closeSystemDialogs().
Joe Onorato
Daniel Sandler
Romain Guy
Daniel Sandler
Wink Saville
Bjorn Bringert
Jason Sams