There is a flaw in the mechanism used by AudioService
to detect the fact that mediaserver process did crash and restart.
It relies on polling AudioFlinger service until a successful
connection triggers a callback into AudioSystem JNI and then into AudioService.
But if another thread in system_server process, not attached to the
JNI environment, reconnects before AudioService, the callback is called in
a detached context and dropped.
The fix consists in attaching the thread executing the callback
and detaching it if needed.
Bug: 9693068.
Change-Id: I184308b12a3f87653bf818abf0159e0e45a66ef0
We now keep track of all of the active start operations per
non-system process, so they can be cleaned up if the process
goes away.
Change-Id: I9d05f1e0281c47dbe1213de014f0491f1359685c
Add a reworked version of "Tejat", at 48kHz.
The original asset is "/data/sounds//notifications/wav/Deneb.wav".
Use this new version in Audio Package 11 under its original name.
Bug 9900161
Change-Id: I4d7c73715db4e52f5c89aeca726f8b314e0895d5
This gid is not needed by camera-using apps, since all camera access
is mediated by the camera service, which does not depend on gid for
permission checks.
Bug: 9904186
Change-Id: I859e6cabc905af9d98e2b09f5bbad086b5eb2b26
A simple mechanism for doing this is to take advantage of the fact
that we require the device to reboot after a sim has been changed.
Thus when connectivity service is started we wait to get a connection
then call checkMobileProvisioning once. We also add a check that
the DEVICE_PROVISIONED is true, i.e. SetupWizard has been run.
Bug: 9784024
Change-Id: I5c1936744f6fc55a447ae44cd36eec3849d27e21
The display wake lock and other internal state could become
out of sync if we happened to execute the power manager's update
function concurrently due to the missing lock.
This bug can be trigged due to display state changes or proximity
sensor updated. Although it would be extremely rare, we have
some evidence of this happening on at least a few devices resulting
in rapid power drain with the screen off or a crash.
Bug: 9880044
Change-Id: I3c674ce429621a50cbb36c3a01883d5f388205b2
(cherry picked from commit d91e417b06388694db213257b4df6b4dd78e0d49)
1. Adding bundle with metadata to PrintDocumentAdapter#onLayout
with one key for now to specify whether this is for a preview.
2. Cleaned up docs.
Change-Id: I89380781bf3ae41aa89f8a0347d74516a210394c
The default Alarm Manager behavior for KLP+ apps will be to aggressively
coalesce alarms, trading exact timeliness of delivery for minimizing the
number of alarm-delivery points, especially wakeup points.
There is new API in AlarmManager, setExact() and setExactRepeating(),
for use by apps that absolutely *must* get their alarms at a specific
point in time.
Bug 9532215
Change-Id: I40b4eea90220211cc958172d2629664b921ff051
bug:9797004
Grants a means to reuse a bitmap's allocation for different
width/height/Config without going through
BitmapFactoryOptions.inBitmap
Change-Id: Ib62319f3bd96c451fc1636288adf06a8275b4e3d
This new method on view reflects whether the view has been laid out
at least once since it was attached. hasLayout() seems too vague for that
meaning; every View that has a parent has a layout (since we use container,
parent, and layout interchangeably). The new version of the method
is closer to the actual meaning.
Change-Id: I519745739b6a6317faeb077aa61f994025cf81f3
Move away from storing the configs in the Intent to prevent issues with
PendingIntents and multiple configs.
The Dialog now queries ConnectivityService for the configuration to
display in the management dialog.
Change-Id: I0e0ef52db840152914d117a24f776d8106e836ff
A simple mechanism for doing this is to take advantage of the fact
that we require the device to reboot after a sim has been changed.
Thus when connectivity service is started we wait to get a connection
then call checkMobileProvisioning once. We also add a check that
the DEVICE_PROVISIONED is true, i.e. SetupWizard has been run.
Bug: 9784024
Change-Id: I5c1936744f6fc55a447ae44cd36eec3849d27e21
Also do some tweaking of the various container classes
to synchronize them with the support lib and make it
easier to copy code between the two.
And update activity/fragment to use ArrayMap.
Change-Id: I3cfe82392a17119dfc72c3d9961f64e1914f42be
If a window's task stack has no sibling, restore old behavior
of allowing frame to go below the nav bar.
Bug:9884905
Change-Id: Ifc38901a6633cf431dba8740a65258d0618c0fd0
This change introduces a new measure cache to View, to remember
the measured dimensions for previous pairs of measure specs. The
measure cache is cleared whenever a View requests layout.
Unfortunately some Views rely on measure being always called when
layout is invoked. To work around this problem, we need to remember
when we hit the measure cache to force a call to measure just prior
to calling onLayout(). This does not completely removes all measure
calls but enough to optimize a number of layouts.
Change-Id: Ie085fbcf186e9d7505e1127e0786a12968ebc344
The display wake lock and other internal state could become
out of sync if we happened to execute the power manager's update
function concurrently due to the missing lock.
This bug can be trigged due to display state changes or proximity
sensor updated. Although it would be extremely rare, we have
some evidence of this happening on at least a few devices resulting
in rapid power drain with the screen off or a crash.
Bug: 9880044
Change-Id: I3c674ce429621a50cbb36c3a01883d5f388205b2
(cherry picked from commit d91e417b06388694db213257b4df6b4dd78e0d49)
Remove DisplayContentsIterator and AllWindowsIterator. These were cute
but they take up valuable resources. Iterate over ArrayList members
in their place.
Change-Id: Ie0c537608532cfb36f34d976cc6eacd21bad98cd
The display wake lock and other internal state could become
out of sync if we happened to execute the power manager's update
function concurrently due to the missing lock.
This bug can be trigged due to display state changes or proximity
sensor updated. Although it would be extremely rare, we have
some evidence of this happening on at least a few devices resulting
in rapid power drain with the screen off or a crash.
Bug: 9880044
Change-Id: I3c674ce429621a50cbb36c3a01883d5f388205b2
Previously, there were two distinct problems with how delayed
transitions were being run:
- there would be a delay between the transition being put into
a preDrawListener (to be kicked off when that listener fired) and
being removed from the pending list. This allowed another delayed
transition to be run in parallel, which would cause conflicting/
clobbering issues with transition values on the same objects.
- there would be an extra frame delay in some cases due to how/when the
delayed transition would be started. Specfically, we would postOnAnimation()
to call a method that would then add the onPreDraw listener. This two-step
forwarding caused issues noted above.
The fix is to simply add the transition to the preDrawListener immediately, removing
the two-step problem, and also ensuring that the transition is only removed
from the pending list when it is actually started, which prevents other transitions
from starting in the meantime.
Also, added more debug logging to help chase future issues with transitions.
Change-Id: Ie2ff8e73d29f342512842e9641bd8d605e74544c
