Bug: 161594550
TL;DR;;
- draging an item closes the IME
- clearing a searchbox to empty string has no effect on IME
Change-Id: Ic3a91d1b22434dcb78347dd8b12b5ceab14eb928
This would allow adding different source for model items without
modifying every model task
Bug: 160748731
Change-Id: I5a14dd761e2b8696c58dc8fec7b14077da0aced3
- Calculate work profile switch height and apply it as a padding to recyclerview instead of reading height from view.
- Add solid background to work_apps paused overlay for improved crossfade animation on pause/unpause
- Don't show work paused overlay text in landscape mode
Bug 151672365
Bug 153763804
Bug 151595687
Test: Manual
Change-Id: I6c14a8a1624455181d4998555bcc3ae2bb422efe
> Launcher uses realSize, availableSize and insets to calculate
various layout values. Without drawing behind cutouts, these values
are not consistent (insets + availableSize != realSize) leading to
jumps in layouts.
> Removing fake black bars in low-ram devices to avoid inconsistent
insets.
> Fixing various layouts not taking lert/right insets into account.
Bug: 156268804
Change-Id: I8441db8a468b08a65b57b932050b5b4b37313966
- hide overlay icon in landscape mode
- don't show edu if user has already seen legacy work profile edu
- make sure personal tab is highlighted when work profile is reinstalled
- always go home after a work profile is added or removed
- add tests for work edu flow
Bug: 150122946
Test: Manual
Change-Id: I8f80ac763acf03ca31a534464f4ddfd84528d329
Instead of creating a fixed number of targets, we now pass an ArrayList
of targets to. Any class implementing
LogContainerProviders#fillInLogContainerData can setup it's own target
and add it to the ArrayList, It can also pass the ArrayList to other
LogContainerProvider to capture full Target hierarchy.
Bug: 147305863
Change-Id: I0063c692120fb9e1cff2d8902c5da972d0623418
This includes
- Dismiss work edu on launcher state change
- Remove work tab flash on first setup
- Make edu bottom sheet adopt theme color
- Fix Work toggle bottom inset
Bug: 149200572
Bug: 149197172
Bug: 149199058
Bug: 149215103
Bug: 149198955
Bug: 145595763
Bug:149481723
Test: Manual
Change-Id: I39a30782b80fd3a66bede55754fa30a940d2caee
Extremely rarely, All Apps will get stuck in a non-updating state even
after the interaction ends.
It would be impractical to try drilling to the root cause of this,
so it's better to just allow All Apps updates while the user interacts
with it.
Bug: 139384936
Change-Id: I2ed7fb052da77a9e47ef9b9aa7800499071b98c3
This would fix the issue that when drag and drop an icon from the all apps
page, it doesn't have the right container information logged.
Logging after this fix:
07-11 10:57:04.392 12969 12969 D UserEvent: action:DRAGDROP
07-11 10:57:04.392 12969 12969 D UserEvent: Source child:APP_ICON parent:ALLAPPS
07-11 10:57:04.392 12969 12969 D UserEvent: Destination child:APP_ICON parent:WORKSPACE id=0
07-11 10:57:04.392 12969 12969 D UserEvent: Elapsed container 744 ms, session 17440 ms, action 739 ms
Test: manual
Bug: 111935715
Change-Id: Ifb078e57697b051e3a527c16abaad40663eae687
This CL adds a very low risk because most (but not all) changes affect
only Launcher behavior during the test.
This should fix a lab-only flake when all apps keeps changing while
the test is working with it.
Example: test figures out which icon to click, by the moment it clicks
there, there is another icon there, or the icon is under the search box,
and clicking opens IME.
Switching test devices to airplane mode didn't help. The earlier change
that prevents popup menu cancellation is not general enough.
Now the tests are given an API to explicitly freeze and unfreeze
all-apps, which should be a final solution.
Bug: 132900132
Bug: 133765434
Change-Id: I8b81cc9be004482beb6cdcdd05406e2d9b4c7629
Normally, if all apps is open, and an app installs/uninstalls/updates,
All Apps will immediately reflect this.
However, depending on something subtle in the intensity of the swipe
gesture that brought All Apps, all apps will freeze, and won't update.
This frozen state will go away after scrolling in all apps, iteration
with an icon and, generally, any tap interaction with All Apps.
Otherwise, it will stay until it's closed and opened again via a gesture
with a different pattern.
The reason is in the code that freezes All Apps updates during user
interactions with all apps.
For example, during scrolls. Or while the user holds an icon, expecting
to see a context menu; in this case an update would cause the menu to
not appear, which is somewhat annoying.
The motivation to add this code was to solve a category of lab-only
flakes when a context menu couldn't open because the lab device was busy
with post-flash activities.
The code incorrectly assumed that after ACTION_DOWN, we are guaranteed
to get either UP or CANCEL, which is wrong.
It's after *consumed* ACTION_DOWN that we'll get these events.
The fix still solves the user's and tests' problems that the code was
supposed to solve.
Bug: 134442147
Change-Id: I9db74a33ecf93b1dc6bc69df301f7f542dea2a40
=> After the scrubber was engaged, it would continue to intercept touches forever
(seems like a long standing issue)
=> Also fixed issue where the All Apps scrubber could be engaged from the Home / Overview
states
b/133265591
b/132716177
Change-Id: I8c7b9d45be65216f2f1a69f69ab1636accd812c0
Insets are dispatched to all views. We never consume the insets and
let each view decide what to do with it.
Also fixing scrim in all-apps when in full-gesture navigation
Change-Id: Ib1c6bef5b32aac0c6ea03078b5138d2d0408c6d8
This is supposed to eliminate test flakes in the lab.
When an app gets updated while all apps is opened, all-apps will be
re-laid-out.
If the layout happens while we are recognizing a long-press on an app
icon in all Apps, the long-press won't be recognized.
In the lab, this happened so frequently that it caused considerable
flakiness. Even after we started running tests in airplane mode, this
still keeps happening. The bug refers an example with airplane mode on.
The fix will be also mildly beneficial for users.
Bug: 132177321
Change-Id: Ie7c7473fe94b8af83f04cd719286bae69e2d9de0
This hides the quick search bar and the suggested apps. Visibility is
unchanged when the all apps view is fully expanded.
Test: Tested locally
Change-Id: I6bc453b5ad89ca3d1280957e595bf2a3f074a72d
BUG:129755311
FIX:129755311
(cherry picked from commit 917af755e4)
When a user created a work profile and was already in the All Apps
view, the work tab was not highlighted, because the logic for that
was only in AllAppsContainerView#onScrollUpEnd(). This CL
highlights the tab when the user has resumed and the All Apps view
is expanded.
Bug: 79242814
Test: Manual
Change-Id: I40af0d513c95f8084e21f4e276e9f56bcb06555e
All tests keep passing.
WorkTabTest.workTabExists was made gesture-stable. There is no need to
use TAPL, as the point is not to check answering to gestures, but to
check presence of tabs, which is better to do using launcher internal
state. (It still fails if run as a part of all tests, presumably,
because after Launcher's start, changes in user configuration are not
recognized, so I've commented the failing part)
Bug: 110103162
Test: Run all tests
Change-Id: Ic30b8e8475d16cee3880332f12311a44ddfa26cb
Done by scrolling only when scroll position is not zero. This way, the
scroll gesture can't close All Apps.
Bug: 110103162
Test: TaplTests suite
Change-Id: Icfe47d2bcc0210ae221df169d6c35cd1be10ff86
