- we were not actually using mRecentsSurface so we no longer need to compute that. By removing this we will also fix the NPE.
Test: Pre-Submit
Fixes: 269716918
Flag: not needed
Change-Id: Ief4be341061a1c914456d6740f175662ccebc364
And call initCompose() in Launcher.java. Therefore there is no behavior
change for BaseActivity, or other ActivityContext subtypes that don't
call initCompose().
This should work for non-activity subtypes of ActivityContext. It's
likely that the Launcher activity will require more complete supoort for
Lifecycle and SavedState.
Note: In order to test the ComposeView, need to build this CL together
with ag/22461463.
1. `ViewTreeLifecycleOwner.set(..., ...);` is necessary to fix the
following crash:
java.lang.IllegalStateException: ViewTreeLifecycleOwner not found
This error comes from WindowRecomposer.android.kt
- http://cs/androidx-platform-dev/compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/WindowRecomposer.android.kt;l=351-354;rcl=5673af1441ebe04c776f528193dfc5f85c0c9a66
2. `ViewTreeSavedStateRegistryOwner.set(..., ...);` is necessary to fix
the following crash:
java.lang.IllegalStateException: Composed into the View which doesn't propagateViewTreeSavedStateRegistryOwner!
This error comes from AndroidComposeView.android.kt.
- http://cs/androidx-platform-dev/compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeView.android.kt;l=1178-1183;rcl=5673af1441ebe04c776f528193dfc5f85c0c9a66
3. The lifecycle needs to be STARTED. Otherwise the ComposeView doesn't
show up in its parent (i.e., isn't drawn).
- In ComponentActivity, `onSaveInstanceState` starts the lifecycle.
- In ComposeInitializeImpl (from SystemUI),
ViewLifecycleOwner.updateState() starts the lifecycle when the
window is visible and in focus.
The implementation in this CL does the same thing as the
ComposeInitializeImpl.
Bug: 275905704
Test: on device, trigger a card such as the timer
Test: RUN_ERROR_PRONE=True m out/soong/.intermediates/packages/apps/Launcher3/Launcher3/android_common/lint/lint-report.xml
Test: RUN_ERROR_PRONE=True m out/soong/.intermediates/vendor/google/gms/packages/SearchLauncher/SearchLauncher/android_common/lint/lint-report.html
Test: Presubmit
Change-Id: Ieced66ad5238916a82ea13c01f69146bbdcf287a
Before we use TaskbarModeSwitch but had a drawback where we would not know which variant of taskbar the test failed for. So, we split the taskbar tests into transient and persistent for better error logs and debugging.
But, now we can use Parameterized Test Runner to achieve the same and do not have to duplicate test code for testing two different variants of Taskbar.
There can be instances where we only want to test certain taskbar variant only, we have separated files for that.
Test: Presubmit
Bug: 267648422
Flag: not needed
Change-Id: I4322498f13d257a5f1793b008f45b09ac9b9f3ff
This shouldn't change anything in the grids, only support the creation of responsive grids in the future. For now, to check that the flag works, turn it on and check the dumpsys. There is also a dump test created for this.
Fix: 277064696
Fix: 277064702
Test: DeviceProfileResponsiveDumpTest
Flag: ENABLE_RESPONSIVE_WORKSPACE
Change-Id: I1bef87043a100234bd661cd6ac00007fdc654116
Before we were only applying the icon.clearAccessibilityFocus() only on normal popup and not material u popups, since the flag is turned on for udc, we can move it outside.
There seems to be a bug associated with either nested abstract floating views or the accessibility service where upon opening a nested abstract floating view from another the icon get the focus. This change make the bug littl less visible to use but users will still see this bug if they open the shortcut pop agian withought closing taskbar all apps.
The accessibility delegate was always null when using the TaskbarOverlayContext, now we use TaskbarActivityContext Delegate when in TaskbarOverlayContext.
Test: Manual
Bug: 280657266
Flag: not needed
Change-Id: I631e3aa6e54748c4c8ea2ac7daf5473b198e47d6
- Fixed back button image padding (and updated all other images to prevent hidden padding)
- fixed done button size
- padding top and bottom insets for status bar and nav bar
Flag: ENABLE_NEW_GESTURE_NAV_TUTORIAL
Fixes: 281121442
Fixes: 281121138
Test: launched the tutorial menu on handheld, foldable and tablet, compared before/after pictures
Change-Id: I61bce2fc4a8d3824048229e0d48f9a429c80a204
* Return a copy of taskIds in TaskView#getTaskIds() to
prevent accessors from getting clobbered values
* In RecentsView#applyLoadPlan we overwrite values in that
array, so callers using it to cache old values would read
incorrect values when reading it after a TaskView has been
bound to new tasks.
* Load/Unload visible task data for all tasks in a given
TaskView, not just single task <-- probably not necessary for
bug fix, but seems sensible
Flag: none
Fixes: 266905177
Test: Quickswitch works as expected. Currently
unable to test thumbnails (created b/281582106)
Change-Id: Ifd4d8a856976ab9cc200b0f61eca1c68897f343c
* BubbleControllers is optionally available (gated behind a flag).
* The bubble bar controllers follow init & onDestroy after the taskbar
controllers.
* Adds the relevant views used by the bubble controllers to the
transient taskbar layout.
Bug: 253318833
Test: manual, with other CLs, see go/bubble-bar-tests
Flag: WM_BUBBLE_BAR
Change-Id: I685163cdcc912768b1a720952762f4cbc602b14b
- The main issue arises when a task is successfully launched from
overview, but the activity later finishes (ie. during resume) which
prevents the usual logic of resetting Launcher to a good state
(ie. it can get stuck in overview with a blank or empty snapshot)
In this case, the Launch will "succeed" so that onTaskLaunchFailed
is not called, but then also silently fail (launched task finishes
and Launcher is again resumed) before Launcher stops, which does the
usual resetting of the state back to normal state after quickswitching.
This change checks for this case by listening for the activity and
transition state, and in the case where Launcher has not been stopped
or is resumed again after the transition finishes, returns the
user to the default home state.
This primarily only affects quickswitch for now, as other launch
failures leave the user in a valid state (ie. overview) while this
issue will leave the user in background state while quickswitching.
Bug: 268448123
Test: Quickswitch to an activity that finishes when resumed
Change-Id: I7d554f8fd521f7bc480dc06930ad91eeef0f1a1a
DropTargetHandler was calling getModelWriter() on a final variable
and the model writer it was using was and old one.
Fix: 280170665
Test: Manul test, delete widget and rotate the device, you have to do this twice.
Change-Id: I7b3ac4b272568fcc81438ffd5ac84cf7b64a62ea