| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Test: none
Bug: 237342281
Change-Id: Ia9e971152b7e297a78d79cbb79690f66d3029c9f
|
| |
|
|
|
|
|
|
|
|
| |
WindowProviderService to broadcast configuration changes to listeners.
This is needed to allow IME to listen to WindowLayoutInfo changes.
Bug: 237342281
Test: CTS InputMethodServiceTest
Change-Id: Id8ddce5889b52859172caf3b4f0763bb5010b5dc
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
fixes: 196781957
Test: atest WindowContextPolicyTests
Change-Id: If0f8e124f3ee7939bf1e121d6d73616ff07e0829
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we initialize WindowManager and associate DisplayArea in onCreate,
but apps may use WindowManager before WindowProviderService#onCreate.
The code may be like:
```
public void onCreate() {
WindowManager wm = getSystemService(Windowmanager.class);
wm.getCurrentWindowMetrics().getBounds(); // <--- crash here
super.onCreate()
...
}
```
This CL move the initialization step to attachBaseContext to prevent
the crash.
Test: atest WindowContextTests
Test: run gsi_avd/boot_health/vendor_img_rvc on ABTD
Bug: 191635763
Change-Id: Id8bad73a749813a90b307ac2b4d020f740631ea3
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also introduce IWindowManager#getDisplayIdToLaunchIme to make IMS
be aware of the launched display to prevent extra onConfigurationChanged
callback
Bug: 149463653
Test: atest MultiDisplaySystemDecorationTests CtsInputMethodTestCases
Test: atest ContextTest ContextIsUiContextTest
Test: manual - moving IME between 2 displays and displayArea within
display - config change received
Test: manual - the app to show IME crashed and focus is set to the
next task - no config change
Change-Id: Ie565e30ed5dd3f2cfe27355a6dded76dc3adc14b
|
|
|
A Window Provider Service is a Window-Context-like Service which handles
UI
components and is able to obtain the latest configuration.
The differences between a Window Context and a Window Provider Service
is that:
1. It is always associated with the primary display before
attachWindowToken() or WM#addView is called. It is suggested to
render UI
components after calling the APIs mentioned above.
2. A window context registers the listener in constructor and
unregisters it in finalize(), while a window provider service
registers the listener in onCreate() and unregisters in onDestroy().
3. Like the API Context#createWindowContext(int windowType, Bundle
options),
the users of a Window Provider Service need to override
provideWindowType and
provideOptions to pass the attributes.
4. When there's a configuration updates from the server side,
the Service#onConfigurationChanged callback will be invoked.(TBD)
It is suggested to use window context when possible. This class is to
migrate the
Service to show UI components to the window context concept. We can't
migrate them
to WindowContext directly because developers are used to use this kind
of Service as
the container of UI components and may change its property at runtime.
An example is that keyboard developers may apply a new theme by
InputMethodService#getResources#setTheme(newTheme).
Bug: 159767464
Test: atest WindowContextTests#testWindowProviderServiceLifecycle
Change-Id: I7d537fd2d128efa28aa6e771d77aa105fb497672
|
