It is now just a shell of itself. :)
Also brings in a few fixes to never try to open files from the system
process.
Test: manual
Change-Id: Ia8187196af597046fd2e7092dbf19ce1dc1ea457
Without this, exec()ing these fails.
Found with `grep -L bin/sh $(grep -Rl Script)`
Bug: None
Test: exec()ed each of these scripts; I no longer get "exec format
error" for any of them.
Change-Id: I47db5007e5cc14ab91eb846b7bffecb925d37874
We can use the new mechanism to ask the calling shell to open
a file in order to implement the rest of these commands, allowing
you to give the path to an apk to install. That API is thus
extended to allow you to open readable files, not just opening
file for writing.
Doing this however means we no longer can pass a file path to
AssetManager for the apk to parse, we only have an already open
fd for that. Extending AssetManager to allow adding apks from
fds is not that hard, however, since the underlying zip library
already supports this.
This main thing this changes is in AssetManager.cpp where we
retrieve the open zip file for a particular apk that has been
added. This used to look up the zip file by path every time
it was needed, but that won't work anymore now that we can have
things added by fd. Instead, we keep track of each opened zip
in the AssetManager, so we can just directly retrieve it from
the asset_path representing the item that was added. As a
side-effect, this means for normal paths we no longer need to
look up by name, but just have the opened zip file directly
accessible. (This is probably good, but it does mean that we
no longer run the logic of seeing if the zip file's timestamp
has changed and re-opening it if it has. We probably shouldn't
be relying on that for an active AssetManager anyway, and maybe
it is even good that we don't allow the zip file to change
under it?)
A follow-up change will finally remove the Pm.java implementation
and turn the pm "command" into a simple shell script that runs
cmd package.
Test: manual
Change-Id: Ie103e3bdaa5b706796cc329254f2638151a3924f
Everything is now moved out of the pm command except for
the various install commands. I am going to hold of on
those since they require doing some resolution with the
current implementations in the package manager to make
sure they match and behave identically to the implementations
currently in the pm command. But other than that, everything
in pm is now just redirecting over to "cmd package".
Also fix up some of the dumpsys output of a few other sevices
when asking to print the data for a particular package, so
the "pm dump" command gives a little more sane result.
Test: manual
Change-Id: I139e06e560203b72243d7eea9543c2240db0f8f8
Awhile back we explicitly blocked any new ASEC installs, with the
expectation that we'd eventually remove the logic entirely. We've
had them disabled for about a week now without incident, so let's
rip out the remaining code.
Test: bit FrameworksCoreTests:android.content.pm.PackageHelperTests
Test: bit FrameworksCoreTests:android.content.pm.PackageManagerTests
Bug: 32913676
Change-Id: I1ecc35487420731f5c4bdf03bca5751548ce51b3
Similar to Package Installer App. This reduces the overhead of each
chunk and slighly speeds up package installation.
Test: Installed app via 'adb install' and 'adb shell pm install'
Change-Id: Ic8f67087e578bf0696e3d55ad3d7f3892ca2bf90
There's no need to do this during a "lite" parse. Moreover, we don't
resolve resource references during a lite parse, which means that we
lose a lot of flexibility.
Test: CtsAppSecurityTestCases
Bug: 64339642
Change-Id: I7d02faab6bd226d96d63d2edd8c06b94e15e14ad
Add an attribute android:classLoader which can be set to the name
of the classloader the base or split wishes to use. For now, this can
only be set to "dalvik.system.PathClassLoader" or
"dalvik.system.DelegateLastClassLoader". The current implementation
only allows the classloader to exist in the boot classpath but that
restriction can be loosened in a future change if necessary.
Test: cts-tradefed run cts-dev -m CtsAppSecurityHostTestCases
Bug: 36044779
Change-Id: I5a51f7aa0c8c4c398d2f46129eb06785cc8e3c3f
We normally prevent apps from allocating into the "reserved" cache
space, but this change makes an exception for an active camera app,
since the user is probably trying to capture an important memory.
This change only lets the active camera app clear up to half of the
reserved space, since we don't want to completely destroy the
experience of all other apps.
Test: manual app before/during/after active camera session
Bug: 38267830
Change-Id: Ie9e63884fb2638ca881e10b894629eea84601648
When answering the question "how much space is free", use the same
logic for Settings UI and StorageManager.getAllocatableBytes(). That
is, the reported free space is usable bytes plus any cached data the
system is willing to delete automatically.
This does *not* include any reserved cache space, since we don't want
abusive apps to penalize other well-behaved apps that are storing
their data in cache locations. Callers freeing cached data need to
now explicitly request defiance of the reserved cache space. (Most
callers are already doing this by using FLAG_ALLOCATE_AGGRESSIVE.)
Rewrite the core logic of DeviceStorageMonitorService to understand
this new "reserved" cache space, and to be easier to understand. It
also now handles cached data on adopted storage volumes, which had
been ignored until now. Also fix bug where we had skipped "low"
broadcasts when the device skipped directly from/to "full" state.
Bug: 38008706
Test: cts-tradefed run commandAndExit cts-dev -m CtsJobSchedulerTestCases -t android.jobscheduler.cts.StorageConstraintTest
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Change-Id: Icbdcf3b52775f7ada1ceaeff2f96094c8d8052f9
There is now an IBinder "token" that must be specified when setting
the whitelist duration for an Intent. To have the whitelist supplied,
the caller to send a PendingIntent must pass in the same token. The
PendingIntent and IntentSender classes now internally maintain this token
to pass in when their send() is called.
The big complexity for making this work is we now need to associate this
whitelist token correctly with the actual PendingIntent objects that
applications and other code is getting. To do this, we propagate the
token in the Notification object, and have a new API on Parcel that allows
us to make it available to PendingIntent when it is unmarshalled. And
this allows to deal with PendingIntents appearing in nested bundles, as
we can propagate that information from the original Parcel to the new
Parcel that Bundle keeps to delay unmarshalling.
Test: manual
Change-Id: Idda00490ccfe2be37e4ab21354b9ab7528a52750
We've seen evidence of lab devices racing with other apps that are
using cache space immediately after tests wipe it clean, which can
cause test failures. To mitigate this, try our best to wait for the
device to go "idle" by watching for broadcast queues to fully drain.
Also improve javadocs along the way.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Bug: 37486230, 37566983, 37913442, 37914374
Change-Id: I4d430db443b6fa6d33a625fe07b90279b5d51c12
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
