Use `enable_expanding_pause_work_button` as an example.
See go/trunk-stable-launcher for implementation details
Bug: 294913042
Test: adb shell device_config put launcher com.google.android.platform.launcher.aconfig.flags.enable_expanding_pause_work_button true
Flag: enable_expanding_pause_work_button
Change-Id: I732722c8b219c023adf5bf31f132ce9da72fc4d5
* Hypothesis for why ALL_APPS isn't showing is that
directly navigating to it via state manager might have
some more hiccups (historically it has), so we do it
now via swiping up on workspace
Bug: 288152874
Flag: None
Test: Passes locally
Change-Id: I8ada7d3bde88fa54c9aab84012a9b0e3e045069e
* That's the bit that updates new packages for work profile,
at least from command line.
* There is variability in how long it could take work profile
apps to show up, from 2-8 seconds.
Bug: 243688989
Change-Id: I710befc5f17b4a16bff523eb03f1e88975cafd43
* There were two separate methods, which can run in
any order. Consolidate to reduce variability
Bug: 243688989
Change-Id: Ic924aa8a5d75505aecf6c830c63a85a0d2028d83
check if work profile is indeed set up
- after workProfile setup, added log of profile ID for each test..
- added CLI check for "start-user"
- Investigating where flakiness occurs because of failed
work profile account set up or test just fails
bug: 243688989
test: Tested where there is no shell command in setup and all tests were skipped
Change-Id: I131b62c1a929c2e550be111a3840fd93c7435860
Simplifying view type constants to make it easier to add new view types
Bug: 234008165
Test: Verified on device
Change-Id: I96589ceba362ea7e75afdfc3fe8da3be214aa682
Bug: 206905515
Test: Manually verified b/230648542 did not resurface. Tested
on phone and tablet with and without work profile.
Change-Id: If724f635286b9dff2c64255f9ece3568a5cb4ea9
This reverts commit 6729f0b950.
Reason for revert: This change caused b/230648542.
Please see https://b.corp.google.com/issues/230648542#comment5 for the video after reverting this change.
Bug: 206905515
Bug: 230648542
Change-Id: I85f063c56cad137c05b810204244bba7e8f94ee7
This will help enable transitions between A-Z apps lists and
search results because both can be seen simultaneously and
manipulated independently.
Some high level items of the refactor:
- SearchRecyclerView is added; logic that populated the main
(personal) tab with search results was simply redirected to
this RV instead.
- BaseAllAppsContainerView added isSearching() method. Returns
false, and ActivityAllAppsContainerView overrides (as search
is handled there).
- Renamed BaseRecyclerView to FastScrollRecyclerView to better
describe what it does. SearchRecyclerView extends this, but
returns false for supportsFastScrolling().
- AlphabeticalAppsList#mAllAppsStore is now optional, so the
Search RV doesn't need to store/listen to apps. Note this
doesn't affect the predicted app row which is still updated
if one of the predicted apps is uninstalled (I tested this).
Future work:
- Determine why dispatchRestoreInstanceState is not called for
BaseAllAppsContainerView. Save is called, e.g. on rotation.
Effect of restore not called: rotating while searching goes
back to A-Z list.
- Keep suggested apps in Header while searching. Currently they
are rendered in the SearchRV above search results, as before.
- Potentially extract Personal/Work tabs to move independently of
header.
- AlphabeticalAppsList is a misleading name because it can also
contains search results. However, things are pretty intertwined
between that and BaseAllAppsAdapter (effectively a circular
dependency), so I figured cleaning all that up was out of the
immediate scope of this refactor, which is mainly meant to
unblock transition work.
Bug: 206905515
Test: Manually checked for regressions, ran tests.
Change-Id: I4d3757c8a8f9b774956ca6be541dd4fcdad1de13
The current AllAppsContainerView has been split into a base class and a
subclass for activities. The base class allows using all apps with an
activity context. A-Z and work profile tabs are supported, but search
and the hotseat still require an Activity.
Test: Manual. All apps should work the same.
Bug: 204696617
Change-Id: I3b146714bc11b3b3555d97623aab5d78ac836482
- Tests were flaky with waitForStateTransitionToEnd
- Tests stopped flaking with both waitForResume and waitForStateTransitionToEnd
- waitForResume may be enough to fix the flakiness, so
removing waitForStateTransitionToEnd for now, if flakiness
returns we can add it back
Bug: 202735477
Test: presubmit
Change-Id: Ib9cc16ea7815387582486517a87249d0053475f6
Similar to how AbstractLauncherUITest waits for resume after
switching state to Normal.
Bug: 202735477
Test: presubmit
Change-Id: I61834d32f8005491a4e14a354dc0097b05267f7b
Anushree Ganjam
Vinit Nayak
vadimt
TreeHugger Robot
Andy Wickham
Brandon Dayauon
Sunny Goyal
Brian Isganitis
Jonathan Miranda
sfufa@google.com