This reverts commit 7d9eb2b6f9.
Reason for revert: Regression happens in "com.instagram.android" that IME will cover the comment fields
Bug: 195385541
Bug: 192337037
Bug: 194746204
Change-Id: Id33459ab4f53f8bec2027759302dafc1a4f02fae
(cherry picked from commit 9eca14b72b)
Root cause:
1. Design change "tap app to exit" -> always being true, and settings
remove this option.
2. Tuning performance, due to 1, no longer listens to the key change,
so we remove the listener.
Solution:
Change getSettingsTapsAppToExit() API to return default TRUE.
Bug: 195629000
Test: Build ROM and factory-reset to test
Test: atest WMShellUnitTests
Change-Id: Id3c265258ed28f7e0aa54505c339671885d28fa7
This is split into two high-level issues which together cause
strange auth behavior on keyguard:
============= Issue 1 =============
For fingerprint, auth ends when:
1) Success
2) Error
For face, auth ends when:
1) Success
2) Reject
3) Error
This change ensures that cancellation signal is set to null upon
any of these conditions, so that there is never an opportunity of
using a stale CancellationSignal.
Furthermore, do not invoke stale cancellation signal when
starting authentication. In the off chance the bug is re-introduced,
or if some other situation can cause a cancellation signal to be
non-null when keyguard requests auth again (e.g. bad state management
in keyguard), do NOT invoke the stale cancellation signal's cancel
method. The framework already handles this case gracefully and will
automatically cancel the previous operation.
============= Issue 2 =============
We have a runnable that's scheduled to run after X ms if
ERROR_CANCELED is not received after cancel() is requested. However,
there are various bugs around that logic:
1) shared runnable for both fp and face, leading to unexpected
and incorrect state changes (e.g. face does not respond to cancel
within X ms, both fp and face will go to STATE_STOPPED, even though
cancel() was never requested of fp
2) Always remove and re-add runnable when requesting cancel() though
it should never occur that cancel() is requested in close temporal
proximity, it never hurts to have the correct timeout before
resetting the state.
Bug: 195365422
Bug: 193477749
Test: manual
Change-Id: I3702f41c8af7e870798f19c43012a26281a6632a
By default, use 48px. This value can be
overridden by overlays.
Update stroke width of lock and udfps icons from 2.5 => 2
Update stroke width of aod udfps icon from 1 => 1.3
Test: manual
Change-Id: I7c3883c9acac68acc02684a3115e9e6512fe9a1f
Bug: 195564809
In some situations the hostView needs to have initialized some
LayoutParams
Fixes: 195651626
Test: atest SystemUITests:KeyguardMediaControllerTest
Change-Id: I567393e6fb7ba4df38e7937c6005ba8058de431f
Shell owns the whole display rotation animation now. So, we
can just provide enough information for it to decide when
seamless is requested/appropriate. The default behavior (when
not explicitly animating) is already a jump-cut/seamless, so
just skip the rotation animation if we are doing seamless
Bug: 194693472
Test: atest SeamlessAppRotationTest ShellTransitionTests
Change-Id: I64748f5910c04784fd9818818b029fa5f1339c6c
This could happen after a quick double tap on the ringer icon, where you'd hit the ringer icon as the drawer animated shut. This resulted in a permanently unusable ringer drawer (a reboot was needed to fix).
Fixes: 195392457
Test: switch to vibrate, then tap the ringer icon several times quickly
Change-Id: If5ddd2a27364a6fd66ebd6bfd12b5810e1973a75
Apps that create RippleDrawable on a background thread could crash,
making them incompatible with S.
Test: manual with MindBody app
Fixes: 194952073
Change-Id: I9d16d5c63c192e96191b4fbc859ff3bc3da733cb
