This CL has no functional changes and I am just breaking this change
out of another large CL I am working on.
Test: existing tests pass.
Change-Id: I4c93e2b1820dc31ba28f81692f2f8f6081e1f315
This patch fixes the following issues in LocalLog:
- reverseDump() uses a descending iterator with linear complexity
instead of a quadratic loop using get(index) on a linked list.
- reverseDump() is added to ReadOnlyLocalLog.
- synchronized section in log() is restricted to mutation of internal
list.
- formatting of the log message does not create an internal
StringBuilder.
- the instance variable mNow is removed: it was only used inside log()
as a local variable.
- remaining instance variables are qualified with final.
- the linked list is replaced by a fixed capacity array-backed queue.
Test: added unit tests
Change-Id: I1a54f0ad26dd35448d3297ea24df1fd626d20ef3
Because of course during system shutdown, the wallpaper service
won't actually get relaunched. Sometimes shutdown can take long
enough that this timeout kicks, so we need to avoid clearing the
live wallpaper state spuriously.
For simplicity we just check at "would have timed out now" time
rather than try to distinguish between the shutdown case and a
genuine crash that raced with the shutdown broadcast.
Bug 32020355
Change-Id: I9335b2c0214b4c750ef950fed157d186aa670176
If we created a BROWSE PendingIntent early during boot (while the
device was still locked), we would resolve the MIME type as "null"
meaning the intent would fail to launch.
Since we always know what the MIME type will be, set it explicitly.
Test: boot device while USB device attached
Bug: 30742481
Change-Id: I23c523cbe2660ca63a3b7df1f41300ab803b314c
RIL_UNSOL_MODEM_RESTART will be sent by vendor RILs when it detects
a modem restart along with the reason for restart which could be a
crash signature if the modem restarted due to a crash or a some
other string such as a user-initiated restart or AT command
initiated restart.
Change-Id: Idf08e20a49e82d40f6aa0854d23384c35c2efc3a
Animators can be scaled to have zero duration globally in any device.
This can happen either via Developer Options (an uncommon path) or
Battery Saver mode (much more common for real users).
In general, this works fine; it just causes app animations to be jump-cuts
instead (which is the desired effect, either to make transitions faster
(Developer Options setting) or to optimize battery usage by rendering
fewer frames (Battery Saver mode).
But sometimes, choreographed animations can have undesired artifacts. For
example, an animation that calls an end listener to restart itself
will end up doing this almost constantly due to this effect. Other artifacts
can also occur, such as intermediate results in a complex choreography of
multiple animations can show several intermediate results in a way that is
confusing to the user.
For these cases, there is nothing that the platform can do to automatically
determine how to best handle the result. Instead, we surface this new
API to help developers discover this behavior and compensate accordingly.
Bug: 31052471 Animation playback is abnormally fast during Battery saver mode
Test: unit tests, CTS test upcoming
Change-Id: Id7ef1a9652ac5c6cdaca0c126756e82582d49b1c
