Bug: 62692677
Test: Use an activity options that requires the bitmap copy, ensure
that it does not crash.
Change-Id: I20bdab1b91dfe47f7fe134fd17fe104eb4b27ec1
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
I will not pretend classes are interfaces...I will not pretend
classes are interfaces...
Bug: 62444724
Test: cts-tradefed run singleCommand cts -d -o --module CtsViewTestCases --test android.view.cts.SurfaceViewSyncTest#testSurfaceViewBigScale
go/wm-smoke
Change-Id: Iccca46edcd669430c32f31e9c7d8aba1db254f2d
- Move the bounds animation onto the animation thread
- Remove existing code referencing the old sf-vsync choreographer
- Add ability for ValueAnimator subclasses to reference a different
AnimationHandler, which uses a different FrameCallbackProvider with the
sf-vsync choreographer in the animations that require it
- Ensure that PiP touch events are batched and sent aligned with the
sf-vsync
- Move GC onto its own thread to not block other BackgroundThread calls
Bug: 36371375
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: bit FrameworksServicesTests:com.android.server.wm.BoundsAnimationControllerTests
Test: go/wm-smoke
Change-Id: I6a41b35a4e4d4d6dbea82c2673452825fe3ffa58
Allows for dumping the activity state during the last anr. This will
also be included in collected bug reports.
Bug: 38121026
Test: Cause an anr to occur and run 'adb shell dumpsys activity lastanr'
Change-Id: I1e4200f9e5cc16bfab98e5af31fc599cdd54cd11
