GitLab

Since CONTEXT_RESTRICTED is not a default flag of createPackageContext,
we can't rely on it for preventing unexpected font injections.
To protect developers and existing apps from a risk of font injection,
stop loading font from other package's resouce unless the developer
explicitly set CONTEXT_IGNORE_SECURITY.

This CL contains Iac2a6fb3d82ef23d5ca6ee33f4aaa9ed28455271 by manual
merging to handle repository split.

Bug: 62813533
Bug: 62879353
Test: Manually done
Merged-In: I4442ddc48dadb5c968b444be86038b602074d301
Change-Id: I4442ddc48dadb5c968b444be86038b602074d301

a different user

Test: Manual tests and CTS
Bug: 38204385
Change-Id: Ic3bddbc2e6070c11b11f0685077db7737f2b8849

Bug: 37465538
Test: manual; Verified that Instant Apps can send broadcasts to
receivers still via the changed API.

Change-Id: Ib0f3d0c8ee71234288ccecd07e621554eb9b70ac

ANDROID_ID for Instant Apps now has the following properties:
1) per-app scoped
2) reset if the user clears the Instant App
3) remains the same if the Instant App gets upgraded to an installed
app.

Note that if the user goes instant -> installed_1 -> uninstall ->
installed_2 the ANDROID_ID at installed_1 will not be the same as
installed_2. This was deemed better than the id changing on the upgrade
step.

Test: manual
Change-Id: I532975c50049c94ff80902a897e001dd35a69f9f

Test: cookie CTS tests pass

bug:37327624
bug:37325276
bug:37323696

Change-Id: I52b10470759e471629ec6772e115df94482eb341

The NotificationManager.startServiceInForeground() experiment is over,
and will not ship as API, so it's time to tidy up and get rid of it.

Bug 36130212
Test: manual

Change-Id: I834d1ce059aa464ff27f69f5e5d3625cc5e61d8a

Bug: 35873804
Test: TreeHugger
Change-Id: I4d962927587bb10833bfe3c3db27fdceab668fc3

Yum!

Also needed to have a Context.revokeUriPermission() variant that is sane,
so reasonable CTS tests can be written.

Test: new ClipDataJobTest added.

Change-Id: Ia3135ea788a6e32c971bae7dab3a844d0ef4139c

Rather than require an a-priori Notification be supplied in order to
start a service directly into the foreground state, we adopt a two-stage
compound operation for undertaking ongoing service work even from a
background execution state.  Context#startForegroundService() is not
subject to background restrictions, with the requirement that the
service formally enter the foreground state via startForeground() within
5 seconds.  If the service does not do so, it is stopped by the OS and
the app is blamed with a service ANR.

We also introduce a new flavor of PendingIntent that starts a service
into this two-stage "promises to call startForeground()" sequence, so
that deferred and second-party launches can take advantage of it.

Bug 36130212
Test: CTS

Change-Id: I96d6b23fcfc27d8fa606827b7d48a093611b2345
(cherry picked from commit 79047c62)

This Intent will be used in Settings to show the settings UI for the
Ephemeral resolver. Settings can get the correct component to send the
Intent to by calling
PackageManager.getInstantAppResolverSettingsComponent

Bug: 35918998
Test: Boots
Change-Id: I0edcf85704f2c19e0ee27f91b6ef057d52e32778
(cherry picked from commit aa49cb86)

Ostensibly for instant apps, we allow play to mark an app as having
an update available. This will trigger instant app resolution even
if the instant app is already installed on device.

Bug: 35143464
Test: Manual; launch URI of installed instant app, see it runs w/o resolution. set bit. launch URI of installed instant app, see it runs resolution
Change-Id: I511df2b2a3eab39377167c770255ccbe02d5dad2

Instant apps can only send broadcasts to receivers that are declared in
the manifest with android:visibleToInstantApps=true or if the app
registers a receiver at runtime using the new methods that take
visibleToInstantApps.

Bug:33350280
Test: Manually sending broadcasts from Instant Apps only goes to
receivers with visibleToInstantApps set to true.
Test: Receiving a broadcast from within the same app does not require
visibleToInstantApps to be set.

Change-Id: I54d79a502ba9c5fd03ede3c09e08afc88fe2775f

a given package name is an instant app.

Test: refactor existing codepaths retained

Change-Id: I6253fe8cc398d6547566d11043bffd1c4ffaa74a

Deprecates com.android.internal.util.Predicate in favour of
java.util.function.Predicate.

Deprecates TestMethod and TestSuiteBuilder in favour of
Android Test Support Library.

Bug: 35089332
Test: make checkbuild
Change-Id: Id8b2be55925d7ca09750fc9681817793517ceb5d

Removes package.html files and update package-info.java files to
use same wording as previous releases.

Bug: 35653948
Test: make docs
Change-Id: Idbede2eb4f57818f152834fad7e75dd181fe25d6

Added @SystemAPI method Context.getPreloadsFileCache.

Bug: 31008665
Test: manual
Change-Id: Id61ab5e1b78d8bfbd40f61985406a8de4082b30f

When activity that is moved between displays handles all configuration
changes, it won't be restarted. This CL adds a callback to the client
to notify it about display change. Usually it will be followed by
onConfigurationChanged, except when configuration didn't actually change.
When activity is recreated, it won't receive onMovedToDisplay.

Bug: 34862802
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testOnMovedToDisplayCallback
Change-Id: I9a9501cab788623ada15a31efb53e4b2378639fe

After any package install, removal or update, save the changed
package and update a global sequence number. At any point, apps
can query for the packages changed since a particular sequence
number.

If a package is changed multiple times, it is only included once
in the change list.

Bug: 33865505
Test: Create sample app to query for changes and see which packages are changed after performing certain operations
Change-Id: Ia4646035362b16a97110e05f3f909ce385b48428

This partially reverts commit 3e5fbca0.

Bug: 35187548
Bug: 30188076
Bug: 35089332
Test: make checkbuild
Change-Id: I7ab4279aab604e3d56003b0a59867948aebabd28

Bug: 35089332
Bug: 30188076
Test: make checkbuild
Change-Id: I0a5b4bf520fc39b59d8d790b01e9cff0d54e6d21

Bug: 35089332
Bug: 30188076
Test: make checkbuild
Merged-In: I0a5b4bf520fc39b59d8d790b01e9cff0d54e6d21
Change-Id: I58e4e35e7b7315033d893748f7c79e1ba6732f39

This change adds APIs for instant apps to store cookie data
that is presisted across instant installs and across the
upgrade from an instant to a standard app. Standard apps
can use the cookie APIs but when they are uninstalled the
cookie is also deleted. The cookies are kept longer than
the instant apps as they are much smaller - 16KB by default.
We can change the cookie size via a system setting i.e.
after we ship we can increase size if needed.

We also add internal APIs to surface information about
installed and uninstalled instant apps which should be
used for showing them in the UI. For this puporse we store
the icon, permissions, and label of uninstalled apps. If
the app is re-installed we drop this meta-data but keep
the cookie around. If we have cookie data stored and the
signing cert of the app changes when it gets re-intalled
we wipe the cookie.

Test: CTS tests pass; hiddent APIs tested manually

Change-Id: If145c0440cc61a5303e2cbb70228d235d36037a5

BUG: 34240393
Change-Id: I68e55767a7da1d457a6cedd210aac9e339fb996c

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

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

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

In preparation for removing junit classes from the Android API
the legacy-test target will be removed from the
TARGET_DEFAULT_JAVA_LIBRARIES. This change adds explicit
dependencies on junit and/or legacy-android-test to ensure that
modules will compile properly once it is removed.

(cherry picked from 6387604f9e672ece85e07c4bcbd7be396867f06f)

Bug: 30188076
Test: make checkbuild
Merged-In: I13e88297731253420e4e5f5291d503f13a39a156
Change-Id: I58446eb8c45d8ac2bcdbc9fa40d1321e811bdd4b

This reverts commit 21f77806.

Change-Id: I65586f9739da84fb32b51b0ea166b8288c41d1b3

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

In preparation for removing junit classes from the Android API
the legacy-test target will be removed from the
TARGET_DEFAULT_JAVA_LIBRARIES. This change adds explicit
dependencies on junit and/or legacy-android-test to ensure that
modules will compile properly once it is removed.

Bug: 30188076
Test: make checkbuild
Change-Id: I13e88297731253420e4e5f5291d503f13a39a156

This CL allows a reason to be specified when installing a package. The
install reason is a sticky piece of metadata: When a package is e.g.
installed via enterprise policy and an update is then manually
installed or sideloaded, the install reason will remain "policy."
The install reason is tracked separately for each user.

With this CL, two install reasons exist: "policy" and "unknown." Other
install reasons will likely be supported in the future.

Bug: 32692748
Bug: 33415829
Test: Tested manually with "adb install" / "adb uninstall"

Change-Id: I0c9b9e1b8eb666bb6962564f6efd97e41703cd86

Upcoming platform features need to cluster apps together into broad
categories to help summarize information to users.  (For example,
when presenting battery, network, and disk usage.)

We are tightly limiting the set of categories to keep them easily
presentable to users when summarizing information.  This feature is
not designed to be a general-purpose taxonomy, nor should it be
allowed to become one.

Older apps may not have defined a category in their manifests, so
allow the installing app to define a category on their behalf.

Test: builds, boots
Bug: 33815939
Change-Id: I785b882ee7c18072ef47d56e0fc19ad72888e1b7

Fix: 33568999

Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases
--test com.android.cts.devicepolicy.DeviceOwnerPlusManagedProfileTest

Change-Id: I14c8b5b1f78192429e68a3057430406245a909c8

The android.test.runner target forms part of the Android API and
so must maintain backwards compatibility. The junit classes that
belong in there are copied here to ensure that they do not
change when external/junit is upgraded.

Bug: 30188076
Test: make checkbuild and checked android.test.runner contents
Change-Id: I947144c47ae1c3eb361a43c39bdd03dc11b9575f

Test: cts-tradefed run cts-dev -m CtsContentTestCases
Bug: 30927484
Change-Id: Idb9dbc2b80896e9f8474a0db71353b7a3810d597

Bug: 30188076
Test: make checkbuild
Change-Id: I0cb6f89907eb099714b54bac57b51c4be186c3e0

Support a system property on debugable builds to
override the max number of managed profiles to
allow easier dogfooding of multiple profiles.
Support 3 different badge colours for managed profiles.

Bug: 30473760
Test: runtest -c com.android.server.pm.UserManagerServiceCreateProfileTest frameworks-services
Test: runtest -c com.android.server.pm.UserManagerServiceUserInfoTest frameworks-services
Test: manual - attempting to create 2 profiles with adb fails, passes once I set the property.
Change-Id: Ie7fb19048a04a01572666f229283152254d0ffc3

Checked that android.test.runner had the same classes in as
before the change.

These classes are legacy 3.8.1 classes, they are not in 4.10 at
all. They appear to have been left here by accident. Looking at
the history it appears that at one time there were copies of
JUnit 3.8.1 junit.runner classes in frameworks and
external/junit. The classes here were upgraded to 4.10 but even
though these classes had been deleted immediately after 3.8.2
was released they were not removed, instead they appear to have
been reformatted as part of the upgrade. The external/junit
source was upgraded to 4.10 about two weeks later which seems to
have been done correctly. About three months after that the
classes here that were duplicates of those in external/junit
were removed from here leaving the legacy classes from 3.8.1.

I could not find any usages of these classes and they are not in
the public API so they can probably be removed altogether.
However, for now I will simply move them into external/junit as
described and remove them when upgrading JUnit there to 4.12.

Bug: 30188076
Test: Built android.test.runner and checkapi
Change-Id: I88687889315c041d999fe7e61b9652ac8406165c

Settings needs to access a variant of getInstalledApplications() which
takes a |userId| argument. Since this is not currently exposed by
PackageManager, Settings calls into PackageManagerService directly. This
is ugly and breaks the regular abstraction layer hierarchy.

The CL fixes the problem by exposing the required variant of
getInstalledApplications() as a hidden API, analogously to what was done
before with getInstalledPackages().

Bug: 32692748
Test: Will be CTS-verifier-tested together with Settings
Change-Id: Id9c4e8e18524d312159821f1a4d5527263c7e950