Some apps may want to check whether they are trusted to install apps on
the device, so they can prompt the user to go to settings and mark them
as trusted before they do an intensive operation like downloading an
apk.
Test: cts-tradefed run cts -m CtsExternalSourcesTestCases
Bug: 31002700
Change-Id: Icd9d04daa157e6733decba245ec251ce4acd4122
Apps can now declare in their base APK AndroidManifest.xml
that they want to have their split APKs loaded in isolated
Contexts. This means code and resources from the split
get loaded into their own ClassLoader and AssetManager.
<manifest xmlns:android="..."
...
android:isolatedSplits="true"
...
In order to make this more useful, splits can declare dependencies
on other splits, which will all get pulled in to the Context
and run as expected at runtime.
A split declares its dependency on another split by using the
tag <uses-split> in its AndroidManifest.xml:
<manifest xmlns:android="...">
...
<uses-split android:name="feature_split_1" />
...
A split can have a single parent on which it depends on. This is
due to the limitation of having a single ClassLoader parent.
All splits depend on the base APK implicitly.
PackageManager verifies that no cycles exist and that each dependency
is present before allowing an installation to succeed.
The runtime will then load splits based on the dependencies.
Given the following APKs:
base <-- split A <-- split C
^----- split B
If an Activity defined in split C is launched, then the base,
split A, and split C will be loaded into the ClassLoader defined
for the Activity's Context. The AssetManager will similarly be loaded
with the resources of the splits.
A split can be manually loaded by creating a Context for that split, defined
by its name:
Context.createContextForSplit("my_feature_split_1");
All installed Activities, Services, Receivers, and Providers are accessible
to other apps via Intent resolution. When they are instantiated, they are
given the appropriate Context that satisfies any dependencies the split they
were defined in stipulated.
Test: WIP (CTS tests to come)
Change-Id: I8989712b241b7bc84381f2919d88455fcad62161
The color mode lets an application request a wide color gamut for
a specific window. This will also be used in the future to request
HDR. The color mode is currently either default (sRGB) or an undefined
wide gamut color space chosen by the platform. These attributes could
later be used to choose a specific color space if we deem this important
or useful.
This change also renames the various "colorimetry" attributes and
constants to "color mode" for consistency. These symbols were
added in O and can be safely renamed.
Test: CtsColorModeTestCases
Bug: 32984164
Change-Id: I4d4691dd12dbe3f3aa6a5cf893cff39aa16c739e
This CL adds FEATURE_EMBEDDED to PackageManager to identify Android
Things devices.
BUG: 34644059
Test: built using make update-api
Change-Id: Ife4430e4a445f6afdd969e94db5fe5c9098ee145
Clear data Intent can be called from any application and
executes in the PackageInstaller. The user will be asked
to verify that they truly want to clear package data via
an AlertDialog.
This was initially intended to be @SystemApi, but
conversations with API-Review led to it be public.
Test: Covered by a gts-test ag/1806256 and manually tested
by calling from com.android.vending (Play Store).
bug: 33017941
bug: 31008483
Change-Id: Ibeae6620303ba52cc2ebf0383756c9380d3fa013
We need to specify the version code to use when installing
splits since the version on the device might be different
from the latest on the server.
Bug: 25119046
Test: manual
Change-Id: I4ad21f9e5924fcf76a39780e6d98e8d7a1fef5d4
- Removing the requirement for activities to have both the
resizeableActivity and supportsPictureInPicture attribute
to enter PiP. The activity may still be resized when
entering picture-in-picture.
Bug: 34256643
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: If6bd4721c53072e5518f554a8c7598705517c132
Rename to TextClassifier
Move to android.view.textclassifier package
Adds getTextClassifierInfo(...)
Changes addLinks(...) to getLinks(...)
This CL also integrates this interface with framework components
and passes a context to TextClassificationManager.
Test: Tests will be added with implementation.
Bug: 34661057
Change-Id: If9e90f034ebb702c1f78e72b6a844f39eebf738f
Attribute is availble on activity, provider and service components. Allows
specifying which split contains that component.
Test: built test app with attribute
Change-Id: Ibc615321035f76a71d0dce5a6fae3f3ef4c3e762
This change creates a new FontManagerService, in charge of providing
font management data. It exposes a public API to retrieve the
information in fonts.xml without accessing it directly. To do this,
it also refactors FontListParser's internal classes into a new public
FontConfig class holding all the font data.
getSystemFonts() returns all the available information in fonts.xml
as well as file descriptors for all the fonts. This allows us to
share the memory consumed by these files between all clients.
Bug: 34190490
Test: See attached CTS change in topic
Change-Id: I0e922f8bcc9a197a1988d04071eb485328d66fb7
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
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
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
This change promotes some of the APIs that Settings uses for the
"Open by default" screen from @hide to @SystemApi.
GTS tests are added in ag/1811536.
This change also changes the protection level for
Manifest.permission.SET_PREFERRED_APPLICATIONS to allow package verifiers
(e.g. the Play Store) to be granted it. This permission is used in the
PM.updateIntentVerificationStatusAsUser() and
PM.setDefaultBrowserPackageNameAsUser() APIs.
Bug:31008483
Test: Patch in ag/1811536 and follow the test instructions there.
Change-Id: I18b069de11eaa8fe97c151fb3cfb63854f1fd056
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
