There is a race condition that occurs primarily (maybe entirely) with
Android Auto, it seems because they hijack the Home intent or something
similar. I'm not exactly sure how Android Auto works, but if I pair my
phone with the Desktop Head Unit (car dashboard emulator), I can repro
the NPE fairly easily by simply force closing Android Auto and then
disconnecting my phone from the DHU. If I don't force close Android
Auto, then pressing home launches Android Auto or other apps that I
assume handle some custom intent, such as Car Home Ultra, instead of
normal Home intents such as Launcher3/Google Now Launcher. So I think
what's happening is that, when the phone is disconnected from the car,
Android Auto restores and launches the real home intent (Launcher 3)
around the same time that it destroys the previous home intent
(Android Auto, Car Home Ultra, etc.). This could cause the NPE if both
intents are actually Launcher 3, as is the case when Android Auto is
already closed, because mWorkspace is set to null in
Launcher#onDestroy() (something like onNewIntent() --> post() called
--> onDestroy() --> post() runs). This is consistent with the fact
that I can guarantee a repro if I use postDelayed() instead of post().
Long-winded explanation aside, I think this fix is safe, especially
since we already have a null check for mWorkspace in onNewIntent(),
just not inside the post().
Bug: 24610231
Change-Id: I42f75b83946f375d947be1961a1f2a03a3707a84
Previously, any child of ShortcutAndWidgetContainer was added to the
matrix, causing widgets (which aren't focusable) to be considered as
potential targets to gain focus when an arrow key was pressed. But if
the algorithm chose them, they couldn't take the focus so nothing
happened (i.e. the focus stayed on the app/folder it was on before).
Bug: 25126768
Change-Id: Id55fc310f7f58fb8795cce51dcefe4fd1210f788
This ensures that the QSB widget options are set correctly the first
time they are used.
Bug: 24704753
Change-Id: I2bb13ff012b6f13ca076deed61f0b08a7037e2fa
The problem was due to a race condition between removing a prebound
widget view from the drag layer and adding the same view to the
workspace upon dropping it; if you let go of the widget immediately
after picking it up, the latter happened before the former.
Specifically, the flow was: long-click a widget --> drop --> remove
the view from the drag layer if it's not null (it is, so nothing
happens) --> the view is finally bound/inflated and added to the drag
layer --> add the view to the workspace --> already has a parent.
There are actually 2 problems here: one is that the bind/inflate is
asynchronous, and can therefore happen after dropping the widget view
being inflated, and the other is that the view is added to the
workspace even though the transition has barely started (we usually
ignore drops if the transition is less than half complete). It turns
out that this second problem was also due to a race condition, this
time between dropping a widget or app onto the workspace and calling
LauncherStateTransitionAnimation.dispatchOnLauncherTransitionStart().
If the drop happened before the dispatch, as in the case of the
crash, then the drop was accepted because the transition progress was
still 1.0 from the previous transition.
I fixed the first problem by removing the drag layer widget view
in Launcher where it is potentially used instead of Workspace. And I
fixed the second problem by setting mTransitionProgress to 0 in
Workspace.onLauncherTransitionPrepare().
I also added some debugging logs.
Bug: 23896857
Change-Id: I66944e6d3f23b70dea15f7fb01af0763a1bfcbda
There are 3 animations that 3 different transitions use; to prevent
future problems, let's put them all in one place. For instance,
ag/781127 added dispatchOnLauncherTransitionStepAnim() to the two
transitions that existed in burnaby-polish, but not to a third,
startAnimationToNewWorkspaceState(), that was added in master. If a
common method existed in polish, the new animation would have merged
into master automatically instead of forcing us to remember to add it.
Change-Id: I7775aaa43a08ae8b8241b0eeb77b6c84167c5ff0
The increased breathing room makes it more likely that long app names
will fit in the folder cells without being cut off.
Bug: 22462641
Change-Id: I110ede040f9e8fdddbf0c4e7a395ac71435559f3
The search bar can now be be normal or tall. When it is set to tall,
the hotseat and page indicators move down so that the workspace isn't
compressed quite as much.
Change-Id: Id92a946eab3a93524999f92efd847a501a95f002
Sunny Goyal
Tony Wickham
Winson