The first issue is the animating a display as a consequence of the
freezing due to configuration change during construction. This
additional animation is not expected and interferes with tests
expecting for the original display contents to be shown intact. This
CL addresses the issue by not freezing while the display is not ready
(before construction is finished).
The second problem addressed is book-keeping for
DisplayContentsAnimators in WindowAnimator. Currently, a getter
method is used internally to reference these animators, which
generates them if not present and adds them to the animation
iteration. In the case we set an animation on a display that no
longer exists (which can be the case after unfreezing), we end up
recreating this object. This can lead to us trying to animate a
non-existent DisplayContent. This CL prevents creating an animator
for a non-existent display and adjusts the methods using this getter
to handle this case.
Fixes: 62460846
Fixes: 62461229
Bug: 35486733
Bug: 62541591
Test: go/wm-smoke
Test: open and close projected android auto mode repeatedly and
ensure display correctness
Test: cts-tradefed run singleCommand cts-dev --module CtsMediaTestCases --test android.media.cts.EncodeVirtualDisplayTest#testEncodeVirtualDisplay
Change-Id: I60ade6f97440c8fa01b10e36c019865cf1fd0730
mHistoricalSessions maintained a strong reference to a PackageInstallerSession,
which in turn kept references to Bitmaps and other heavy-weight objects around.
Since this field is primarily used for debugging, this change replaces it with
a String dump of the session in question. Each dump takes about 600bytes, which
is comparable to the sizes of the un-serialized raw objects.
Bug: 62485552
Test: Manual
Change-Id: I4949a64b538ab4a97384f4f8bc9a6ef155a4b128
We normally prevent apps from allocating into the "reserved" cache
space, but this change makes an exception for an active camera app,
since the user is probably trying to capture an important memory.
This change only lets the active camera app clear up to half of the
reserved space, since we don't want to completely destroy the
experience of all other apps.
Test: manual app before/during/after active camera session
Bug: 38267830
Change-Id: Ie9e63884fb2638ca881e10b894629eea84601648
Since okToDisplay was false when we started the keyguard exit
animation, no animation was applied and we didn't create a
starting window, which lead to flickering. We fix this by
allowing animations from mScreenOnEarly.
Furthermore, we synchronize the navigation bar better with the
rest of the animation.
We also need to apply no animation to the status bar window as
we go through performShowLocked because we were waiting for it
to draw.
Test: go/wm-smoke
Test: Wake-and-unlock
Test: Make sure no other regression with screen on experience
Change-Id: I5f264b74cc258e8d7f608978edfb1faa5ead385c
Fixes: 38441599
OTA fails on fugu under quiescent mode because the reboot reason changes
from "recovery-update" to "recovery-update,quiescent". The new reason
isn't checked in shutdown thread so that shutdown thread doesn't call
uncrypt properly before rebooting into recovery.
Bug: 62324707
Test: Recreated and fixed the "block.map" missing failure on fugu.
Change-Id: I110653cd64dbbdc71e89ead2197bf023a7c054e8
we only want to log the successes
Change-Id: I31c79a1c964088ee67fd7527ca7fea16b0d29830
Fixes: 36563095
Test: Manual; run and see that only the success events are in the eventlog
- 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
When invoking updateAllRecognitions, if a callback binder was determined
to have died, an internal function would go and remove it from
mModelDataMap. However, updateAllRecognitions was iterating over this
map, so it would then explode. By first making a copy of the model datas
before iterating over all of them, this problem is avoided.
(As part of trying to figure out what was happening, also updated all
the method names that implicitly assumed they had a lock, and double
checked that everything with a Locked suffix is actually locked)
Bug: 62487479
Test: Use the sound trigger test app to load and start two models, force
kill the app (so the dangling binders hang around), then enable power
save (which triggers the call to updateAllRecognitions)
Change-Id: I87b9dfc1b2af5e294050b146737916ccaad882c1
When invoking updateAllRecognitions, if a callback binder was determined
to have died, an internal function would go and remove it from
mModelDataMap. However, updateAllRecognitions was iterating over this
map, so it would then explode. By first making a copy of the model datas
before iterating over all of them, this problem is avoided.
(As part of trying to figure out what was happening, also updated all
the method names that implicitly assumed they had a lock, and double
checked that everything with a Locked suffix is actually locked)
Bug: 62487479
Test: Use the sound trigger test app to load and start two models, force
kill the app (so the dangling binders hang around), then enable power
save (which triggers the call to updateAllRecognitions)
Change-Id: I87b9dfc1b2af5e294050b146737916ccaad882c1
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
...JobServiceEngineImpl$WrapperWorkItem.complete
Add more useful information in the security exception message that
is shown -- the reason the last job that was running on the context
was stopped. This should tell you why when you are calling at that
point your job is no longer running.
Test: bit CtsJobSchedulerTestCases:*
Change-Id: Ia7155248b4b4f032cbf8e8754c5437f658ed192c
Also, use the correct default value when querying the setting when
starting demo mode.
BUG: 62346506
Test: manually flash and run through setup wizard
Change-Id: Ie9a5ae8a998eb267fcf1f509cb93ea6f566b3c96
We need to conditionally set the prevPriority only if we enter
the first locked section. Otherwise we'll never reset back to the
lower priorities.
Test: Make sure no binder threads are stuck at 110.
Test: go/wm-smoke
Bug: 36631902
Change-Id: I8a9c329bc3084371022da91eabee45943c1b8c9f
