| 446079600ece83b22cb91865bcbeb694292b0108 |
|
16-Mar-2017 |
Andrii Kulian <akulian@google.com> |
Separate global and override config sent to client
There is some flakiness in View#onConfigurationChanged callback -
if ViewRootImpl receives config update earlier than ActivityThread,
it may not detect the configuration change and skip inner updates.
Also now ViewRootImpl assumes that it receives the global config as
a param, but instead it gets merged config from WM. This means that
ViewRootImpl#sConfigCallbacks was sending incorrect values to the
recipients.
This CL switches to sending global and override configuration to the
client separately. Also in case if there is a corresponding activity,
it first updates it and waits for update callback to ViewRootImpl.
This way global config and override config for activity will always
be set first and resources will be updated before inner state of
ViewRootImpl is updated.
Bug: 35870157
Bug: 34164473
Test: android.server.cts.ActivityManagerDisplayTests
Test: testOnMovedToDisplayCallback
Change-Id: Ic9e7541cf25ecfac6ec90e48f7efb0ece91f657e
/frameworks/base/services/tests/servicestests/src/com/android/server/wm/TestIWindow.java
|
| b047b8bd7e363081e91ba6cbc8d09cd355624584 |
|
09-Feb-2017 |
Andrii Kulian <akulian@google.com> |
Report move to display for activities that handle config changes
When activity that is moved between displays handles all configuration
changes, it won't be restarted. This CL adds a callback to the client
to notify it about display change. Usually it will be followed by
onConfigurationChanged, except when configuration didn't actually change.
When activity is recreated, it won't receive onMovedToDisplay.
Bug: 34862802
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testOnMovedToDisplayCallback
Change-Id: I9a9501cab788623ada15a31efb53e4b2378639fe
/frameworks/base/services/tests/servicestests/src/com/android/server/wm/TestIWindow.java
|
| 3787de16d24001eeb452e1c711d4290a396e67c9 |
|
21-Dec-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Implement pointer capture API
When in pointer capture mode, mouse pointer disappears and
further mouse events are dispatched to the focused view
in the window which has requested capture.
The captured events have the source SOURCE_MOUSE_RELATIVE
belonging to SOURCE_CLASS_TRACKBALL. They are
dispatched through dispatchCapturedPointerEvent /
onCapturedPointerEvent. There is also a new listener.
Pointer capture mode may only be granted to a currently
focused window, and will be canceled upon a window focus change.
Test: cts-tradefed ... --test android.view.cts.PointerCaptureTest
Bug: 30897034
Change-Id: I6e5934aa415ac2b6dda1cee173d0f23e5021af84
/frameworks/base/services/tests/servicestests/src/com/android/server/wm/TestIWindow.java
|
| b699ce0d06eb6be91c0be0a791d8d8d7c68b4f41 |
|
18-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added foundation for supporting unit tests in WindowManager
- Check for null where appropriate when using WM from a test
- Inject WindowManagerPolicy for test can have its own policy
- Added skeleton for WindowStateTests that will contain tests
for WindowState class.
Bug: 30060889
Change-Id: I0cd7d50c98de16c7412759401075c4bb48d13dfe
/frameworks/base/services/tests/servicestests/src/com/android/server/wm/TestIWindow.java
|