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
This prevents any cross-user requests. Cross-user requests are already
not allowed, but due to a bug elsewhere in the code. This intentionally
handles the case and also throws a SecurityException.
Bug: 193903221
Test: presubmit
Test: manually checked cross-user requests get an exception.
Change-Id: I5bd867b86b972452daa2d8253f3c19f059a8a4b3
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
Optimize is an important job for AppSearch to work properly.
It could collect garbage and release resources. Without it, the garbage
resource will last forever and the device's space will be fulled up by
zombie documents.
The algorithm to trigger optimize is:
1: Query garbage resource info after a batch of mutation operations.
2: Only trigger optimize if there are enough resource could be released.
The behavior exists in AppSearch Jetpack for a while and working properly
for our Jetpack dogfooders.
Bug: 175255572
Test: FrameworkOptimizeStrategyTest
Test: AppSearchConfigTest
Test: AppSearchImplTest
Change-Id: Ib7ae475cc035d1b69969df1e22ac409895e0e3fa
A user-package can only manipulate their own nextPageTokens (i.e.
advance or invalidate it) otherwise some other package could affect the
search results of a package. Because we check at the user-package level,
this still allows a package to manipulate nextPageTokens that were
returned for different databases. This isn't recommended, but not a
security risk since it's the package's own data.
Note that manipulating nextPageTokens isn't available through
AppSearch's public API. This would be if someone were circumventing the
normal AppSearchSession.
Bug: 187972715
Test: AppSearchImplTest
Change-Id: I67a22f3ae171ea2886eb89dcf493286a8421408d
This is needed to prevent abuse of our service and to share icing
docids in framework, which are the resource we are most likely to
run out of.
Without this change, an app could use the platform backend to index
a very high number of documents and exhaust the docid limit, thereby
preventing any other app from using AppSearch.
Bug: 170371356
Test: New testcases added to AppSearchImplTest
Change-Id: I03ade35072bc69b84f8fcefed72b3c3bc2b8ee68
- 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
Previously, the hidden API encoding of the appsearch boot dex jars,
i.e. those dex jars that appsearch contributes to the bootclasspath
were done as part of the monolithic hidden API processing. This change
causes the encoding to be done by the appsearch's
bootclasspath_fragment.
This change involves the following:
* Addition of the fragments property to the appsearch's
bootclasspath_fragment module to list all the other
bootclasspath_fragment modules on which this depends.
* Addition of the additional_stubs property to add stubs for APIs that
are not provided by another bootclasspath_fragment.
The build automatically checks that the hidden API flags which are
computed by appsearch and encoded into its boot dex jars match those
that are generated by the monolithic processing so this is guaranteed
to be safe.
Bug: 179354495
Test: m com.android.appsearch
- ensure that the generated APEX is byte-for-byte identical
before and after these changes.
m out/soong/hiddenapi/hiddenapi-flags.csv
- make sure that they are not changed by this.
Change-Id: I8e5a60d64d3e147535e11a4ad30404f9888f53d2
This reverts commit 6cf25139a0.
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
The hidden APIs have already been fixed, so this CL mostly changes
build rules.
Bug: 181787682
Bug: 146218515
Test: Presubmit
Change-Id: I5d68d68ce8f39753f62c5e3680216877b7d7f819
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
Changes included:
* 79f2ffe: Fixes required for export.
* e1ca63a: Implement empty schema shouldn't have a version number.
* 8b76be4: Refactor VisibilityStore from a no-op implementation into an interface.
* 47ba533: Remove the max repeatable length limit for GenericDocument
* 52ca287: Add GetSchemaResponse cts test.
* 56585f5: Change PutDocumentsRequestTest to be a cts test.
Bug: 183050495
Bug: 180058203
Bug: 191592792
Bug: 189161227
Bug: 183239766
Test: Presubmit
Change-Id: I30f51a18d697d3a5e43d2c63549ab19a36bbe99e
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
Included changes:
* a8c984: Add more tests for logging
* 501a51: Remove some deprecated TODOs.
* 639f25: Add SchemaMigrationStats.
* 0b8885: Use consistent terminology for 3p and system access.
* 064c36: Add a CTS test for snippeting window sizes and max match counts.
Bug: 173532925
Bug: 187879464
Bug: 180058203
Test: Presubmit
Change-Id: I878fd6c7a42cccb237898392aac8c615830eb564
