Also add API for voice interaction service to control
whether the system should hold a wake lock while it is
working with an activity (and actually *do* hold a wake
lock while doing so, duh!).
And while in there, clean up the launching wake lock to
correctly give blame to the app that is launching.
Change-Id: I7cc4d566b80f59fe0a9ac51ae9bbb7188a01f433
setSELinuxEnforce is not allowed by policy.
get/setBooleanValue and getBooleanNames are moot since SELinux
policy booleans are forbidden by CTS.
Change-Id: I512953edd1c38828efce698ae8475603775c32e8
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
If we close the PFD status channel before returning, then the Looper
will take care of unregistering it correctly but it will end up
doing extra work to rebuild the epoll set to work around a limitation
of the epoll interface. If we unregister the FD first then this
extra work will not be required so it's slightly more efficient
this way.
Bug: 19715279
Change-Id: I0f7b90f3458adf1894b7561c05fa842fdb87b498
Optimize parceling of AssistData (which is now renamed to
AssistStructure) by pooling duplicated class name strings.
Change text associated with a view node to a CharSequence,
so styling information comes along.
Include global text attributes -- size, colors, etc.
Introduce a new AssistContent structure, which allows us
to propagate information about the intent and data the
activity is looking at. This further allows us to propagate
permission grants, so the assistant can dig in to that data.
The default implementation propagates the base intent of an
activity, so if for example you bring up the assistant while
doing a share the assistant itself has the same information
and access that was given to the share activity (so it could
for example share it in another way if it wanted to).
Did some optimization of loading PersistableBundle from xml,
to avoid duplicating hash maps and such.
Changed how we dispatch ACTION_ASSIST to no longer include
the more detailed AssistStructure (and new AssistContent)
data when launching; now the example code that intercepts
that needs to be sure to ask for assist data when it starts
its session. This is more like it will finally be, and allows
us to get to the UI more quickly.
Change-Id: I88420a55761bf48d34ce3013e81bd96a0e087637
The methods were previously defined on Looper but on reflection
they actually make more sense on the MessageQueue instead since
the Looper class is primarily concerned with thread lifecycle
rather than the actual messages themselves.
Change-Id: Iff356b94754fc9960774fa17e3eec9604229cba6
The loop isn't technically idle at this time, it's just checking
whether any file descriptors have pending events. However it's
still a good signal as to whether the loop is alive.
Added a real isIdle() function.
Bug: 19532373
Change-Id: Idd273e8774f469ccafb00d560818cf279dfd6ba6
Surface some of this information in BatteryStatsHelper. If we are given a
total energy from the WiFi controller, we normalize the computed
energy of each app and blame them for a fraction of the real energy.
Change-Id: I64051b600f5d9f6ac4580d56ef0977971eb4be2d
Issue #19431959: Framework incorrectly assumes that kernel
clock_ticks are 10ms
We now retrieve the time of a jiffy from the kernel, and all CPU
times are now handled in milliseconds.
Issue #19571810: Add per-app breakdown of number of WiFi scans
in batterystats checkin data
Added to the report (the information was already being tracked).
Change-Id: If1702d6b9bcf851704129f1811471e68ed576a5d
Silently fail when a managed profile app tries to change the
wallpaper and return default values for getters in that case.
This is implemented through a new AppOp that is controlled by
a new user restriction that will be set during provisioning.
Bug: 18725052
Change-Id: I1601852617e738be86560f054daf3435dd9f5a9f
android.os.Debug.startAllocCounting() is deprecated but other things
that rely on it or do not make sense without it aren't deprecated.
Bug: 8241521
Change-Id: Ib769cb8f4e96f41ed310e17e7345acb2a630a076
Currently is only used for tracking the daily charge
and discharge rates. We keep up to 10 days of data.
Change-Id: I54e29e35ff60d9277da9e476cdab22f4a6d540bf
Added an overload of getSystemService() that takes a class instead of a
service name to eliminate the extra cast and provide more type safety.
Cleaned up docs.
Removed the default constructor of BatteryManager which should not have
existed.
Change-Id: I9da46b20641fc83ecd3342560e5b94cb721f289c
This commit removes a couple of apostrophes from the word "UEvents" as
the apostrophes would only be needed if something that belongs to the
UEvent was being talked about. Instead, the UEvents are being talked
about themselves - as a bunch.
Change-Id: I6a7908c6b73c0739102b632d2499e0f1e3c2d47f
There is currently an issue somewhere regarding these checks on
some devices. Disabling them until those issues are resolved.
Bug: 19058575
Change-Id: Id5ce93c2d4069d3058636b8e12317e200229472b
Signed-off-by: Daniel Rosenberg <drosen@google.com>
When the display state is DOZE or DOZE_SUSPEND, assume this means
that the AP may go to sleep at any time so hold a wake lock for
a little while starting when traversals are scheduled to ensure
that the AP remains awake long enough to draw and post the frame
to the display hardware.
This patch is somewhat approximate but should be good enough for
most devices today.
Note that the implementation uses the window manager to ensure that
the window which wants to draw is actually visible before acquiring
the wake lock. There is a cost to this test (a round-trip) which
should not be significant today since we do not expect apps to draw
more than one frame or two while dozing. However, if we wanted to
support animations in general, we might want to optimize it or
eliminate the check altogether (since we can already account for
the app's use of the wake lock).
Another way to implement this functionality might be for the view
hierarchy to listen for the power manager to report that it has entered
a non-interactive power state before deciding to poke draw locks.
This would be somewhat more accurate than watching the display state.
Also, the draw lock timeout logic could be implemented more directly
instead of using an ordinary timed wake lock.
Bug: 18284212
Change-Id: I84b341c678303e8b7481bd1620e634fe82cc4350
