'KEYCODE_ZOOM_IN' and 'KEYCODE_ZOOM_OUT' are defined in 'keycodes.h' and 'keyEvent.java', but not mapped in 'Generic.kl'. I think this is used by the camera to adjust the focus and it should be sent to the camera.
Change-Id: Ib5057ca2151de7a91bfec7f646ad9f491789cc0c
Signed-off-by: zhangzhihao7 <zhangzhihao7@xiaomi.corp-partner.google.com>
This keyCode is defined in both 'keyEvent.java' and 'keyCodes.h', but not in the Generic.kl file. The comment of 'KEYCODE_FOCUS' says that this keyCode is used for camera focus, so this keyCode should be sent to the camera app, but now he is not in 'Generic.kl'.
Change-Id: I2d0a49edae0390c9199efe0f01e527b15d14e68e
Signed-off-by: zhangzhihao7 <zhangzhihao7@xiaomi.corp-partner.google.com>
for both shell and legacy transition system.
The general sequence will be:
1. Create animation leash in core, pass to remote animation runner.
2. Remote animation finish, collect finish transaction before
transition happen. Apply finish transaction here if back event won't
trigger.
3. Check whether next transition is triggered from back gesture via
checking the open/close targets.
The 3rd step introduce another change, which to let the back transition
happen. Instead of consume next transition, we should try to find out
whether the participant was the animation target, because we cannot
assume what the opening target will do in resume stage. For example,
the opening activity could finish itself, or start another activity at
onResume, so in either case, the opening activity will become closing
activity. We can only ensure that activity will participant in next
transition.
So the more robust way should be, find out those targets which were
animated. For shell transition, and add a flag to the corresponding
change, then the transition handler can determine what to do based on
the targets. For legacy transition, ignore those targets when estimate
the transition type in AppTransitionController#getTransitCompatType.
Bug: 238474994
Bug: 131727607
Test: varify transition can be handled for some unexpected scenario:
1. launch new activity when close app.
2. launch singleInstance activity when close app.
Test: do back gesture on both shell/legacy transiton system, verify
no flicker happen whenever the back is triggered.
Change-Id: I9364be25c608f7b5797577d26b57bc7d6f2dde9c
If an app requests READ_MEDIA_VIDEO/IMAGES, we should add
READ_MEDIA_VISUAL_USER_SELECTED automatically.
Also updates documentation
Bug: 256921561
Bug: 251783841
Test: atest PhotoPickerPermissionTest
Change-Id: I2ddb2caeeacd8c1d65b7892ea7fc22c024f69325
Instead of pulling the active dream component, we push the component
when a dream is started. This ensures that the active component remains
in sync with the currently active dream.
Bug: 246091760
Test: flashed device and verified dreams are working correctly
Change-Id: Ifece2dc62486b74794f0d333d19bec2ab3bc9229
This fixes conflict between app transition and recents animation in the
following scenario.
1) App transition animation finishes after app closing animation, which
is controlled by recents, finishes.
During the app closing animation, recents makes the closing app surface
invisible, but app transition animation overrides it to visible again.
This causes a flicker.
2) App transition starts during recents animation.
When a user launches an activity, and immediately after that, swipes up
the screen to close the app. Or a user launches an ChooserActivity on
top of other activity, and swipes up to move back to home.
While recents is running, we assume animation on tasks is controlled by
recents, and visibility is commited without animation after recents
animation finishes. However starting app transition during recents
breaks this assumption, which ends up with playing one more unexpected
closing animation (so users see closing animation twice).
This change also obsolute the logic which exludes launcher activity from
app transition while recents animation is running, since app transition
is delayed until recents animation finishes.
Bug: 223499269
Bug: 231669960
Bug: 232060413
Test: atest AppTransitionTest + manual tests
Test 1
1. Launch Gmail app.
2. Click icon on the bottom tab (e.g. Chat).
3. Swipe up from the bottom (immediately after step 2).
4. Verify closing animation only plays once.
Test 2
1. Launch "Google TV".
2. Play a trailer.
3. Full screen and PIP mode switch twice.
4. Verify PIP window is shown.
Test 3
1. Change phone to portlait mode.
2. Launch Photo app.
3. Swipe up from the bottom.
4. Verify no rotation animation on the launcher.
Test 4
1. Launch photo app.
2. Take screenshot.
3. Hit share icon to share the screenshot.
4. Swipe up from the bottom.
5. Verify photo app closes.
Change-Id: I264b0daf1118b75fae481f0251ed50b556f27c5f
unless it has the privileged permission KILL_ALL_BACKGROUND_PROCESSES.
Bug: 239423414
Test: atest CtsAppTestCases:ActivityManagerTest
Change-Id: I35d20539ffac055a6d61260445620f45584bd9c5
When in 'tabletop' or 'book' mode, allow the display to rotate
even if it is frozen. Then return to the previously locked rotation when
the device is unfolded.
Bug: 240146362
Test: locally tested + ran atest on DisplayRotationTests
Change-Id: I9869f5b070fecd7df70e08323dfacef8b883f470
In previous design, it would create all necessary leashes when starting
back navigation, and they would be carried by `BackNavigationInfo` and
`BackEvent` and would finally deliver to the shell and animator side.
In this CL, we will use the adapter that wraps a back animation runner
to deliver all leashes in next surface placement after back navigation
has started.
In shell side, every animator should be registered by type, so the
adapter could deliver leashes via IRemoteAnimationRunner to the
target animator, and invoke callback when it finished.
This also eliminated all unecessary fields from `BackNavigationInfo` and
`BackEvent`.
Bug: 241808055
Test: atest BackNavigationControllerTests BackAnimationControllerTest
BackNavigationTest
Change-Id: I8bbec0d8d9631110c3d2788d958b50ae487520a7
Grant FULL_ACCESS_CELL_BROADCAST_HISTORY permissions to the shell identity for use within CellBroadcast MTS tests.
Bug: 236217191
Bug: 227422973
Test: atest com.android.cellbroadcastreceiver.compliancetests.CellBroadcastConfigTest
Change-Id: Ief5a4c168968b4dc8c9cf7cc071618d41c23d220
Ensure the new stylus buttons are not yet sent to apps.
DD: go/android-stylus-buttons
Bug: 246394583
Test: Build, Presubmit
Change-Id: I440a359ec8cffb60b9e87f2e51304c9b0320e16f
- Traditionally, we only show the current user and its profile users.
But, to support the multi-display, multi-user system, we'd like to
show the background users too.
- This CL will replace WMS.isCurrentProfile() with UMI.isUserVisible().
Bug: 239828153
Test: atest WmTests
Change-Id: Ie432e413aab256b6bac5d4537d19bdcbb0dd8956
To make sure the embedded TaskFragment surface will be updated when
Shell transition is enabled.
Bug: 207070762
Test: testApplyTransaction_collectTaskFragmentBeforeApplyChange
Change-Id: Id726b67cd30bd68e3ca4bc2665ab0a9024d76dab
