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>
It looks like the evil hack in 14f122bf84 to make the workspace
not animate didn't completely work. The key to reproducing this bug is to make sure the
activity is destroyed and to have last gone to an app from a screen other than the center
screen, because that causes it to get reloaded from the icicle, which makes the timing
more amenable to missing the animation, because the view isn't attached yet.
This marks the apps list as dirty by default. Usually, because of how long
it takes the loader thread to run, the apps list comes in after the surface
has been initialized. However, if the surface isn't around yet when setApps
is called, then setApps won't set mRollo.mAppsDirty because mRollo is null.
The extra null check is necessary for the normal case when mAllAppsList isn't
ready yet when the surface comes in.
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
Sometimes clearAnimation() is called on the search widget
when it has no parent, e.g. when it being removed from the
home screen. This caused an NPE, because clearAnimation()
called invalidate() on the parent.
This is a partial fix for: 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().
at the bottom of app drawer
This includes some contortions to get it not to perform the vibrate
haptic feedback then.
(By the way, it appears that we're vibrating on the add context menu
long press, so also do it when when we show the previews.
