The version of the warning with a named installer should be shown in
the case of a managed profile, not only a managed device.
Bug: 18224038
Change-Id: I58bddb162799481d5e8feb169b0c0bff17cbeeb7
Add a background thread to post bt broadcasts to for processing.
Try to cache all bluetooth connection state info possible and pull
from broadcasts because requesting it too often may be locking up
devices.
Bug: 18771211
Change-Id: I2cf4852c935b2f471e735d953370e5d9e996c6f7
MHL devices should be of type source that can stream AV contents
to the connected TV. This should be supported by the API
HdmiDeviceInfo.isSourceType().
Bug: 18897172
Change-Id: I7dcbd7773127bf26797c204504a12c3e2ebbd83b
<Set System Audio Mode> is another command that needs to be buffered
in case the command arrives before the system is ready to process it.
When processed, system audio mode will be enabled based on the
global setting.
Bug: 18809965
Change-Id: Ia6ebc4e2919e1b94498ca28f652c6db95f907f9c
The accessibility manager has APIs for clients to observe changes
in accessibility, touch exploration, and high contrast states. The
notification of the listeners has to be done with no lock held but
in an attempt to do that the code was incorrectly iterating over
the copy on write collection.
bug:18840784
Change-Id: I6803ff1657fbf6b0cc7936671d5bbdebb5cbf6bb
This prevents our lint tooling from complaining that we're passing
invalid values when trying to get the MediaProjectionManager.
Bug: 18830590
Change-Id: I34633248e895b0ac7f5083e18a7d2385ca6f8adb
Restoring a device that supports telephony using the backup set of
a non-telephony device would cause the ringtone to be set to "None"
instead of the default value. This was due to the fact that on
non-telephony devices, the ringtone value was being backed up as
"_silent" instead of null.
Bug: 18777629
Change-Id: Idece1f874438a895169dbba7df1d716adea6660e
Device event listener mechanism invoke the callback on all kinds
of devices in order to deal with a caller who wants to get notified
for all types. TIF was changed to check the device type to make
sure it handles source type only.
Bug: 18832462
Change-Id: I5123fe79c09f623849b93b64d0c28e6a930dd437
Use a signal condition value for the forever condition in the panel
to ease the distinction between no selection + selecting indef.
Bug: 18810529
Change-Id: I2590899ab43734708c72aad066653ef27f89d760
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
A legacy network type request would generate a bcast before the network
notification was sent - the legacy startUsingNetworkFeature API requires
the notification so it can bind your dns queries to the new network.
Fast-moving clients could try to use the network before it was ready.
bug:18792871
Change-Id: I24c46ef15c249c50bfc321f62756d1f66dc3a6a9
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
