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
Not 100% sure why it was flickering, but I do know that the
flicker started happening after putting this into a separate
thread, and that with that change it doesn't flicker anymore,
ever.
Adds 0.5ms while unlocking but at this point this is a good trade-
off to make.
Test: Unlock device with FP
Change-Id: I736a3c64d9b63df9d6cdcb7855bde13a19560a83
Fixes: 62380221
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
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
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
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
This will allow the NotificationMenuRow plugin to do something else
rather than showing a menu when the view is long pressed.
- Allow menu to intercept touch events
- If the menu item provided to long press is null, don’t show it
- Also passes the status bar notification when the menu is created
or updated
Bug: 62534409
Test: manual, have no plugin and long press -> see notification info
have a plugin that returns null for long press -> nothing happens
Change-Id: I384c5217d5343e990f4c3506eb2477b015705e5c
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
This CL will be reverted once it merges into the next release branch
to re-introduce the proposed APIs.
This CL also makes the following code changes to preserve API
compatibility:
-- It keeps the recently added RemoteViews.clone() synchronized logic
intact, but moves it inside the method to avoid changing the API
signature.
-- It reverts the RttCall.read() behavior to the oc-dev logic, since
we can't throw IOException until we get an API level bump. (The
original logic returned null instead of throwing.)
Test: builds, boots
Bug: 62427252, 62431886, 62427329
Bug: 62468911, 62431162, 62428935, 62429096
Bug: 37290820, 37359238, 36886243
Bug: 30143923, 35761231, 62192626, 29829689
Change-Id: I83d723f598cb0ee1fe198e65debd86ef7fd0420c
It was set to 3 (handover+reliability) during the development
cycle, but should not be set to a nonzero value on user devices
until the returned value takes into account the amount of
non-default network data usage.
Bug: 34630278
Test: marlin builds and boots
Test: ConnectivityServiceTest passes
Change-Id: I2b09a6e09c497886862cbaaaf3b283dedfbfa94c