We now peform a total-size preflight pass before committing data to the
wire. This is to eliminate the large superfluous network traffic that
would otherwise happen if the transport enforces internal quotas: we
now instead ask the transport up front whether it's prepared to accept
a given payload size for the package.
From the app's perspective this preflight operation is indistinguishable
from a full-data backup pass. If the app has provided its own full-data
handling in a subclassed backup agent, their usual file-providing code
path will be executed. However, the files named for backup during this
pass are not opened and read; just measured for their total size. As
far as component lifecycles, this measurement pass is simply another
call to the agent, immediately after it is bound, with identical
timeout semantics to the existing full-data backup invocation.
Once the app's file set has been measured the preflight operation
invokes a new method on BackupTransport, called checkFullBackupSize().
This method is called after performFullBackup() (which applies any
overall whitelist/blacklist policy) but before any data is delivered
to the transport via sendBackupData(). The return code from
checkFullBackupSize() is similar to the other transport methods:
TRANSPORT_OK to permit the full backup to proceed; or
TRANSPORT_REJECT_PACKAGE to indicate that the requested payload is
unacceptable; or TRANSPORT_ERROR to report a more serious overall
transport-level problem that prevents a full-data backup operation
from occurring right now.
The estimated payload currently does not include the size of the
source-package metadata (technically, the manifest entry in its
archive payload) or the size of any widget metadata associated with
the package's install. In practice this means the preflighted size
underestimates by 3 to 5 KB. In addition, the preflight API currently
cannot distinguish between payload sizes larger than 2 gigabytes;
any payload estimate larger than that is passed as Integer.MAX_VALUE
to the checkFullBackupSize() query.
Bug 19846750
Change-Id: I44498201e2d4b07482dcb3ca8fa6935dddc467ca
In order to not deadlock the system, we need to retrieve
WiFi energy info outside of the BatteryStats lock. We do this,
then pass that data down to BatteryStatsImpl to process.
b/19729960
Change-Id: Ib8beba1d5ac81d89144d502c4b688d0a88c5b102
Instead of just tracking the total number of wakeup alarms
per package, track a count for each tag. Note this is only
wakeup alarms, not non-wakeup alarms.
Also tighten up the code a bit by exposing the actual ArrayMap
container through most of the BatteryStats API, so we can more
efficiently iterate over them (which is all we ever want to do
with those containers at that point).
Finally remove all printing of "since unplugged" stats, as
another step towards completely removing that tracking. If
nobody screams, hopefully soon we can go through and just get
rid of all the extra state we are carrying around that is
tracking that data.
Also note that currently the per-tag wakeup alarm data is
being reported in the human-readable stats, but in the checkin
data it is still being rolled up into a single number. To fix
this, I need to completely rework the pkg entry line to have
separate data for services and wakeup alarms (so have three
types -- pkg for the start of a package, wal for a wakeup
alarm, svc for a service).
Change-Id: I8033acca8742935cfe95511cdea730a405b17cab
- There is now an API for people to find out about
its state.
- Moved DeviceIdleController to be closer to the
power manager implementation, since they are
closely related.
- Job scheduler now knows about idle state and doesn't
run jobs while the device is idle.
- Battery stats now keeps track of "idling" vs "idle mode".
Idling is when we consider the device to be idle,
independent of whether we are actually in deep idle mode.
This allows us to keep track of longer-term changes
independently of cycling in and out of idle mode.
- Battery stats also now keeps track of package changes in
its daily stats.
- Small optimization to network policy manager service to
not touch uids that do not have the NETWORK permission.
Change-Id: I0b3304fb3722c78cdfdd0c1eada7369ece7cbcf9
The restored set of enabled IMEs/subtypes is merged into the
current state of the system, rather than simply replacing it.
This is because we do not want to accidentally disable or
reconfigure something that the user is currently relying on.
There's a certain amount of repetitive activity here, rebuilding
the enabled-state data structures in a different format, but it's
important for maintainability that the restore code be able to
rely on the core InputMethodUtils implementation of reading/writing
the settings element.
Bug 19822542
Change-Id: If0104151b3526da6ecc669adde3119a239ecafeb
Introduced new 'extractNativeLibs' attribute to manifest/application.
Setting it to false prevents installer from extracting library from apk.
The default value for extractNativeLibs is true.
Bug: 8076853
Change-Id: I1aa2c039bb2a590ae72f256acc9ba5401c2c59b1
This is a temporary fix to prevent deadlocking in the
system. Need to come up with a better solution for
accessing WiFi and other subsystems from BatteryStats.
b/19729960
Change-Id: I464e7490c9780249d2a3eef05ce084a7d84372c0
Introduce a new device idle controller service that
monitor's the device state and determines when to go
in to idle mode. When in idle mode, all we do right
now is turn off network access the same as we do for
power save mode. Many more things should come in the
future -- stopping the alarm manager from scheduling
(most) alarms, telling GmsCore for it to stop doing
stuff, etc.
Battery stats now has state tracking for devie idle
mode, as well as events for the reasons we can come
out of idle mode (significant motion or the device
becoming active). Also added new events noting when
packages are installed.
Renamed the "low power" event in battery stats to
"power save" because the former was just way too
confusing.
Finally, fix buffer size reading kernel wake locks.
(Stupidly, just increasing the buffer size. Ideally
we should try to be smarter and grow our buffer to
fit the data available, but I'll leave that for
another time.)
Change-Id: I0be2062466c83ee9d890c6cf5a228d9cc4090eca
New flag you pass in to startSession() to say you want it,
new callback on VoiceInteractionSession to receive it.
Change-Id: I61fdcfdee41a60d46036a2ef16681a9b4181115a
This is a follow up CL for a recent attempt to minimize
the number of default enabled IMEs.
- part1: I831502db502f4073c9c2f50ce7705a4e45e2e1e3
- part2: Ife93d909fb8a24471c425c903e2b7048826e17a3
- part3: I6571d464a46453934f0a8f5e79018a67a9a3c845
- part4: I871ccda787eb0f1099ba3574356c1da4b33681f3
This CL removes following deprecated hidden public methods
from InputMethodUtils as planned.
- isSystemImeThatHasEnglishKeyboardSubtype(InputMethodInfo)
- isValidSystemDefaultIme(boolean, InputMethodInfo, Context)
- containsSubtypeOf(InputMethodInfo, String, String)
This is a pure code refactoring with preserving the current
logic. Hence no behavior change is intended.
Change-Id: I1ff994cbbdef83e1e907a0d88aa9ae09d45263b4
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
We were properly setting up the underlying storage at boot time, but
*not* doing so after an "initialize" operation, i.e. after wiping all
of the data upon request. The effect was that after an init operation
while using the local transport (e.g. if you disabled backup and then
reenabled it with the local transport as your active one), full-data
backup operations wouldn't work until after the next reboot.
(Resubmit, with fixes, of earlier revert.)
Change-Id: I745cb49b5155119d63cff6fffad5230687faca71
This is a follow up CL for a recent attempt to minimize
the number of default enabled IMEs.
- part1: I831502db502f4073c9c2f50ce7705a4e45e2e1e3
- part2: Ife93d909fb8a24471c425c903e2b7048826e17a3
- part3: I6571d464a46453934f0a8f5e79018a67a9a3c845
- part4: I871ccda787eb0f1099ba3574356c1da4b33681f3
In the avobe CLs, an internal (hidden) method
InputMethodUtils.isValidSystemDefaultIme was marked as
deprecated and we decided to migrate to
InputMethodUtils.isSystemImeThatHasSubtypeOf.
To finish this refactoring, this CL make the new
method visible to the settings app.
InputMethodUtils.isValidSystemDefaultIme remains
to be an internal method. No behavior change is
intended.
Change-Id: I8cb9ca40d15af099c3d1ded46797fb57f14fb9e8
This requires adding a new method to View and Window.Callback to pass
down the type as a parameter.
For compatibility purposes, the new method implementations keep the
type and call the old method, in case clients have subclassed it.
Change-Id: If5d857f131e33be8cc6a8814f2e9c4e85ad2da25
We were properly setting up the underlying storage at boot time, but
*not* doing so after an "initialize" operation, i.e. after wiping all
of the data upon request. The effect was that after an init operation
while using the local transport (e.g. if you disabled backup and then
reenabled it with the local transport as your active one), full-data
backup operations wouldn't work until after the next reboot.
Change-Id: I3bfda1e94ae2312678b0bb2dde13ebdb64a56d2b
