Instrumentation package should be immediately marked as active so
that the jobs aren't throttled.
Also, make sure special apps' buckets are correctly initialized.
Fixes: 68900608
Fixes: 69799327
Fixes: 69793822
Fixes: 69788489
Test: atest CtsNetSecPolicyUsesCleartextTrafficTrueTestCases
atest FrameworksServicesTests:AppIdleHistoryTests
atest FrameworksServicesTests:AppStandbyControllerTests
atest CtsNetSecPolicyUsesCleartextTrafficUnspecifiedTestCases
atest CtsNetSecConfigDownloadManagerTestCases
atest CtsNetSecPolicyUsesCleartextTrafficFalseTestCases
cts-tradefed run cts-dev -m CtsAppUsageHostTestCases
cts-tradefed run cts-dev -m CtsHostsideNetworkTests
gts-tradefed run gts-dev -m GtsUsageStatsTestCases
Change-Id: Ic880b6f5ed1fdb7912613e882ccf7b2d4e388159
Only check for INTERACT_ACROSS_USERS in getAppStandbyBucket()
Bug: 70126098
Test: gts-tradefed run gts-dev -m GtsUsageStatsTestCases
Change-Id: I6c3f69ff56d8513f84c7d91162567d17c06980c3
Allow apps to query their own standby bucket.
Allow privileged apps with PACKAGE_USAGE_STATS permission to
query apps.
Allow privileged apps with CHANGE_APP_IDLE_STATE to set the
standby state for apps, but not for themselves.
Removed AppStandby class and moved constants into UsageStatsManager.
Bug: 63527785
Test: cts-tradefed run cts-dev -m CtsAppUsageHostTestCases
Change-Id: I3c1c20f6ecb6d54e248233696039286b243d663c
We need over 8 days of UsageEvents in order to capture weekly
patterns in our app usage models
Change-Id: I8e1149b82cfbaedae4d19bbbfaeffa989bfd54e7
Fix: 69244223
Test: It builds
Switch to using the new bucket thresholds and
remove the previous idle thresholds.
Bug: 63527785
Test: atest AppStandbyControllerTests
atest AppIdleHistoryTests
Change-Id: Ica3fd10fe172faa5b4e712b08273b77357fdae14
Start off with slightly more aggressive timeouts to
switch between buckets. 12Hrs, 24Hrs and 48Hrs.
Bug: 63527785
Test: atest AppStandbyControllerTests
Change-Id: I4aa0cc38ef91538192eda0f48dd3840217aa49c4
On a notification becoming visible, NOTIFICATION_SEEN event is
dispatched. This will only bump up the app's bucket to WORKING_SET and
no higher. Same goes for sync adapters associated with a content
provider. Only move them to WORKING_SET.
Updated NotificationManagerService to report event to usagestats on
visibility changes.
Bug: 63527785
Test: runtest -x
frameworks/base/services/tests/servicestests/src/com/android/server/usage/AppStandbyControllerTests.java
atest NotificationManagerServiceTest
Change-Id: I5b132e1fc1f70e2126473b43b9b1979fbc523b85
And inform listeners when the bucket changes, not just when
going in and out of RARE bucket.
Avoid redundant callbacks when informing listeners.
Bug: 63527785
Test: runtest -x
frameworks/base/services/tests/servicestests/src/com/android/server/usage/AppStandbyControllerTests.java
Change-Id: Icd98d59f597147fbf8ea4bf44edf4b3b3d5c8e14
Everything is now moved out of the pm command except for
the various install commands. I am going to hold of on
those since they require doing some resolution with the
current implementations in the package manager to make
sure they match and behave identically to the implementations
currently in the pm command. But other than that, everything
in pm is now just redirecting over to "cmd package".
Also fix up some of the dumpsys output of a few other sevices
when asking to print the data for a particular package, so
the "pm dump" command gives a little more sane result.
Test: manual
Change-Id: I139e06e560203b72243d7eea9543c2240db0f8f8
Manage the standby bucket in AppStandbyController
Default implementation of bucketing based on simple timeout:
ACTIVE, if recently used
12 hrs to move to WORKING_SET
2 days to move to FREQUENT
7 days to move to RARE
(subject to change)
RARE bucket equates to the old "idle" or "inactive" state for
an app.
Bug: 63527785
Test: AppStandbyControllerTests.java
Change-Id: I970d7afcdf47c31a9413da8fd4852066a13676a2
Move the App Standby code out of UsageStatsService into
an AppStandbyController class. This doesn't change any
behavior. Also, it doesn't change the entry points, which
are still in UsageStatsManager. The binder APIs are still
in UsageStatsService and are forwarded to
AppStandbyController.
This change is in preparation for switching to app standby
buckets instead of a boolean state.
Bug: 63527785
Test: adb shell dumpsys usagestats
adb shell am set-inactive <packagename> true
// Ensure state changes are persisted
Change-Id: Ic94357bdc891d1defae37bb29d533b6153a09967
This is becoming a common pattern (keeping track of which processes
are cached and not allowing them to do stuff in that state), so I
am turning this in to a general mechanism for monitoring this state
through the activity manager's IUidObserver. Now we can just have
AudoService implement its own IUidObserver to get this state and
update which uids it is blocking.
This required making some changes to uid change reports so that
the integer is now a bit mask instead of an enumerations, but that
is what it was already turning in to anyway. (This gets rid of
the crazy GONE_IDLE constant that we'd needed to add before because
it wasn't a bit mask).
Eventually the power manager should be changed to be told about
these changes to cached state instead of listening to every proc
state change, but we'll do that later, it is more disruption than
I want to take for now. However, while working on this, I noticed
that the power manager had regressed in the cached uids it would
actually block, because the activity manager was no longer telling
it about all uids that are idle. (I think this happened when I had
to change the default idle state of UidRecord to true.) So I am
adding a bit of new code to keep track of what idle state we last
reported to observers, to make sure we tell it about newly created
uids that are idle but have never actually become active.
Test: runtest -c com.android.server.am.ActivityManagerServiceTest frameworks-services
Change-Id: I7bfd46bacadd4cab2a69f40e6e52afb4e67b456a
New quota APIs are much faster than trying to measure manually, and
removing this last user of calculateDirectorySize() means we can
remove it once and for all.
Bug: 36056324
Test: builds, boots
Change-Id: Ibdf1ee4e8885680e106df6a9269b6309ddc61af8
We normally prevent apps from allocating into the "reserved" cache
space, but this change makes an exception for an active camera app,
since the user is probably trying to capture an important memory.
This change only lets the active camera app clear up to half of the
reserved space, since we don't want to completely destroy the
experience of all other apps.
Test: manual app before/during/after active camera session
Bug: 38267830
Change-Id: Ie9e63884fb2638ca881e10b894629eea84601648
When answering the question "how much space is free", use the same
logic for Settings UI and StorageManager.getAllocatableBytes(). That
is, the reported free space is usable bytes plus any cached data the
system is willing to delete automatically.
This does *not* include any reserved cache space, since we don't want
abusive apps to penalize other well-behaved apps that are storing
their data in cache locations. Callers freeing cached data need to
now explicitly request defiance of the reserved cache space. (Most
callers are already doing this by using FLAG_ALLOCATE_AGGRESSIVE.)
Rewrite the core logic of DeviceStorageMonitorService to understand
this new "reserved" cache space, and to be easier to understand. It
also now handles cached data on adopted storage volumes, which had
been ignored until now. Also fix bug where we had skipped "low"
broadcasts when the device skipped directly from/to "full" state.
Bug: 38008706
Test: cts-tradefed run commandAndExit cts-dev -m CtsJobSchedulerTestCases -t android.jobscheduler.cts.StorageConstraintTest
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Change-Id: Icbdcf3b52775f7ada1ceaeff2f96094c8d8052f9
Change-Id: I97f791b61f9b4f7ed33305345bf3d92394b40ae4
Fixes: 38202759
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest
Test: Manual. Create sample app that replaces the launcher to test ability to see ephemeral apps.
- Events are obfuscated based on whether the app was instant or not at
the time each event was logged.
- UsageStats are obfuscated based on whether each app is instant or
not at the moment.
Bug 38202133
Test: Manual test using UsageStatsTest and instant apps
Change-Id: I3c74309196b88d010d317cb0dd6749bf4624e876
For volumes where the OS manages cached data, use the "free space" as
reported by StorageStatsManager, which is the same value shown in
the Settings app and other UI elements.
Also, when the storage space changes significantly, invalidate anyone
who was holding a cached "free space" value.
Test: builds, boots
Bug: 38146029
Change-Id: I4b3a484a8bf32cd137a83f1ea441beca6dc6719a
We've seen evidence of lab devices racing with other apps that are
using cache space immediately after tests wipe it clean, which can
cause test failures. To mitigate this, try our best to wait for the
device to go "idle" by watching for broadcast queues to fully drain.
Also improve javadocs along the way.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Bug: 37486230, 37566983, 37913442, 37914374
Change-Id: I4d430db443b6fa6d33a625fe07b90279b5d51c12
Move aggressive allocation to @SystemApi, which means we can hide
the "flags" API variants.
Remove UUID APIs, since we should use existing Serializable APIs.
Relax permission checks to allow apps to ask for their own stats.
Improve docs.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Bug: 37534687, 37534941, 37718184, 37738770
Change-Id: I6a763fb3ab3169c8d3329765bb31e1ee08d9ced7
When counting code size, don't include APKs baked into the system.
Settings already accounts external storage used by apps, so they
need a way to exclude that from the total space used by external
storage; give them new getAppSize() API.
Refine docs to explain that emulated storage might be included in
measured statistics.
Resolve symlinks as part of matching getUuidForPath().
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Bug: 35812899, 35844919, 37193650
Change-Id: Iec3ce8b336b71dc98a7d25fdd30fa78e9ee826dc
Based on API council feedback, switch to using real UUID objects
instead of Strings. Since UUID is a general-purpose utility class
that will be passed around quite a bit, add it to Parcel and Bundle.
Define well-known namespaced UUID values for "default" and "primary
physical" storage devices, which will let us annotate a bunch of
things with @NonNull.
Define new extras for MANAGE_STORAGE intent that apps can use to
signal where and how much space they'd like the user to free up.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Bug: 37325923, 35812899, 35806020
Change-Id: I8421b126d680f69141a361c1e77223fe2bf4a325
If we are measuring storage and a volume is removed at the same time,
we can enter a state where we previously verified the volume existed,
but it no longer does. This causes an NPE.
By adding in a null check, we can avoid this crash.
Change-Id: Ib8dbf05102a122bdf4bb6063374e993a1de68425
Fixes: 36689190
Test: None
It's confusing, but f_bsize is not the value you're looking for; the
real block size is f_frsize. Fix all those bugs.
Also, the vast majority of clients are interested in the usable
disk space, not including reserved space.
Test: builds, boots
Bug: 36840579
Change-Id: Ib1470389afd49c14cab62282ec1e978ebb2c4791
Some system services are offering package usage data through both
public/system APIs and through dump() calls. In principle, usage
data hould always be protected with PACKAGE_USAGE_STATS, so start
enforcing that. (Otherwise if a user blocked PACKAGE_USAGE_STATS
access to an app, that app could still obtain the data via dump()
if they held the DUMP permission.)
Bottom line, let's respect the user's wishes.
Protecting the entire output like this is pretty blunt, but future
CLs can add more nuance to the output if desired.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: I46173562713bea7d89e12a4313c78eb52ea8d77d
This change introduces new methods on DumpUtils that can check if the
caller has DUMP and/or PACKAGE_USAGE_STATS access. It then moves all
existing dump() methods to use these checks so that we emit
consistent error messages.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: Iaff6b9506818ee082b1e169c89ebe1001b3bfeca
to meet CDD requirement.
bug: 33423136
Test: manual - shared images in Camera. More CTS and GTS tests to be
added.
Change-Id: I0e0c759bec11137e2290f4a43a92be8e97eef022
Using the word "atomic" has too much baggage relating to locking
guarantees, so move to something softer.
Add isQuotaSupported() for CTS tests.
Move CacheQuotaStrategy over to using SparseLongArray, which has a
more efficient memory footprint inside the system server.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Bug: 35812899, 35684969, 36482620
Change-Id: I894f53e6f3bc76c77d1bb18c51db14833df14a49
Now that we have CTS tests to verify the cache clearing v2 logic,
we're ready to enable it!
Switch storage APIs over to "usable space" to match implementation
down in installd. Add a missing clearCallingIdentity(), and offer
better logging for missing appop permission.
Load quotas from disk right away at device boot instead of waiting.
Bug: 35685848, 35684969
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Change-Id: I8167e0322b4662ca6c975da5c50715e2d71332a7
Apps that live on adopted storage devices appear to be uninstalled
while ejected. They're technically still valid apps, with allocated
UIDs, so use MATCH_UNINSTALLED_PACKAGES when querying for their
details.
Test: builds, boots
Bug: 36177795
Change-Id: Ia7ed5f0462b1f47609ea8e1ace6fa145e0b5602c
Can be used to quickly pivot between manual and quota calculations
when running CTS tests.
Bug: 35684969, 35441006, 34945234
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Change-Id: I7500dde597a4f3cde20998df45c5d54a053181fc
First, every time installd starts up we need to invalidateMounts()
to ensure we have valid mappings for quotactl() to work. (Without
this forced invalidation, we were falling back to manual calculation
after an installd restart.)
Second, when calculating the disk space for an app, we need to use
the real appId deconstructed from the uid; oops! (Without this we
were always trying to calculate the disk usage for UID 0, which
forced us back into the slow-path.)
Bug: 36032444, 35706513
Test: runtest -x frameworks/base/services/tests/servicestests/src/com/android/server/pm/InstallerTest.java
Change-Id: I1ca55e2b7670678ed55798e2e06857d727ce2487
This procStateSeq is associated with the process state change of
an uid and will help in identifying if network policy rules have been
updated for a process state change.
Bug: 27803922
Test: runtest -c com.android.server.am.ActivityManagerServiceTest
frameworks-services
Change-Id: Iaab8d004f476b96f28d08c886c7b0a6b585b9fef
Apps should now be able to get the real cache quota
value, instead of a stock 64MB.
Bug: 33965858
Test: Manually verified that an app recevied a non-64MB quota.
Change-Id: Idba47ecba356ffb592694a0d5a72363f3d0e95d0
This will prevent us from unnecessarily redoing calculation work
by loading the last caches on boot and shoving them down to
installd.
Bug: 33965858
Test: Framework services tests
Change-Id: Ie94e269aa72bceb1ebe87911eaa42e2d826c1123
This simplifies the QA process significantly more than
I originally expected.
Bug: 34400961
Test: Manual
Change-Id: I5d26526e7ea9a7f16a00b7c2281c5b460f6bbbff
Decoupled the app idle book-keeping from usage stats lock, by
introducing an mAppIdleLock. This is used for all state related
to app idle. In some cases, the locks will be nested, with
mLock being acquired first and then mAppIdleLock.
This should fix the situation where a rollover, which writes to
disk and could take several seconds when the system is swamped,
like when the device just came out of idle and the screen was
turned on (like this run-on sentence), causes calls from other
services for app-idle status to be blocked. This was resulting
in a long time to turn on the screen.
Also fixed a dump indentation issue.
Bug: 34627115
Bug: 34961340
Test: Manual, force into idle, increased rollover frequency,
and tested screen on time.
Change-Id: Ie8b44e6f07f82d8a31f1b733a403dd9b6dc310f6
This allows manual QA folks to change the datetime to test events
which depend on a large gap between uses of an app.
Currently, if the system detects a drift of more than 2 seconds,
it will automatically correct the usage stats. This means that manual
time changes will cause the usage stats to update to match, making it
impossible to test manually.
Bug: 34400961
Test: Manual
Change-Id: Iffb92c929872d841d22f089ec71922bf120cc544
