Moves the fixUris call from onTargetSelected directly to the intent
launch to ensure the intent which is actually started is updated with
userId specific URIs.
This is a backport of ag/19657256 and ag/20063949.
Bug:242165528
Bug:244876518
Bug:242605257
Test: manually share image from personal profile to work gmail,
first with chat target then backing up and selecting the main target
Test: manually share image from work Photos app to personal WhatsApp's
frequent contact target.
Change-Id: Id815984e691bf962e19e30a54f7247d16060b3b8
Merged-In: Id815984e691bf962e19e30a54f7247d16060b3b8
Merged-In: Ib41c8a3c46afcc2d62a4c1a924212bcd98bcfbe4
Merged-In: Iabf5dcf2612fe718f2f0886e2e5e9b76f37af1e1
Make sure only the app currently interacting with the IME can
query this, and restrict the API to apps targeting SDKs before T
Fixes: 204906124
Test: atest 'InputMethodManagerTest#getInputMethodWindowVisibleHeight_returnsZeroIfNotFocused'
Change-Id: If1da19a3dd8c29542afc970b4b201d87547c27a9
Merged-In: If1da19a3dd8c29542afc970b4b201d87547c27a9
When switching users and attempting to lock the device, the sysui main
thread becomes overwhelmed with events, creating a significant lag
between the time a message is posted and processed on the main
thread. This can be dangerous when these events are critical for
security, such as calls coming from PhoneWindowManager#lockNow() that
call KeyguardViewMediator#doKeyguardTimeout(). On older devices with
slower CPUs and less memory, the delay in processing can be
significant (15 - 30s).
The result of not prioritizing these events leads to a window of time
where a guest user can switch back to the owner, and gain access to
the owner's homescreen without needing to unlock the device with the
owner's credentials.
As a mitigation, prioritize two events originating in two specific
methods to make sure the device locks as soon as possible as well as
have the system server preemptively update its local cache.
Bug: 151095871
Test: Very manual race condition - follow steps listed in bug
Change-Id: I7585a0a5eeb308e0e32a4f77f581556d883b5cda
Merged-In: I7585a0a5eeb308e0e32a4f77f581556d883b5cda
(cherry picked from commit 28c53ab8bc)
A malicious application could overlay the activity. The overlay is
able to be tapped through, which can trick the user into starting a
harmful activity.
The CL added the flag SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS for
the activity to prevent the tapjacking/overlay attack.
Bug: 205595291
Test: atest CtsHarmfulAppWarningHostTestCases
Change-Id: Ia1a1ae0dc451e04bf5c31e3cb8cf30a0d8e32991
(cherry picked from commit a04b3666b8)
A malicious application could overlay the activity. The overlay is
able to be tapped through, which can trick the user into starting a
harmful activity.
The CL added the flag SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS for
the activity to prevent the tapjacking/overlay attack.
Bug: 205595291
Test: atest CtsHarmfulAppWarningHostTestCases
Change-Id: Ia1a1ae0dc451e04bf5c31e3cb8cf30a0d8e32991
(cherry picked from commit a04b3666b8)
Prevents non-system apps from placing a window over the app selection
screen.
Bug: 143559931
Test: Installed test app and attempted to overlay
Change-Id: Ied05088a5007e0f10cd3e1abd8d7da8ffeb3b674
Merged-In: Ied05088a5007e0f10cd3e1abd8d7da8ffeb3b674
(cherry picked from commit 34534e1fd2)
Prevents non-system apps from placing a window over the app selection
screen.
Bug: 143559931
Test: Installed test app and attempted to overlay
Change-Id: Ied05088a5007e0f10cd3e1abd8d7da8ffeb3b674
Merged-In: Ied05088a5007e0f10cd3e1abd8d7da8ffeb3b674
(cherry picked from commit 34534e1fd2)
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)
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)
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
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
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 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
