After refactoring NPV, BiometricUnlockController started to receive
authentication callbacks before NotificationPanelViewController.
This means that wakeAndUnlock will start earlier, and the order that
onBiometricAuthenticated and onBiometricRunningStateChanged is not
guaranteed anymore.
This CL checks if we're unlocking with biometrics before showing the
status bar, in order to keep it hidden when dismissing the keyguard,
regardless of callback invocation order.
Test: unlock with face
Test: wait for face timeout
Test: unlock with password
Test: unlock with face after SB is visible
Fixes: 159445348
Change-Id: I43f78f4ab4d0e89e27fcfe5ba527a6c3ff18b0ae
onBoundsAnimationEnd does not set the permanent bounds if mSpringingToTouch=true, since that indicates that PIP caught up with the touch location - and the touch location is a temporary position. We eventually set the permanent bounds after flingToSnapTarget's animation ends.
However, if PIP was flung to a snap target while mSpringingToTouch=true, those permanent bounds were never set. Starting a drag gesture would have set the permanent bounds, which is why this is only visible if you tap immediately after doing all this.
Bug: 159909223
Test: tap pip after dragging it through dismiss without moving it again
Change-Id: I67a9c19bf8dafab4cee646539d9f5a4575a14ffd
Accessibility was relying on WS.mEnterAnimationPending to determine if a
window was ready on screen. However, that variable no longer represents
what it used to and it doesn't actually mean the app is animating. The
variable is only set when a relayout is requested and then unset when
show is called. Accessibility is already checking isOnScreen and
isVisibleLw so that should cover the cases to check if the window is
ready.
mEnterAnimationPending is not always set properly and causes issues with
accessibility, which is the only place currently using it.
Fixes: 152537982
Test: Magnification for Accessibility works
Change-Id: Ib0f37b3cc6d744fd84f466a65e6ce006e07e116e
This adds the following to the stack state:
expandedContainerVis: 0
expandedContainerAlpha: 1.0
expandedContainerMatrix: Matrix{[1.0, 0.0, 0.0][0.0, 1.0, 0.0][0.0, 0.0, 1.0]}
As well as a new 'expanded bubble state':
Expanded bubble state:
expandedBubbleKey: 0|com.facebook.orca|10000|ONE_TO_ONE:903330182:1183835847|10375
expandedViewVis: 0
expandedViewAlpha: 1.0
expandedViewTaskId: 27543
activityViewVis: 0
activityViewAlpha: 1.0
Test: dumpsys
Bug: 159861400
Change-Id: I964803b77ad5a0b3780c219ac919d6bd4316c53f
Allow opening the dialog in all users
Stop recording when the user changes
Post notifications in the correct user
Still some issues with tile state and status bar but those require more
work to coordinate across users, so may not make it into R
(related bug: b/158004991)
Fixes: 147921212
Bug: 148955577
Test: manual
Test: atest ScreenRecordTileTest
Test: atest com.android.systemui.screenrecord
Change-Id: Idf10931c5ddf3079b903708824fae11135169c1b
Currently we extract the intent and send that directly, which means
it is sent with SysUI's permissions (which is a security
vulnerability). This change switches to sending the PendingIntent
(with the creator's permissions) instead.
Bug: 159822190
Fix: 159822190
Test: manual (ensured that the smart actions still work)
Change-Id: Ia567272382021d4324974fb7d8c2c01b7e556846
ResolverActivity.
Test: Manual, using `adb shell su 1000 service call user 72 s16 android
i32 1 i32 10 i32 0 i32 0 && adb shell su 1000 service call user 72 s16
android i32 0 i32 10 i32 0 i32 0` to quickly toggle work profile while
on share sheet. Confirm that the work profile is visible again.
Fixes: 159646289
Change-Id: I29e5600b6d416e1bb6150629c9d94d20b344e4a9
Introduce strategy which uniformly samples OPs, without biasing in
favour of specific ops.
Use this strategy half of the time.
Test: atest RuntimeMessageCollectionTest && statsd_testdrive 10069
Bug: 143519689
Change-Id: I481d3a9ef9c66f04577b57432cecdf2c02055e58
NotificationManagerService has a non-mockable relationship to
System.currentTimeMillis and this test assumes that calls into the
service will not happen in the same millisecond. The fix here is to
sleep for 1ms in between calls to ensure that the clock advances.
Test: atest --rerun-until-failure 100 NotificationManagerServiceTest
Bug: 155331470
Change-Id: Ica6b26a3d72295b0be52c6b1579dde30447ddeaf
