If the voice interaction doesn't set RecognitionService, it may cause
NPE when it tries to get recognizer name. We don't need recognizer
name since Android 12, we delete it directly. To avoid the app does
not set RecognitionService then updating the app to earlier platform
that may cause boot loop. We add a warning log and set empty service
for voiceinteraction to let app aware the problem. Also logging and
unset the voiceinteraction service if the app try to update the app
without recognition service.
Bug: 170742278
Test: Use sample VoiceInteractionService without a RecognitionService
The system doesn't crash when choosing the sample app as the default
assistant app from Settings. And make sure the VoiceInteractionService
is unset.
Test: Install sample VoiceInteractionService with a RecognitionService
and then update it without a RecognitionService. Make sure the voice
interaction service is unset.
Change-Id: I79ab3d6449984ead0be28a94adaad57ab24d1fb9
These changes cause some noted app ops to be swallowed due to one-way
app ops.
Fixes: 187721493
Test: atest AppOpsLoggingTest
Change-Id: I3b761b65b2e06138fc1d130bf80587f8885bb1d5
CL[1] aims to fix a potential ANR issue happen when the IME focused app
popup IME picker dialog and then switching another task through
status bar settings button or notifications, system will filter the IME
selection dialog window to not be the focused window when finding the next
focus during switching to the next task.
However, that filtering rule mistakes to ignore the IME picker dialog as
focus window when Gboard 'SELECT INPUT METHOD' page popup IME picker dialog
by using IMM#showInputMethodPicker (i.e. Gboard page still keeps focused),
so that after choosed input method from picker, Gboard page will not
receive onWindowFocusChanged callback to update the IME selection status,
because the page has already focused.
To fix this window focus issue of IME picker dialog and CL[1] issue scenerio
, use WindowState#isAnimating() to check if the app window with IME
picker dialog is under app transitioning, if so, then we can say it's
safe to ignore IME picker focus.
[1]: Iae3dd713b1e980067d28debea4e0a03707aa7938
Bug: 195073688
Bug: 194214768
Test: atest InputMethodManagerTest#testShowInputMethodPicker
Test: atest atest DisplayContentTests#\
testImeMenuDialogFocusWhenImeLayeringTargetChanges
Test: manual as issue steps:
0. Current input method is not Gboard (Canary).
1. Tap Gboard (Canary) icon on App list.
2. Tap 'SELECT INPUT METHOD' icon and select Gboard (Canary).
3. Verify the IME status should updated after dismissed IME picker
dialog.
Change-Id: I771d9817cd6dfcb1bf0d576d94bea9d1b9adc80e
When switching tasks from the task has IME shown to another task
without showing IME (e.g. youtube apps.), the flickering might happen
because the next activity accidentally received the IME insets attached
in the previous activity.
If the IME is attached to one app window on that time, even the next
app window is behind the IME window, conceptually the window should
not receive the IME insets if the next window is not eligible IME
requester and ready to show IME on top of it.
Fix the logic in InsetsPolicy#adjustVisibilityForIme for the above
case.
Fix: 192337037
Bug: 194746204
Test: atest WindowStateTests#\
testAdjustImeInsetsVisibilityWhenTaskSwitchIsAnimating
Merged-In: Ib3a1eacedd3763bcf1e6eed82e7efdf01c50b204
Change-Id: Ib3a1eacedd3763bcf1e6eed82e7efdf01c50b204
(cherry picked from commit f4eb054460)
This CL fixes one of the issues with SurfaceView parent frame and
content syncing.
With BLAST, we have two surface controls each setting a scale. The
parent surface control sets a scale based on the requested surface
size and the SurfaceView layout size. The BlastBufferQueue surface
control scales the buffer to the requested buffer size if the buffer
has the appropriate scale mode.
The destination frame controls the second scaling and it must be
applied with the parent surface scale changes. This cl fixes flickers
where the requested fixed surface size changes without any view size
changes. This cl allows the caller to pass in a transaction to
BLASTBufferQueue#update which is updated with the destination frame
changes. This transaction can then be applied with the parent
surface changes.
This also fixes an issue where destination Frame was being set on
every buffer update and when we updated the BlastBufferQueue size.
Since buffer transactions can be queued up on the server side, a
stale value maybe applied for a few frames causing flickers.
Fixes: 194458377
Test: bug repro steps
Test: atest SurfaceViewSyncTest#testSurfaceViewSetFixedSize
Change-Id: I118bd1c3942b389e3951c3fd7389403895fc7b31
In current logic, we broadcast Bluetooth state OFF at BLE_ON state.
However, if Bluetooth gets crashed, we won't have the chance to send OFF
intent as we never get to BLE_ON.
This change makes the BluetoothManagerService skips the OFF intent only
if the previous state is a BLE state.
Bug: 189271317
Bug: 195032127
Test: manual
Change-Id: I3936766ab8bdd45d59550dacb64bdc0323bb424d
(cherry picked from commit 1b2f8bc9843b2d6ba7ba199a89412c8fb632f508)
When moving the security footer in the same container, correct the index if
it's before the desired position (because it will be removed from the
current position).
Also, extract moving logic so it can be easily tested.
Fixes: 195104944
Test: atest QSPanelTest QSPanelSwitchToParentTest
Change-Id: Ibc85cd5501010fcf9752d8af103500479c6f28c2
Merged-In: Ibc85cd5501010fcf9752d8af103500479c6f28c2
This reverts commit 9b34cca80f.
Reason for revert: restore info for S to not break tooling, can re-consider for T
Bug: 191386282
Change-Id: I3e6919c5ce8073f22c860e1be59264668643d910
Even if we're dozing b/c this # is ignored in low-power mode,
but we still want the display to already be at this refresh
rate when we exit doze.
Test: on device w/ udfps enrolled + preferred refresh rate config,
check dumpsys display when in AOD and check for refresh rate vote
(ie: PRIORITY_APP_REQUEST_REFRESH_RATE_RANGE = preferred rate)
Bug: 192699858
Change-Id: I9ae31e64c4d698eb9e7da46fad5331632b632090
