A 540dp device causes keyguard to select SlidingChallengeLayout
and a height of 400dp which isn't enough space for the security
area. This fix adds an intermediate value to grow the security
area slightly.
Fixes bug 11344424
Change-Id: I35c979f619c593b604e4bf45afd3e591329229e4
Target the two biggest offenders:
- Coalesce keyguard setHidden(false) calls during unlock.
- Make sysui->WM call async.
Found during investigation into b/11221659.
Bug: 11221659
Change-Id: Icab48376bc356a933e0f9940bc2f924e2e77ab22
Add supplyPinReportResult & supplyPukReportResult that
returns the result code and attempts remaining.
Display "Attempts remaining" in Keyguard
Bug: 9928717
Change-Id: Ibad0635dd1375fabce11ba2b7b9f95f8868489e6
Transitions, when started, add an OnPreDrawListener to the current
ViewTreeObserver (which is global to the view hierarchy). This listener
is removed when the listener is called.
It is possible to add this listener and then remove the view from
the hierarchy before the listener is called. This could result in
either the listener not getting called at all (since there was no
drawing event) or (in the case of this bug) the listener getting called
when the sceneRoot had no AttachInfo (which is the case when that
root has been removed from the hierarchy). This results in the listener
trying to remove itself from a *different* ViewTreeObserver than the one
it added itself to, leaving the actual listener still sitting on a list
of listeners in that original VTO. This can result in a growing list of
listeners and a growing amount of work that gets done on every frame.
It can also lead to a serious memory leak, since the objects referred to
by the transition may be non-trivial (as in the case of this bug).
The fix is to add another mechanism for the listener to get removed.
Specifically, we now listen for detach events on the sceneRoot. If that
view gets detached before the listener is called, then we have a chance to
remove it from the correct VTO before the AttachInfo becomes null.
Issue #11307391 keyguard is slow after updating to krt16c and playing music
Change-Id: I108413ea2f18f5351df0a11d4ae56fec0b4aa154
This fix ensures that only one runnable is running at a time, no matter how
many events come in. There's probably a better way to do this, but this is a
safe fix.
Fixes bug 11307391
Change-Id: I007c95062b20285571f39603c95fb9174b9a2da3
This works around a problem where removing a review with unfinished
transitions results in leaked object references to KeyguardTransportControlView.
The workaround disables transitions until we have a better fix.
Fixes bug 11307391
Change-Id: I1df82f2c6f1cd9f5c9076d4c76cfd4aec3b6806c
While under heavy system load, keyguard was able to create widgets before
before ActivityManagerService was ready. The result was a race
between keyguard adding widgets and ActivityManagerService being
ready to send broadcasts.
This fix provides keyguard with an additional signal to know when
the system is booted and widgets are safe to load.
Fixes bug b/11217169
Change-Id: I7a714d65b068678f961e52bdde4e1c20f9c287f0
This fixes an issue where the mUpdateSeekBars runnable was being
repeatedly posted to the handler while keeping a reference to
the transport control (and hence keyguard). Even after the view
was detached from keyguard it would continue to post events that
would ultimately keep the instance of keyguard from being GC'd and
cause keyguard to slow down.
Fixes 11169793
Change-Id: If2bb238adf6d78101589926b60a61d9f187c6d1c
Make sure that caches are cleared at the right times and views have
their data populated correctly. Also fix a caching issue in
RemoteController.
Bug 11218218
Change-Id: Ieb833b5dc440ccd1b82050f12eb7059a4e0a412f
If a layout has already been requested when we want to show the
correct widget pane, post the event for later and immediately return.
This works because PagedView has some interesting ideas about
maintaining a consistent state. It will attempt to recalculate the
current page position during measurement, but thanks to a reliance on
this measurement to establish scrolling boundaries that scrollTo uses
for clamping plus other code that depends on the idea that it can add
a new widget pane view and immediately scroll to it, this attempt to
scroll fails if the target page was added and measurement is not yet
complete. This patch ensures we don't hit these edge cases in a few
known ways.
While this ends things in the correct state, it predictably has a few
visual artifacts. Situations where things would completely fail
before, positioning pages incorrectly or fading out wrong pages now
will briefly flash and fade the widget frames or in some cases will
visibly animate from the starting page to the correct one. We should
address these issues in a future release.
Bug 11217368
Bug 9760604
Change-Id: I989d03b5bfdd5b6403a6b67a8aae7585ca0c8ae0
This fixes an issue where keyguard isn't showing but tells
PhoneWindowManager to wait anyway. The fix is to send a null token
when keyguard isn't showing.
Fixes bug 11216030
Change-Id: I4985fe50c63819415d9d5a1de0b741c8aa6391d8
