Currently, we keep the process up even if the user switches,
meaning that in some cases (if the user is switched while the
screenshot UI is up) we will save images to the wrong profile.
This change makes ScreenshotHelper listen for user switches and
close the screenshot service, so that a new screenshot is
guaranteed to be constructed with the correct user's context.
Bug: 170474245
Fix: 170474245
Test: manual -- verified bad state occurs if user switches within
the timeout period, ensured that screenshots work immediately
after switching with this change.
Change-Id: I9d32d0928e6c2bda161d04555438d0dd7afef0ba
(cherry picked from commit 7ef1a5dd15)
DO NOT CHERRY PICK ANYWHERE: Security issue
This API is meant to grant an app complete verification over the
domains it has declared, meaning it will always resolve the domains it
declares for web links.
This can allow an app to take over links that are unowned. Any time a
user selects "Always" when resolving an Intent in the diambiguation
dialog, this API would be called, and all subsequent resolutions of any
domain declared by the app selected would be automatically directed to
that app, with no prompt to the user.
From a quick search, it's possible that all usages of this API are
actually unintended and should be removed. Should be considered for
deprecation in the future.
Bug: 163358811
Test: none, this is not generally testable, see linked bug for context
Merged-In: Iff7f788a83af68c7fbb1c6b9a8be7b47136be2b6
Change-Id: Iff7f788a83af68c7fbb1c6b9a8be7b47136be2b6
When the file is deleted, renamed or moved, revoke all uri
permissions with the file
Bug: 157474195
Test: manual test with DocumentsUI
Test: atest DocumentsTest#testAfterMoveDocumentInStorage_revokeUriPermission
Change-Id: I4ffb183630aadb2d87b0965e8cecf88af15f4534
Merged-In: I4ffb183630aadb2d87b0965e8cecf88af15f4534
(cherry picked from commit 9efd606f43)
When dismissing a dialog with EditText focused and keyboard shown,
the keyboard does not get correctly dismissed.
This happens because after CL[1] landed, returning to the activity won't start
new input connection, and the activity will thus not regain control over
the IME.
This fix restores the previous behavior, where IMM will start a fake input
connection even without an editor.
[1]: I1ef3d341af9d473d94d52fd1890deafbae2bc9e1
Fix: 161273049
Test: atest CtsInputMethodTestCases
Test: manual as follows
0) Have some files downloaded in the device
1) Launch Files app > Browse > Click Internal Storage
2) Long press on any file > From menu, click "Rename"
3) Enter some name with soft keyboard and click "OK"
4) Expect Keyboard should hide
Change-Id: I022ad658844142ff4a4cf3b91953013f2bfbb58a
Fixes a flicker that occurs during transitions between windows.
This happens for two reasons:
1.) Control is immediately transferred to the new window, and the
previous window didn't get a chance to play the animation.
This is addressed by adding logic to keep control on the
exiting window for the duration of the transition - similar to
what we do with the target for z-ordering purposes.
2.) Upon the input connection being severed, the InputMethodService
immediately hides its window, preventing any animations whenever
the input connection changes
This is addressed by moving hiding of the surface into the
controlling windows - where upon receiving control, we now
trigger removal of the IME surface if we don't show it.
Additionally:
- Now ensures that any requests from the ImeInsetsSourceConsumer
ensure that they come from the window that is currently served
by IMM.
- Removes the transparancy clause from isImeTargetFromDisplayContentAndImeSame
to match the updated IME target computation in DisplayContent in [1].
[1]: Iedd5f7407926167f4891ce9b7e9a79e22751e668
Fixes: 153145997
Fixes: 150902448
Test: atest WindowInsetsAnimationControllerTests
Test: atest DisplayContentTests InsetsSourceConsumerTest
Test: Open app with IME, press HOME button, verify IME smoothly animates away
Test: Open Messages, open a thread, open IME. Click search icon, verify IME opens in the search activity
Change-Id: I4910c2a06cc67b0470477b245fc1de54b75f10f9
The current implementation has a problem where:
In the autofill side, there can be multiple autofill sessions existed
at the same time. But in the IME side, there is always only one
InlineSuggestionSession at any given time. It will cause the previous
autofill session to fail communication with IME.
It would better change to drop down UI when the autofill inline
suggestions don't be shown in IME.
How to reproduce this issue:
To add an input field with autofillable into the authentication activity
of InlineFillService. To tap on the input field of the authentication
activity during the authentication flow. After completing the
authentication, the inline suggestions won't be shown in IME.
BTW, if the input field is marked as non-autofillable, this issue won't
occur.
Manual verification:
1.Tested this patch with InlineFillService and it worked well.
2.Feng also helped to test this patch with the webview
(sort of randomly), and didn't find any broken case
Bug: 158877106
Test: atest CtsInputMethodTestCases
Test: atest CtsAutoFillServiceTestCases
Test: new CTS test Ie1d9055b0eabfcaa00861869467be8dcee25833e
Test: manual verification with InlineFillService
Test: Feng also helped to test this patch with the webview
Change-Id: Ib06edd823fa4478f34362164f3f7dd3544e51705
After selecting a suspended app, the package monitor would be
unregistered even though the app would never be launched. This would
cause an IllegalStateException on the next selection of any target,
and crash the sharesheet. Check for a suspended target before
unregistering.
Fixes: 160015744
Test: manual, follow BR steps and pause an app
Change-Id: I1b0c79bad0fa75aea6a543b6f8a4848720faa0c8
For sharesheet, assume that the reordering of elements will make the
last assigned ViewHolder invalid for async icon loading. If we already
have an async task for the particular ResolveInfo, update the
ViewHolder target when it's complete.
Fixes: 158172791
Test: atest ChooserActivityTest ResolverActivityTest
Change-Id: I0ea9f443512f91e8fa4c5d6b72a35e9231e69e51
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
Sometimes a suspended app may be started while the device is locked. The
suspend dialog should request the user to unlock in these cases.
Test: Manual:
1. Suspend camera app.
2. Lock the screen.
3. Try to launch the camera while the screen is locked, e.g., by double
tapping the power button.
Bug: 157867645
Change-Id: Ie3b5e2903804bc8b385de4fc9276dd55a8108c0f
Merged-In: Ie3b5e2903804bc8b385de4fc9276dd55a8108c0f
Fixes: 156301524
Test: # to enable controls component
adb shell am start -n com.android.egg.test/com.android.egg.neko.NekoActivationActivity
# manual step: activate controls from GlobalActions
# to visit the cat list
adb shell am start -n com.android.egg.test/com.android.egg.neko.NekoLand
# to check on the status of the food bowl job (once
# the food bowl control has been tapped)
adb shell cmd jobscheduler get-job-state com.android.egg.test 42
# to trigger the food immediately
adb shell cmd jobscheduler run com.android.egg.test 42
Change-Id: I985a930bb5dd56d99eb57a340e4affe08c09724b
This technique is also used by the Recents animation to hide the IME. It replaces the AV back press workaround entirely, which fixes the IME hanging around issue (and by extension, the weirdness around the insets).
Test: open a bubble (go/use-bubbles), focus an input field, then tap outside the bubbles UI to close the stack, observe that the IME hides
Test: open a bubble, focus an input field, switch to another bubble, observe IME hides
Test: open bubble, focus input field, switch to another bubble, focus input field, switch to the original bubble, focus input field, collapse stack, observe IME hides (previously the IME would remain visible)
Bug: 159369847
Bug: 159561847
Change-Id: I09f27b3c187a7bcfbef663cd3101a74ad8ab95ab
During transitions and while the IME is controlled by the app,
the IME may be "visible" as far as the IME framework is concerned,
but not actually perceptible by the user due to offsets or alpha
applied to the leash.
This may lead to out-of-place navbar symbols for the IME, especially
in gesture nav.
To avoid this, the ImeInsetsSourceConsumer now notifies the IMF of
whether it has made the IME unperceptible to the user.
For now, we ignore the cases where the IME is controlled by something
other than the client window - in that case, we just revert to the
previous behavior of it being always considered perceptible.
Fixes: 158079255
Test: manual, launch email compose activity, observe that back button only indicates once IME appears
Test: atest InsetsAnimationControlImplTest
Change-Id: I4dc9d6513d0559156f7da39244f3fc5ebc952ed4
CL[1] introduces new WINDOW_FOCUS_GAIN_REPORT_ONLY flows to notify
InputMethodService only reports IME input target to WM when focusing to
the next window and its input connection remains.
Originally in android Q and prior devices, we don't need such report
mechnism but just skip to start new input connection and ignore
onStartInput / onFinishInput for the above use case.
Since starts from Android R, new IME insets control APIs relying on this
mechanism (see CL[2]) to keep the actual IME input target up-to-date.
As we expected there should be no new input connection and additional
onFinishInput when CL[1] landed.
However, in IMMS, startInputUncheckedLocked will be called
to callback additional onStartInput for InputMethodService, which mostly
is not expected, except when focusing the same window after device
turned screen on, we need to start input and callback onStartInput to
align with the behavior of android Q or the prior platform.
Besides, to have more clear code logic and debugging concept of
ignoring onStartInput and onFinishInput only when focused the same editor
with input connection remains, we remove WINDOW_FOCUS_GAIN_REPORT_ONLY
reason and introduced 2 more start input reasons to distinguish the
different behavior:
- WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR
- WINDOW_FOCUS_GAIN_REPORT_WITHOUT_EDITOR
[1]: I45a9814d812ad906f417c24200fd4219959e2423
[2]: I9e8984b7e5aa989a53ece9e2576393f795b9ef94
Fix: 158624922
Test: atest FocusHandlingTest InputMethodStartInputLifecycleTest
Test: manual as below steps:
1. Use Gboard, Open the emoji keyboard
2. Swipe down to reveal notification shade
3. Swipe up to dismiss notifications
4. Expect the Emoji keyboard is still open without close
Change-Id: I2da99ae67b9ce4051dec0c0f0e975ebe6e1ab118
This fixes several issues relating to pinning and work profile.
(In future, we might want to maintain a separate pinned list for
WP than for main profile - this CL doesn't address that but
doesn't prevent it.)
Fixes: 159038941, 159035711
Test: atest ChooserActivityTest, manual with WP enabled thru TestDPC
Change-Id: Ibbe908a60dfeee859e576c5e1473123f02147958
- in situation when developer provides message when op is noted, do not
report it through stack trace collection infrastructure
- collect only statcktraces for OP_FLAG_SELF and OP_FLAG_TRUSTED_PROXIED to
match collection of appops counts
Test: atest android.app.appops.cts.RuntimeMessageCollectionTest
Fixes: 159433071
Change-Id: I1ab56a530832873a1f1f68aba5ab6eabc9e8a17a
