The code for this was fairly conservative since the components of the
apps could change, leaving junk in the preferred app list. Now we
don't pro-actively clear them, but try to catch missing components
later.
Change-Id: I793063449dcc577fd3d56bb56495b308f0c95ea8
Most of these comments will be removed after the threadLoop merge.
Note: the trivial change in assignments to mixBufferSize, and the
comments about "tracks to remove" is to make them all identical.
Change-Id: I3b1a33a7f2cd12ad557a1986bb71f6171161974a
* changes:
Detect animation completions like we used to. Previous approximations weren't indicating completion and windows weren't being layered correctly as a result.
debug
Previous approximations weren't indicating completion and windows weren't being layered correctly as a result.
Change-Id: I08fcd278485bb87dc10bca257b9f8073108753f3
prctl(PR_SET_NAME) limits to 15 characters. Before we had names like
"Binder Thread #" and the counter was cut off :-( Also remove redundant
"thread" at end of name; it's always a thread.
Change-Id: I1f99c2730ba0787ed9b59c15914356cddf698e2f
An "UpdateLock" works similarly to a wake lock in API: the caller is
providing a hint to the OS that now is not a good time to interrupt
the user/device in order to do intrusive work like applying OTAs.
This is particularly important for headless or kiosk-like products
where ordinarily the update process will be automatically scheduled
and proceed without user or administrator intervention.
UpdateLocks require that the caller hold the new signatureOrSystem
permission android.permission.UPDATE_LOCK. acquire() and release()
will throw security exceptions if this is not the case.
The "is now convenient?" state is expressed to interested parties
by way of a sticky broadcast sent only to registered listeners. The
broadcast is protected; only the system can send it, so listeners
can trust it to be accurate. The broadcast intent also includes a
timestamp (System.currentTimeMillis()) to help inform listeners that
wish to implement scheduling policies based on when the device became
idle.
The API change here is a tiny one: a dump(PrintWriter) method has been
added to the TokenWatcher class to facilitate getting information out
of it for dumpsys purposes. UpdateLock itself is still @hide.
Bug 5543442
Change-Id: Ic1548dd43935f45d4efc67f970abdc290a45f715
...if the process is killed and restarted
Try to ensure that in all cases we deliver an activity result if one
was requested.
Change-Id: Id43e830d2ee782f98ed1e3b68e5e16f3258d4ad8
This fixes a bug where the device could see a priority inversion when
updating display brightness. The problem occurs because the code that
manages screen brightness holds the master lock while waiting for the
native method to complete. On some devices, each call can amount to
tens to hundreds of ms, which meant clients using PowerManager APIs
could block for the duration of the call. In some cases, the animation
could block for many seconds because the unfairness of Java locks.
The solution is to handle all brightness updates in a separate thread that
does not hold the master lock while calling native methods.
This also makes the animation more consistent by animating by actual
wall clock time rather than depending on the round-trip from the driver.
Change-Id: Ifad76fb2fb77e7b2a72dd9150440d87e22581b40
this could happen after an orientation change. basically
we need to triger a geometry-changed when the very first buffer
is received
Change-Id: I097e411fd6612c18725737cffccdbf6b2af3511c
Useful especially for last kmsg (e.g. IMG/DSS logs truncate
and loose useful info). Since this is a max, won't affect files
that are already shorter than 64kb.
Change-Id: Ia5bb178678067e69384285e8c338dc8cb6ad071b
No need to check for presence of item before removing
(but we do lose the log of the previous value).
Change-Id: I2838430824de5f257f2ee15db0c22b1920c67d08
