We only use parts of Context in the Content Capture manager and
main session, we don't need to cache context object which will
cause some memory issues.
This change will extract the necessary information to save it, instead
of caching the entire context object.
Bug: 256247718
Fixes: 239192932
Test: atest CtsContentCaptureServiceTestCases
Change-Id: Id7b5e8617c521f31879199b0f2c7e18204bb7526
Merged-In: Id7b5e8617c521f31879199b0f2c7e18204bb7526
(cherry picked from commit c3380c162b)
Otherwise if the language of the configuration is changed between
RTL and LTR, the layout direction may still keep the previous
direction after calling recreate().
Bug: 250868428
Test: The layout direction will change with below sample:
Configuration config = getResources().getConfiguration();
configconfiguration.setLocales(LocaleList.forLanguageTags("ar"));
getResources().updateConfiguration(configuconfigration, null);
recreate();
Change-Id: Iad405bf02b2f19cb3aa8cbc21f9bca67d8a53c30
When a translated Activity is destroyed or translation is finished
(e.g., finishTranslation() call), we also have to remove the entry in
the active translations we are keeping track in
TranslationManagerService. Prior to this change, we were not removing
the entry in the Activity destroyed case, and this caused problems when
a new callback is registered (e.g., Gboard) because it would incorrectly
get an onStarted() call for the now-inactive translation.
This can happen relatively frequently when the device has a work
profile, since switching to apps across profiles re-creates the IME, and
in the case of Gboard, it registers a callback every time.
Also added additional logging on Activity destroyed and when callbacks
are registered and triggered.
Bug: 245911471
Test: atest UiTranslationManagerTest
Change-Id: If1881fd4588725021d38e5b9336c3e69bca17039
Merged-In: If1881fd4588725021d38e5b9336c3e69bca17039
The condition in [1] was accidentally inverted. Then the activity
might get an intermediate config from view root but ActivityRecord
isn't aware of that.
[1]: I19af6cf7f9a4a27fbc987d920630e2de95ced602
Bug: 245225302
Test: atest WindowManagerServiceTests#testRelayoutExitingWindow
Change-Id: I4cbbd52f32019fbc7347365156b1e95399d1ecc7
It's broken currently, is extremely difficult to access, and will
need to be heavily rewritten/refactored anyway if we decide to
bring it back.
Fix: 249325548
Test: adb shell input keycombination -t 300 META_LEFT CTRL_LEFT
SHIFT_LEFT S
(now takes a regular screenshot)
Change-Id: I2cde564f6369b88bd4c6b20a9eecf8172fae7e7a
System apps can now register an InputDeviceBatteryListener on a
per-device basis to be notified of battery changes.
- InputManager manages registration of the binder callback with
InputManagerService to ensure that there is only one battery
listener per process.
- The battery listener is invoked immediately upon registration
to provide the initial battery state for the device.
- The callbacks are removed automatically when the process dies.
- This CL does not yet identify changes in battery state for monitored
devices.
DD: go/inputdevice-battery-notifications
Bug: 243005009
Test: atest FrameworkServicesTests
Test: atest FrameworkCoreTests
Change-Id: Idf2b06a099155a6f5cc13b55dcd40852f54aa56c
Merged-In: Idf2b06a099155a6f5cc13b55dcd40852f54aa56c
(cherry picked from commit e86f73ac50)
This reverts commit 975dd2c513.
Reason for revert: This is too risky for tm-qpr1
Bug: 161810301
Bug: 175861564
Change-Id: If906b4d538885fca407ce0bd7039c9d35b507032
When configuration changed, an Activity was relaunched because the
new layout size is smaller than old layout size. However, the
mLastConfigurationFromResources was not updated when relaunching
Activity while the window is preserved.
If the same Activity was resized to the previous bounds and the
configuration changes are not cross the size buckets, the Activity
won't be relaunched. Meanwhile, the View#onConfigurationChanged
was not reported because `mLastConfigurationFromResources` was not
update-to-date and was the same with the new configuration.
Bug: 247013643
Test: resizing the app in split-screen
Change-Id: I392417e1e6cc8bb5e8be0006b3b81385c3ef41aa
Sometimes, views may not be visible for the user immediately after
laid out, so add flag for do the evaluation once the view is visible.
Bug: 234429643
Test: Manual, check the fill dialog is appeared
Change-Id: I6b96b68ffc4a4b1ee5f5056848c5c4996d21ae73
When drawing is disabled the window's layer won't have a valid buffer. This
causes surfaceflinger to set the window's touchableRegion to zero.
This commit sets a window crop when drawing is disabled, so surfaceflinger
set touchableregion from crop instead of buffer.
And it modifies LetterboxUiController to not reset the crop.
Test: cts and perf tests as documented in go/android-slimulator-dev-env
Bug: 229870984
(cherry picked from commit 32dfc98382)
Merged-In: I4d6ca513c3daf5818ded03eae00e551fc319ad69
Change-Id: Ic8e1b17af825951505d448509530edf3ea81af5b
Their was a input coordinate discrepancy for dialogs when we use the wm
caption in the shell.
Test: tested manually on multiple builds
Bug: 244190356
Bug: 243950192
Change-Id: I84cf95a933e90062f20978e4e1f83276c100c326
The existing Keyguard Occlude Animation Runner doesn't match the spec
for Dream in. It animates activity expanding from the center of the
screen. For Dream in, we have:
- Dream fading in
- DreamOverlay complications fading in slightly delayed, with each part
starting at different times.
This CL adds dedicated AppTransitionType and remote animation runner,
which animates Dream fading in. It doesn't implement the separate
animation for DreamOverlay complications.
Bug: 222507937
Bug: 240477956
Bug: 242864189
Fix: 240477956
Test: on device, wait for Keyguard to time out to Dream.
Change-Id: I5517ded2eea77ea962ca1551ed51dd997ff09993
Merged-In: I5517ded2eea77ea962ca1551ed51dd997ff09993
The client needs to call relayout to get the valid surface if
- mFirst,
- mViewVisibility != viewVisibility,
- mNewSurfaceNeeded, or
- mAppVisibilityChanged.
We didn't cover mNewSurfaceNeeded or mAppVisibilityChanged previously.
All of them are covered by FLAG_WINDOW_VISIBILITY_CHANGED.
Bug: 244521023
Bug: 161810301
Test: 1. Enable LOCAL_LAYOUT
2. Open Camera and double press the power button.
See if the preview screen of Camera become blank.
Change-Id: I37fb8ffc9063b72bf3abba5d29fc2f750e7fc64f
This stores the computed decor insets and frame excluding insets.
So it can save 99% time of recomputing the insets every time during
starting an activity. E.g. dozen times of "prepare display info/frame,
compute window layout of insets source windows, calculate insets"
becomes "get result from array".
The saved decor insets will be updated when:
- Display metrics is changed (DC#updateBaseDisplayMetrics).
- Insets provider is added/removed/changed.
Also
- Use DisplayCutout rather than WmDisplayCutout to simplify
passing the cutout between methods.
- Optimize getSourceProvider to avoid unnecessary object allocation.
This also fixes an issue that the display doesn't compute the latest
configuration when navigation mode is changed. Now it is fixed by
checking if the insets provider has layout changes and then recompute
screen configuration.
Bug: 238399969
Bug: 159103089
Test: atest DisplayPolicyInsetsTests DisplayPolicyLayoutTests
DisplayPolicyTests#testUpdateDisplayConfigurationByDecor
Test: Change navigation mode or display size (density) in Settings.
And then swipe-up or press home key, there won't be a
frozen effect (display configuration change).
Change-Id: If6c28a89939372e6362b92f469ef7d793e8ec215
The original patch reverted as commit
bc0d5539e6.
This patch only includes the part of refactors to make the calculation
of configuration around insets easier. The actual change of making extra
navigation bar treated as navigation bar and the fix of the UiDevice in
ui automator is in a separate patch to avoid being blocked and blocking
other changes for long.
Test: PlatformScenarioTests
Test: TaplTestsQuickstep, ThemeIconsTest, TaplTestsLauncher3
Bug: 238981445
Bug: 238985243
Bug: 238581838
Bug: 233945217
Change-Id: If966bcc8125300d47d5cd631f7db17ff027e5261
This passive window inset animation control listener
is used to for logging purpose when hide, show
method is called.
Test: atest InsetsControllerTest
Bug: 240192346
Change-Id: I399268ead9d04b356f10cc3e9ac1da9e31306e86
This fixes issues with Views that have their own custom
ViewTranslationCallback.
Bug: 236678324
Test: atest CtsTranslationTestCases
Test: manual - Verified on chat app that uses their own custom
ViewTranslationCallback; old and new messages are translated
Test: manual - Spot-checked translation on a few other chat apps
Change-Id: If4194bc8cde73a9cebb7b56594f6982855374410
IWindowSession#relayoutAsync is similar to IWindowSession#relayout, but
the former is an oneway method which just sends the layout attributes to
the server. Since the client can compute its own window frame, it just
needs to send attributes to the server without getting blocked for
receving the window frame.
In somes cases, the client still needs to obtain things from the server.
Such as:
- When view visibility is changed. The client maybe not be able to
receive the latest insets state while it is INVISIBLE or GONE. In this
case, the client needs to obtain the frame and the insets state. Also,
the client need to obtain the surface control when it becomes VISIBLE.
- When the insets state is stale but the config is up-to-date. This can
happen when WindowProcessController sends the new config to the client
before WindowState does. In this case, the client needs to obtain the
window frame from the server.
- When the position and the size of the frame are both changed. This
will trigger a BLAST sync, and the client needs to obtain the sync seq
ID.
For cases above, the client needs to call the original relayout method.
Bug: 161810301
Bug: 175861051
Test: Seamless rotation, fixed rotation, and regular rotation.
Merged-In: Ifb365789fa08103773fd3180e486ba1d92042fc5
Change-Id: Ifb365789fa08103773fd3180e486ba1d92042fc5
