Applications with the android:isolatedSplits="true" attribute in
their AndroidManifest.xml would have their Split APKs loaded in
isolation of each other, based on a set of dependencies.
Configuration Splits generated for a Feature split would not be properly
loaded before, so this change, along with a tools change, fixes this
issue and completes support for isolatedSplits.
Bug: 30999713
Test: CTS test coming (depends on some tool changes)
Change-Id: Ia4e7b0e69168a9d6637867558e306f7031720fb3
In AccountManagerService.getAccountsAsUser, we check if opPackageName
belongs to calling uid by calling AppOpsManager.checkPackage. But when
AccountManagerService.getAccountsAsUser is called from
AccountManagerService.addSharedAccountsFromParentUser, we're using the
opPackageName from system context instead of calling context.
Bug: 35258008
Test: cts-tradefed run singleCommand cts-dev --module CtsMultiUserHostTestCases \
-t android.host.multiuser.CreateUsersPermissionTest#testCanCreateRestrictedUser
Change-Id: I5c425d9314beb86f7c64a5b5c64b7d879711879a
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
during install, the user could specify an invalid size [ie. a negative
number].
also error out if we're given a path that's not a file.
Change-Id: I79e9ef82723495782146208eb5469722d1f8ed02
Test: manually ran 'adb install' with invalid arguments
Internal implementation of "adb install" has been changed to
session install. As a result '-s' option doesn't work.
Size info is required when using '-s' option in session install.
PackageHelper.fitsOnExternal() returns false and moving app to SD is
failed when size info is not set.
So set size info when '-s' option is used.
And change identity on some method because shell doesn't have some
permission to access to asec.
Bug: 29932779
Author: Ryuki Nakamura <ryuki.x.nakamura@sonymobile.com>
Change-Id: I65edcc0f01ceecaaba17792ad329791a9253d603
This introduces a new feature of the IBinder command protocol
to allow the shell command implementation to call back into
its caller to ask it to open files in the calling context. This
is needed so that commands that have arguments specifying files
can open those files as the calling shell, not the system (or
whatever) process.
To test this all out, move the "am start" implementation over
to ActivityManagerShellCommand, in particular along with its
option to specify a file in which to write profiling data.
Test: Manual
Change-Id: I0c1e3857defefbd19a2ac29413aafbb34b1e48a3
Count each demo user creation and time between
first touch (to dismiss the video) and the start
of inactivity timeout.
Fixed an NPE in SysUI when user switcher is missing.
Bug: 29540372
Change-Id: I7bc0e0dde75e7b213a025683c15c9b3e750643a9
We need to make IIntentSender oneway... but when the system is
calling that for itself, it needs to be able to return a result code.
Solution: instead of directly calling the interface, we have a new
IPC through the activity manager. If the thing being used is the
activity manager impl, it can do the synchronous send and return
the result directly in place. If not, you only get asynchronous
sending and thus never a failure result back (too bad for you!).
Change-Id: I4096e5b00063e8dba66230585a2dfe67e35e8092
If a package targets a pre-release SDK [eg a letter version] it should not
be allowed to be upgraded by a release SDK [eg a number version]. If one
absolutely must upgrade to a release SDK, use the "--force-sdk" option
during install.
Bug: 28345311
Change-Id: Ic9fb209968e7c5da2c80c5ca4c0f44f5125f610a
Passing the "--dont-kill" argument to pm install-create can be used to
install a feature split without killing the contianing application.
Use with caution.
Bug: 27780548
Change-Id: I743ac4f640c9c4251d1b3bc70ddf428bd79e07bf
Replace some custom rules with BUILD_PREBUILT.
Move tools from ALL_PREBUILTS to BUILD_PREBUILT. All of them are already
in PRODUCT_PACKAGES in build/target/product/base.mk.
Remove uses of ACP and replace with core build system macros or 'cp'
Change-Id: I529e7c6c50fc64ad36b75bb47142f6bde909d141
This reflects the change in PackageManager service:
frameworks/base commit 921dd754ab49df0cd580ff96503f7616c4c85f4a.
Bug: 27327503
Change-Id: Ic13788a3850c4d1a3a566b208853de9a6d2c5237
In an attempt to provide more detailed information to the end-user, we
caused tests to fail [they parse the output of the 'pm' command]. Remove
the 2nd line of the output that was causing the failure.
Also took the opportunity to merge changes from the Pm command to the
Cmd command.
Bug: 26131598
Change-Id: I459f9ec8978d87dd571136222f780039e426474e
Unless the APK is streamed, proxying pm install commands to the cmd command
will generally not work on any system that has SElinux enforcement. This
is due to the system sever [where cmd commands are run] not having access
to the directories where files are uploaded to. We'll re-enable the proxy
once we determine an appropriate, safe location for uploaded APKs.
Bug: 25769800
Change-Id: I73b2da0b03fe8bd9ce29e20b37cb4eeff9b491b4
* Add a new --ephemeral argument to 'adb install'
* Add plumbing to internally track ephemeralness
* Create new app directory for ephemeral installs
Bug: 25119046
Change-Id: I1d379f5ccd42e9444c9051eef2d025a37bd824fe
Move the implementation of the install variants and uninstall to the cmd
command. Additionally, make two other important changes: 1) replace calls
to the legacy PackageManager#installPackageAsUser with the PackageInstaller
2) allow streaming package bits for 'pm install'
Change-Id: I5680f57208d377daadb69b2cc09c233c02fe5016
Move the implementation of the install variants and uninstall to the cmd
command. Additionally, make two other important changes: 1) replace calls
to the legacy PackageManager#installPackageAsUser with the PackageInstaller
2) allow streaming package bits for 'pm install'
Change-Id: Ia49dac0ccd6470f9d1c1964bdeb3c0b22b856075
sm showed IllegalArgumentException after usage.
pm inconsistently used "return showUsage()"
Bug: 20948199
Change-Id: I5828489a9d4ef2eabfb97dd408d66e1560a5a983
Also moved restricted profile create/setup logic from Settings to
UMS.createRestrictedProfile.
Bug: 24212155
Bug: 24303609
Change-Id: I0346a3368de53f4bb4b6e054349f19adac959d7f
