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
Apps that target O+ are always subject to background restrictions.
Legacy apps' background restriction is subject to the OP_RUN_IN_BACKGROUND
app op.
Apps with these properties are exempted from background restrictions:
- persistent process
- currently on the idle battery whitelist
- global whitelist for things like bluetooth services
Bug 30953212
Change-Id: Icc19b2fbc05f40dcf8c3fc4abf718c373dc8d4f6
ag/1633903 added config_allow3rdPartyAppOnInternal flag to specify
whether 3rd party apps are allowed on internal storage. We need to
respect the flag when moving apps between storages.
Bug: 30980219
Test: Added ApplicationPackageManagertest
Change-Id: I0f8e76467b5071d70f40da28c2087e689c049c06
When an ephemeral application explicitly accesses an
installed application, it grants access to its package
metadata. The ephemeral application effectively stays
hidden if it doesn't explicitly connect to any activity,
service or provider [i.e. implicit connections using
an ACTION_VIEW/CATEGORY_BROWSABLE intent will not expose
its metadata].
Bug: 34123112
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest
Change-Id: I7e1680902599b3ada0d4fba5998af30566017051
Make TelephonyManager#get/setAllowedCarriers system api under
PackageManager#FEATURE_TELEPHONY_CARRIERLOCK feature flag.
Bug: 33480084
Test: cts
Change-Id: I1ce77a9e3801bd4003b52887d0a36866e5a5b81a
This CL allows system code to retrieve persistent preferred activities
(default intent handlers set by a Device Owner or Profile Owner app).
Settings will use this information to indicate which default apps were
set by the admin.
There is no public PackageManager API. Settings will call via the
IPackageManager interface directly.
Bug: 32692748
Test: Will be CTS-verifier-tested together with Settings
Change-Id: Ibd0a39f13852a9117836ca75cc0882e4cbe0ec1d
Apps that target O+ are always subject to background restrictions.
Legacy apps' background restriction is subject to the OP_RUN_IN_BACKGROUND
app op.
Apps with these properties are exempted from background restrictions:
- persistent process
- currently on the idle battery whitelist
- global whitelist for things like bluetooth services
Bug 30953212
Change-Id: Ib444829a2d222125f64ff19e8218823fa78373f9
as a result of Intent.ACTION_CREATE_SHORTCUT
> Adding API to allow launchers to query shortcut config activities in
managed profiles.
> Adding API to allow the default Launcher to start the shortcut config
activity in managed profiles.
> Updating the ACTION_CREATE_SHORTCUT documentation to represend changes
in the expected result.
Test: Manual tests and all the unit tests
adb shell am instrument -e class com.android.server.pm.ShortcutManagerTest1 -w com.android.frameworks.servicestests
... to test10
Change-Id: I785c4f2fba782b864cc401ac7905330ea4498289
Teach running applications to refresh already loaded ApplicationInfo
objects without resorting to restarting the application process.
Activities will be scheduled for restart via the regular life-cycle.
This is similar to a configuration change but since ApplicationInfo
changes are too low-level we don't permit apps to opt out.
This change is intended to be used with runtime resource overlays and
split APKs.
Test: Manual - command to update application via ActivityManagerShellCommand
Change-Id: Ice10a1691cced90eee95e3278fd784b8a9206d87
- Catch a wider variety of exceptions from the package parse
stage. Ignore and delete the cache entry if we catch *any*
exceptions from deserializing the parse result.
- Rename the system property pm.boot and not ro.boot, since the
former needs less effort to change back and forth.
- Finally, add a heuristic to wipe caches on non-numbered
userdebug builds when changes to the system partition are detected.
Also re-enable the cache by reverting commit
20274d15d8.
Test: Manual
Change-Id: I7b5b71ac60d8c438398c354be50b207e80550148
