In P we moved destroying per-user shared storage into installd,
where it can iterate quickly over large sets of files. This change
now moves cleaning/destroying of per-app shared storage data down into
installd, letting us greatly simplify the logic in PMS to no longer
require spinning up DefaultContainerService. This also fixes an
obscure bug where DCS (which always runs as USER_SYSTEM) wasn't able
to clear shared storage for secondary users.
This also gives us the ability to target specific storage devices
by UUID, such as when the user has migrated their primary shared
storage to an adopted device.
We no longer distinguish between keeping or deleting OBB files
during various operations, since upcoming changes in the Q release
will mean OBB files are no longer shared between users, and they'll
now live inside a sandbox that will be fully cleared when the user
clears data. (Going forward, apps should be using splits instead
of OBBs, so they're effectively deprecated.)
Uses newer "const" feature of AIDL to ensure constant values remain
consistent between native and Java code.
Bug: 111854851, 111838160
Test: atest android.appsecurity.cts.StorageHostTest#testCache
Change-Id: Ib90be155718a768da76110fbfcf010a471b37378
There are several places across the OS where Java code is simply
copying data between two points, which requires bringing that data
out into userspace before going back into the kernel. (That's pretty
lame.) The patches for the recent Meltdown/Spectre security issues
have made this overhead even worse, so it's finally time to move this
copying directly into the kernel.
This change adds a couple new FileUtils.copy() methods which inspect
the given streams/FDs, and attempt to do as much optimization as
possible before falling back to a slower userspace-based copy.
Benchmarks are showing typical improvements of 44% for 32KB files,
50% for 32MB files, and 35% for 32MB pipes.
Plenty of tests are included, and there's a simple kill-switch that
can be used to enable/disable the feature if it starts causing any
trouble. (A future CL will enable the optimizations.)
Test: bit FrameworksCoreTests:android.os.FileUtilsTest
Test: vogar --mode app_process --benchmark frameworks/base/core/tests/benchmarks/src/android/os/FileUtilsBenchmark.java
Bug: 71932978
Change-Id: I52518d529da5d961610998b9f61399064d8025cd
It turns the version code into almost a 64-bit integer, with the
new major part being the upper 32 bits.
The only tricky part about this is the backup manager, since it
stored 32-bit version codes in its backup data sets. This is dealt
with by, when the major version code is not 0, writing MIN_INT as
the version code and following that by the full long version code,
which we can detect when reading. Note that this makes backup sets
containing apps with major version codes incompatible with older
versions of the platform.
Bug: 64459786
Test: Added in Change-Id: Iab8a682b62103babd6c16a56b8dc1e97d7078658
Change-Id: Ibfffe235bbfcf358b3741abd3f7197fdb063d3f3
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
New quota APIs are much faster than trying to measure manually, and
removing this last user of calculateDirectorySize() means we can
remove it once and for all.
Bug: 36056324
Test: builds, boots
Change-Id: Ibdf1ee4e8885680e106df6a9269b6309ddc61af8
We're not actually clearing any files, only deciding how much free
space is available, so we're fine assuming the remote caller has the
permission.
Test: builds, boots
Bug: 37169076
Change-Id: I6cd42f77c43e9d2de40e2b8b937c7f2145f1b869
It's confusing, but f_bsize is not the value you're looking for; the
real block size is f_frsize. Fix all those bugs.
Also, the vast majority of clients are interested in the usable
disk space, not including reserved space.
Test: builds, boots
Bug: 36840579
Change-Id: Ib1470389afd49c14cab62282ec1e978ebb2c4791
Apps delivered as multiple split APKs must have identical package
names, version code, and signatures. However, developers may want
to iterate quickly on a subset of splits without having to increment
the version code, which would require delivery of the entire app.
This change introduces "revision codes" which can vary between
split APKs belonging to the same app. An install is valid as long
as the normal version code is identical across all splits. Splits
can be added/removed to an app over time, but if a split is present
across an upgrade the revision code must not decrease.
Since system apps could have been updated with splits, only revert
to the built-in APKs if the version code is strictly greater than the
data version. Also fix bug to enable inheriting from system apps
when adding splits.
Bug: 18481866
Change-Id: I34d8e14c141a8eb95c33ffe24b4e52d6af5c8260
Sessions can now zero-copy data directly into pre-allocated ASEC
containers. Then at commit time, we compute the total size of the
final app, including any inherited APKs and unpacked libraries, and
resize the container in one step.
This supports both brand new ASEC installs and inheriting from
existing ASEC installs. To keep things simple, it currently requires
copying any inherited ASEC contents, but this could be optimized in
the future.
Expose new vold resize command, and allow read-write mounting of ASEC
containers. Move native library extraction into the installer flow,
since it needs to happen before ASEC is sealed. Move multiArch flag
into NativeLibraryHelper, instead of making everyone pass it
around. Migrate size calculation to shared location.
Separate "other" package name in public API, provide a path to a
storage device when relevant, and add more docs.
Bug: 16514385
Change-Id: I06c6ce588d312ee7e64cce02733895d640b88456
Teach DefaultContainerService to install split APKs, which will be
needed when moving to/from ASECs. Also support forward locking for
testing purposes, even though its deprecated.
Move native library unpacking code to NativeLibraryHelper location
where it can be shared by both DCS and PMS. Also update footprint
calculation logic to mirror the later unpack codepaths.
Immediately persist sealed sessions. When resolving install
locations, prefer location of any existing install of that
package. Lightweight parse requesting certificates now always
verifies that all contents are signed correctly.
Bug: 16514385
Change-Id: Ida1c4eb0f95b065104dd971e19126d4085ebf1f0
Move location selection logic into shared PackageHelper location,
and share it between DCS and PackageInstaller. Fix bugs related to
installed footprint calculation; always count unpacked native libs.
Have PMS do its own threshold checking, since it's fine to stat
devices. PMS only ever deleted staging ASECs, so move that logic
into installer and nuke unclaimed staging ASECs. Allocate legacy
ASEC names using PackageInstaller to make sure they don't conflict
with sessions.
Start wiring up session to allocate ASEC and pass through staged
container for installation.
Fix bug to actually delete invalid cluster-style installs.
Bug: 16514385
Change-Id: I325e0c4422fc128398c921ba45fd73ecf05fc2a9
Each application now has two ABIs, the primary
and the secondary. The app is always launched with
the primary, but the secondary might be used by other apps
that load the given applications code. This implies we
must:
- dex2oat the app both ways.
- extract shared libraries for both abis.
The former is relatively straightforward but the latter
requires us to change the layout for shared libs that we
unpack from applications. The bulk of this change deals
with the latter.
This change continues to fill in nativeLibraryPath during
scans for backwards compatibility. This will be removed in
a future patch.
Change-Id: Ia943dd11ef815c5cbfc60f17929eaa2a652a385a
Now that all the other pieces are in place, we're ready to start
installing new file-based packages as a cluster (the new unified
directory-based layout). This greatly simplifies the renaming
process.
Also add helper methods to ApplicationInfo to give a much clearer
mapping between it and internal field names, since we can't change
the public API.
Add recursive restorecon().
Bug: 14975160
Change-Id: I72a63c5ddbc594c2fec4a91dd59f73ef253fbfd7
For the time being, DCS is going to still be doing heavy lifting for
some install tasks, so it need to know how to handle both monolithic
and cluster packages. This change is mostly plumbing work to
eventually handle any various splits APKs that we may encounter.
Bug: 14975160
Change-Id: I39848d5666f9083cb4eca493e5cdaa868f3f99fb
The new PackageInstallerSession APIs will allow installers to deliver
bits directly into system protected storage, so we no longer need
encrypted containers.
Change-Id: I8b598cb149b7dfd1d41e6626c1359610a573edf1
In the new split APK world, multiple APKs work together to define a
single package. This means that native code may be split among those
APKs. To handle this, extend NativeLibraryHelper to examine all
APKs in a package ordered by splitName.
A package has valid native code as long as one matching ABI is found
inside. The "best" ABI found across all APKs is picked for the
entire package. No attempt is made to ensure that every native
library defined is available for the picked ABI; that's the
responsibility of the installer.
Re-introduce PackageLite to represent a lightweight parsing of an
entire package, which may be a single monolithic APK or a cluster
of one or more APKs.
Remove native code extraction from InstallerSession, since it'll be
handled inside PMS for this release.
Bug: 14975160
Change-Id: I4f4db0f82e88a46101c7777499ebc0a11fd911f9
Differentiate between "split APKs" and "cluster packages". A cluster
package is a directory containing zero or more APKs (base+splits),
and a monolithic package is a single APK (base).
PackageSetting will use the directory name as its codePath, so track
the baseCodePath separately. Clarify documentation in several
places.
Require that all installers provide file:// URIs through existing
hidden APIs; PackageInstaller hasn't been able to read content://
URIs for a long time.
Bug: 14975160
Change-Id: I1c6fed1b55205c2474b09871161a98a26669d22e
There was lax / incomplete error checking around the
construction of Apk handles. This change changes the ApkHandle
API and makes it throw IOException if the zipfile couldn't
be opened.
Additionally :
- Fix a resource leak in DefaultContainerService
- Report errors correctly during package moves.
bug: 15563874
(cherry picked from commit ec4516470d)
Change-Id: Ia35b464355467d0d36faf34fae85acbbab3f2896
Require that method callers always provide relevant paths, instead of
relying on constructor. Move DisplayMetrics to be an overall parser
parameter, and move PARSE_TRUSTED_OVERLAY to flags.
Parse split APKs and apply deterministic ordering based on split
names. Assert consistent package name and version code across all
split APKs in a package, and enforce unique split names and required
base APK.
Collect certificates for split APKs, enforcing they're all signed
consistently. Better flow control and resource cleanup when
collecting certs. Refactor validation code so it's easier to reason
about. Cleaner maintenance of read buffer when draining stream
contents.
Change-Id: I8bc8c62095fbb933227b9e76ad8771f4b1246fe8
It previously kept mPath separate from mScanPath for some very odd
edge cases around moving apps-on-SD. This changes it to always use
a single path, refactors moving to keep separate paths.
Refactors method names in PackageParser to be clearer about their
APK-versus-package relationship.
Beginnings of a split package parser. Instead of requiring that
callers check error codes when null, switch to always throwing on
parse errors, to require that callers deal with the error. Longer
term the entire parser should switch to this style, but its too
pervasive for a simple refactoring.
Change-Id: If071d8e55e46e56cc201fadfb51cb471713ae973
The presence of ".bc" files in an APK implies
incompatibility with any of the 64 bit ABIs.
bug: 14900093
Change-Id: I66ca339a9a149cb3b7e7b349033d80acdeb4140a
This allows callers to force an install to a particular
ABI. This is intended only for testing (and CTS) and is
not meant for usage by the installer package.
Change-Id: Icb1528c0cd35b1aa9323386cb35ff4aaba374fcb
We now use a two step approach :
- First we look through the list of shared libraries in an
APK, and choose an ABI based on the (priority) list of ABIs
a given device supports.
- Then we look through the list of shared libraries and copy
all shared libraries that match the ABI we've selected.
This fixes a long-standing bug where we would sometimes copy
a mixture of different ABIs to the device, and also allows us
to clearly pick an ABI to run an app with.
The code in NativeLibraryHelper has been refactored so that all
file name validation & matching logic is done in a single place
(NativeLibrariesIterator). This allows us to avoid a lot of
redundant logic and straightens out a few corner cases (for eg.
where the abi determination & copying logic do not agree on
what files to skip).
bug: https://code.google.com/p/android/issues/detail?id=65053
bug: 13647418
Change-Id: I34d08353f24115b0f6b800a7eda3ac427fa25fef
Co-Authored-By: Zhenghua Wang <zhenghua.wang0923@gmail.com>
Co-Authored-By: Ramin Zaghi <ramin.zaghi@arm.com>
Co-Authored-By: Narayan Kamath <narayan@google.com>
When calculating directory sizes of data living on emulated external
storage, translate the path to use the internal backing data, which
avoids going through the emulation layer. It carefully retreats to
the original path when it runs into trouble.
Testing with a hierarchy of 10 directories deep and 2 directories
and 10 files wide at each level, this change improves performance
from 5900ms before to 250ms after; over 20 times faster (!).
Bug: 8172425
Change-Id: Ia7365416f091e102bf7345a49f7d7209a22580a9
Also fix a little problem where the USER_STARTED broadcasts
were not being sent as ordered broadcasts(!).
Change-Id: I3aa3e0a9b3900967cdd2d115ee103371b0a50c41
Try to get installd to free up cache before giving up when there is too
little space free.
Bug: 7232123
Change-Id: Ie3c8ca8dfc190abbb9a29a7baee31f32e9de7d69
Migrate networking, storage, battery, DropBox, and PackageManager
related Secure settings to Global table.
Bug: 7232014, 7231331, 7231198
Change-Id: I772c2a9586a2f708c9db95622477f235064b8f4d
When PackageManagerService deals with external storage, always bind
to DefaultContainerService as USER_OWNER. This avoids binding to a
stopped user, which would fail.
Bug: 7203111
Change-Id: I8e303c7558e8b5cbe4fea0acc9a472b598df0caa
This add a new per-user state for an app, indicating whether
it is installed for that user.
All system apps are always installed for all users (we still
use disable to "uninstall" them).
Now when you call into the package manager to install an app,
it will only install the app for that user unless you supply
a flag saying to install for all users. Only being installed
for the user is just the normal install state, but all other
users have marked in their state for that app that it is not
installed.
When you call the package manager APIs for information about
apps, uninstalled apps are treated as really being not visible
(somewhat more-so than disabled apps), unless you use the
GET_UNINSTALLED_PACKAGES flag.
If another user calls to install an app that is already installed,
just not for them, then the normal install process takes place
but in addition that user's installed state is toggled on.
The package manager will not send PACKAGE_ADDED, PACKAGE_REMOVED,
PACKAGE_REPLACED etc broadcasts to users who don't have a package
installed or not being involved in a change in the install state.
There are a few things that are not quite right with this -- for
example if you go through a full install (with a new apk) of an
app for one user who doesn't have it already installed, you will
still get the PACKAGED_REPLACED messages even though this is
technically the first install for your user. I'm not sure how
much of an issue this is.
When you call the existing API to uninstall an app, this toggles
the installed state of the app for that user to be off. Only if
that is the last user user that has the app uinstalled will it
actually be removed from the device. Again there is a new flag
you can pass in to force the app to be uninstalled for all users.
Also fixed issues with cleaning external storage of apps, which
was not dealing with multiple users. We now keep track of cleaning
each user for each package.
Change-Id: I00e66452b149defc08c5e0183fa673f532465ed5
The package manager calls to clear data / clear cache were not also
having default container service clear the data on external storage. Now
they do.
Change-Id: Ib5e5eb6adf2cac5a4cc094cc1a02ac8cfb6a2edf
Change the thread priority for all disk measurement and statfs calls to
background priority.
Also move the measurement fully into the measurement task since it makes
more sense.
Bug: 6332097
Change-Id: Iafc2151313ad9b14117daf67e933dccd32f68d54
Use long instead of int so we don't run into a 2GB file limit.
Fix possible overflows in offset and length.
Change-Id: Idb3a34f5600f9c2372b9c89256f21757049fa43b
On devices that had external storage, permissions weren't set correctly
on non-forward-locked applications. Also, moving forward locked
applications didn't work since DefaultContainerService wasn't able to
read it.
Fixed some faulty unit tests as well.
Bug: 6427212
Change-Id: I5c1f0bf5278549069c78939f0708c4c43a7d4006
We couldn't put forward-locked apps in ASEC containers before since we
didn't have any permissioned filesystems. This adds the ability for
forward-locked applications to be in ASEC containers.
This means that forward locked applications will be able to be on the SD
card now.
This change also removes the old type of forward-locking that placed
parts of apps in /data/app-private. Now all forward-locked applications
will be in ASEC containers.
Change-Id: I17ae0b0d65a4a965ef33c0ac2c47e990e55707ad
* Verifiers can be specified in the AndroidManifest.xml
* Those verifiers can respond to the new Intent action
* PackageManager API for those verifiers: verifyPendingInstall
Change-Id: I4892bce2e6984871e6e93c60a1ca0dae145f5df5
Unfortunately fixed internal size calculations for HC, but never the
external size calculations.
Bug: 5113898
Change-Id: Idfe8af0ba74a20aa767eb9abac431ee1c74dcf8e
Copy resource would fail without a good error code when the file
couldn't be found during copy.
Also destroy the target container ID during move operations since it
might exist. If the copy failed due to it existing, it would get
destroyed anyway. This way the user has a chance to have a good outcome
the first time.
Bug: 3375299
Bug: 5113898
Change-Id: I00559833f0801bc50e7cc031b462495e37a6b4ab
Make sure that files that don't exist aren't returning bogus 'out of
space' error codes.
Add some Javadoc so I can remember what each thing does in an IDE.
Add copyright header to NativeLibraryHelper
Bug: 3375299
Change-Id: Iac46019160921daca65b21d38897e5165063316e
The built-in ZipFile class was quite a long time to find an unpack
libraries. Move everything to using the libutils ZipFileRO class that
goes quite a bit faster. Initial measurements are 6 times faster than
the Java code.
Also, read files off the disk and compare their CRC against the APK's
CRC to see if we need to write the new file to disk. This also cuts down
the bootup time by up to a second per APK that has native files.
Change-Id: Ic464a7969a17368fb6a6b81d026888c4136c7603
OBB files on USB storage or SD card should be removed when an
application is removed.
Bug: 3356804
Change-Id: Ifbbf043368b125fcd47fd74e5cd2e5167a8deb00
