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
We are caching nextPageToken in query(), and validate it in
getNextPage(). But when it reach to the end, the token will be changed
to 0. And it will crash if user is trying to fetch next page since 0
is not cached and won't passed the validation.
This change fix the issue. Without it, users maybe crashed if they
are trying to retrieve all documents in all result pages.
Bug: 187972715
Test: AppSearchSessionUnitTest
Change-Id: Ia95feb52f2a37348e11afdf0b320c61bfce22d40
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
This limit was removed from the AppSearch Jetpack API meaning that
a client could construct a GenericDocument successfully, but then
have a PutDocuments call fail when converting from
androidx.appsearch.GenericDocument
to android.appsearch.GenericDocument.
Icing still has a total document size limit which is 16 MiB.
The put call will fail if it trying to write such document.
Bug: 192909904
Test: GenericDocumentTest
Change-Id: I86f97acc3a8e0f1c25fadf597aed9f42a2c493eb
OptimizeStats is crucial for us to tune our configuration for
optimization, which might affect the health of AppSearch and system
overall. Details can be found in Ib7ae475cc035d1b69969df1e22ac409895e0e3fa.
Also add sampling parameters in AppSearchConfig for:
1) initializeStats
2) searchStats
3) globalSearchStats
4) optimizeStats
Bug: 173532925
Bug: 175255572
Test: AppSearchStatsTest, FrameworksMockingServicesTests:AppSearchConfigTest, CtsAppSearchTestCases
Ignore-AOSP-First: AppSearch is not available on AOSP yet
Change-Id: Id61704407bdb40707cb8fa46b556024aea9f9083
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
These versions were kept around to facilitate dogfooder transition
during the API council review process. Our dogfooders' apps have updated
to versions that use the finalized sdk, so these are no longer required.
Bug: 181887768
Test: Presubmit
Test: Flash device, run jetpack platform backend tests
Change-Id: I4852b1ecc25254ffb781926ca799d0c8128339ab
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
