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
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`
This reverts commit e61cf5125e83b119701228e742f7b2cb3a433cb6
but changes onUserUnlocking to onUserUnlocked.
Reason for revert: Direct-boot-aware jobs should be allowed to run when the user is locked
Bug: 200174299
Bug: 201307089
Test: N/A
Change-Id: Ic5a67a42590e171f0bfed8da0c138096031469d5
(cherry picked from commit 171bf04113154a7e3668e07677701869dfae9eda)
This reverts commit e61cf5125e83b119701228e742f7b2cb3a433cb6
but changes onUserUnlocking to onUserUnlocked.
Reason for revert: Direct-boot-aware jobs should be allowed to run when the user is locked
Bug: 201307089
Change-Id: Ic5a67a42590e171f0bfed8da0c138096031469d5
(cherry picked from commit 171bf04113154a7e3668e07677701869dfae9eda)
allowlisted.
Previously when PowerExemptionManager.addToTemporaryAllowList() is
called for a second time before the first time call's duration expires, the
second call does not update ActivityManagerService's
FgsTempAllowList for the new duration. This CL fixes this problem.
Bug: 199801023
Test: atest cts/tests/app/src/android/app/cts/ActivityManagerFgsBgStartTest.java
Change-Id: Ibb8c6f41740a9b7468b50a4cdabe526ae58550ec
Use an exact alarm for the location timeout to avoid keeping the GPS
active for too long.
Bug: 194385761
Test: atest DeviceIdleTest
Test: atest FrameworksMockingServicesTests:DeviceIdleControllerTest
Change-Id: I52b7ec6d993705ee605e3780a29a484c0d48e633
There are times when the enqueue time of two different jobs are exactly
the same. In those cases, if an EJ skipped over one regular job with an
enqueue time X, then it should skip all other regular jobs with enqueue
time X.
Bug: 194324016
Test: atest FrameworksMockingServicesTests:JobSchedulerServiceTest
Test: atest CtsJobSchedulerTestCases
Change-Id: I77e106676238dd3ae198fab619af430e48d433a2
When apps are stopped unnaturally (ie. because something stopped the job
and the job itself didn't call jobFinished or dequeueWork with no
remaining work) then we have the chance of small race conditions where
the job may try to complete its work. Since the race condition isn't
really the app's fault, we shouldn't punish the app for it.
Bug: 194358301
Test: atest frameworks/base/services/tests/mockingservicestests/src/com/android/server/job
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/job
Test: atest CtsJobSchedulerTestCases
Change-Id: I3b0edd4f2241172fe97875eb8070cb5188027afb
APP_STANDBY_BUCKET_CHANGED messages are for single apps, so it doesn't
make sense to remove all messages whenever any app's standby bucket
changes.
Bug: 193918191
Test: N/A
Change-Id: I981cd3be3cd381c6d00f06e3da9f8e67f157a26b
Merged-In: I981cd3be3cd381c6d00f06e3da9f8e67f157a26b
AlarmManager.setWindow's parameter order is type -> window start ->
window length. Actually put the values in the correct order.
Bug: 193866265
Test: atest DeviceIdleTest
Test: atest FrameworksMockingServicesTests:DeviceIdleControllerTest
Change-Id: I5c87dad3015859d68aacb6781166432b615327b9
Restrict all jobs (and not just connectivity jobs) when the thermal
status is SEVERE+.
Bug: 193269111
Test: atest frameworks/base/services/tests/mockingservicestests/src/com/android/server/job
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/job
Test: atest CtsJobSchedulerTestCases
Change-Id: Id8eed849dfeb26aca1c0743af974c9efadf7fb78
Using a separate container for lower allow-while-idle quota to avoid out
of quota issues. Using the same container means that the lower quota is
out whenever higher quota is used for alarms from the same app.
Lower quota - currently once per 9 minutes - is used in the
following cases:
- Inexact allow-while-idle alarms. This means the same app can use
alarms using high quota and low quota simultaneously.
- When the caller is targeting < S.
- When the caller is in the power save allowlist, but does not have the
permission - for exact alarms.
Test: atest CtsAlarmManagerTestCases
Test: atest FrameworkMockingServicesTests:com.android.server.alarm
Bug: 190788800
Change-Id: Iba46fdd36dc04843e9256827b0754d21cfff89c9
Querying for the state of the exact-alarm permission produced
inconsistent results depending on circumstances. This is now fixed so
the failure reporting is invariant.
Bug: 193032972
Test: manual
Test: atest CtsAlarmManagerTestCases
Change-Id: Ie1cc126cec568b6f53ebe6049e57ed13abdfd5bb
- Following the change of device idleness checking, car idleness
tracker considers screen on to determine idleness.
- The condition to get idle in automotive is 1) garage mode is started,
or 2) screen is off and idle is triggered.
- If idleness is forced or garage mode is running, it is considered idle
by car idleness tracker, regardless of screen on/off.
Bug: 182492612
Test: atest android.jobscheduler.cts.IdleConstraintTest
Change-Id: I15e78157c6b1539086e9b39354e5da51186c6535
Specifically, mentioning that the alarm count can only be included with
the alarm if the supplied pending intent is mutable.
Test: make offline-sdk-docs
Fixes: 178413211
Change-Id: I2914bceebeed8b52b0de11d70960aa33e6837b13
They can already use a lot of APIs to perform work in the background
and it simplifies the logic handling permission state changes and the
return value of canScheduleExactAlarms.
The major changes in behavior are:
1. Allowlisted apps can schedule unlimited alarm-clock alarms. This
should be the same as pre-S behavior.
2. If they happen to get the permission revoked, due to whatever reason:
user revocation, deny list, or app update, their alarm-clock alarms will
stay safe like their other exact alarms.
3. The API canScheduleExactAlarms is now true to its name: It returns
true even if the app is allowlisted.
Test: atest CtsAlarmManagerTestCases:ExactAlarmsTest
atest FrameworksMockingServicesTests:AlarmManagerServiceTest
BYPASS_INCLUSIVE_LANGUAGE_REASON=Existing APIs
Bug: 191716678
Bug: 190625528
Change-Id: I420694455f50aac10cf49cd43ff3b98575d86e9f
This reverts commit 6cf25139a0c4625a753f84183c641e83e89ec8fb.
Reason for revert: It results in thrashing the system in some cases
Bug: 192082833
Bug: 152573287
Test: atest FrameworksMockingServicesTests
Test: atest FrameworksServicesTests
Change-Id: I0ca09655b7911857cded5da74169b0c3bd332bda
Only requested-expedited-jobs could have their run-in-bg constraint
change (because of EJ quota) without a corresponding call coming through
the ForceAppStandbyListener. Restrict job evaluation to requested-EJ
jobs to avoid making unnecessary/redundant calls for regular jobs.
Bug: 192105110
Test: atest frameworks/base/services/tests/mockingservicestests/src/com/android/server/job
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/job
Test: atest CtsJobSchedulerTestCases
Change-Id: I9acc45e109c32fb77c79df4fe126a9b1845163ff
We want to always run an app's expedited jobs before its own regular
jobs. This means that we order an app's EJs before its regular jobs. In
order to satisfy the transitivity constraint, we must also order one
app's EJs ahead of a differing app's jobs iff we had to order the first
app's EJ ahead of a job that was earlier than the second app's jobs.
The current sorting system fails the transitivity requirement.
Test case: regJob1 enqueued at t1 for UID A, regJob2 enqueued at t2 for
UID B, EJ3 enqueued at t3 for UID A. Because we expedite EJs, EJ3 is
ordered before regJob1. Because we sort jobs of differing apps by enqueue
time, regJob1 comes before regJob2 and regJob2 comes before EJ3. This
violates transitivity.
The new sorting system will order a later EJ ahead of a differing app's
jobs iff the first app has a regular job that is earlier than the
differing app's first regular job.
Bug: 191592712
Test: atest FrameworksMockingServicesTests:JobSchedulerServiceTest
Test: atest CtsJobSchedulerTestCases
Change-Id: I5391a4f35269d7d43eefc1954788f9df160b1d22
Callers that don't target S can schedule exact alarms so should get a
return value of true when they call canScheduleExactAlarm.
Test: atest FrameworksMockingServicesTests:AlarmManagerServiceTest
Bug: 191328951
Change-Id: I1cd1d0fb3d3d922360494552e653ed540bfe5227
- Create a new XML tag for the new format. The new format should
persist the arrays of values without assuming they necessarily
have different bits.
- Upon reading, if the new tag is present, use that. If the new
tag is not present but the old tag is present, then limit the
contents to the capabilities/transports that existed in R.
- Catch all exceptions and ignore the requests if they can't be
re-read from disk. This is a measure to avoid any mistake where
the device couldn't boot when JS tries to restore state.
Bug: 183071974
Test: atest JobStoreTest
Original-Change: https://android-review.googlesource.com/1679762
Merged-In: I56cde50d2adab81134c8be4f6996d68018f4212a
Change-Id: I56cde50d2adab81134c8be4f6996d68018f4212a
Set explicit alarm window sizes so we can control the maximum alarm
delay for Doze alarms.
Bug: 187947479
Bug: 188468510
Test: atest DeviceIdleTest
Test: atest FrameworksMockingServicesTests:DeviceIdleControllerTest
Change-Id: I40c0e1a0fce18886ea817245d9a064a509eb6e08
Ensure SYSTEM_INTERACTION can bring an app out of the RESTRICTED bucket
(temporarily) if the app is only in the bucket due to timeout.
Bug: 191297958
Test: atest AppStandbyControllerTests
Change-Id: Ie76d224710228a8654d4d57ee0c73bb9441ef28f
Callers that have power exemption should be allowed to set smaller
windows for their alarms.
Test: atest FrameworksMockingServicesTests:AlarmManagerServiceTest
Bug: 185199076
Change-Id: I5f6515a917da7f87891f79fb637d48a3d7862a1b
The permission SCHEDULE_EXACT_ALARM state changes at the following
boundaries:
1. App-op: This gets toggled by the user via Settings.
2. Deny-list: Packages can be added to the deny list via DeviceConfig
APIs.
3. Package changes: A package's manifest may changes when it gets
updated.
In both cases 1 and 2, if alarm manager detects a permission change
from revoked to granted, it sends the
ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED broadcast to the
app.
If it detects a permission change from granted to revoked, it kills
all the processes within the hosting uid.
In all three cases, when the permssion changes from granted to revoked,
all the exact alarms scheduled by the relevant package are removed.
Package updates are treated differently as they require processes to
restart anyway. The broadcast is not needed in this case as there
are no alarms expected to have been lost by a previous revocation, and
apps can always use ACTION_MY_PACKAGE_REPLACED for post-update setup as
usual.
All this only applies to packages that have the change
REQUIRE_EXACT_ALARM_PERMISSION enabled.
Also changed canScheduleExactAlarms to return false if the change is not
enabled for the calling package.
Test: atest FrameworksMockingServicesTests:AlarmManagerServiceTest
atest CtsAlarmManagerTestCases
Bug: 179541791
Bug: 187206399
Change-Id: Icd68275701f2804be65b3a10a7dd81bbf6e2a0bb
Bug: 189291729
Test: atest ./tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
BYPASS_INCLUSIVE_LANGUAGE_REASON=Existing public API
Change-Id: I7e26eaef4fe9d7d7b4b3a1740608e0fe821537d2
