This change adds support for static shared libraries that
emulate static linking allowing apps that statically link
against the same library version to share a common
implementation. A library is hosed by a package in a standard
APK.
Static shared libraries have a name and a version declared
by a dedicated manifest tag. A client uses also a new tag
to refer to the static library it uses by specifying the
lib name, version, and the hash of the signing certificate.
This allows two apps to rely on two different library versions
and prevents impersonation of the shared library by a side-loaded
app with the same package name.
Internally apps providing static libs use synthetic package
name generated from the manifest package name and the library
version. This allows having different "versions" of the same
package installed at the same time.
An application cannot be installed if a static shared lib it
depends on is missing. A used shared library cannot be uninstalled.
Shared libraries can rotate certificates like normal apps. The
versions of these libs should be ordered similarly to the version
codes of the hosting package. Such libs cannot use shared user
id, cannot be ephemeral, cannot declare other libraries, cannot
rename their package, cannot declare child-packages. They must
target O SDK. Also they cannot be suspended or hidden or their
uninstall blocked. Generally, speaking policy regarding code in
static shared libs should be applied to the packages using the
library as it could have just statically linked the code.
We now have APIs to query information about the shared libraries
on the device in general. To clients static shared libraries are
presented as multiple versions of the same package which is how
they are declared and published. Therefore, one can have two
versions of the same package which means we need way to query
for and uninstall a specific version of a package. Also static
shared libs can depend on other static shared libs which are
versioned packages. To ease representation we add the concept
of a versioned package which should be used in the case of
static shared libs.
A client can see only the static shared libs it depends on and
more specifically only the versions it depends would be retrieved
by using the standard package manager APIs. There is a new
dedicated API to get info about all shared libraries which
would provide data about all static shared lib versions. Also
these libraries must use v2 signing scheme.
Test: CTS tests pass
bug:30974070
Change-Id: I4f3d537ee7a81f880950377b996e1d9d4813da5c
This was a request from Chrome to be able to specify
one-sided ranges. Rather than add new behavior, I'm just
documenting what seems to me a reasonable convention.
Bug: 30025621
Test: No tests as this just adds comments.
Change-Id: I1467f57729eed08a981c3e6d50951e78c3564a50
When a device gets stuck in a crash loop, it's pretty much unusable
and impossible for users to recover from.
To help rescue devices from this state, this change introduces a new
feature that watches for runtime restart loops and persistent app
crash loops, and escalates through a series of increasingly
aggressive rescue operations. Currently these rescue levels walk
through clearing any experiments in SettingsProvider before finally
rebooting and prompting the user to wipe data.
Crash loops are detected based on a number of events in a specific
window of time. App stats can be stored in memory, but boot stats
need to be stored in system properties to be more robust.
Start up RecoveryService much earlier during the boot so we can
reboot into recovery when needed.
Add properties tha push system_server or SystemUI into a crash loops
for testing purposes.
Test: builds, boots, forced crashing walks through modes
Bug: 24872457, 30951331
Change-Id: I6cdd37682973fe18de0f08521e88f70ee7d7728b
Test: Manually tested onDeviceUnlockLockout being called with an actual
TestAgentService implementation.
Notes:
- Active Trust Agents are no longer killed/unbinded from when a temporary
device lockout occurs. Instead, the onDeviceUnlockLockout callback of
the agent is called.
Change-Id: Ifa0984d1d7e5153568334d736e9ebd5a00ef1297
Bug: 34198873
Unlike the existing addItem(Item), this method updates
the MIME type list in the ClipDescription.
Bug: 28750744
Test: cts-tradefed ... -m CtsContentTestCases
--test android.content.cts.ClipboardManagerTest
Change-Id: Ida0477267d1319a31a738dfd704c0af71928dd2f
- System UIDs must be allowed to launch anything and everywhere.
- Display owner must be allowed to launch activities on it.
- Apps that are already on target display must be allowed to launch
there.
- All other apps mustn't be allowed to launch on private displays.
Bug: 34230873
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testPermissionLaunchFromSystem
Test: #testPermissionLaunchFromAppOnSecondary
Test: #testPermissionLaunchFromOwner
Test: #testPermissionLaunchFromDifferentApp
Change-Id: Ic98005649a6368370c512e822cba4e9decc18ae9
There is a new APP_START_MODE_DELAYED_RIGID which means that
things discovering something is not allowed to start should
report a clear error back to the caller. This is how apps
that opt in to bg check should behave, and will now
be used if the app op mode is set to ERRORED.
This (for now?) removes the code that allows services to
be started if the request is coming from a foreground process.
That behavior isn't in the current bg check spec, and
probably not what we want as the standard platform model (since
it makes knowing when a service can start even harder to
determine). It was originally done for the experimental
bg check work in N to see how much we could avoid
breaking existing apps, so not relevant when apps need to
explicitly opt in.
Also report temporary whitelist changes to activity manager for
it to lift background restrictions temporarily for apps. Being
on the whitelist is now part of UidRecord, preventing a uid from
going idle.
Test: Initial CTS test added.
Change-Id: I36fd906fa69de8b7ff360605ae17c088f182e172
- Adds BluetoothDevice as a parameter where required
- Gets rid of device management APIs that can be done via
BluetoothProfiles instead
Test: Manual sanity tests
Bug: b/33554547
Bug: b/30984220
Change-Id: I3485ac5bfe1fcb29c774ad040fdd608e1cacb8df
By default, we don't restart the activity when MCC/MNC changes
even when they are not set in configChanges. If they want to
restart, set mcc or mnc in the new attribute restartOnConfigChanges.
Bug: 34258948
Test: Test in unit test(testGetActivityConfigChanges() in
PackageParserTest.java) and on real device with
changing the SIM card.
Change-Id: Icd6899597c9b8f2e5706e74373a0280d19150092
Preloading EGL in Zygote was originally a memory footprint
optimization, but it turns out to be an important app startup time
optimization as well. Preloading EGL in Zygote is incompatible with
updatable graphics drivers, but we don't want to do it on-demand as
part of drawing the first frame either, since that increases
first-frame latency unacceptably.
This change removes Zygote preload, and instead loads EGL on a
low-priority background thread immediately after choosing which
graphics driver to use. This means it is usually done well before
drawing the first frame, without significantly disrupting other
activity launch work.
Test: observe systrace of Calculator launch on bullhead
Bug: 34404021
Change-Id: I887aa09bd35b088b16f53a89838a0c7c98f15761
Currently the list is small, only whats required to launch a basic
ephemeral app. It will expand in followup CLs.
Note that the goal of this is not to completely shut down all ways that
an ephemeral app could learn the value (or part of) of a setting not in
the set. The goal is to limit the raw access to settings to a small set that
includes settings that ephemeral apps should have access to directly
System APIs that are exposed to ephemeral apps may allow for
ephemeral apps to learn the value of settings not in the directly
exposed set and that is OK and _not_ a security issue.
This contains a hack to support code in system system server that in
the process of a binder transaction reads a setting using a
ContentReceiver with a system package name. This was previously not an
issue but causes an exception to be thrown from getCallingPackage which
reading a setting now calls.
Bug: 33349998
Test: Boots, functions as normal for regular apps.
Test: cts-tradefed run cts -m CtsProviderTestCases -t
android.provider.cts.SettingsTest
Change-Id: Icc839b0d98c725d23cdd395e8cb76a7b293f8767
