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
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
