summaryrefslogtreecommitdiff
path: root/packages/SystemUI/src/com/android/systemui/keyguard/KeyguardService.java
Commit message (Collapse)AuthorAgeFilesLines
* Cancel current animation instead of candidateRobin Lee2023-06-161-10/+8
| | | | | | | | | | | | | | | Otherwise everything along the way confidently ignores this and Keyguard doesn't even see the timeout and force-abort coming when it hits. This leaves an animation timer running for 950ms which sets occlude status on finish callback and causes unpleasant race conditions. Test: atest android.server.wm.KeyguardTests Test: specific case to be added in b/274003805 Bug: 275650364 (cherry picked from https://googleplex-android-review.googlesource.com/q/commit:8ffedf11e398f9a6aa8b30cff5f06b102fd54536) Merged-In: I7b3dcd06e7483fde745a1d56dfee7c4efc262ed7 Change-Id: I7b3dcd06e7483fde745a1d56dfee7c4efc262ed7
* Reset keyguard drawn tasks in onScreenTurnedOffNick Chameyev2023-02-201-0/+1
| | | | | | | | | | | | | | | | | Resets keyguard drawn tasks in onScreenTurnedOff callback instead of onScreenTurnedOn callback. This is necessary to avoid clearing of the tasks on the first boot when onScreenTurnedOn is called immediately after onScreenTurningOn from the WM side (without waiting for the SystemUI drawn callback). Bug: 268144550 Test: manual fold/unfold Test: check boot time with/without fix Test: atest com.android.keyguard.mediator.ScreenOnCoordinatorTest Change-Id: I780e2738ed2fcf8ec013058a2212612fb6874288
* [DO NOT MERGE] Add centralized DisplayTracker for SystemUIAlex Stetson2023-01-261-3/+6
| | | | | | | | | | | | In multi-user multi-display systems where there could be multiple SystemUI instances running, the concept of what displays are relevant for a particular SystemUI may change. By adding a DisplayTracker class to abstract away display retrieval and callbacks, these instances can return the information that is most accurate for them. Bug: 256236871 Test: atest SystemUITests Change-Id: I51c1a380a344fb45d5e0de2c5c6ba5610733a3a2
* [Unfold transition] Fully manage the vignette on the background threadNick Chameyev2022-12-141-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | Updates onScreenTurningOn/device state callbacks in the unfold overlay class to be executed on the background thread. This allows to draw the first black frame even if SystemUI's main thread is busy at the moment, so it will be less likely to have flicker because of that. Also this CL adds a separate thread to render the vignette to avoid conflicting with the other operations made on the shared background thread. Bug: 262381044 Bug: 262518402 Bug: 233045200 Test: manual fold/unfolds with/without AOD enabled Test: add artifical delay to SystemUI configChanged that exceeds WM keyguard drawn timeout => test that there is a flicker without changes test that there is no flicker with the changes Test: atest com.android.keyguard.mediator.ScreenOnCoordinatorTest Change-Id: Ic5a61839500dbbf63e9c5422bfc0085827526d92
* Manually manage memory of native objectsEvan Rosky2022-11-281-0/+9
| | | | | | | | | | | | | | | | | | | | Even though these surfaces/transactions are unreachable, it still takes time for the GC/NativeRegistry/FinalizerQueue to actually flush/free references (even if you force GC, it won't flush the NativeRegistry/FinalizerQueue). This skews the results of our memory benchmark tests since they measure instantaneous memory. So, add logic to manually release Transactions/SurfaceControls when we know they won't be used. This is extra tricky due to unparceling creating new refcounts. To resolve this, we assume that all remotes are getting a COPY of all surfaces and then we make deep-ish copies on the CALLER side if the binder is actually local. We can't alter the logic on the receiver side because the binders are one-way and thus PID information isn't available. Bug: 258913831 Test: systemui-notification-memory-suite-demo and check aggregates Change-Id: If094e7eeb248a8674e8094cf5cf3019b2cd58047
* Gate & metrics log WakeReason for face auth runBeverly2022-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Include the PowerManager#WakeReason in the metrics log for FaceAuth being triggered by the device waking up. Add config that only allows some wakeups to trigger face auth. For example. we don't need to start running face authentication when the device wakes-up when the user starts charging their device. Also, update KeyguardUpdateMonitor face auth triggers to exclude dream stopping as a signal to run face auth. Since Dozing and AoD are dreams, this meant that any state changes that left the dream would trigger face auth. Test: atest KeyguardUpdateMonitorTest Test: atest FaceWakeUpTriggersConfigTest Test: check sysui logs Bug: 232882273 Bug: 242628816 Change-Id: I3794b7eda7f5e4cf550d9e4a813a28e6c5322d68
* For shell transition, register remote for DREAM occluding Keyguard.Xiaowen Lei2022-09-161-1/+23
| | | | | | | Bug: 222507937 Test: on device, with shell transtion flag on Change-Id: I55f1eb1ed89caf2fb682cbc9580e8461482b8820 Merged-In: I55f1eb1ed89caf2fb682cbc9580e8461482b8820
* Add AppTransition type and remote animation for Dream in occluding Keyguard.Xiaowen Lei2022-09-091-0/+10
| | | | | | | | | | | | | | | | | | | | | The existing Keyguard Occlude Animation Runner doesn't match the spec for Dream in. It animates activity expanding from the center of the screen. For Dream in, we have: - Dream fading in - DreamOverlay complications fading in slightly delayed, with each part starting at different times. This CL adds dedicated AppTransitionType and remote animation runner, which animates Dream fading in. It doesn't implement the separate animation for DreamOverlay complications. Bug: 222507937 Bug: 240477956 Bug: 242864189 Fix: 240477956 Test: on device, wait for Keyguard to time out to Dream. Change-Id: I5517ded2eea77ea962ca1551ed51dd997ff09993 Merged-In: I5517ded2eea77ea962ca1551ed51dd997ff09993
* [Shell Transition]Fix occluded activity could show behind keyguard.wilsonshih2022-08-171-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Register for specific un/occluded transition filter type in keyguard service. The current condition cannot fulfill every situation. E.g. when close top activity while screen off but next activity is occluded, this should an occluded transition, but since the activity is invisible, the condition would match unoccluded transition. The unoccluded status could accidentally trigger keyguardGoingAway and ask core to resume top activity. But on the contrary, if we add above condition in occluded transition, then when user trying to dismiss occluded activity when unlock keyguard, the condition would match occluded transition. To simplify the filter conditions, additional register the filter for those transition type. Also fix DisplayPolicy#mAwake wasn't synchronized by wm lock. Bug: 241745428 Test: Enable shell transition. 1. Start Activity A with showWhenLocked + turnScreenOn while keyguard locked and screen off. 2. Start Activity B in the same task without showWhenLocked. 3. Turn screen off, activity B finish itself. Monitor the occluded status in SystemUI should be true. No keyguard going away triggerred. 4. Turn screen on. Monitor Activity A resumed and occluded keyguard. 5. Swipe up/press back to dismiss Activity A. Verify device can show keyguard. Test: run atest ActivityVisibilityTests#testTurnScreenOnActivity, monitor test activity won't remain behind keyguard while test finish. Change-Id: Ide14913f2b2d25af2c518866b4df8d1a3ff4b18d
* Don't setOccluded in onLaunchAnimationStart.Josh Tsuji2022-07-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | After recent fixes, WM exclusively communicates occluded state by calling the occlude/unocclude animators' onAnimationStart and onAnimationCancelled methods. We call KeyguardViewMediator#setOccluded there to officially set System UI's occluded state. Those methods are guaranteed to be called prior to the launch animator methods. This means that the setOccluded call in onLaunchAnimationStart should always be redundant. However, a series of race conditions (see https://buganizer.corp.google.com/issues/235463625#comment85) could cause this to be called after WM called the unocclude animator's onAnimationStart. Also, add logging to places where we set occluded state to aid in future debugging. These logs are only called during activity launch so should not be frequently logged. Fixes: 235463625 Test: launch and kill the Android Auto head unit ~50 times until onLaunchAnimationStarted ends up being called after the unocclude onAnimationStart, verify that we don't end up in the black screen state Test: launch/kill camera repeatedly to verify no regressions with camera occluding lockscreen Test: launch device controls, with and without controls added, to verify that we are not regressing other trampoline occluding actvities Change-Id: Ia71eb5fb0f85eb5fb494e66a270c68d7df5e1629
* Pass keyguard occluded status in onAnimationCancelled.Issei Suzuki2022-06-251-2/+2
| | | | | | | Test: No visible changes yet. Pass existing tests. Bug: 235463625 Change-Id: Iabee71bc76e19f20702f8a2739f565aa915f9b52 Merged-In: Iabee71bc76e19f20702f8a2739f565aa915f9b52
* Merge "Attemp to fix Launcher stay invisible after keyguard unlock." into ↵Evan Rosky2022-06-231-5/+29
|\ | | | | | | tm-qpr-dev
| * Attemp to fix Launcher stay invisible after keyguard unlock.wilsonshih2022-06-221-5/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the keyguard exit animation end up in a fully/semi transparent case, because the timing of keyguard exit animation may not match to panel fling status, so no matter it's playing fadeInSurfaceBehind or surfaceBehindEntry, there should always cancel the animation when received notifyFinishedKeyguardExitAnimation. Another case is that the Notification shade become invisible while animating, in this case the SyncRtSurfaceTransactionApplier won't apply next transaction because there won't draw any frame for that view. For Launcher re-show case, because the transaction cannot be applied synchronized at KeyguardViewMediator#handleStartKeyguardExitAnimation, so we should initialize the alpha to zero for the opening app. Test: enable shell transition, then scroll up to unlock device, a. verify the launcher won't stay in a fully/semi transparent. b. verify the launcher won't reshow when scrolling on keyguard. Also verify above cases via fingerprint unlock. Also verify when unlock to split screen. Also verify nothing change for legacy transition. Bug: 232852578 Change-Id: I520102f476a417b66822d44f8effb905da4ff943
* | End transitions when receiving merge requestEvan Rosky2022-06-211-1/+24
|/ | | | | | | | | | | | | | | | | | | | | | The default behavior (if nothing is done) for a merge request is to let the animation continue and queue up the incoming animation to start once the current one has finished. This is maybe the "smoothest" default; however, it is not responsive for the user. So, instead, go through and, where appropriate, make animations "jump-to-end" when they receive a merge request. This way the user will see the new animation start immediately after they perform an action. There is technically a "jump" in the animation, but it seems like the responsiveness is preferable and the jumps aren't super noticable anyways. This is also how legacy transitions works so it's not a behavior change. Bug: 236309064 Test: interrupt animations with other transitions and observe. Example: launch an app and then go "back" before it finishes animating. Change-Id: I4a76e7efe2c610b22f3fe97b0bd3ab692a01be08
* Re-enable remote occlude/unocclude animations.Josh Tsuji2022-03-281-1/+1
| | | | | | | | | | | | | This was previously disabled due to an issue where the bouncer would appear whenever the home controls (or other non-camera occluding activites) were launched. This issue appears to now be fixed on tm-dev, likely by some of our other fixes over the last month. Bug: 202963722 Test: With AOD enabled/disabled Test: With security/no security/no lockscreen Test: enable home controls, use home controls activity Change-Id: I486c7adeb23113fa98377d1d5b16c8b6a8be003c
* Merge "Revert "Enable remote occlude animations by default.""Josh Tsuji2022-02-151-1/+1
|\
| * Revert "Enable remote occlude animations by default."Josh Tsuji2022-02-151-1/+1
| | | | | | | | | | | | | | | | This reverts commit 8edb15ffad511fd1f415f5f2a3e210e6cef30a87. Reason for revert: Causing issues with non-camera occluded activties Change-Id: Id33be05745e5afd02cb25377ec2476caa54e8287
* | Merge "Enable remote occlude animations by default."TreeHugger Robot2022-02-101-1/+1
|\|
| * Enable remote occlude animations by default.Josh Tsuji2022-02-021-1/+1
| | | | | | | | | | | | Test: atest SystemUITests Bug: 197312643 Change-Id: I3d5270c8f0dce0fb2239d299e87570e97d8ac860
* | Uses ActivityLaunchAnimator for occlusion animations.Josh Tsuji2022-02-021-40/+13
|/ | | | | | | | | | | | | | | | | | | This is used when the lock screen is visible and an activity occludes it, such as the camera. Currently, the camera launches behind the lock screen and then the lock screen janks out of the way to show the camera. There are currently some pretty severe performance issues, but I'm not sure yet whether that's due to the new launch animator, or the fact that the old animation is so janky that you can't really tell. I'm investigating that, but we should get this into the build to start working out any bugs with the remote occlude animations. This requires remote occlude animations to be enabled: adb shell setprop persist.wm.enable_remote_keyguard_animation 2 Test: atest SystemUITests Bug: 197312643 Change-Id: Id801e44c25c6e2340b4269d215b9a1c056f0ceff
* KeyguardViewMediator refactorMatt Pietal2022-01-051-3/+2
| | | | | | | | | | | Continue dividing KeyguardViewMediator into smaller, testable units, first by removing screen on/off calls that go here. Consolidate screen on/off logic into one file. Add support to Lifecycle to dispatch methods with 1 argument. Bug: 195430376 Test: KeyguardViewMediatorTest ScreenLifecycleTest Change-Id: I2696629fc7e1a3934503e8c94ecdeed749762769
* Upstream Wear Keyguard changesAleksandr Litovchenko2021-12-151-0/+12
| | | | | | | | | | | | 1. KeyguardService#dismissKeyguardToLaunch. It will be called if watch is keyguarded and user does button presses to launch Pay or Assistant. Applied only for watches. 2. KeyguardService#onSystemKeyPressed. Passes stem button press to keyguard. 3. Launch android.intent.action.VOICE_ASSIST_RETAIL for retail assistant button press. 4. Allow ACTION_VOICE_ASSIST to be disabled at runtime. Bug: 204870856 Tests: manual Change-Id: Ibc7fd2d57d0f01bdfca4ea3054fb833fb01b5471 (cherry picked from commit 848b4576561120c875430f4fd38806142a08a115)
* Move keyguard shell transition init to onCreateEvan Rosky2021-11-041-48/+55
| | | | | | | | | | | | | | Some state isn't available in the Constructor and generally we're not supposed to be doing much work in constructor anyways vs onCreate. The problem here is the base context isn't initialized at KeyguardService construction time, so we can't get sysui's application thread. Bug: 183993977 Test: device doesn't crash on boot with shell-transit enabled. Change-Id: I4c0d99a913080c767c913168f226f4c688ef8250
* Boost remote-transition animator processes during animationEvan Rosky2021-11-011-3/+5
| | | | | | | | | | | | This basically ties applicationthread binder token to remote transitions. Shell is first boosted (to run the shell transition logic) and if it then delegates to a remotetransition, it will then request that process also be boosted. Bug: 183993977 Test: add logging in WPC.setRunningRemoteAnimation and verify calls during transitions Change-Id: I94babc327e935ea81271942287a83b948dd11f8b
* Enable keyguard remote animation.Issei Suzuki2021-10-201-1/+1
| | | | | | Test: Existing test pass. Bug: 192688157 Change-Id: Ib0fb41b07458e51a87d68e4554f751a96efaad64
* Revised logic to sync keyguard occlude status.Issei Suzuki2021-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | WM and SysUI must be in sync about keyguard occlude status, so WM calls IKeyguardService#setOccluded to notify to SysUI whether the top activity can occlude the keyguard or not. In case remote animation is used for keyguard (un)occlude transition, SysUI receives a binder call to start keyguard (un)occlude animation and updates its internal state. So WM doesn't need to call IKeyguardService#setOccluded. Note: Keyguard occlude state can be changed without running app transition animation. In such case, WM still needs to call IKeyguardService#setOccluded even if remote animation is enabled. Bug: 191349992 Test: Existing tests pass. Change-Id: I3991809302cf151c382af5821f5a64df939ecb79
* Wrap IRemoteTransition in a parcelable to enable extra propertiesEvan Rosky2021-09-031-3/+5
| | | | | | | | | | | | | | | | | This is in preparation for attaching some extra meta information to remote transitions (eg. process token). Most of this refactor just replaces references to the raw interface with references to the wrapper class. There is also a small refactor in RemoteTransitionHandler to better-manage death-recipients. It is possible to have >1 filter and >1 pendings referencing the same remote simultaneously, so this arrangement properly handles the 1-to-many possibility. Bug: 183993977 Test: refactor, so existing tests pass Change-Id: Icae8f2128e0ffdf7aee51284cba106963450e3e7 Merged-In: Icae8f2128e0ffdf7aee51284cba106963450e3e7
* Invoke keyguard going away when it is collecting for wakeChris Li2021-08-101-4/+7
| | | | | | | | | | Before, when KEYGUARD_GOING_AWAY is called before WAKE starts,it will not be passed to the keyguard service to dimiss keyguard. Now, we merge the flags and add check for that. Bug: 193564917 Test: check with/without sEnableRemoteKeyguardAnimation Change-Id: I28d40664b4fbdc0ea199baa32ccefba7dea473f8
* Merge "Pass AppOps result for PiP in RemoteAnimationTarget" into sc-v2-devHongwei Wang2021-07-311-1/+1
|\
| * Pass AppOps result for PiP in RemoteAnimationTargetHongwei Wang2021-07-301-1/+1
| | | | | | | | | | | | | | | | | | | | This result will be used by Launcher when deciding if we should start the auto-enter-pip transition. Video: http://recall/-/aaaaaabFQoRHlzixHdtY/c9raN4jiaNqbiV7DF4YTJ6 Bug: 194272108 Test: try auto-enter-pip with permission disabled Change-Id: Iea3a45fd68b54d74e7d5da91b63684c206a0132e
* | Add occlude/unocclude support in keyguard shell transitionsEvan Rosky2021-07-301-2/+75
|/ | | | | | | | | Creates and registers remote transitions that deal with situations where keyguard might be occluded/unoccluded. Bug: 191799478 Test: atest KeyguardInputTests Change-Id: I625a810aef915de7a01ded9ddbe3042f0e124b52
* Enable keyguard remote animation when WMShell is used.Issei Suzuki2021-07-271-22/+165
| | | | | | | | | | This also adds a WAKE transition type to handle situations where a showWhenLocked activity is made visible during wake. Bug: 191799478 Bug: 183993924 Test: atest ActivityStarterTests Change-Id: I18f9f5a0af41766a52efd87855f6a3b074aa98f1
* Revert "Enable remote animation for keyguard going away transition."Adam Bookatz2021-07-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | Revert submission 14519409 Reason for revert: Regression in multiuser performance (b/192021579) Reverted Changes: I4dae426cf:Enable remote animation for keyguard going away tr... Other changes that were submitted together but hopefully do not need to be reverted here: I3e45ca52b:Continue to dismiss keyguard when the remote anima... I46879ef87:Stop animating wallpaper and non-app windows in WM... I81cf31fe6:Extend property to enable remote animation for key... Bug: 192044570 Bug: 166736690 Bug: 192021579 Bug: 191030359 Change-Id: I31b3f701e4fe3691308f71f74e5b249dc500e787
* Enable remote animation for keyguard going away transition.Issei Suzuki2021-06-111-1/+1
| | | | | | Bug: 166736690 Test: Pass existing tests. Change-Id: I4dae426cfaac7d498463078de571892f2b82e24a
* Extend property to enable remote animation for keyguard.Issei Suzuki2021-06-111-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | There are two types of keyguard invovlved app transitions. Instead of enabling / disabling remote animation for all such transitions, we can now enable remote animation one by one. Disable remote animation for all keyguard transitions. % adb shell setprop persist.wm.enable_remote_keyguard_animation 0 Enable remote animation only for keyguard going away transition (default). % adb shell setprop persist.wm.enable_remote_keyguard_animation 1 Enable remote animation for both keyguard going away and (un)occlude transition. % adb shell setprop persist.wm.enable_remote_keyguard_animation 2 After setting the property, you need to restart shell and sysui, or reboot the device. Test: No-op chaneg. Pass existing tests. Bug: 166736690 Change-Id: I81cf31fe60583f0fe0d9f46c3189fc0309e8374f
* Merge "Adds the ScreenOffAnimationController, which fixes multiple issues ↵Selim Cinek2021-06-011-2/+3
|\ | | | | | | with unlocked screen off." into sc-dev
| * Adds the ScreenOffAnimationController, which fixes multiple issues with ↵Josh Tsuji2021-05-271-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | unlocked screen off. This changes the screen off animation so that the controller directly animates the LightRevealScrim and the shade keyguard UI, rather then tying these to the dozeAmount. This makes it easier for us to manage/cancel these animations, such as during the camera launch gesture, since the various doze components update their state asynchronously. This approach also means that instead of actually changing everything to KEYGUARD as soon as the power button is pressed, we actually just show the LightRevealScrim and the shade's AOD UI. This results in far less jank. We then actually show the keyguard once the animation finishes or is cancelled. Bug: 169693662 Bug: 169739682 Bug: 181020504 Fixes: 185567665 Fixes: 189342687 Fixes: 185567665 Fixes: 183195436 Test: atest SystemUITests Test: trigger screen off and cancel it Test: trigger screen off and don't cancel it, make sure it wakes up fine Test: disable 'power button locks instantly' and make sure it doesn't lock the device, both when the animation finishes or when it's cancelled Test: press the power button twice in rapid succession Test: press the power button twice in slower succession about 200ms apart (which triggers the camera onWakingUp vs onFinishedGoingToSleep) Test: press the power button 5 times, make sure emergency gesture comes up Test: disable AOD, observe no screen off animation and lock functionality works Change-Id: I1c44304becdadfd37bab7fd81286a9702e5d6141
* | Animate app launches from lockscreenJordan Demeulenaere2021-05-271-1/+1
|/ | | | | | | | | | | | | | | | | | This CL animates the app launches (from notification, media, etc) on the lockscreen when the lockscreen can be dismissed (i.e. when there is no security or when SmartLock/FaceAuth is enabled). Note that in order to try this CL, you need to enable remote keyguard animations: $ adb shell setprop persist.wm.enable_remote_keyguard_animation 1 $ adb reboot See b/184726377#comment20 for before/after videos. Bug: b/184726377 Test: Click notification/media/QS from lock screen. Change-Id: I27e616c1549676f6d1aca53b71efc18db8eec77a
* Revert "Enable remote animation for keygaurd going away."Collin Fijalkovich2021-04-301-22/+6
| | | | | | | | This reverts commit d0ba2859dd8cc851475b0e481adde30cb0eae795. Reason for revert: Checking for cause of test breakage Change-Id: I32f434f2e0c9b7d20bcd0ba51c0b770df8dfa575
* Enable remote animation for keygaurd going away.Issei Suzuki2021-04-281-6/+22
| | | | | | | | | | | | | | | | | Disable remote animation for keyguard transition. % adb shell setprop persist.wm.enable_remote_keyguard_animation 0 Enable remote animation only for keyguard going away transition (default). % adb shell setprop persist.wm.enable_remote_keyguard_animation 1 Enable remote animation for both keyguard going away and (un)occlude transition. % adb shell setprop persist.wm.enable_remote_keyguard_animation 2 Bug: 166736690 185616888 Test: Pass existing tests. Change-Id: Ia40e3325a9f22ce108f36c7111a92b514ce4fa19
* Adds the continuous unlock animation!Josh Tsuji2021-04-261-1/+2
| | | | | | | | | | | | | | | | | | | | | This adds the new unlock animation, which is a subtle scale and translate from the bottom part of the screen. More importantly, it connects the surface behind the keyguard to your finger when swiping, so that it's one continuous motion between the lock screen and the app/launcher. Issei's RemoteAnimation-enabling CL was rolled back for a test breakage, so you'll need to enable it to see this: adb shell setprop persist.wm.enable_remote_keyguard_animation 1 A few P2 issues to be fixed in follow-up CLs since this one is getting large: - Status bar icons need to animate mid-swipe so they don't jump cut post-unlock (b/183063033) - Launcher should use a custom animation rather than surface-based animation (b/183063432) - The scrim should probably animate out once the surface appears rather than at the end (b/183062235) - Handle RemoteAnimation timeout, either by restarting it, or cancelling the gesture (b/183066204) Test: change security to swipe, unlock via a slow swipe and a fast swipe and everything in between (also, release swipe halfway) Test: PIN/password security Test: double tap to open a notification Test: fingerprint bypass Test: fingerprint from lockscreen Bug: 169692441 Change-Id: Ic78c603b2375d36cf2170b81cca7cddbf334408b
* Revert "Enable remote animation for keygaurd."Wei Sheng Shih2021-03-171-1/+1
| | | | | | | | This reverts commit edcdd961d9f76709caf479cc3daf9f3c53683f6e. Reason for revert: suspect of b/182929692 Change-Id: I8c32a10b6e1728c76635b04345fb282e89520355
* Enable remote animation for keygaurd.Issei Suzuki2021-03-101-1/+1
| | | | | | Bug: 166736690 Test: Pass existing tests. Change-Id: Ibff1c8ae6fe8800d5bac49b5f9de4350598ca3f0
* Supress IKeygaurdSerivce#setOccluded binder call from WM.Issei Suzuki2021-03-101-2/+7
| | | | | | | | | | | | | | | When remote animation is enabled for keygaurd (un)occluded status update, KeyguardServices recieves binder call via IRemoteAnimationRunner interface when occlusion status chagnes. The only place we need to keep IKeygaurdSerivce#setOccluded call is in ServiceConnection#onServiceConnected. This is used to synchronize keyguard occluded status in WM and SysUI process when SysUI process restarts, which is handled without any animation. Bug: 166736690 Test: atest AppTransitionTests Change-Id: Idf3a1dedb81be10eb2014f5da190750caf6b6869
* Make keyguard exit animation to remote animation.Issei Suzuki2021-02-041-0/+92
| | | | | | | | | | | | | | The change is disabled by default. To enable remote animation, one needs to set a property and to restart the WMS. % adb root % adb shell setprop persist.wm.enable_remote_keyguard_animation 1 % adb reboot Test: Existing tests pass. Bug: 175686676 Bug: 179122467 Change-Id: I65f36232df715616cfcadcf5d389b72e0894fddd
* Adds the power button unlock animation and plumbs detailed wake/sleep reason ↵Josh Tsuji2021-01-201-7/+14
| | | | | | | | to System UI. Test: unlock the phone using either the power button or lifting it Bug: 169693662 Change-Id: I567555e6ee04f369ce7f4b32744639be70583112
* Don't mark Services and Activities as @SingletonDave Mankoff2019-11-071-2/+0
| | | | | | | | | | Android gets to choose when to create services. If Dagger has them marked as @Singleton, then it hangs onto the references forever, and this causes problems. Bug: 143895143 Test: manual Change-Id: Iee61fc8d6f70e01af167cc215ae7dcde235687af
* Pass context into the constructor of SystemUI objects.Dave Mankoff2019-10-101-9/+14
| | | | | | | | | The next step is to remove `components` from the SystemUI objects and replace them with Dagger injection. Bug: 138786270 Test: atest SystemUITests Change-Id: I27415a8fa8ba0378599356426d849c9cfb9879d2
* Fixes import ordering.Gus Prevas2018-11-141-2/+2
| | | | | Test: n/a Change-Id: I432e11b52deb7974e50f62076af3b7aa07e364b6
* Allow custom keyguard "prompt reason"Lucas Dupin2018-01-111-2/+2
| | | | | | | | | | | | | | Adds the possibility of presenting a custom message on the keyboard if you're trying to dismiss the keyguard. This is particularly useful when you're showing the bouncer because custom authentication (SmarLock) failed. Test: launch FLAG_SHOW_WHEN_LOCKED activity and call KeyguardManager#requestDismissKeyguard Fixes: 63940122 Change-Id: I0d88c0e59521887efa56d74874062b2b14970e4e
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-12 02:17:04 +0000