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
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
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 79047c62b58fb0a0ddf28e2b90fe4d17e05bc528)
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 aa49cb86e6d5f23d82c97db32c848bc4ea2b81bc)
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
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
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 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
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
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
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
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
