The root cause of the exception was that the activity destroy listener was
reacting to any activity being destroyed instead of just the one used with
the CompanionDeviceManager
Fixes: 62549525
Test: Ensure the attached bug no longer reproduces
Change-Id: I2f977e9ac9176247f5be9d08d19b3875f2b4a703
Autofill seems to need IDs to be preserved across things
like configuration changes, while accessibility will not
function without views with unique ids. Separating out the
two types of IDs. We can re-combine them once it's clear
that both demands can be satisfied.
Bug: 62301218
Test: Run a11y and autofill CTS, and verify that the play
store app functions with TalkBack after a screen rotation.
Change-Id: I17a99de2874768fc0ade3aa354130dd1f6b4cd7e
There are some apps that use the Surface object itself to indicate
changes. As a result, recycling the existing Surface object for
updates can lead to such apps ignoring events such as size changes.
This changelist restores the original behavior for legacy apps, where
the underlying native Surface object is recreated during updates.
Fixes: 62108743
Test: go/wm-smoke
Test: Open affected application, observe expansion to fullscreen when
nav bar disappears. Rotate to other orientation and observe
expansion to fullscreen.
Change-Id: I874602b6b8686c6ecb05cf7b1a04ec4b700ad3f9
Session was using findViewNodesByAutofillIds(ids) before, which not only was
not optimal, but error prone (for example, it could return a non-empty array
with an empty value).
Test: CtsAutoFillServiceTestCases pass
Fixes: 62532979
Change-Id: If984f1263cc3f2aac1d1e098687fe02d73c55211
Currently if View.setTooltipText is called while
the tooltip is being shown for that view, it will
update the displayed text. The tooltip then will
resize to wrap around the new text, but not change
its position. This looks confusing if the new text
is significantly shorter or longer.
Removing this functionality until proper
re-positioning is implemented.
Bug: 38491655
Test: android.view.cts.TooltipTest passes
Change-Id: I79689288185888854b992b89e19fe381d3ac50e4
Bug: 62692677
Test: Use an activity options that requires the bitmap copy, ensure
that it does not crash.
Change-Id: I20bdab1b91dfe47f7fe134fd17fe104eb4b27ec1
- Unify logic for detecting availability of the accessibility button
- Ensure the initial visibility state is propagated to A11yMS
- Ensure services only receive availability callbacks for changes
Test: Manual, created test accessibility services
targeting specific breakages
Bug: 38345417
Change-Id: I2250b32830cdfc2ecdc1dff7b7130dced2c1db29
Test: existing CtsAutoFillServiceTestCases pass
Test: manual verification using Contacts app
Test: manual verification adding a CTS test case that crashes the app, but such
test cannot be commit because once the issue is fixed, it crashes the
service (the right way to test this fix is through unit tests against
exceptional conditions, but we don't support those on Autofill yet).
Fixes: 62649290
Change-Id: I8fc01fa929270219cd40035ff02eaf0dda5ecbfa
Let's first understand how mView could become null. Notice
at the beginning of performTraversals, there is a check that
mView != null, and so it is nulled while we are in the function.
mView is package private and there are only two places which assign
to it, ViewRootImpl#setView and ViewRootImpl#doDie. setView is guarded
by mView == null. But mView was not null (per the check at the beginning
of performTraversals) and so mView is being nulled by doDie().
doDie() only has 3 callpoints:
1. ViewRootImpl#die(). Here though, calling it is guarded by
!mIsInTraversal. !mIsInTraversal is unconditionally set at the
beginning of performTraversals, and so this isn't our caller.
2. ViewRootHandler, handling MSG_DIE. This runs on the same thread
as performTraversal, and so it can't be our nuller.
3. WindowManagerGlobal#addView. This must be our nuller.
We see WindowManagerGlobal#addView will call doDie in the case that
we attempt to add a view which we had previously set to be removed
but deferred removal of. Now we can construct a reasonable sequence
for getting here:
1. requestLayout(). Perform traversals ends up on handler.
2. removeView(). MSG_DIE ends up on handler, View ends up in mDyingViews
3. performTraversals is executed by the handler
4. From a callback initiated by performTraversals (e.g. measure)
the client calls WindowManagerGlobal#addView on the view which
was just removed.
5. We are still in performTraversals so MSG_DIE hasn't been processed
yet. This means that WindowManagerGlobal will perform the doDie
immediately nulling mView.
6. We return to performTraversals and crash.
We can see shortly after the offending call to doDie, a new ViewRoot will be
constructed and so whatever traversal we are doing on the old one doesn't
seem particularly important. It doesn't seem that we can do any better
than letting it fall through without crashing.
Bug: 38421184
Test: go/wm-smoke. Feed to the monkeys.
Change-Id: I55f310a3533175c9df4a82878be5a60fd01b80c1
Change-Id: I997b8ae515f7bf2570edca4ed7ab4b46198148a5
Fixes: 62591398
Test: Manual; install instant app and see that it doesn't dexopt
Test: Manua; update gservices flag, install instant app and see that it does dexopt
...can't hide themselves
Tune the policies for when we tell about apps running in the
background after their services have stopped.
- If it ran while the screen was on, the time we require for it
to be running is much shorter (a couple seconds) as well as the
time we tell about it having run (with another tunable for the
minimum time we tell about this).
- If it has only run while the screen is off and stops a sufficient
amount of time before the screen goes on (currently a second) then
we will not show anything when the screen goes on.
- If it stops when the screen turns on, we will make sure the user
sees about it for a short period of time (currently 5 seconds).
Also includes some improved debug output about handler message
queues.
Test: manual
Change-Id: Iab438410d7182b2dfe4f9c1cce7069b26b34834c
To workaround a deadlock caused by bufferqueue locks
we force RenderThread over to use async mode which
we enable via eglSwapInterval(0)
Bug: 38372997
Test: steps in the bug
Change-Id: Ia305f73abbdd64ab0c25d1f7d32792cc6295a0ce
Instead of maintaining a separate structure just for overlay
paths, store them as user state in the package setting. Also
centralize updating the overlay paths to avoid issues with
inconsistent updates.
Fixes: 36561125
Test: Manual
Change-Id: Iac1c987e8650074dbc564e332d5da1950fad6ac5
Currently when WM detects certain events, it will notify the logger
of these events asynchronously and logger uses the timestamp at which it
gets notified to log these events. It's possible that the delay between
when the event actually occurs and when the logger gets notified could be
large. So for better accuracy, WM should also pass on the event timestamp
to the logger.
Bug: 62375480
Test: Triggered sysui_multi_action event logs and verified that
APP_TRANSITION_DELAY_MS is less than APP_TRANSITION_WINDOWS_DRAWN_DELAY_MS.
Test: When the system is not busy, the timestamps we used to log earlier
and timestamps we log with this change are almost same.
Change-Id: I5f62654a6b7f179d821c0082b180246c8a569df1
This is required for migration scenario, where device(s) are already
paired(and thus no longer discoverable) but didn't go through companion
flow.
This also fixes a bug with filtering by mac address, which is also relevant to
the use-case of associating a specific device
Test: Pair with a device first, and call associate with a filter with its MAC
address and single device requested. Ensure the device is found.
Ensure only that device is ever returned when filtering by MAC address.
Bug: 62487084
Change-Id: Ic7cc6affc0648ad85b15620e8c3aba4b9fc91aa1
Retrieving list of methods in every invoke() call is very expensive.
Caching the list inside the constructor prevents several unnecessary
calls to Class.getMethods().
Test: Run camera2 CTS
Bug: 62490715
Change-Id: Ib2a93af0f364b055df2eab9bd7870730428429ad
