Instead of re-using PACKAGE_USAGE_STATS permission,
we are creating a new permission to guard access to
broadcast response stats.
For now, we check both permissions until the clients
migrate to using the new permission.
Bug: 225039700
Test: atest tests/tests/app.usage/src/android/app/usage/cts/UsageStatsTest.java
Change-Id: I65965b647da5994f434167693df999bc939807e2
This will allow the tests to query the value for
appstandby constants that are last known to
the AppStandbyController.
Bug: 221176951
Test: atest ./tests/tests/app.usage/src/android/app/usage/cts/UsageStatsTest.java
Change-Id: I8175c9f0acbc44b25606b477c6db8b0edf85991d
An SystemApis that allow a prediction app to update app launch time
estimates.
Bug: 194532703
Test: atest CtsPermissionTestCases:AppIdleStatePermissionTest
Test: atest CtsPermission2TestCases
Change-Id: I0fde220fa038f7f1f4d543a8906e92ca625bf097
If a profile owner is defined for a specific user, do not delete usage
stats for a package on package deletion.
Bug: 197399948
Test: atest UserUsageStatsServiceTest
Test: atest UsageStatsTest [all]
Change-Id: I94a8e3dfca8ef4c7616f77944d61726e06043b85
We estimate the next app launch time by looking at the past 7 days of
usage history and assuming that the user opens the app like clockwork.
If there is at least 24 hours of usage events, then we take the earliest
ACTIVITY_RESUMED event and estimate that the app will be launched
exactly 7 days after that event. If there is less than 24 hours of
history (which would be the case for a new app), then we take the
earliest ACTIVITY_RESUMED and add 24 hours. If we don't see any launch
event in the past 7 days, then we just say the app should be launched
within a year. If we have a long estimate for an app and it is launched,
then we re-evaluate our estimate because we can now estimate a launch
within the next 7 days.
Bug: 194532703
Test: atest FrameworksMockingServicesTests:PrefetchControllerTest
Test: manually launch apps and check dumpsys for expected launch time changes
Change-Id: I9ef5fc3e3df3c2d029243b1fb8949a4bf21900db
1. Don't hold the lock for validation checks that don't need it.
2. Put early returns ahead of other work when possible.
Bug: 203811598
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/usage
Test: atest frameworks/base/services/tests/mockingservicestests/src/com/android/server/usage
Change-Id: Ic923db1534e27e0932e594b8259fe482772b8a6a
UsageEvents.getAppStandbyBucket() and .getStandbyBucket() are the exact
same (except for the name). Remove the hidden one.
Bug: 135214188
Test: Android builds
Change-Id: I1c42228fe31e9d978df1cb5feda04a2c0a542904
Enforce the permission check for both INTERACT_ACROSS_USERS and
PACKAGE_USAGE_STATS permissions.
Bug: 191382775
Test: atest CtsUsageStatsTestCases:UsageStatsTest
Change-Id: I1371070478306005b2b4a59a1bc794bc368ae0c4
UsageStatsService wrongly assumed a ACTIVITY_PAUSED event must be
preceded by a ACTIVITY_RESUMED event, but there are some scenarios where
it is possibly to go directly from STOPPED to PAUSED.
Fixes: 182007710
Test: manual (start a pip activity, turn off the screen, and turn it
back on. UsageStats logs should not report unexpected events.)
Test: atest android.app.usage.cts.UsageStatsTest
Change-Id: I609ecb574d8401ab597aa61ba7c3b9d1f4e66827
Finishing the suspend dialog when the package for which it was shown
gets unsuspended for any reason.
Also, attributing any interaction with this dialog to the suspending
package, as the system is showing the dialog on its behalf.
Test: Manual, from an unrooted shell:
adb shell pm suspend com.android.chrome
Tap to start chrome and wait for the dialog to appear. Then:
adb shell pm unsuspend com.android.chrome
The dialog should disappear. Further,
adb shell dumpsys usagestats
should show USER_INTERACTION for com.android.shell.
Bug: 169137795
Fixes: 180336589
Change-Id: I70b6f23e2994d8802335e35932ed09209754697c
