am: 36b03ec9f0
* commit '36b03ec9f0cd6466f2bd9517a72438e446033685':
Back up / restore the 'mono audio' setting
Change-Id: I0947760de027c0dfa1fd5f66ea7adfcae9d965a0
am: a3aaa5ee25
* commit 'a3aaa5ee2558ac5a6b6ca0b309dc9eea4c51bf14':
Back up / restore the 'mono audio' setting
Change-Id: Ieb242d2d382218b6090acf0e72c33c865fb0994b
am: a3aaa5ee25
* commit 'a3aaa5ee2558ac5a6b6ca0b309dc9eea4c51bf14':
Back up / restore the 'mono audio' setting
Change-Id: Ie20918c1a8306342de7a5e2201d3e55fff39500c
am: 761f70d5a6
* commit '761f70d5a6b926780db3bba95ee1e01b4d8d95be':
Add support for ICU data pinning in the Zygote
Change-Id: If693e8cbb737186fdf0a3169d024bef08c8ceb6a
We handled stale wakelocks (wakelocks that disappear from /d/wakeup_sources)
differently in previous version of Android. They would be set stale, but still be
updated with their previous counts (they would never disappear).
The method setStale has been replaced with endSample(), which is semantically different.
Once a SamplingTimer has endSample() called, it expects any future calls to update() to
be a new sample, meaning the entire amount passed to update() is included in the kernel
wakelock's total. Since stale wakelocks were never removed from the list, this would
increase by large amounts when nothing had actually changed.
This was exacerbated by the fact that there was a bug where the last wakelock in
/d/wakeup_sources was never parsed, so if the order ever changed, this "stale" wakelock
would suddenly re-appear and the entire amount reported would be charged to the wakelock,
instead of just the difference since the last update.
All this was exposed when we added support to handle wakelocks that would disappear and
reappear with smaller values, meaning the kernel had pruned them from its accounting and
reset them.
Bug:28601080
Change-Id: Ic96027f7d580dac5e20aa73d67e5cedac4ccabeb
am: e9b32c77f8
* commit 'e9b32c77f88a2acb7e7e23fbd14f6b4f373cba0b':
Fixed a bug where the chronometer was invisible
Change-Id: Ie6f36bca7345f7b1f86425e993deb7d617bbc4d5
am: 2486cb2c89
* commit '2486cb2c8978003d2b5cfa7e8169019421582cb0':
Fixed a bug where the chronometer was invisible
Change-Id: Ib495f096b5b2bc758ce7224fae33ba1a44c027a2
am: 8e8aa4ec4d
* commit '8e8aa4ec4daa5ac46e9be921bc0dd34f812e1a97':
Fixed a bug where the chronometer wasn't updating the time
Change-Id: Ibaf35c283513973a22dee6eb601493b01a5de573
am: 2486cb2c89
* commit '2486cb2c8978003d2b5cfa7e8169019421582cb0':
Fixed a bug where the chronometer was invisible
Change-Id: I8caf83fdb4a27e477e644123d349bc4951eda0dd
am: 0676196be2
* commit '0676196be2657fdf265fa7ad1eae3eecf1bbfebc':
Fixed a bug where the chronometer wasn't updating the time
Change-Id: I16327b27bcfce8eaeb18cbddd420bb134cff1e45
am: 0676196be2
* commit '0676196be2657fdf265fa7ad1eae3eecf1bbfebc':
Fixed a bug where the chronometer wasn't updating the time
Change-Id: Idd72e636e42f59a17445694b4c4c97b47bf58e71
TalkBack is seeing crashes that I can only explain by our assumption
that window layer is unique in all cases. TalkBack reports that it
happens during animation, so I assume that the layer may repeat
transiently.
Reducing our dependence on this assumption by traversing the list of
windows sorted by layer without assuming that the list has the same
length as the list of unsorted windows.
Also documenting the undefined behavior of SparseArray when indexing
beyond its bounds. The undefined behavior itself is intentional for
performance reasons.
Bug: 28679528
Bug: 28815817
Change-Id: I0c9f90b0b458b4cde465f603ba204fe6691e5c2c
This method is a helper for internal use only.
+ Updated docs for QUOTA_OCCUPIED, QUOTA_TOTAL, and QUOTA_UNAVAILABLE.
Change-Id: Ib146926cd2bff50affe970a0123bcbec62ac3e70
Fixes:28842445
As pointed out here:
https://code.google.com/p/android/issues/detail?id=69834
registerApp() causes onClientRegistered() to happen before autoConnect
is set. This patch fixes that.
Bug: 28861330
Change-Id: Ie1174c0f224f5084178439420b383164d22d542c
