The app window is now on top of the scrims, so we can just mark the
window as opaque and keep blurring.
Bug: 196828055
Test: atest OutputUpdateAndWriteCompositionStateTest
Test: systrace on all app, and overview
Change-Id: I128d3b4722060c0bb72a218bf01ba26dabaddacf
- The new style is a Widget.DeviceDefault.Button with tweaked corner radius, min size and color
- Light: http://screen/4aTR7DKuhADn2Z6
- Dark: http://screen/68XkvaAqRivbDw8
Bug: 194194694
Bug: 197887431
Test: manual
Change-Id: I1e0f2217a424a244d729c1f952035615ba045d5a
* changes:
Animate PredictedAppIcon when its icon changes
Add "wave" animation when entering taskbar edu
Add slot machine animation for PredictedAppIcon
They are now:
1. Switch apps
2. Splitscreen
3. Docking
They all use the same (blank) placeholder image.
Bug: 180605356
Test: Manual
Change-Id: I53b3f71519c50a1d93f800490d3127e4d669e068
Reuses the slot machine animation to slide in the new icon. Additionally, staggers based on other icons changing before it.
Test: open apps, watch predictions change
Bug: 197780290
Change-Id: Ib2bc84193a9e350c915dd3486b6c98c6c88d3f83
Each icon scales and translates up, then back down. If the icon is predicted, it also plays a "slot machine" animation through random icons from AllAppsList.
Test: Visual
Bug: 180605356
Change-Id: Ia41cb0e340347eea6b580d23c8a2386837e9c399
PredictedAppIcon has the ability to create a "slot machine" animation which cycles through given icons and settles back on the original icon.
Currently the animation isn't used, but here's how you could start it:
if (view instanceof PredictedAppIcon) {
List<BitmapInfo> randomIcons =
mLauncher.getAppsView().getAppsStore().getApps()
.stream()
.map(appInfo -> appInfo.bitmap)
.sorted(Utilities.getRandomComparator())
.limit(3)
.collect(Collectors.toList());
((PredictedAppIcon) view).createSlotMachineAnim(randomIcons)
.setDuration(1000).start();
}
Test: Played the animation locally
Bug: 180605356
Change-Id: I43bfbc41256fb99ee9df3732fd493e6b96bde7cb
Shows up only for large screen devices, not phones.
Tested for NexusLauncher, general 3P launcher support
needed for staged split (TODO b/195607777)
Bug: 195423591
Change-Id: I4d455769b17637174b590c640516b9fbb6352c3d
I guess FrameLayout has willNotDraw=true by default, so we need to set it to false in order to get onDraw().
Test: open a folder on taskbar
Bug: 197866264
Change-Id: Ia521bc3da28527b9c3f1fa7bcdaf5d9ffb7feccf
The idea is that both taskbar icons and recents navigate you to new apps, which we'd want to disable in similar contexts. Hence reusing FLAG_DISABLE_RECENTS.
Test: locally set FLAG_DISABLE_RECENTS=true, ensure taskbar icons don't show up (both in 3 button mode and gesture nav)
Bug: 193183428
Bug: 194990283
Change-Id: I9537f57dc25663151b1414c5260dadb58506fdb0
- Don't remove a single page if it's empty, only if both pages are empty.
- Add back empty pages after they were removed while the phone
was on single panel home.
- On two panel home don't add new workspace items onto the second screen
Test: manual
Bug: 196376162
Change-Id: I4c54ffa3b359a236deb3ab67adb54111e77ec896
When adding a new page to the workspace, mWorkspaceScreens doesn't
necessarily keeps the order. We should use the mScreenOrder field to get
the correct index of pages.
Fixes: 197198491
Test: drag an app from first page and paddings should be correct
Change-Id: I4f79c164391348b53b71a87d5d49cfc4d3d35e5a
I suspect that something happens in Launcher after enabling the provider
that causes "mismatched event sequence" errors.
This CL is to verify that.
Bug: 195031154
Test: presubmit
Change-Id: Ic22df5fa631b287b580f0aaf00c84cd408cb60b0
* Maintain task split percentages when swiping up.
* Split percentages not maintained in GroupedTaskView, however.
That is a TODO.
Bug: 181704764, 181705607
Test: Swiped up in landscape with home rotation on/off.
Portrait still works.
Change-Id: Iec62abae34f6ccadf98e2afdc9409cf3160f8223
Until now the SurfaceControl transaction was being applied
asynchronously, which could lead to it being executed out of sync with
launcher drawing.
This became an issue at higher refresh rates, where frames are produced
at a much faster pace.
In order to fix this issue, we can use BLAST transactions, which are
annotated with a frame number.
Test: record video, go through it manually
Fixes: 194320152
Change-Id: I1636a1ded4f9dd84c54ba12239e3549b92ed7567
Merged-In: I1636a1ded4f9dd84c54ba12239e3549b92ed7567
Until now the SurfaceControl transaction was being applied
asynchronously, which could lead to it being executed out of sync with
launcher drawing.
This became an issue at higher refresh rates, where frames are produced
at a much faster pace.
In order to fix this issue, we can use BLAST transactions, which are
annotated with a frame number.
Test: record video, go through it manually
Fixes: 194320152
Change-Id: I1636a1ded4f9dd84c54ba12239e3549b92ed7567
Android Build Prod User
Hyunyoung Song
Lucas Dupin
Alex Chau
Andy Wickham
Tony Wickham
Vinit Nayak
András Klöczl
vadimt
Mariia Sandrikova
Thales Lima
TreeHugger Robot