The periodic parole window is the 10 minute window that occurs every
24 hours to let RARE apps run. Now that we have the quota system in
place, there's no need to have the periodic parole window. Alarms and
jobs will still be allowed to run when charging. Network will continue
to be restricted for RARE apps even when charging. JobScheduler requests
an exception for RARE jobs in quota, so they will still be able to run.
Bug: 136184981
Test: atest AppStandbyControllerTests
Test: atest CtsAlarmManagerTestCases
Test: atest NetworkPolicyManagerServiceTest
Test: atest com.android.cts.net.HostsideRestrictBackgroundNetworkTests
Test: atest com.android.server.AlarmManagerServiceTest
Test: atest com.android.server.AppStateTrackerTest
Test: atest com.android.server.job.controllers.QuotaControllerTest
Test: atest com.android.server.net.ConnOnActivityStartTest
Change-Id: Ide382ad7fb9c7441f0a5232833ad39bf8c3a1e94
Allow the active supervision component to access app usage limit APIs.
This includes #registerAppUsageLimitObserver
and #unregisterAppUsageLimitObserver.
Bug: 138681869
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest#testIsActiveSupervisor
Test: atest AppTimeLimitControllerTests
Test: atest android.app.usage.cts.UsageStatsTest
Change-Id: I3daafc14ccdbf27558c1325b965f2bc6d2dab2f6
Due to the recent migration to CE, some async calls were being triggered
after the user was removed. Most places were already handled by a
previous CL - this is just another minor fix.
Bug: 141979865
Test: builds and flashes
Change-Id: I059180cb99d04ac266b3e4745f141c285e189314
With the migration of usage stats data to CE, it's possible for a user
unlock event to be handled after the user has been removed. To prevent
exceptions from being thrown when the user is stopped or removed, when
an exception is thrown, check if the user is unlocked, only then throw
the exception.
Bug: 141307758
Test: atest CtsDevicePolicyManagerTestCases
Change-Id: I70fdb56dd6e87dc911c400554a4b5760785b87a4
The time change event was happening for every user even if they were not
unlocked, causing UsageStatsService to crash. Since the data is now
located in CE, the #checkAndGetTimeLocked function has been moved to
UserUsageStatsService, tying time change events to each user instead of
UsageStatsService. This gives the guarantee that no usage stats data
will be accessed or modified if the user service is not existent while
keeping the same behavior as earlier.
References to #checkAndGetTimeLocked in UsageStatsService have been
updated to call System.currentTimeMillis() directly.
Bug: 140529704
Test: atest UsageStatsTest
Test: atest UsageStatsDatabaseTest
Change-Id: I746790f3918b927ac8ac76ee860c94cac603e5da
Move all of the usage stats data from the regular system storage to
the system CE (credential encrypted) storage.
All events being reported while the user is locked will be stored
in memory and will be processed via the handler after the user is
unlocked. All of these events reported will regularly be persisted to
system DE storage to ensure important events are not lost.
Any query requests will be ignored while the user is locked.
Two new usage events have been added: one to indicate the user has been
unlocked and the other to indicate the user has been stopped.
Also updated documentation for APIs in UsageStatsManager to reflect the
new behavior in R when the user is locked.
Bug: 135484470
Test: atest android.app.usage.UsageStatsTest#testDataIsInCe
Test: atest android.app.usage.cts.UsageStatsTest#testUserUnlockedEventExists
Test: atest android.app.usage.cts.UsageStatsTest
Test: atest UsageStatsDatabaseTest
Change-Id: I18da1a9354b6686472972c5f2304e4c19e28307f
ProtoInputStream.isNextField() skips over the current field to read the
next tag. This side effect means that calling isNextField prevents the
caller from reading the field it was just on. The "is" prefix makes it
easy to assume that the method has no side effects. Renaming to
nextField(long) with a parameter should help make it clear that the call
is as dangerous as calling nextField().
Fixes: 137294060
Test: atest android.app.usage.UsageStatsTest
Test: atest android.app.usage.cts.UsageStatsTest
Test: atest com.android.server.usage.UsageStatsDatabaseTest
Test: atest ProtoInputStreamTests
Change-Id: Ibfb8ef741f27a211f076dc0b715b64acbfc0696a
Similar to how we target DE and CE storage areas, callers need to
specifically ask to work with EXTERNAL storage. This is because
external storage often lives on a separate device from where internal
DE and CE data lives.
As one specific example, if we're moving an app between two
"internal" storage devices, we don't want to clean up the data
for that package on external storage, since it's not being moved.
This change also expands to all mounted external storage devices,
not just the storage backed by the incoming UUID.
Bug: 113277754
Test: atest android.appsecurity.cts.StorageHostTest
Test: atest android.appsecurity.cts.ExternalStorageHostTest
Test: atest --test-mapping frameworks/base/services/core/java/com/android/server/pm/
Change-Id: Ie125303726dd757ee45bd373f53addb35569c2f7
1. checkCarrierPrivilegesForPackages by subId
2. getPackagesWithCarrierPrivileges by subId
3. new hidden API getPackagesWithCarrierPrivilegesForAllPhones which
returns packages for all subs.
Bug: 132078279
Test: Manual
Change-Id: Ic666218f0c290d1b428530982b689af110f74c69
'dumpsys usagestats file [user] [interval] [filename]' added.
When all options are specified, this command dumps all usage stats
information stored in the specified filename.
If the filename is not specified, information of all files for the
specified interval is dumped.
If the interval is not specified, information of all files in all of the
intervals for the specified user is dumped.
If the user is not specified, information for all users is dumped.
Also added 'dumpsys usagestats database-info [user]'. This simply
connects the existing dump in UsageStatsDatabase.
If the user is not specified, information for all users is dumped.
Bug: 131923219
Test: various combinations of the dumpsys command added
Change-Id: Id2c2b20e07f9ab0e1a577e45fba199d565532b7b
If an app is in the NEVER standby bucket, a foreground service start
will bring the app up to the ACTIVE bucket for 30 min (by default).
Foreground service starts in other circumstances will not affect the
standby bucket
Bug: 111578623
Test: atest AppStandbyControllerTests#testInitialForegroundServiceTimeout
Change-Id: Ia9d5fd7a04d2378a5525457d465da7ed463fe8fc
When upgrading a device from P build to Q build, since mInstanceId,
majorVersion, minorVersion are newly added fields in Q build, P version
XML file does not have this fields and Q build will get
java.net.ProtocolException and these newly fields are assigned default
value. This is normal during upgrade process. There is no need to
printout the exception and stack trace because that would confuse
people.
Bug: 127451110
Test: NA.
Change-Id: I0fb38a68d7f049b7f417c9ca444db61c4e5c3657
Close hole in IntervalStats time tracking.
Fix EventTracker commitTime math
Also make eventList final
Fixes: 124850206
Test: builds and runs
Change-Id: I967cd4b3f5ccea0f7f8fd7e8729f258a5f8f1981
Update the time remaining parameter of #registerAppUsageLimitObserver to
time used to avoid confusion between time limit and time remaining.
Bug: 128414428
Test: atest FrameworksServicesTests:AppTimeLimitControllerTests
Test: atest android.app.usage.cts.UsageStatsTest#testObserveUsagePermissionForRegisterObserver
Test: atest android.app.usage.cts.UsageStatsTest#testObserveUsagePermissionForUnregisterObserver
Test: manual (mmma frameworks/base/tests/UsageStatsTest/)
Change-Id: Ied8e4ca0b8636bb9efc4d85dcae46ac6cf1ef5f7
As a counterpart to DEVICE_SHUTDOWN event, DEVICE_STARTUP records the
device startup event and timestamp.
Bug: 126529272
Test: adb shell dumpsys usagestats | grep DEVICE
Change-Id: Ia977658f9a1f701ad802dc943e9eff71171e9957
UsageStatsManager#registerAppUsageLimitObserver now accepts the time
remaining in addition to the total time limit.
The API now also uses java.time.Duration instead of long+TimeUnit for
the total time and remaining time.
Bug: 124272203
Test: atest FrameworksServicesTests:AppTimeLimitControllerTests
Test: atest android.app.usage.cts.UsageStatsTest#testObserveUsagePermissionForRegisterObserver
Test: atest android.app.usage.cts.UsageStatsTest#testObserveUsagePermissionForUnregisterObserver
Test: manual (mmma frameworks/base/tests/UsageStatsTest/)
Change-Id: I6f85ca9295cad46e10a30035b67e6210ae5c1886
Also repair defaults if persisted file is missing on boot.
Fixes: 123206562
Test: manual ("adb shell reboot" within 20 min of a fresh wipe
"adb shell dumpsys usagestats"
System apps bucket levels equal 10)
Change-Id: I0403099c899d181ef6206cc9f5516c25213edc9c
Print total number and list of daily/weekly/monthly/yearly files, so
we can tell if excessive number of files are created.
Bug: 125426689
Test: "adb shell dumpsys usagestats" and search for UsageStatsDatabase
Change-Id: Id5c6028151d4c21e019820f7b6070712283f4983
Now IntervalStats.events field is initialized at construction of
IntervalStats object, we can remove the extra null-check on
IntervalStats.events, make code more clean and readable.
Test: atest UsageStatsDatabaseTest.java
Change-Id: I2580509f41593c1fdf380ba56ebc7a5b6c6f0c5f
A wrong condition causes new sets of daily/weekly/monthly/yearly files
been created before it reaches the rollover time.
Currently database files are pruned by timestamp, it allows 3 years
yearly files, 6 months monthly files, 4 weeks weekly files, 10 days
daily files. Because the bug there could be unlimited number of files
are created as long as files' timestamp falls in these allowed time
spans.
Add a logic to prune files by number of files. Only allow up to 10 yearly
files, 12 monthly files, 50 weekly files, 100 daily files.
Change-Id: Iac42f70ae19edb48885a123dfd9988021de6c88d
Fix: b/122725555
Test: NA.
It is possible for an activity's task root to be reported as null to
UsageStats during a destry. Use past known data to populate the fields.
Change-Id: Id20c809580e854ca9075444957bd10a338087e3d
Fixes: 123404490
Test: atest cts/tests/tests/app.usage/src/android/app/usage/cts/UsageStatsTest.java#testSuddenDestroy
A wellbeing app can now register AppUsageLimit observers with a time
limit of 0 seconds. There will be no callback intent fired in this case.
Bug: 123899673
Test: atest FrameworksServicesTests:AppTimeLimitControllerTests#testAppUsageLimitObserver_ZeroTimeLimitIsAllowed
Test: atest android.content.pm.cts.LauncherAppsTest#testGetAppUsageLimit_allowsZeroLimit
Change-Id: I9cdff21bcfa72f202699cea288e703f35a4f158f
Device level event like DEVICE_SHUTDOWN does not have package name,
but some user code always expect a non-null packageName for every event.
Create a default packageName for these device level events.
Change-Id: Iee49794bdc6f5cb7b30d50f7421ac0de2a33c858
Fix: b/123429960
Test: NA.
