When apps are restored, set their standby bucket to RARE if
they have been used within the past 90 days, based on the
restored UsageStats data.
Bug: 214580000
Test: atest UsageStatsDatabaseTest
Change-Id: I9d63032ef84fef97734b51323f41b797caa4f554
(cherry picked from commit 89f69113ad)
If a pre-created user is removed before it becomes a full user, the
ACTION_USER_REMOVED intent is never sent, so UsageStatsService is never
notified that the user's pending events should be discarded. It will
eventually try to persist the events. As the first step, it tries to
create /data/system_de/$userId/usagestats and the parent directory
/data/system_de/$userId if it doesn't already exist.
However, due to https://r.android.com/2078213 the SELinux policy no
longer allows system_server to create /data/system_de/$userId. The
failure to create this directory is causing UsageStatsService to throw
an IllegalStateException which crashes system_server.
(Before the sepolicy change, system_server could create
/data/system_de/$userId, so the crash wouldn't have happened. But
problems still might have occurred if the user ID was reused.)
The underlying user state tracking bug still needs to be fixed. For
now, just avoid crashing system_server unnecessarily, and avoid an
SELinux denial by using mkdir() instead of mkdirs().
Test: pm create-user --pre-create-only
pm remove-user 10
# Wait 20 minutes and check logcat.
Bug: 234059731
Change-Id: Ic5efc19cda6b820a2c07f77b4f316d501acb9e80
For the purposes of tracking whether there is a response event
from an app after receiving a broadcast, treat all broadcasts
received by the app immediately after each other into a single
session and when there is a response event, then treat as if
the app received only one broadcast and there is one response
event corresponding to that.
Bug: 206518114
Test: atest tests/tests/app.usage/src/android/app/usage/cts/UsageStatsTest.java
Change-Id: I4c495d07026a4d6ab445ce463bd1b07e9a89bd06
When we added the new ACCESS_BROADCAST_RESPONSE_STATS
permission, we updated the new broadcast response
related APIs to check both PACKAGE_USAGE_STATS and
ACCESS_BROADCAST_RESPONSE_STATS permissions until clients
are udpated to use the new permission. We can now remove
the logic for checking PACKAGE_USAGE_STATS permission and
only consider ACCESS_BROADCAST_RESPONSE_STATS.
Bug: 225039700
Test: atest tests/tests/app.usage/src/android/app/usage/cts/UsageStatsTest.java
Change-Id: I5b8e8565b936b26463110ce1f0368122c322e632
/data/system_de is only for per-user data; it *must* only contain
per-user encrypted directories. Only vold should ever create anything
directly in this directory. In preparation for removing system_server's
write access to this directory (https://r.android.com/2078213), make
UsageStatsService store its globalcomponentusage file at
/data/system/usagestats/globalcomponentusage instead of
/data/system_de/usagestats/globalcomponentusage.
Migration happens lazily, except that the old file and directory aren't
ever deleted since the SELinux policy will no longer allow system_server
to do that; the old file just stops being used. vold will need to
handle the cleanup instead, or we could just leave the file around.
Note that before Android 11, UsageStatsService stored per-user stats in
/data/system/usagestats/$userId. These per-user stats are *not* the
same thing as globalcomponentusage, which was added in Android 12.
UsageStatsService contains code to migrate the per-user stats to
/data/system_ce/$userId/usagestats. This is fine, and is the right
thing to do, since the per-user stats are potentially sensitive per-user
data. This does mean that UsageStatsService now implements two types of
migrations, and that the source directory for one migration is the
target directory for the other, which is a bit unfortunate. However,
since different files are involved in each one, it all works out.
Bug: 156305599
Change-Id: I53c16640e8ed8b7eac111990f1cdb3f59579e051
Track pending estimated launch time changes in a single Set so that we
avoid sending repeat notifications for a single package.
Bug: 227796747
Test: atest CtsUsageStatsTestCases:UsageStatsTest
Test: atest FrameworksCoreTests:android.util.SparseSetArrayTest
Test: atest FrameworksMockingServicesTests:PrefetchControllerTest
Test: atest FrameworksMockingServicesTests:UserUsageStatsServiceTest
Change-Id: I671c97e4e4110d0a1c76a8f6400dfe8c1e5055dc
Cache the results from getEarliestEventsForPackage() so we don't have to
go down to the raw database as often.
Bug: 227796747
Test: atest CtsUsageStatsTestCases:UsageStatsTest
Test: atest FrameworksMockingServicesTests:PrefetchControllerTest
Test: atest FrameworksMockingServicesTests:UserUsageStatsServiceTest
Change-Id: I2e3cf6650ed36b4915e4fcab16e9519cc8800f65
* changes:
Add new onUidProcAdjChanged callback to be consumed by the camera service.
Modify UidRecord.CHANGE_PROCSTATE such that it behaves like a bit mask.
service.
The camera service needs to know when individual process oom adj scores
are changed in order to address bug #124224342. When two separate
processes are displayed in split screen and focus is switched between
them, both proc states will remain the same while their oom scores
change. This is a problem if both have access to the camera - we want
only one owner of the camera stream at any given time and for the app
in focus to be the one to own it.
This patch adds a new IUidObserver registration level for individual
process oom score changes. In addition a new callback has been added to
IUidObserver to track these changes.
Change-Id: I68d964f474d20f819f54b614a4e314ce00aac8fb
Bug: 124224342
Test: -- ActivityManagerServiceTest
-- ActivityManagerProcessStateTest
-- ActivityManagerFgsBgStartTest
-- UidObserverControllerTest
-- NetworkPolicyManagerServiceTest
-- ShortcutManagerTest2
-- HintManagerServiceTest
-- VibrationSettingsTest
-- CameraEvictionTest#testCamera2AccessCallbackInSplitMode (x100)
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
Merged-In: I94a8e3dfca8ef4c7616f77944d61726e06043b85
(cherry picked from commit 157fbcfbe4)
Merged-In:I94a8e3dfca8ef4c7616f77944d61726e06043b85
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
