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
Create a user-agnostic package-level last time used usage stats for app
hibernation. Usage is updated when USER_INTERACTION or
APP_COMPONENT_USED event reported. Also moved checkAndGetTimeLocked and
convertToSystemTimeLocked methods up to UsageStatsService class and
refactored usages.
Bug: 183142974
Test: atest CtsUsageStatsTestCases:UsageStatsTest
Test: atest UsageStatsServiceTest
Test: atest UserUsageStatsServiceTest
Change-Id: I93d8653bb92b98af8f6b57156eb1139fbd7e562a
Created a new metrics called mLastTimeComponentUsed in UsageStats.
It is persisted and loaded as other metrics.
Bug: 175829712
Test: core/tests/coretests/src/android/app/usage/UsageStatsTest
Test: cts/UsageStatsTest
Test: UsageStatsDatabaseTest
Test: UsageStatsServiceTest
Test: UsageStatsPersistenceTest
Change-Id: I10cf5c40cf5955246a6a04e96ac0352b4ed29acd
* changes:
SysUI changes for setSuppressBubble
Track locusId visibility in ShellTaskOrganizer
Add locus id to ActivityRecord / TaskInfo
Bubble API: suppress bubble
1) We need a way to listen for locusId, this is done via
a new listener on ShellTaskOrganizer that is informed
for all task info changes.
2) When locusId for focused activity changes, check for
a bubble in data that has a matching locusId & has
API set
3) Add suppress/unsuppress in the state change flow and
update the views
TODO in later CL:
- animate the view being hidden / shown; handle flyout
Test: atest ShellTaskOrganizerTests BubbleDataTest BubbleXmlHelperTest (also CTS CL)
Bug: 170267239
Change-Id: I5c9bd15fa8b5b326e146efdc40916454ca1c73f6
