All jobs with HIGH or MAX priority should have reduced execution
timeouts, including downgraded expedited jobs.
Bug: 142272435
Test: atest FrameworksMockingServicesTests:JobSchedulerServiceTest
Change-Id: I131206fbfa0b58bedbe912b02e44a90ef1e49596
Make it so that each standby bucket can have a different "allowed time"
per its window size. That way, we can say apps in bucket X can run for Y
minutes total in a Z time period.
Also separating EXEMPTED from ACTIVE so that any changes to ACTIVE quota
don't affect EXEMPTED apps when we don't want it to.
Bug: 143495340
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: I2a3f6da75a328505e4091a314a73c0f9d8bbb050
add extra annotations, reset lint-baseline.xml files.
The lint-baseline.xml includes code fixes from 2021/11 that had no xml
regeneration. XML files updated with output from the test make commands.
Bug: 188851874
Test: build
Test: m out/soong/.intermediates/frameworks/base/apex/media/framework/updatable-media/android_common_apex29/lint/lint-baseline.xml
Test: m out/soong/.intermediates/frameworks/base/apex/media/service/service-media-s/android_common_apex29/lint/lint-baseline.xml
Change-Id: Iad4d811d4d04dd9901d7290d1342e3aae2c22499
* changes:
Expose the bg restriction exemption list as an internal API.
Add an action button to the notification for bg battery abusive apps
Exempt certain app behaviors for their background battery usage
Add tracking on abusive broadcast and service binding requests
Add exemption cases for app background restrictions
Monitor long-running foreground services
Post notification on abusive background current drain
Allow limited alarms/jobs when background restricted
Cap the LRU position of broadcast receivers in bg restricted apps
Add a tracker on background current drains for each uid
Add background restriction levels definition and its controller
Use the new onUser completed event for JobSchedulerService.
This delays handling aspects of the user starting/unlock events
(which are important, but not urgent) until a little later.
In particular, it delays the intial job scheduling until a little after
the user has started, instead of immediately.
Test: manual
Bug: 197344658
Change-Id: I78ea7f7822ee466ce34dfc0b9f602fa1a4ceb7c3
To share the same exemption policy with task manager.
Bug: 200326767
Bug: 203105544
Test: atest FrameworksMockingServicesTests:BackgroundRestrictionTest
Change-Id: I01c70b501e37f13c516d439533e95061ed4a9ebe
This change annotates dump/debug methods in services.odex that are
larger than 10000 bytes with NeverCompile so that they will not be
compiled. This results in an overall ~1% decrease in the size of
services.odex.
Bug: 215417388
Test: Build and check that these methods are not called during boot or
app startup.
Change-Id: I0b8d62c68a6a79c07f2a8a533bf69aee100f0877
When app is background restricted, allow alarms/jobs but they'll be
under the quota control of restricted standby bucket.
This behavior is gated by a feature flag now.
Bug: 200326767
Test: atest CtsJobSchedulerTestCases
Test: atest CtsAlarmManagerTestCases
Test: atest FrameworksMockingServicesTests
Change-Id: I154656c19954a306e8ae05dc50ea708c4de2a739
This CL adds the definition of background app restriction levels.
The existing various system background app restriction features will
be mapped into the levels here, including app standby buckets,
background restrictions (forced-app-standby) etc. Future CLs may
apply restrictions to background apps accordingly.
BYPASS_INCLUSIVE_LANGUAGE_REASON=Legacy API name
Bug: 200326767
Test: atest FrameworksMockingServicesTests:BackgroundRestrictionTest
Change-Id: Icf82031c572e7b8e82e6528402e9df4de5b7a675
While in Doze, jobs of apps the Foreground Service proc state or higher
are only exempted if they're expedited or have the
important-while-foreground bit set. We were accidentally considering all
uidActive jobs as exempt, letting the device exit the Doze maintenance
window early, and then stopping the uidActive app's jobs if they weren't
exempted or had the important-while-foreground bit set. This meant that
if only the app running a foreground service had jobs to run and the app
didn't ask for the jobs to be exempted from Doze, the maintenance window
would last for 30 seconds and the jobs would be stopped, but if there
were other background jobs to be run, the maintenance window could last
for the full time (10 minutes or whatever it would be). Fixing the
inconsistency so that we don't exit a maintenance window early when
there are non-exempt jobs running.
Bug: 216150579
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: I07de57b364c9fee995eca020153622ba85d17c96
* Suggested by API council to move them to
`android.safetycenter.SafetyCenterManager`
Test: Will be tested in use in SafetyCenterManager refresh API
Bug: 215555855
Change-Id: I4f84ae5a9037b4938f0ba7feb151c50149362fdd
Shorten the timeout to the restricted standby bucket, and extend
the minimum required time to the restricted standby bucket.
Bug: 200326767
Test: atest AppStandbyControllerTests
Test: atest CtsJobSchedulerTestCases
Change-Id: I03f16d407942bdab4602361ecac430be9d5d9dcf
Make sure there is some minimum amount of quota available for higher
priority jobs before we start running lower priority jobs.
Bug: 205714315
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: I87919e08684fe1012bfc66d7fae928d04f575637
This reverts commit 331be9a6431d6489f8d1e1b80cb510d0ee073c50.
Reintroducing ag/16366278 since it seems unrelated to b/214053959 (more details on b/214053959#comment55).
Original commit message:
Migrate unsafe parcel APIs in framework-minus-apex
Migrate the following unsafe parcel APIs in framework-minus-apex:
* Parcel.readSerializable()
* Parcel.readArrayList()
* Parcel.readList()
* Parcel.readParcelable()
* Parcel.readParcelableList()
* Parcel.readSparseArray()
This CL was generated by applying lint fixes that infer the expected
type from the caller code and provide that as the type parameter
(ag/16365240).
A few observations:
* In some classes we couldn't migrate because the class also belonged to
another build module whose min SDK wasn't current (as is the case for
framework-minus-apex), hence I suppressed the lint check
(since I'll eventually submit the lint check to the tree).
* In some cases, I needed to do the cast in
https://stackoverflow.com/a/1080525/5765705 to make the compiler happy
since there isn't another way of providing a class of type
Class<MyClassWithGenerics<T>>.
* In the readSerializable() case, the new API also requires the class
loader, that was inferred to by InferredClass.class.getClassLoader().
* Note that automatic formatting and import rely on running hooked up
to the IDE, which wasn't the case here.
Bug: 195622897
Change-Id: I272432e6e082a973f7a50492ec35d79c2b577c93
Test: TH passes
* See BroadcastOptions#setTemporaryAppAllowlist(long duration, @TempAllowListType int type, @ReasonCode int reasonCode, @Nullable String reason)
Test: Will be added once the constant is used in SafetyCenterService
Bug: 210431135
Change-Id: I466d4e9cfa722b04343121f09e0cb52f99580581
Several releases ago, we delayed the CHARGING broadcast to ~15 minutes
after the device was plugged in. This means that any job that specifies
a charging constraint won't have the constraint satisfied until 15 minutes
after the device is plugged in. If such a job's setting is explicitly set
by the user and the user plugs in their device while the app is on top,
they will see that the work doesn't start immediately. This would be
confusing for the user. We now the top app's charging constraint jobs
as satisfied when the device is plugged in to avoid this confusion. If
any TOP app's charging constraint jobs start while the app is on top,
the job will be allowed to continue running after the user leaves the
app as long as the device is plugged in. Any jobs that didn't start will
be treated regularly and will have to wait for the CHARGING broadcast.
Bug: 198624541
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: I914176d7bf9fd4a8998c05d411483bd4607589f2
Currently, notification-seen event will promote an app to
Working set bucket. This change adds a knob to allow changing
the bucket that the app gets promoted to on a notification-seen
event.
This change also updates AppStandbyController logic to allow
setting timeouts for buckets other than Active and Working set.
Bug: 206518483
Test: atest --test-mapping apex/jobscheduler/service/java/com/android/server/usage/TEST_MAPPING
Change-Id: Ic818c3871a34107b86b97c983285214beea220a5
As Android Bluetooth becomes a mainline module, we need to
remove all hidden API usages. BluetoothManagerService is
using REASON_BLUETOOTH_BROADCAST so we have to make it
accessible to the Bluetooth module.
Tag: #feature
Bug: 211851706
Test: make
Change-Id: I99ade4673836c068b2e643ce5e56d9ad0454233f
Combine the separate Controller battery/charging trackers into one so
that JobScheduler only has to receive the battery change broadcasts once
to update all of the state. This also makes testing easier since the
test can be sure that once the battery sequence is updated, all of JS
has processed the battery state change.
Bug: 141645789
Bug: 213277873
Test: atest --rerun-until-failure 25 CtsJobSchedulerTestCases:android.jobscheduler.cts.JobThrottlingTest#testRestrictingStopReason_Quota
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: I7151798f17c177eb5e86a6ec51c2d545768a4fcd
Revert "Update cts to depend on new ExoPlayer version"
Revert submission 16527581-update_exoplayer_version
Reason for revert: b/213856810
Reverted Changes:
I231cf3512:Update cts to depend on new ExoPlayer version
I26f7159a7:Make MediaParser depend on the latest Exo version
Id69a309ce:Update MediaParser's ExoPlayer version
Change-Id: I84fbc379ec4868d1a81a3abcabb61ccaa919972c
