Both showSoftInputUnchecked() and closeCurrenInput() rely on rootView to
obtain window token. If view root is null, window has already gone away
and IME control had been revoked. Trying to show or hide at this time
would be a no-op.
Bug: 149900693
Test: Manually using the steps mentioned in bug and verify that there is
no NPE.
Change-Id: I294bb2ec5395d7502a855bafbac672af069e9b4a
Merged-In: I294bb2ec5395d7502a855bafbac672af069e9b4a
(cherry picked from commit ba9b716a70)
1. Clarify the distinction between the prioritized and non-prioritized
intents.
2. Make the priority ordering and choice of them more clear.
Test: make -j offline; preview updated docs for formatting.
Fixes: 150685399
Change-Id: I493bca75db44f25eedb07964e3dc8c8ab38827c2
Was lost in a rebase.
Bug: 150398686
Test: atest com.android.cts.devicepolicy.QuietModeHostsideTest
Test: manual verify no other ParsingPackage changes were lost
Change-Id: I3e17796433686ef38e24492c3255f5ccba1f431c
This covers the usecase when we show the share sheet or
intent resolver on a device with a work profile, and
the work profile is turned off. In that case, when
sharing from the personal profile, we show an empty
state screen with the option to turn on the work profile.
When we tap that button, we now show a spinner, as there
is a delay until the profile is actually enabled.
Fixes: 149821684
Test: manual
Change-Id: Id90b21a61b10ecce8172bddc42fdeec5fb61c5fe
Image wallpaper uses DisplayInfo to compute the wallpaper scaling.
When the wallpaper has a fixed rotation transform, its DisplayInfo do
not correspond to its transformed bounds.
We can't use the Configuration's bounds either because the wallpaper
token is created on the server side and we do not have a way to
propagate the changed configuration to a token created from the server.
Bug: 148000485
Test: atest WallpaperControllerTests#testWallpaperSizeWithFixedTransform
Change-Id: Ie80592ae868c980faddece17b94cd34178b1de0e
(cherry picked from commit f79baeaa20)
Provide a recording insets controller before the window gets
created, and replay the commands once a view gets attached. This
allows the client to use the controller in Activity.onCreate.
Test: WindowInsetsControllerTests
Bug: 118118435
Change-Id: I1a825ecc4367c02b27f2d08cd5442325315d4f89
Commit ag/9740370 caused problem with robotests b/149806146
The fix ag/10373855 froze targets like run_host_tests
This revert will unfreeze run_host_tests but robotests will break
Bug: 150011638
Test: m RunSettingsRoboTests0
Change-Id: Ibe954e9d0dc1542477ba7156da5799479631cfb0
* autofill will cache the inline suggestions response until it receives
a start input view event from IME
* the data flow from IMS point of view is:
IMS#startViews and IMS#doStartInput (before calling onStartInputView)
->
[async] InlineSuggestionsRequestCallback#onInputMethodStartInputView()
--- process boundary ---
->
IMMS.InlineSuggestionsRequestCallbackDecorator
#onInputMethodStartInputView()
->
InlineSuggestionSession.InlineSuggestionsRequestCallbackImpl
#onInputMethodStartInputView()
* similar data flow for IMS#finishViews()
* this CL should not block IME's UI thread because it's only issuing a
new async IPC from IMS start/finish input view call that's running on
the UI thread.
* there should not be performance impact on IMEs if autofill inline
integration is not active
Test: manual verification, atest EditorInfoTest
Test: atest android.autofillservice.cts.inline, with two failing cases:
InlineAugmentedLoginActivityTest#testAugmentedAutoFill_twoDatasetThenFilledSecond
and InlineAugmentedLoginActivityTest#testAugmentedAutoFill_oneDatasetThenFilled
due to the test itself being broken, I'll fix the test in a separate patch
Bug: 149522488
Bug: 149442582
Change-Id: I2faa3577b9f95a122f26a6d7fa7822a769a51e34
When an overlay is not specified as immutable through OverlayConfig,
enabling the overlay using the OverlayConfig `enable` attribute makes
the overlay enabled by default.
When an overlay is scanned by the OverlayManagerService for the first
time, the default-enabled state will be applied to the overlay. If the
configured default-enabled state changes in a subsequent boot, the
default-enabled state will not be applied to the overlay.
This means OTAs cannot change a mutable overlay from default-enabled
to default-disabled (or vice-versa) and except the configured enabled
state to take effect.
When the device is factory reset, then the configured enabled state
will be applied. If a package is removed from the device in one OTA
and added back to the device in a future OTA, the configured enabled
state will be applied. If an overlay changes its target package or
target overlayable, then the configured enabled state will be applied.
If an immutable overlay becomes mutable, then the configured enabled
state will be applied.
Bug: 149499802
Test: atest OverlayManagerServiceImplRebootTests
Change-Id: I24f86591ac811ef2b836da36ef5574a82628b151
When a service or activity attaches to a base context, add the
loaders from the application context to the base context. Activity
and service contexts are created before creating the Application
context, so in order to add the app loaders before the component
onCreate method is called, we must add the app loaders to the
component after the app has been initialized.
Bug: 148630842
Test: launch AppResourcesLoaders
Change-Id: I44aa718779c574094590d25fd839f1d9f9134edb
