* 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
* 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
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
If a job is started while an app is in the TOP state, then it shouldn't
consume any of the app's credits, even if the app leaves the TOP state.
Bug: 158300259
Test: Android builds
Change-Id: Ie66a70a5a9342fb7e25129f7701ee72697e9a87b
Make it clear when JobScheduler.schedule() should be called by an app
that wants a content URI to be continuously monitored.
Bug: 19536175
Bug: 209981186
Test: `m offline-sdk-docs` and check output
Change-Id: I0ebaaf91339d300671412b5d63ae00ad386753ca
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
Test: TH passes
Change-Id: I11a27b9bdab7959ee86e90aa1e1cbebd7aaf883c
Create explicit start and running bills for each priority so we can
better determine when a job is allowed to run based on TARE policies.
Also defer min and low priority jobs more by ensuring an app can pay for
higher priority jobs before we run the lower priority jobs.
Bug: 158300259
Bug: 205714315
Test: See additional bills registered in dumpsys
Change-Id: I901d4d7cc6d02fc0b2084d90d7fe7a199148cb3b
Make sure to track Activity instance ID in UsageStats.Event so RESUMED
and PAUSED/STOPPED events are correctly aligned.
Also improve dumpsys of ongoing events.
Bug: 158300259
Test: Check dumpsys and logcat
Change-Id: If3a338f09a78c9089a827083609bfd80c83788aa
The wakeup alarms for doze-light-maintenance steps are causing battery drain in idle state. In terms of idle state battery optimization, Doze light maintenance step alarms can be changed to non-wakeup alarms as verified it is not critical as well as there is no user impact during our tests over a 50 days of Samsung's internal testing including User Trial.
Once it's changed to a non-wakeup alarm, the time gap between maintenance can be increased. But from our real test data, the gap has not increased as much as we worried, so doze-maintenance is working well.
Merged-In: Ib9bf9e120c806e61eced99fbfb84cdb19d844e69
Bug: b/197216833, b/185466339
Change-Id: Ida62842bdf8019563466fbf79326bc4d52ff3a99
Test: run `atest FrameworksMockingServicesTests:DeviceIdleControllerTest`
Changing some light idle alarms to non-wakeup to reduce the number of
alarms that could potentially wake up the device. If the CPU is already
in suspend, we don't need to wake it up just to officially enter doze
light. We can just wait until the CPU wakes up to do the transition. On
a particularly active device, this won't change the time we enter Doze
light much, but on a quiet device, the Doze light and maintenance
windows may be shifted significantly.
Bug: 185466339
Bug: 197216833
Test: atest DeviceIdleTest
Test: atest FrameworksMockingServicesTests:DeviceIdleControllerTest
Change-Id: Ib9bf9e120c806e61eced99fbfb84cdb19d844e69
The individual EconomicPolicies were correctly reading the Settings
constants for the max circulation in setup(), but
CompleteEconomicPolicy treated those values as final upon
initialization, so it wasn't updating the max circulation.
Bug: 158300259
Test: set value via adb and confirm limit increased in dumpsys
Change-Id: Ic9769a4173d652d8dc2ca43677e4618c57869613
Dump all transactions when we're not dumping for a bug report.
Bug: 158300259
Test: adb shell dumpsys tare
Change-Id: Idb7045dcacaa228947ad80d7b5651eb75407b9bd
Autoboxing considered harmful: attempting to obtain a Message with a
particular int value for arg1 was instead matching the supplied-Object
obtainer because of it.
Bug: 207352051
Test: atest FrameworksMockingServicesTests:com.android.server.alarm
Test: atest com.android.server.DeviceIdleControllerTest
Change-Id: I759ef29342cc64fa72f941f6f21f0909bbd2fe4b
Add priority, prefetch, and num failure fields in order to track
the effectiveness of the feature and policy changes.
Bug: 138239687
Bug: 142272435
Bug: 194532703
Test: atest CtsStatsdAtomHostTestCases:JobSchedulerStatsTests
Change-Id: Id76e9eb872b92ee64baab1898d9acdc08e386f74
Avoid incrementing the bg job count and other timer tracking
adjustments if the job is already being tracked.
Bug: 205295122
Test: atest --rerun-until-failure 25 FrameworksMockingServicesTests:QuotaControllerTest
Change-Id: I2b9690c95d3ea31ef37a5631fa8322e925da511c
We currently can't tell if a widget is displaying data that is
updated periodically. If a prefetch job is scheduled for such a widget,
it should get to run since it'll be helpful for the user. Given what we
know right now, we will mark the prefetch bit as satisfied for apps with
active widgets. We won't relax the force-batching requirement unless we
also determine that the app will be launched soon.
Bug: 194532703
Test: atest FrameworksMockingServicesTests:PrefetchControllerTest
Change-Id: I6d1c17c386a27e70525f72824710739b78e9ad5e
Bug: 158300259
Bug: 205624100
Test: Run adb commands and verify TARE is toggled when user hasn't set a value
Change-Id: I931c354cc2c972be566ac798853f57335d3b50aa
If a prefetch job hasn't started by the time an app is opened, then we
decide not to run it until the app is closed again. The rationale being
that "prefetch" is to do something before the app launch and it wouldn't
be useful while the app is on TOP. Any prefetch job that is already
running when the app is launched will be allowed to finish.
Bug: 194532703
Test: atest FrameworksMockingServicesTests:PrefetchControllerTest
Change-Id: I485cd0170a0066a82ab66bf92e36206a9a78bd78
Give apps on the power allowlist a higher minimum balance so they're
able to do more work. When a user removes an app from the list, we
reclaim some of the credits (with the amount reclaimed depending on the
time since the app was used).
Bug: 158300259
Bug: 202954395
Test: Charge device from 1% and see exempted apps get more credits.
Exempted apps approach minimum balance as device nears 100%.
Change-Id: Id19c43d31477daa90173bda5294479487b025ea2
