summaryrefslogtreecommitdiff
path: root/core/java/android/window/WindowTokenClient.java
Commit message (Collapse)AuthorAgeFilesLines
* Fix memory usage issue on WindowTokenClientMing-Shin Lu2022-05-091-11/+17
| | | | | | | | | | | | | | As WindowTokenClient#{onConfigurationChanged, onWindowTokenRemoved} requires to post on mainthread, in case posting runnable accquires more java objects to increase java heap memory, use PooledLambda to obtain cached runnable for saving memory usage. Also, use ActivityThread.currentActivityThread.getHandler to get the main handler rather than creating the new object. Fix: 215447496 Test: run MemoryOnBoot Change-Id: Idb2c01a0da02ff669e1a3f1a55f4841f7aa258ba
* Revert^2 Fix testRegisterComponentCallbacksOnWindowContext flakyCharles Chen2022-04-251-14/+35
| | | | | | | | | | | | | | | | | | | | | This flakiness is due to race of config updates when WindowContext attaches to DisplyArea. This CL fixed it by: 1. Don't dispatch config updates to the client side when registering to DA. We have reported the value by the return value of #attachWindowContextToDisplayArea. 2. Add lock in WindowTokenClient#onConfigurationChanged to avoid race. During applying DA's config to WindowContext, WindowContext may get another callback from the server side and dispatch to ComponentCallbacks unexpectedly. Bug: 190019118 fixes: 228911504 Bug: 230022846 Test: atest RegisterComponentCallbacksTest --iterations Test: atest WindowContextTest WindowContextTests Test: atest WindowMetricsWindowContextTests Change-Id: I2d749a058c7a3828c8c8288040236f005aa00ab6
* Merge "Fix IME shrunk by WindowTokenClient mis-detach" into sc-v2-devTreeHugger Robot2022-01-151-12/+22
|\
| * Fix IME shrunk by WindowTokenClient mis-detachMing-Shin Lu2022-01-141-12/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As CL[1] introduced WindowTokenClient for WindowProviderService (aka the parent class of InputMethodService starts from CL[2]) as a token that IME context can associate with the windowContainer of the InputMethod window in server side. Like the activity context, IME context can adopt configuration/resources update when the IME window changed by display/window changes. And, the IME context caller can also create another type of context with wrapping IME context (i.e. calling createDisplayContext to create a display context), that makes this context can be mixed the window token of WindowProviderService since it's the base context. However, the finalization of the context mixed WindowTokenClient will detach the token when the attached context type is non-window context, this action will mis-detach the token when it managed by WindowProviderService. So like SoftKeyboard previously using createDisplayContext in CL[3] to workaround context resources issues, will in-directly expose this mis-detach token issue as the above. Beside, the handling of WindowTokenClient#{onConfigurationChange, onWindowTokenRemoved} does not thread-safe since this is called from IPC. As the result, the fix is to ignore the check in ContextImpl#finalize to not detach the token when it managed by WindowProviderService, also make sure to post to the main handler when received onConfigurationChanged/onWindowTokenRemoved in WindowTokenClient. Note that this fix could help to resolve "The Window Context should have been attached to a DisplayArea." exception if the token has been detached as the above case that happens before the next WindowProviderService#attachToWindowToken invoked. [1]: I64a1614f32d097785915f6105b1813a929e0fe32 [2]: Ie565e30ed5dd3f2cfe27355a6dded76dc3adc14b [3]: Ic592a1d2fb2da149220c8b503b522b3e864bcc77 Bug: 213118079 Bug: 211062619 Test: manual as steps: 1) adb install -r EditTextVariations.apk 2) adb install -r SoftKeyboard.apk 3) adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard 4) adb shell ime set com.example.android.softkeyboard/.SoftKeyboard5 5) Enable screen auto-rotation 6) Launch EditTextVariations from launcher's shortcut 7) Tap the first EditText field to show IME 8) Rotate the device to the landscape mode 9) Expect the IME should not be shrunk Change-Id: I7beb7a122af93e596239a36db62073233cea0726
* | Reduce cost of WindowTokenClient config changeRiddle Hsu2021-12-131-9/+1
|/ | | | | | | | | | | | | | | | The SizeConfigurationBuckets was used to avoid activity relaunch by insignificant configuration change. Because WindowTokenClient doesn't have relaunch operation, it is unnecessary to use it. Especially Resources#getSizeConfigurations() is a heavy invocation, which may create hundreds of temporal Configuration when calling it in system server. Also fix leakage of SystemUiContext if it is detached, e.g. the associated display is removed. Bug: 207620458 Test: atest WindowContextControllerTest Change-Id: I8388a2ab25f3deed2e29eb5636c4b2130f4f1b87
* [RESTRICT AUTOMERGE] Associate SystemUiContext with DisplayContentCharles Chen2021-11-181-0/+91
| | | | | | | | | | | | | | | | | Before this CL, SystemUiContexts were fixed to the Display metrics when the SystemUiContexts were created. It is the same mechanism as DisplayContext but applies to SystemUiContexts unexpectedly. This CL makes SystemUiContexts associate with DisplayContent with the corresponding display ID. In this way, SystemUiContext would receive updates when there is a Display property change. Bug: 194262507 Bug: 191064581 Bug: 205859784 Test: atest InputMethodMenuControllerTest WindowContextControllerTest Test: atest NexusLauncherTests Change-Id: I64a1614f32d097785915f6105b1813a929e0fe32
* Revert "[RESTRICT AUTOMERGE] Associate SystemUiContext with DisplayContent"Alex Chau2021-11-111-91/+0
| | | | | | | | | | | This reverts commit 71b2172abc534e43a842e5834b0cf6636e0a63c3. Reason for revert: See b/205859784, breaks launcher tests Bug: 205859784 Bug: 194262507 Bug: 191064581 Change-Id: Iaac32bd4142c0539300725dc2f6e4255fefc8b2f
* [RESTRICT AUTOMERGE] Associate SystemUiContext with DisplayContentCharles Chen2021-11-101-0/+91
| | | | | | | | | | | | | | | Before this CL, SystemUiContexts were fixed to the Display metrics when the SystemUiContexts were created. It is the same mechanism as DisplayContext but applies to SystemUiContexts unexpectedly. This CL makes SystemUiContexts associate with DisplayContent with the corresponding display ID. In this way, SystemUiContext would receive updates when there is a Display property change. Bug: 194262507 Bug: 191064581 Test: atest InputMethodMenuControllerTest WindowContextControllerTest Change-Id: Idd74da965c18bdbf8912bd45e89be21f652dcf93
* Allow WPS to create windows with multiple typeCharles Chen2021-08-111-0/+2
| | | | | | | | | | | | | | | | | | | Before WindowProviderService, Service can add windows with several window types. This is previously not allowed for WindowProviderService because a context can only associate with a window container. However, it may cause regressions because Service is used to add windows with multiple types. This CL allows WindowProviderService to do so, but WindowProviderService can only associate with the window type returned by #getWindowType. This CL also extracts some methods to WindowContext interface so that WindowContext and WindowProviderService can reuse the same interface. Test: atest WindowContextPolicyTests StrictModeTest Test: atest ContextIsUiContextTest ContextGetDisplayTest Test: atest WindowContextTest WindowContextTests fixes: 191959013 Change-Id: Ie16916b370a4cbb8a17ccaec9870d47b4b089390
* Send DA's config directly when attaching to DACharles Chen2021-07-051-12/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | WindowContext relies on WindowTokenClient#onConfigurationChanged after calling WMS#attachWindowContextToDisplayArea. However, it took some time to wait for onConfigurationChanged callback from the server side so that we may get a stale value right after creating WindowContext. This confuses developers especially when the foreground activity is in size compat mode or freeform because the process config is overridden by activity's config. This CL makes #attachWindowContextToDisplayArea return DA's configuration and applies to WindowContext direcly. It also benefits WindowProviderService because it can obtain DA's configuration before onCreate() based on [1] and this CL. Bug: 190019118 Bug: 190745506 Test: manual - 1. launch an Activity in size compat mode 2. create a WindowContext and verify if WindowMetrics matches DA bounds. Test: atest WindowContextTest WindowContextTests Test: atest WindowContextControllerTest ContextGetDisplayTest [1]: dd4a748af05851356b5dbd90fb42f503905370bb Change-Id: I8dd3987b731662502bc01e9d2ed67e718ada5f46
* Move IME log to WindowTokenClientCharles Chen2021-06-181-0/+23
| | | | | | | | | | | | IMF has the requirement to debug if the configuration is dispatched to InputMethodService. Since we migrated InputMethodService to WindowProviderService, we should also move the debug logic to WindowContext module because config updates will be no longer from ActivityThread. Test: build & run Bug: 135719017 Change-Id: I248c90f36249a6a4537228f7b0204f0d4466ebc7
* Handle WindowProviderService#onConfigurationChangedCharles Chen2021-06-181-7/+32
| | | | | | | | | | | This CL makes WindowProviderService receive onConfigurationChanged callback when there's a config update from WM side. Test: atest WindowContextTests Test: atest ActivityThreadTest ActivityClientTest ConfigurationHelperTest fixes: 185766946 Change-Id: I922d52c1c38aecc1a948c79039cc03354adc646f
* Remove WMG#closeAll in WindowTokenClientCharles Chen2021-04-091-6/+0
| | | | | | | | | | | | The non-activity window should be managed by the application itself. Framework side doesn't need to handle it. Also apps may remove the view after WMG#closeAll and cause IllegalArgumentException "not attached to window manager". Test: atest WindowContextTest Test: atest WindowContextTests WindowContextPolicyTests Bug: 183251523 Change-Id: I15ccb9a129f541f3be9733e8cd6121bb4c0fd6b8
* Move WindowContext module to window packageCharles Chen2021-03-241-0/+103
In this way, we can clarify the owners and it is easier to maintain. Also refactor to move WindowContext creation logic to ContextImpl. Test: atest WindowContext WindowContextTests WindowContextPolicyTests Bug: 159767464 Bug: 152193787 Change-Id: I78432aa18aa97e001f5a9a04321109e456fd137b
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-21 11:20:11 +0000