Calling into TelephonyManager each of hundreds of apps to check
if the app is carrier privileged was very expensive, especially
when there aren't even any carrier access rules specified. This
change fetches all the carrier privileged apps in one call,
reducing the number of IPC calls to the radio process and checks
the package names locally.
If the carrier rules change or packages are modified, the list
will be computed and fetched again.
Other optimizations in Telephony help speed up the individual calls
to check if a package is privileged, as well.
Bug: 27271861
Change-Id: I5a77b6da4f2cdc603d2a73bd8569c5c38f06b42d
Synchronize only the methods that need to be, so that
the lock is not held for a few hundred milliseconds, blocking
other usagestats operations.
Bug: 27208519
Change-Id: I43bda0791dd8b2576a8af506bcdc67a09a5830f2
Don't continue to check idle states for removed / stopped users.
No need to check for uninstalled packages for all users.
Bug: 27208519
Change-Id: I9a3a3bbec560dd380ce90df9fef102d7f62769ca
Don't mix up with usage stats. Keep a separate db and history
based on elapsed time and screen on time.
Unit tests for AppIdleHistory class.
Bug: 26989006
Change-Id: If343785b46da1db67f7c1c1263854c2732a232c6
Fixed a bug which caused a null pointer exception on restore
in deleteDirectoryContents() method.
Also made other cosmetic changes.
Change-Id: I75712ec585fdfdbca462c468acf2229a47331b59
If we try scheduling a pass before the system is ready, record a
pending event and dispatch once we're actually ready.
Bug: 26863668
Change-Id: I028285383c8bbe8b653aeaa7544eefe3d41277bc
Screen on time should be measured in elapsed realtime, not wallclock.
Cause a checkIdleStates to occur when reloading stats
(on rollover and on time change).
When time changes occur in the negative direction, the new stats file
we create can overlap the previous one with regards to its end timestamp.
Use the begin timestamp to determine which of the latest stats to merge.
(b/22716352)
Bug: 26488100
Change-Id: If31b29bbbee9e98401205b5e26bce86e181286e7
Backing up UsageStatistics using a new API in
UsageStatsService like the Notifications backup.
The backup logic is in the same package as UsageStatsDatabase
while the BackupAgentHelper resides in the android package
alongside SystemBackupAgent.
Bug: 26179323
Change-Id: I022d85fbcd4abb763230bec6eea50a7e723b5152
And ensure that the listeners are informed of app standby transitions
that might occur during time changes.
Fix for apps that sometimes don't have network access until reboot.
Bug: 26488100
Change-Id: Ic342c188a6cd19faee88f50b2c6a342a6968cb23
Ignores the old, re-appropriated key "idle_duration" which is now
set to a high value in order to force disable app idle on devices
with bug b/26355386
Bug:26355386
Change-Id: Iff9de843ad6e547d29c1583687fc7f7ce7e15090
With the updated rolling window of stats for app idleness, we need to make sure
it is populated before we initialize some defaults.
Now that we look at older entries to figure out idleness, if those
entries are in the future (due to time change), set them to the current
screen on time.
Bug:26504153
Change-Id: I4c21e8f094a1a6727373368d043f523053280d7d
With the updated rolling window of stats for app idleness, we need to make sure
it is populated before we initialize some defaults.
Now that we look at older entries to figure out idleness, if those
entries are in the future (due to time change), set them to the current
screen on time.
Bug:26504153
Change-Id: Ia22add0e8eaf0f137002bbe3e91d747fef5b7d69
App Idle queries are very frequent and so they only check in memory stats.
However, in memory stats can be missing some entries, especially after a rollover, but also
due to a larger bug fixed in master (too risky to take now).
The fix is to do a deep query (reading older files from disk) and maintain a parallel cache
of stats for app idle. That way the rolling window of data required to serve app idle queries
stays in memory.
Bug:26355386
Change-Id: I2dd3946b45d7d893410715bb0534b2b48694ced6
Finish moving all UID/GID callers to single AIDL method that requires
callers to provide flags.
Triage AppWidgets and PrintServices, which currently can only live on
internal storage; we should revisit that later.
Fix two bugs where we'd drop pending install sessions and persisted
Uri grants for apps installed on external storage.
Bug: 26471205
Change-Id: I66fdfc737fda0042050d81ff8839de55c2b4effd
Catch a bunch of simple cases where the PackageManager flags are
obvious. Add the ability to use the MATCH_SYSTEM_ONLY flag on
PackageInfo and ApplicationInfo queries.
Re-examine recent tasks after a user is unlocked, since some of the
activities may now be available and runnable.
Bug: 26471205, 26253870
Change-Id: I989d9f8409070e5cae13202b47e2c7de85bf4a5b
When hidden PackageManager methods take a userId argument, they
should be named explicitly with the "AsUser" suffix. This fixes
several lagging examples so that we can pave the way to safely
start passing flags to new methods without scary overloading.
Also fix spacing issues in various logging statements.
Change-Id: I1e42f7f66427410275df713bea04f6e0445fba28
Symptom:
As issue link:
https://code.google.com/p/android/issues/detail?id=193100
RootCause:
UsageStatsService.onDisplayChanged executed in system main thread,
If calling UsageStatsManager.queryEvents with too many events before it
(i.e. in daily usage event file,
too many activity resume / pause events or configuration change
during monkey test),
System will be blocked then watchdog timeout.
Solution:
Let display listener executed in background thread handler
BUG: 25355086
Change-Id: Ic894d112612400ed8fb7ba843b3309fdc4f66fe1
(Cherrypicked from 4e59db328d8b0cc163d2e3eb0f7f3a108f20a58d)
(cherry picked from commit 7018f60b06fd0c647ebf13225320d7e15d02e075)
Symptom:
As issue link:
https://code.google.com/p/android/issues/detail?id=193100
RootCause:
UsageStatsService.onDisplayChanged executed in system main thread,
If calling UsageStatsManager.queryEvents with too many events before it
(i.e. in daily usage event file,
too many activity resume / pause events or configuration change
during monkey test),
System will be blocked then watchdog timeout.
Solution:
Let display listener executed in background thread handler
Change-Id: Ic894d112612400ed8fb7ba843b3309fdc4f66fe1
I think what probably happened is that since we only report an app
going in to the "interaction" state as an interaction event to usage
stats, apps that sit around in that state forever will only see one
interaction at the start and never again. So usage stats could start
thinking they are idle.
Fix this by having the activity manager report an interaction event
for such long running applications at least once a day.
Also, because it is correct and for paranoia by protected us another
way, system uids should never go in to standby.
Change-Id: I8a3805bfca86cbe78560488a649ecd07427da99a
When the time changed, we would end up creating a new stats file, even if we could
reuse an old one. On systems where the time toggled a lot, this would generate
hundreds of files and slow down other IO operations on this set.
Now we properly reuse stats files after time changes. The time at which a particular
file began recording was always clamped to the start of the interval (day, month, year).
However, this makes no sense when the time changes, and clamping to the start of the interval
would always cause a new file to be created, since the current time no longer fell into that
time interval. So now the time is just offset from the last file's end time.
Bug:22716352
Change-Id: I6cec156e2e93b4402116600fa09c1018f3b870fe
There were a few subtle bugs in app idle parole scheduling that
would cause us to never end a parole period we had entered. The
updated logic in this change concentrates the registration for the
next event in one place in setAppIdleParoled().
Bug: 24050462
Change-Id: I1efe43cd6e00a547f70c4a4a37e1f3ef52a7e706
We now have a new whitelist you can put apps in, which
opts them out of the old battery saver mode and new app idle,
but doesn't keep them from going in to doze. This is for a few
special cases that we had previously whitelisted for battery saver,
and inherited to the new modes... ultimately we should figure out
how to get these apps out of the whitelist completely, but this
will help for now.
Apps in this new whitelist are not shown in the UI, because they
are still significantly restricted by not being able to operate
normally in doze. This also means they are still visible in the
list of all apps for the user to be able to put them on/off the
complete whitelist if that is what they really want.
In the course of doing this, I needed to clean up code in the
network policy manager to better separate management of the
two firewall rules that now have different whitelists applied
to them. This also hopefully just generally simplifies and cleans
up that code. Hopefully!
Change-Id: I92e15f2f85899571dd8b049b5e3eb1354f55f353
With lots of usage stats files, the log gets spammy
when the time changes and we are moving files around.
Bug:22549399
Change-Id: I9da39399b090066d52568dea6fc5b59aba063c5a
Not sure how useful this is, since renames should be atomic. If the filesystem
is corrupt I'm sure other parts of the system will break. Good to be safe though!
Bug:22172659
Change-Id: Iad339be2869d170bcf736c59feb93830a51905e1
We now place whoever is receiving the MMS on the temporary
whitelist while doing so, so they can get network access to
download it.
There was also an issue that needed to be fixed where we
were no longer updating the list of allowed uids while
dozing based on their proc states... we now do that.
Also did a bit of optimization of the temp white list update
path do the network policy manager, instead of going through
a broadcast we now directly call in to the network policy
manager. This also allows us to have a synchronous version
of updating the list, so we can know the app has network access
before we tell it to do anything.
Finally added battery stats events for things going on and off
the whitelist so we can diagnose the behavior there.
Change-Id: Ic7fe010af680034d9f8cb014bb135b2addef7455
Currently when app idle parole state changes, all idle apps' states
are updated one by one including firewall modifications which are
very expensive. This optimization gets rid of individual firewall
rule changes and makes sure we only modify the firewall once at child
chain level.
BUG: 21446713
Change-Id: Iafc415fe0bc127826fe17894d4fedcf1755cb17d
Doze and app standby are now off in the default platform config.
The Google overlay turns them on. Other people can do that as
well, if they are feeling like it.
Change-Id: Ic8a87f696df94f2d8354fe0772d03b672f464e32
Set sync adapters to active if the associated content providers are used
at foreground process state.
Minimize how frequently published content providers are reported by
keeping track of last reported time.
Also cache sync adapters associated with an authority in SyncManager.
Bug: 21785111
Change-Id: Ic2c8cb6a27f005d1a1d0aad21d36b1510160753a
Issue #21814207: AlarmManager.setAndAllowWhileIdle should also allow wake locks.
Introduce a whole new infrastructure for providing options when
sending broadcasts, much like ActivityOptions. There is a single
option right now, asking the activity manager to apply a tempory
whitelist to each receiver of the broadcast.
Issue #21814212: Need to allow configuration of alarm manager parameters
The various alarm manager timing configurations are not modifiable
through settings, much like DeviceIdleController. Also did a few
tweaks in the existing DeviceIdleController impl.
Change-Id: Ifd01013185acc4de668617b1e46e78e30ebed041
