Currently, if BiometricPrompt is dismissed quickly (e.g. by tapping on
the top half of the screen to dismiss it while it's being shown) the
ongoing authentication session may not be canceled and the
onAuthenticationError callback may not be run. This commit fixes the
issue by ensuring that a dismissal reason is sent to callback if the
prompt is shown while in the "pending dismissal" state.
Test: atest com.android.systemui.biometrics
Test: Manual:
1. Using a custom test app, trigger BiometricPrompt to be shown
2. While the prompt is being shown, repeatedly tap top half of screen
3. Ensure the prompt is dismissed and onAuthenticationError is called
Fixes: 173417042
Change-Id: I240efba1b008681534380c5e4a10bff973f258a6
Otherwise, the fullscreen IME won't cover the entire display while
there is a hidden system bar.
Fix: 168657591
Test: 1. Steps in the bug.
2. Play WindowInsetsTests with combinations of system bar
visibilities, navigation mode, screen orientation, and display
cutout.
Merged-in: I6e7d665c55839dfbb14c8d2e5365537416f5f6c6
Change-Id: I6e7d665c55839dfbb14c8d2e5365537416f5f6c6
(cherry picked from commit 145f71182a)
* changes:
Add flag to get the name of the Model file from the flag in case we want to try out different models. In addition, we should not log touches in the middle of the screen for logging so moving the block at the very beginning.
Add package_name to log for debugging the back gesture model.
Add log entries for the results for the ML model for the back gesture.
Use ML model for the Back Gesture in EdgeBackGestureHandler.
to try out different models. In addition, we should not log touches in
the middle of the screen for logging so moving the block at the very
beginning.
Test: unittest, manual test
Bug: 150170384
Change-Id: I6ecb556fea01f26323248b999d17c7b1d1b7eeb7
Merged-In: I6ecb556fea01f26323248b999d17c7b1d1b7eeb7
The agreed-upon behavior has always been that after gesture cancelation, touch explorer would exist in essentially a dead state.
It should not be possible to execute a two-finger passthrough gesture for example after doing an invalid gesture.
This is likely why we see GESTURE_PASSTHROUGH in cases where we expect GESTURE_UNKNOWN.
Fix: 171421786
Bug: 162521649
Test: manual
Change-Id: Idce921c5278dea174ec5dad5cecf046f12ab113d
Change-Id: Ic71246adc613ea60d3f25974e4085814c4b3211d
CL[1] add a check in IMMS#hideCurrentInputLocked to
ignore hide request when the current client or the current
input session is null for preventing switching IME may have
unexpected keyboard hidden when focusing the same window to
start input case.
A regression happens when forcing stop the app with focusing a editor
and show soft-keyboard, because the hide request ignored as the above
mentioned, so keyboard will be shown after the next input connection
started since the mShowRequested didn't set to false by hidden request.
As CL[2] uses sameWindowFocused to check all possible hide current
keyboard call places in startInputOrWindowGainedFocusInternalLocked to
hide soft-keyboard only when the window focus changes, so we should
revert the check in IMMS#hideCurrentInputLocked to fix this keyboard
visiblity issue.
[1]: I37ae6e30d1de581ba15131c2a90396b3a522a4d6
[2]: I20e8076acc5fec3c055af0740e2e2a64b1fb6f0d
Note that the QPR version of [1] already includes the follow-up
changes in [2].
Fixes: 171009669
Test: atest KeyboardVisibilityControlTest
Change-Id: I92accb513b728820a3043b365aa5fa4f3a1a34a5
Change-Id: I2fd5255e903932c03a35ae463b0eff3840dc81bd
Merged-In: I2fd5255e903932c03a35ae463b0eff3840dc81bd
Test: manual model test and getting the results
Bug: 150170384
This is a workaround solution for Android R QPR2. We are not allowed
to change the API for QPR release. This is a special case that allows
the current voice recognizer to note proxy ops if it is also the
voice interactor. In S, we will define a new permission that designed
one as a trusted blamer and tie it to a role.
Bug: 17095434
Test: manual
Test: TreeHugger presubmit
Merged-In: I506bbeb95e622b99693dbf5a135c7961b7fd81c1
Change-Id: I0852d1bb438d25b3e93224a71de1bf3b6df72c1c
Activity can be used only in two cases.
1) Calling uid matches uid grantee.
2) Calling uid is is system. This flow is used by getToken methods with
notifyAuthFailure=true.
Test: Existing CTS tests
Bug: 158480899
Merged-In: I1421c333b6cebb4f7cddcdd8766298f6872e933b
Change-Id: I18af48cf3cb4ad23a3e5b02a8ea1416aa5570dba