If a job is started as an EJ, we should stop it once the EJ quota is
finished, regardless of remaining regular quota. If we don't, then the
job would get EJ privileges even though the app shouldn't be getting
them anymore.
Bug: 224533485
Test: atest CtsJobSchedulerTestCases:JobThrottlingTest#testRestrictingStopReason_ExpeditedQuota_noCharging
Test: atest CtsJobSchedulerTestCases:JobThrottlingTest#testRestrictingStopReason_ExpeditedQuota_startOnCharging
Test: atest CtsJobSchedulerTestCases
Change-Id: Ib11023c4e3c05f2b3512bd069bda953fdd9bd0b9
* changes:
Add new onUidProcAdjChanged callback to be consumed by the camera service.
Modify UidRecord.CHANGE_PROCSTATE such that it behaves like a bit mask.
We're encouraging developers to switch from FGS to EJs. However, there
were some aspects of EJs that made developers hesitant to switch over.
This addresses one of the concerns by allowing EJs for the TOP app to
start immediately. "Immediate" here means we start the JobService (call
Context.bindService()) before the call to JobScheduler.schedule()
returns (assuming all of the constraints are met). In order to guarantee
"immediate," we needed to remove the concurrency limit on top-started EJs.
This means there's a chance the TOP app could run more than our intended
limit of 16 apps, so we create new JobServiceContexts for TOP EJs if need
be, and if we ever have more than 16 total jobs running, we don't start
any new jobs (except TOP EJ) until we fall back below the 16 limit. If we
ever get above the intended limit, TOP EJs will be forced to stop at the
earlier timeout (default 3 minutes) instead of being allowed to run for
the full 30 minutes.
Bug: 223437753
Test: atest CtsJobSchedulerTestCases
Test: atest frameworks/base/services/tests/mockingservicestests/src/com/android/server/job
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/job
Change-Id: I97d19f47533690196619a080087bf0a56a21e8f2
If the pending queue is empty, then we don't need to do all the work of
determining job assignments.
Bug: 141645789
Test: Android builds
Change-Id: I3dfad0ea128580ba7e924b332464b807eb2c403f
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)
Added a compat change id for use of this permission. By default this
change will be enabled for apps targeting T or above.
Fixed and optimized the logic dealing with app-update permission
changes.
Separated out hasUseExactAlarm from hasScheduleExactAlarm to have
clearer meanings.
Test: atest FrameworksMockingServicesTests:AlarmManagerServiceTest
atest CtsAlarmManagerTestCases:ExactAlarmsTest
Bug: 218533173
Change-Id: I116323a4aed1e7cc103d4125cfd70c5230209120
If the bg restriction level is inferred from the app standby bucket,
use the reason code from the app standby as the one of being in
such a bg restriction level.
Also fixed an issue where we'd need to restrict the offending bg apps
when it's backgrounded.
Bug: 225951652
Bug: 203105544
Test: atest FrameworksMockingServicesTests:BackgroundRestrictionTest
Change-Id: I5925e90e19d2f8c99d43c0637560d8629c887ed4
The preferred UID is set when we call
JobServiceContext.cancel(...PREEMPT), so clearing the preferred UID
before that call is pointless. Also, make sure not to clear the
preferred for contexts that are only going to be used to transfer jobs
to the preferred UID.
Bug: 141645789
Bug: 204924801
Test: Android builds
Change-Id: I18db34a389919432b604d68f90a6901d9e6f9cba
The concurrency manager was accidentally limiting background apps to one
job at a time instead of correctly letting them run multiple jobs and
limiting them when they hit the package concurrency limit.
Bug: 204924801
Test: atest com.android.server.job.JobConcurrencyManagerTest
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/job
Test: atest frameworks/base/services/tests/mockingservicestests/src/com/android/server/job
Change-Id: I51d9c41ce0c47fc1f634f3df8753730d7d3c641a
Tearing down means unregistering receivers, but if the receiver isn't
registered, then the system will crash. Now, we make sure the receivers
were registered before trying to unregister them.
Bug: 158300259
Test: manual via developer options
Change-Id: I3a022002e2f1286718e08fe1dddf83deda6290de
The debug was printing the context assignments based on the old
mechanism instead of the new one, which meant it wasn't printing
anything.
Bug: 141645789
Test: enable logging and view logcat
Change-Id: I53b2f166cc2c891ef222f35c0889f26dbbf4ccb2
Test jobs should always be pulled first, so optimizing the iteration for
batching won't work with tests. Skip the optimization when dealing with
test jobs.
Bug: 226554375
Test: atest FrameworksServicesTests:PendingJobQueueTest
Change-Id: Icd55cb7f2f6efe00c87272f851661a964fb7c4d0
These tests are currently assuming the initial last used
timestamps to be 0 which is used to be true but not anymore
after the change Ib90b435b1efc34144f0461aaaf339fc6037ecdc2.
So, explicitly initialize the last used timestamps to 0
in the test setup to keep these tests working.
Bug: 225776572
Test: atest services/tests/servicestests/src/com/android/server/usage/AppStandbyControllerTests.java
Change-Id: I5a0246d1d9fec57bd37b941eb93701dfc7da7576
The charging state denoted by mAppStandbyParole was always false, which
would be incorrect if the device was plugged in on boot.
Test: atest FrameworksMockingServicesTests:AlarmManagerServiceTest
Fixes: 187500081
Change-Id: I422aca3c181733ba908e70decbbd43d62723337a
An unused app should be in NEVER bucket but without this change,
when we calculate the standby bucket of an app that was never used,
it could end up in RESTRICTED bucket.
Bug: 206518483
Test: atest tests/tests/app.usage/src/android/app/usage/cts/UsageStatsTest.java
Change-Id: I839041b7aedc87923879ca872c570c35c39b85a5
Switch the pending job sorting mechanism the new topological-sort-like
mechanism. The new system is generally more efficient and easier to
maintain than the previous implementation and allows for further
improvements such as batching in the queue (to reduce process restarts).
Runtime changes (A=# of apps, J=average # jobs per app):
Previous implementation New implementation
Sorting: A*J*log(A*J) A*J*log(J)
Insertion: log(A*J) log(A*J)+J
Remove(Object): A*J log(A*J)
Iteration: A*J A*J (amortized)
Contains: A*J log(A*J)
Bug: 141645789
Bug: 204924801
Bug: 223437753
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/job
Test: atest frameworks/base/services/tests/mockingservicestests/src/com/android/server/job
Test: atest CtsJobSchedulerTestCases
Change-Id: I61cf8488d574e3c7be624b753a02e8c1f151f4fd
Batch the jobs pulled during iteration so that we pull several of an
app's jobs from the queue sequentially (resulting in some out of order
pulls) instead of pulling purely based on the sort order. Batching it
this way will mean we try to run several jobs of the same app at the
same, resulting in fewer process restarts, and can allow the iteration
runtime to amortize to O(A*J) instead of O(A*J*log(A)) for A <= 33,
where A = # apps and J = average # jobs per app.
Bug: 204924801
Test: atest FrameworksServicesTests:PendingJobQueueTest
Change-Id: I4d3dc17afb4d4ab0fb573d75a319bdb20a68c634
Override state is only set via adb, which means its used for testing job
execution. Make sure we put jobs under test at the front of the queue to
avoid issues with execution delay.
Bug: 141645789
Bug: 223437753
Test: atest FrameworksServicesTests:PendingJobQueueTest
Change-Id: Icc4788117c46ada49c030f82f26affbd56e6ef69
Create a pending job sorting mechanism that is more like
topological-sort. The new system sorts pending jobs for each
individual app and then picks from each app's list based on the adjusted
"enqueue" time to retain some fairness. This new sorting may result in
an app's jobs being run more closely together (which helps reduce the
number of separate process startups).
Runtime changes (A=# of apps, J=average # jobs per app):
Previous implementation New implementation
Sorting: A*J*log(A*J) A*J*log(J)
Insertion: log(A*J) log(A*J)+J
Remove(Object): A*J log(A*J)
Iteration: A*J A*J*log(A)
Contains: A*J log(A*J)
Bug: 141645789
Bug: 204924801
Bug: 223437753
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/job
Test: atest frameworks/base/services/tests/mockingservicestests/src/com/android/server/job
Change-Id: Ie077c5ad1cd6c0bd4ff4a9f1e2f000ed99c048b0
Based on initial testing, the limits don't need to be as high as they
were.
Bug: 158300259
Test: N/A
Change-Id: Ic3f29ae1fafd129f5380592498a7a6330129398c
Since 'lastUsedElapsedTime' indicates the timestamp at which
the app was last used by the user and this isn't necessarily
the reason why we create AppUsageHistory objects, we shouldn't
be initializing the 'lastUsedElapsedTime' to the timestamp at
which the object is being created.
Also, update 'lastPredictedTime' to Integer.MIN_VALUE as
getElapsedTime() time doesn't return predictable values for
timestamps in the past and passing getElapsedTime(0) isn't
accurate as it basically indicates the timestamp at boot.
Bug: 206518483
Test: atest tests/tests/app.usage/src/android/app/usage/cts/UsageStatsTest.java
Change-Id: Ib90b435b1efc34144f0461aaaf339fc6037ecdc2
Move handling of the set of JobServiceContexts to the concurrency
manager to make it easier to make the list dynamic and flexible in the
future.
Bug: 141645789
Bug: 223437753
Test: atest CtsJobSchedulerTestCases
Test: atest frameworks/base/services/tests/mockingservicestests/src/com/android/server/job
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/job
Change-Id: I9cf61131700321509800aef0867c911178f80383
