The first of these cases seems like they should already have been
present, and the last couple allow you to switch pages by hitting
arrow keys on the edges of the hotseat.
Bug: 25589939
Change-Id: I9378b209250f7dc376fa97efde979bcee2979537
The All Apps button creates a number of edge cases, mainly because it
causes the hotseat to sometimes have an extra column than the workspace.
Previously, we sort of swept these problems under the rug by simply
ignoring the All Apps button if other icons were present in the hotseat,
with the assumption that those other icons should get focus instead of
the All Apps button. (If possible, we want to stay in the same column
when moving from the workspace to the hotseat.) But this doesn't always
work, as in the attached bug where the hotseat doesn't get focus at all
when the All Apps button is an obvious candidate for it.
By adding a specialized column in the focus matrix for the All Apps
button, we ensure that moving down to the hotseat stays within the
original column when possible, while also allowing the focus to switch
to the All Apps button if appropriate. Furthermore, we take care to skip
over the All Apps column when necessary in order to maintain all
previous functionality.
Bug: 25590522
Change-Id: I5d6a8ee69de8834314c4689246fe7d54329b2eef
There's a case where hitting the left/right arrow in the first/last
column wouldn't give focus to an icon on the next page because it is
vertically too far from the first icon to be considered. This makes
for a bad user experience, because there is no way to switch pages
with the keyboard. So now we brute-force search for an appropriate
icon if none was found in this case.
Bug: 25434120
Change-Id: Ifdead0e3b458717ccb33e2f0ec7c15f1fcce4b95
> As of android M, the platform somtimes throws DeadObjectException
instead of TransactionTooLargeException
Bug: 25305031
Change-Id: I3a98db8a5041aef01640d16f9beb71b72bf598f1
When an icon grabs focus, it already snaps to its own page, so
the explicit snapToPage() is redundant. And in the case where no icon
will grab the focus, the explicit call puts us in a weird state
because the page snaps but the focus doesn't change (see bug).
(This happens, for instance, if you are moving from an icon on the
bottom right of page 1 and the only icon on page 2 is in the top
left. In this case, the second icon won't take focus because the
angle is too wide according to FocusLogic#handleDpadHorizontal().)
Bug: 25434120
Change-Id: I17b0ef7d86426a2599bc948bf2313dca7e112364
Since I62963d225e6ea5d2ec9d8ebc8a6d73099f5d6c7f, we have disabled
selection action mode in the folder-name editing mode on Launcher,
mainly because it messed up the view on phones. However that is no
longer the case in Android M and later, where floating action mode
is available.
With this CL, we start relying on the default floating action mode
in Android M and later.
Bug: 22210697
Change-Id: Ie19e7844194acd86cdb013254a1923f0b1d78e11
Clearing the focus was causing the first child in the new page to
immediately take focus, which caused FocusIndicatorView jank when
using a keyboard.
Bug: 25256728
Change-Id: I5ab31ebc3fe370d7ac9e9792b30dab3467023738
> Pressing 'enter' enters the focus inside the widget.
> If the widget has only one focusable, it directly performs click
> Pressing 'esc' brings the focus back to the parent host.
Bug: 25199581
Change-Id: Ia7fd5d929f5945d61173abd349660a5efbe74afc
- Seperate search bar height from its top and bottom paddings
- Report this height plus 8dps top and bottom for the widget options
- Use a separate bottom padding to adjust spacing between QSB and
the workspace
- Add tests to verify the height of the search bar in both normal and
tall modes (ran on Nexus 6, 7, and 10)
Change-Id: Ia7557785d1b38194eee869d0460456e8f33447d5
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
Tony Wickham
Sunny Goyal
Yohei Yukawa
Winson Chung