This adds necessary nullness conditions on method arguments, and makes
a Builder class final.
Bug: 126700268
Bug: 126701891
Bug: 126701662
Test: Compiles
Change-Id: I4e825057b413fe22d1c2ebd228a5b76641b04868
The top state will make JIT compilation easier to be triggered.
To reduce the impact of startup time, if there is launching activity,
the top state will be deferred to apply until idle or 1s timeout.
The cold launch time of Contacts, Phone, Calculator are reduced ~15ms.
Test: AppLaunchTest
Bug: 123043091
Change-Id: I8a235e18ea6b508c9aa192445c9ea22d9d12f177
App may access a provider frequently in a short time.
(Without using ContentProviderClient to keep the connection)
Then there will have some overhead for the management of
provider reference. So with a delay to release the provider,
the app can reuse the existing holder within the retain time.
Also change removeContentProvider to a one-way method to reduce
the time spent on app's main thread. This should be safe because
originally the app can acquire provider from any thread.
The cold start time of calendar app can be reduced by ~20ms.
Test: AppLaunchTest
Bug: 123043091
Change-Id: I220cec3deab18b658f4102f7eb9f47599c7c4b7c
This code should be enabled from R, but for some devices it just works
because of target SDK + no /product/lib directory. To avoid confusion
this code should be removed from Q release
Bug: 129011845
Test: m -j
Change-Id: I4d85cbcb5e2cbe694ec065f4e3d060eb74f542ba
This follow-up change performs some cleanup changes without affecting
functionality
Bug: 72950854
Test: Compiles, CTS tests using this pass
Change-Id: Ic7394f24f11d713c9374b438182e29d2a02ea236
Merged-In: Ic7394f24f11d713c9374b438182e29d2a02ea236
(cherry picked from commit 7df36ed96a)
Recreating the entire object drops the mApplication inside,
so multiple Application instances are unexpectedly created.
Instead, call into updateApplicationInfo to replace
the Resources object manually.
Bug: 129890769
Test: device boots, applies overlay paths correctly; was unable
to reproduce a case where the overlays are missing from the
system itself, other Resources/caching changes may have
decreased the occurrence rate
Change-Id: Ib5e7d6ca79ac5b37d5691ce327e3b66cc4672335
Clarify the intended use and properties of the default class loader.
Bug: 128524313
Test: n/a
Merged-In: Iae82554f9294d5248b98f1fa72fc1a47993e86fd
Change-Id: Iae82554f9294d5248b98f1fa72fc1a47993e86fd
(cherry picked from commit 59a97141c8)
Callers are supposed to close the hardware buffer themselves. Creating
a utility method around this
Bug: 123874711
Test: No more leak warning on device
Change-Id: I2cf215f0646222f63e564a58edab1ffffa396ff3
Previously when we capture layers into graphic buffer we always assume SRGB
dataspace, however, if we have an app that is in wide color gamut mode, we want
to show the difference. This patch adds the ability to determine the dataspace
screenshot graphic buffer based on the color mode of the display.
BUG: 116112787
Test: Build, flash and boot. Verify with WCG Photos.
Change-Id: Ie2df32cad056576c256b9299a67855ed73714f50
This change adds a mechanism for restricting permissions (only runtime
for now), so that an app cannot hold the permission if it is not white
listed. The whitelisting can happen at install or at any later point.
There are three whitelists: system: OS managed with default grants
and role holders being on it; upgrade: only OS puts on this list
apps when upgrading from a pre to post restriction permission database
version and OS and installer on record can remove; installer: only
the installer on record can add and remove (and the system of course).
Added a permission policy service that sits on top of permissions
and app ops and is responsible to sync between permissions and app
ops when there is an interdependecy in any direction.
Added versioning to the runtime permissions database to allow operations
that need to be done once on upgrade such as adding all permissions held
by apps pre upgrade to the upgrade whitelist if the new permisison version
inctroduces a new restricted permission. The upgrade logic is in the
permission controller and we will eventually put the default grants there.
NOTE: This change is reacting to a VP feedback for how we would handle
SMS/CallLog restriction as we pivoted from role based approach to roles
for things the user would understand plus whitelist for everything else.
This would also help us roll out softly the storage permisison as there
is too much churm coming from developer feedback.
Exempt-From-Owner-Approval: trivial change due to APi adjustment
Test: atest CtsAppSecurityHostTestCases:android.appsecurity.cts.PermissionsHostTest
Test: atest CtsPermissionTestCases
Test: atest CtsPermission2TestCases
Test: atest RoleManagerTestCases
bug:124769181
Change-Id: Ic48e3c728387ecf02f89d517ba1fe785ab9c75fd
Rebased from ag/3785659. This CL switches to using post-execution
state resolution for new intent delivery. Also removes some
unnecessary code needed for old logic.
Bug: 65236456
Bug: 77974794
Test: atest ActivityLifecycleTests
Change-Id: I734ad50de498cd2a6b9514c8ef6cb1eeb08e4ec5
We were persisting jobs' battery-not-low constraints but were not
properly restoring that constraint when the job was inflated at boot.
This could result in a runtime bootloop (!) if the job had no other
constraints, requiring a factory reset to restore the device to
usability.
We now:
* properly inflate the battery-not-low constraint;
* persist & inflate the storage-not-low constraint, which previously was
being stripped entirely and could result in a similar crash-at-boot;
* ignore the job rather than crash the system if one is inflated into
a non-viable state; and
* formally test previously-untested constraint persistence
Bug: 130012063
Test: atest $ANDROID_BUILD_TOP/frameworks/base/services/tests/servicestests/src/com/android/server/job/JobStoreTest.java
Test: atest CtsJobSchedulerTestCases
Test: JobStoreTest with forced throw in JobInfo.Builder#build()
Change-Id: Ia3ab1eb16aeaa85336409368b4340622cec19f4c
