This change moves all of the mBiometricUnlock.installedAndSelected()
checks from inside the biometric sensor implementation to
LockPatternKeyguardView. There are several reasons for this change:
1) Instead of constructing a BiometricUnlock object and asking it if
it's enabled, LPKV can check this for itself and not even bother
constructing it if it's not enabled.
2) Since mBiometricUnlock will not be constructed if biometric unlock
isn't enabled, LPKV can simply do null checks to see if it should call
biometric unlock functions. So it serves the dual-purpose of ensuring
there will be no null-pointer exceptions with regards to using the
biometric unlock.
3) This greatly reduces the chance of bugs being introduced into
non-biometric unlock methods because no biometric unlock calls will be
attempted if biometric unlock is not enabled. Previously, the calls
would be made and then the biometric unlock would check if it was
enabled and return, which was not only bug-prone, but also
inefficient.
4) This simplifies the biometric unlock interface by removing an
unnecessary function call.
5) The biometric unlock implementations do not have to check if they
are installed every time they do something, which greatly cleans up
biometric unlock implementations. It makes much more sense for the
biometric unlock functions to be able to assume that they aren't
being called unless they should be.
6) Eventually when there is more than one possible biometric unlock
method, it will make much more sense for LPKV to be in charge of
what is constructed and what isn't.
Change-Id: I5437ac05d8ceb2b182fe372cd6c75ad944ade28f
1. The AccessibilityInteractionController was using an incorrect
looper i.e. not the UI thread looper which was causing getting
the root node to fail.
2. The AccessibilityNodeInfo was populated by a ViewGroup with the
children for accessibility without checking whether these children
are really displayed.
bug:6362875
Change-Id: I7906d89571eb9d57d10f971639f88632926dd077
Bug: 5416822
The overload of webkitDraw is temporary, but this gets the plumbing
in place and works correctly
Change-Id: Ib3e23b9a4a1862dd445c8dc68a3936590787a62b
When views are removed from a view or a view is detached from
a window, we need to update the touch and hover targets appropriately.
Failing to do this resulted in a NPE while dispatching an
ACTION_HOVER_EXIT to a view that had previously been removed.
Removed views should not get input events.
Change-Id: I4af4f8e2c4028347d3f570894fd1b3b366d11455
Bug 6366482
The animation engine now notifies onAnimationStart() and
onAnimationEnd() even when it does no action. This CL prevents
the setVisiblity call from causing an infinite loop of triggering
animation notifications.
Change-Id: I009217a42debf1a1495da222199ca8f599fa7bcf
Action bar tabs now stack in portrait mode on all screen sizes rather
than display embedded. This only affects apps with a targetSdkVersion
of JB or greater, as older apps may not be prepared for the different
measurement of the bar or have an appropriate stacked bar background
drawable.
Stacked action bar tabs now have a width limit. This prevents
super-wide tabs that can span the whole screen. The cluster of tabs
is centered if it does not span the full width.
Add ActionBarPolicy to give a single point to query for various action
bar measurements and behaviors that vary with configuration.
Change-Id: I01162ca009c14f6f0e712fc906b9db6382c738cd
o Throw runtime exception when selectTrack, unselectTrack, getTrackInfo fails
o remove redundant code for selectTrack and unselectTrack methods
o related-to-bug: 6110705,5542712
Change-Id: I59f0ed638e93d0365eccab1e33c9d50354a9c1ba
A View that is not attached will place posted actions on the
ViewRoot's runQueue. Previously, this runQueue was only ever executed
during a layout (during performTraversals()). This works in most situations
(a View that is added to or removed from the hierarchy will force a layout
in general), but not in all cases. For example, a new View being added to
a ListView will not cause a layout, so any actions posted to that View
prior to its being attached will not be run until some indeterminate time
later when a layout happens to run.
The fix is to execute the (typically empty) runQueue on every traversal.
Issue #6366678 View.post() ignored when called on an unattached ListView item
Change-Id: I94e6fdd9da6bb57fd83b547f8d742cd0ddfecbd6
DO NOT MERGE
this change must be hand-merged into master due to directory
restructuring.
Don't perform the end PTS calculation for each buffer during trimming.
Instead, only calculate the ending PTS of a buffer if there is no next
buffer in the queue. This optimization assumes that the buffers being
queued are in monotonic media time order (a fair assumption for now)
and that the timestamps in the audio are contiguous (not a requirement
for this API, but a reality of how it is being used right now).
In the case where the audio is discontinuous on purpose, it is
that this optimization will cause the system hold one extra buffer
which it could have safely trimmed. It should not be much of an issue
since in real life the audio is almost always contiguous, and as long
as the media clock is running and the mixer is mixing, the buffer will
be used up and discard as part of the normal flow anyway.
Change-Id: I00061e85ee7d5651fcf80751646c7d7415894a14
Signed-off-by: John Grossman <johngro@google.com>
DO NOT MERGE
this change must be hand-merged into master due to directory
restructuring.
Fix issues with continuity threshold handling; notably
+ If the steady-state continuity threshold is exceeded, be sure to
clear the on-time flag. Failure to do this will result in the
system picking a new mix point which simply satisfies the
steady-state continuity threshold instead of the startup threshold.
Since we are putting a discontinuity in presentation anyway, we
really want to pick a perfect point, not just an OK point.
+ Tighten the steady-state continuity threshold. It was currently set
to 100mSec which is enormous. 4mSec (the new setting) is much more
appropriate. On systems with a VCXO (like tungsten) this should
never be wrong by more than a sample. If TimedAudioTracks are ever
to be used on VCXO-less systems, this threshold should probably be a
a parameter configurable by applications on a track by track basis
so they can make the tradeoff between allowed error and frequency of
disruptive corrections.
+ Reset the on-time flag if the mixer provides no PTS during a mix
operation. This makes for a convenient way for the HAL to reset
timed tracks when it makes changes for delay compensation across
multiple outputs.
Change-Id: I2cb23de5a3d1f75618abc1c8ab903db883837aa8
Signed-off-by: John Grossman <johngro@google.com>
