Add new history events for top application package and
foreground application packages.
Doing this involved a fair amount of improvement to history
events. The event code is now separated out to have "start"
and "finish" identifies, and we use that to now keep track
of which events are active. With that, when resetting the
stats, we can spit out all of the currently active events at
the front of the new history.
Also fixed some problems when I re-arranged the history delta
int bits that were conflicting with the packing of the battery
status bits. These packing structures are changed to work
together correctly.
Change-Id: Ic8b815060dd8a50ff4a0a209efc2e1044215cd88
Move the projection surface to be a property of a DisplayList,
set to true for every background drawable.
Additionally, handle a projecting view background such that it doesn't
try to project onto itself (which is undesirable).
Change-Id: Ic70b17474bd87340e80767f8518f73b233419c7a
This allows DownloadManager to use FDs, paving the way for downloading
directly to content:// Uris.
Also return flag indicating if deleteOlderFiles() actually deleted
anything. Update tests to verify.
Bug: 5287571
Change-Id: I2579e5e2113f31b2860d7b021bd61c91b6310963
ProfileOwners, like DeviceOwners, are Device Admins that have
additional priviledges. ProfileOwners however are scoped per
user.
Change-Id: I1e22c85878e0672121e6ebbe97fca38591f992b2
We now try to have a better label for the first wake lock
that is acquired in the log. This is done in two ways:
- The alarm manager now sorts the alarms it is going to
execute so that wakeup alarms are first, which are more
important w.r.t. which one should be logged.
- There is a new power manager facility to make a wake lock
as "unimportant for logging," which just means in battery
stats that a wake lock acquired after that can be considered
the actual one to log. This is only used by the alarm manager
to mark its TIME_TICK alarms as unimportant for logging.
Also reworked the battery history code to be cleaner and a bit
smaller. There is no longer a separate EVENT command, instead
the event code and tag are just another thing that can be included
in an UPDATE command.
The bits used in the first history int are also re-arrange, so
that only the ones that really change a fair amount in the state
bits are up at the top and there is no longer space used for
the command code (since now it is always just UPDATE). This
allows us to have more room for the time delta at the bottom,
to better avoid situations where we need to write an int delta.
Change-Id: I1bb860ae5b558a248800b090b03a84fbf7acd68a
Not a complete solution, since we could be more efficient, but enough
to have both background display lists and proper invalidation.
Change-Id: I0216a104948c0930760275bb2b98318b0a4487e7
Specifically, the ability to force immersive-mode-like behavior
on the status bar, the navigation bar (or both) on a
package-by-package basis - and to disable immersive mode
confirmations for specific packages.
Change-Id: I2df7092a91eceeb815367ef917dd7289f4f2b27e
Applying insets is now handled by:
* WindowInsets class - Encapsulate system insets and local decor
insets into a single object, written specifically so that new inset
categories may be added later. Apps cannot construct their own
WindowInsets, only clone with optional modifications. This is to
prevent losing data in the event of new insets added in the future.
* onApplyWindowInsets - Actually perform the application of insets.
* OnApplyWindowInsetsListener - Allow an app to use a separate
Listener object to apply insets to a View. This allows for things
like support lib integration in custom views written for older
versions where the verifier would otherwise complain about the use
of the new WindowInsets class as a method parameter. It also allows
for applying insets in a custom way without writing a custom view.
* dispatchApplyWindowInsets - Dispatch the call to self and children
in turn, if applicable. An OnApplyWindowInsetsListener will override
the behavior of the view's default onApplyWindowInsets method; a
listener wishing to call down to the 'superclass' implementation as
part of its own operation should call view.onApplyWindowInsets. App
code should generally not override this method and instead override
onApplyWindowInsets or provide a listener.
Compatibility support with the existing fitSystemWindows method has
been provided in both directions: for code that previously called
fitSystemWindows on arbitrary views and also for code that overrode
the fitSystemWindows method in custom views. A view that supports the
newer onApplyWindowInsets mechanism should not mix that behavior with
other calls to fitSystemWindows or vice versa. Support lib-style code
should take care to consistently use one mechanism or the other at
runtime.
Change-Id: Ie88b96e0382beb5d3c3f6cd013f7043acbc0a105
