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)
Note: This needs to be exported from the APEX (ag/15937385) when a new
prebuilt is dropped.
The systemserver_fragment is needed for dexpreopting when the media APEX
is built from a prebuilt.
Bug: 194150908
Test: m nothing
Merged-In: I2cca8b206451858e636c6bd04617cf3933f702c6
Change-Id: I2cca8b206451858e636c6bd04617cf3933f702c6
(cherry picked from commit 381fb640c6e25dbd211d12c791a473c4611e70a7)
renamed to avoid conflict with existing copy in the R framework.jar.
The framework.jar copy was removed during S development
Bug: 195608856
Test: build
Test: cts-tradefed run cts -m CtsMediaTranscodingTestCases
Change-Id: I40ab066cd61be8d278f21cc788016f2edd6bb86e
(cherry picked from commit 1168d9d014cfc0e007c311db92ff2d69cc30df18)
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
Merged-In: Id8eed849dfeb26aca1c0743af974c9efadf7fb78
Change-Id: Id9391a524cabe221b054d6d832ca07668d4312e5
Use reflection method to replace the use of public api
getActiveNetworkForUid.
Android 12 version, the public API getActiveNetworkForUid and all
(outside the module) callers of the API have been removed and replaced.
Unfortunately, the related delete/replace code cannot be synced to AOSP
,so in order to keep the public api consistent in Android 12 & AOSP,
The commit uses reflection method to replace the caller of this public
api, Then we can delete this public API in another commit in AOSP.
Bug: 183465229
Test: atest ConnectivityControllerTest
atest CtsJobSchedulerTestCases:ConnectivityConstraintTest
Merged-In: Ie93cd22b11cc28135a385c0cf6ad6b577b61d1b7
Change-Id: Ia636480b12a9b4a9e2c5dd2ec9259af3167df909
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
