android_frameworks_base/data/etc/preinstalled-packages-platform.xml
Adam Bookatz 1f04060be0 UserSystemPackageInstaller auto-treats static overlays
The UserSystemPackageInstaller installs packages on new users
based on their configuration in an allowlist. An exception was
made for auto-generated RROs, which were instead installed based
on their overlay target package's configuration (thus avoiding
the need for manually allowlisting each such overlay).

This is now expanded to all static overlays (which should
include auto-generated RROs, according to the bug). That is:
Static overlays no longer need to be mentioned in the list,
but will instead be installed based on the listing for their
overlay target package.

Test: atest UserSystemPackageInstallerTest
Fixes: 172956245
Change-Id: I6b974bba20ee059a8f744092db7c3441580d327f
2021-01-21 17:19:02 -08:00

114 lines
5.0 KiB
XML

<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (C) 2019 The Android Open Source Project
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!--
This XML file declares which system packages should be initially installed for new users based on
their user type. All system packages on the device should ideally have an entry in an xml file
(keyed by its manifest name), except for static overlays which are instead treated automatically
according to the entry for their corresponding overlay target package.
Base user-types (every user will be at least one of these types) are:
SYSTEM (user 0)
FULL (any non-profile human user)
PROFILE (profile human user)
the precise meaning of which is defined in
frameworks/base/core/java/android/content/pm/UserInfo.java.
TODO(b/143784345): When UserInfo flags are categorized, reference the "base type" category here.
More granular control is also available by specifying individual user types (every user is exactly
one of these user types).
This includes AOSP user types defined in frameworks/base/core/java/android/os/UserManager.java, like
android.os.usertype.full.SYSTEM
android.os.usertype.full.SECONDARY
android.os.usertype.full.GUEST
android.os.usertype.full.DEMO
android.os.usertype.full.RESTRICTED
android.os.usertype.profile.MANAGED
android.os.usertype.system.HEADLESS
as well as any OEM custom user types defined using
frameworks/base/services/core/java/com/android/server/pm/UserTypeFactory.java.
Any specified user types must be valid user types on the device (i.e. created in UserTypeFactory).
The following three examples should cover most normal cases:
1. For a system package to be pre-installed only in user 0:
<install-in-user-type package="com.android.example">
<install-in user-type="SYSTEM" />
</install-in-user-type>
2. For a system package to be pre-installed on all human users (e.g. a web browser), i.e. to be
installed on any user of type FULL or PROFILE (since this covers all human users):
<install-in-user-type package="com.android.example">
<install-in user-type="FULL" />
<install-in user-type="PROFILE" />
</install-in-user-type>
3. For a system package to be pre-installed on all human users except for profile users (e.g. a
wallpaper app, since profiles cannot display wallpaper):
<install-in-user-type package="com.android.example">
<install-in user-type="FULL" />
</install-in-user-type>
Some system packages truly are required to be on all users, regardless of type, in which case use:
<install-in-user-type package="com.android.example">
<install-in user-type="SYSTEM">
<install-in user-type="FULL" />
<install-in user-type="PROFILE" />
</install-in-user-type>
More fine-grained options are also available by specifying individual user types.
E.g.
<install-in-user-type package="com.android.example">
<install-in user-type="android.os.usertype.profile.MANAGED" />
<install-in user-type="android.os.usertype.full.GUEST" />
<install-in user-type="SYSTEM">
</install-in-user-type>
which installs this package on any user whose user type is a managed profile or a guest, or is of
a SYSTEM base type.
Additionally, packages can blacklist user types. Blacklists override any whitelisting (in any file).
E.g.
<install-in-user-type package="com.android.example">
<install-in user-type="FULL" />
<do-not-install-in user-type="android.os.usertype.full.GUEST" />
</install-in-user-type>
If a user is of type android.os.usertype.full.GUEST (which itself is a subtype of FULL), this
package will NOT be installed, because the 'do-not-install-in' takes precedence over 'install-in'.
The way that a device treats system packages that do not have any entry (for any user type) at all
is determined by the config resource value config_userTypePackageWhitelistMode.
See frameworks/base/core/res/res/values/config.xml#config_userTypePackageWhitelistMode.
Changes to the whitelist during system updates can result in installing additional system packages
to pre-existing users, but cannot uninstall pre-existing system packages from pre-existing users.
-->
<config>
<install-in-user-type package="com.android.providers.settings">
<install-in user-type="SYSTEM" />
<install-in user-type="FULL" />
<install-in user-type="PROFILE" />
</install-in-user-type>
<install-in-user-type package="com.android.wallpaperbackup">
<install-in user-type="FULL" />
</install-in-user-type>
</config>