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
Add a new usage event to UsageStats when a component in a package is
used (content provider binding, explicit broadcast, activity resume)
and it is considered to be important usage.
The follow-up CL will handle the service binding case as it is a little
complicated due to job bindings.
Bug: 175829712
Test: adb shell dumpsys usagestats <package-name>
Test: atest UserUsageStatsServiceTest
Change-Id: I1f2967dcf5999a8f0affea94bce4c0873a04e022
As ARC is moving from a container to a VM based solution, change the
build method to detect this.
Bug: 139490365
Test: Check that VM works after pushing to device: run play store,
install app.
Change-Id: Ic91a7e5c9a36242d2c905cecffeec72acba8ff45
(cherry picked from commit 2f78de6d0e1428d959f97ea0dd0e3c9c28b6e3fb)
Allow queryUsageStats to take in the context's userId. This
allows apps like Settings to query usage stats across
profiles.
Bug: 146921442
Test: atest CtsUsageStatsTestCases:UsageStatsTests
Change-Id: Ia6c90c1a31887efa8d5446c1b1b11e75cb9ab83e
Various ActivityManager actions require calls to
UsageStatsService.reportEventOrAddToQueue(), but that function can
block for hundreds of milliseconds while UsageStatsService is
initialized during post-unlock. However, the only important part of
reportEventOrAddToQueue is the check to see if a user has been
unlocked, at which point the action is enqueued on a Handler.
Move mUserUnlockedStates to a CopyOnWriteArraySet, which should be
updated very infrequently, and allow the common case of "the user is
unlocked and an event should be added to the queue" to run
concurrently with other UsageStatsService operations.
Test: atest android.app.usage.cts.UsageStatsTest
Test: atest android.app.usage.UsageStatsTest
Test: atest UsageStatsDatabaseTest
Bug: 161866124
Change-Id: I11743d78f20db5e5a9471544ae5a1c0ab492202d
