When creating an AudioRecord instance, filter the tags in the
AudioAttributes to remove tags that are handled at the Java
layer.
Bug: 18733215
Bug: 18736417
Change-Id: I16a3497742086deced4e8677bd6231290396c5f6
Changed not to return <Feature Abort> if the command comes
with any vendor-specific data, which is still valid.
Bug: 18816046
Change-Id: I22204d167c7783a841f7bb560e900b525f9f036b
As a bride-gap solution to click on partially covered views in accessibility
mode we compute a point on the screen where to send a down/up event pair.
A heuristic we used was that if the action target is covered by a view that
that has a touch listener we consider the target obscured by the one with
the listener. However, this generates false positives, for example the target
is covered by a view that observers touches for scrolling but not clicking.
bug:18782023
Change-Id: I31ff34011d45667f1eddda47373ec00e4a23dbf6
Bug: 18226391
The issue occurs as a result of a dispatchFrame itself
taking longer than 12ms, the alloted budget. The result
is that a vsync request (which occured at the end) would
miss the vsync that occured 1ms prior to the end of the frame.
As a result it would end up waiting for the following vsync,
essentially dropping to 30fps even though 60 could have been
sustained.
Fix this with a few tweaks.
First, adjust the UI thread's delay bias from (now + 4ms) to
(vsync + 4ms), this prevents RT animators from slowly drifting
if the vsync occurs mid-task.
Second, request a vsync preemptively prior to running callbacks.
This way if any callbacks needs the next vsync and it takes
"too long", we will catch that vsync.
Finally, fix an issue where the display event queue was always
drained & rejected at the end of a task loop. Instead, drain
and reject all stale vsyncs. This still prevents the issue of
both UI thread & RT thread trying to drive 2 frames in a single
pulse, but also allows RT to notice that it missed a vsync
pulse it needed and that it should speed-up a bit in response
Change-Id: I9d6be037737e9283297898cac2e3563453e797cd
Some single-system-image builds may run on devices that lack
certain hardware features. This change allows the OEM partition to
mark a feature as "unavailable" which overrides the system image.
Bug: 18801291
Change-Id: I0d81144ec92ee9a78c13b223bbba20a4aed23fa0
When we switched the way the status bar determines if a
connection is validated from using INET_CONDITION_ACTION
broadcasts to calling getDefaultNetworkCapabilitiesForUser(),
the statusbar stopped displaying ! when a network stopped having
working Internet connectivity. This is because the validated bit
is never set to false once a network is validated.
Fix this, hopefully temporarily, by introducing a new validated
bit that does go back to being false when a network no longer
has working connectivity, and use that bit in
getDefaultNetworkCapabilitiesForUser().
Bug: 18777225
Change-Id: I991c068be50252391d0e64c647fcf2e053dc82f9
This is a straight rename and thus a complete no-op from a
functionality perspective.
Bug: 18777225
Change-Id: I140d7640f1460c869a311294873772819a7a7059
MediaSessionLegacyHelper used a Context passed by an application
which can cause a leak of Activity instances. Use the global
Application context instead.
Also prevent crash if a null Context is supplied (method not
documented as requesting a non-null Context).
Bug 18767503
Change-Id: I8281047d0af233a323f3fc11ababedff848829ec
This is a regression where we changed the source view for the transition
to dummy view, but since it was not yet attached, it could not get the
handler implicitly to post the onAnimationCompleted callback. This CL
modifies these ActivityOption transitions to also take an explicit
handler to process the callback on.
Bug: 18784289
Change-Id: I73f745c33b9f8aed91f8d9cd975f37cf7e4128f1
A missing @Override let the wrong function try to catch changes
to the subscription list.
The SubscriptionManager returns null when no SIMs are in the device,
so handle null as an empty list of subscriptions.
Bug: 18752587
Change-Id: I20ee1bde3f23828860f57b512662ad54ee51baf0
There were situations where the activity manager ActivityStack was
moved to the front but the corresponding window manager TaskStack
was not. This caused the wrong activity to receive focus which led
to Application Not Responding errors.
One path in particular occurred in startActivityUncheckedLocked()
where curTop.task != intentActivity.task and
sourceStack.topActivity().task != sourceRecord.task. In this case
targetStack.moveTaskToFrontLocked() was never called.
This fix forces all calls to ActivityStack.moveToFront() to make
a call to WindowManagerService.moveTaskToTop() and eliminates
redundant calls to moveTaskToTop().
Fixes bug 17721767.
Change-Id: Ibf01389810dd36724eaec5a4a07560144b2f4cef
