| Age | Commit message (Collapse) | Author |
|---|
|
Pre-req for running tests marked with (*): adb shell setprop vold.has_adoptable 1
Bug: 111838160
Test: builds and flashes
*Test: atest cts.AdoptableHostTest
*Test: atest cts.StorageHostTest
Change-Id: Iaa376a6bc984cc449239b7fe54a4a2708ad05a72
|
|
DCS had been relying on the WRITE_MEDIA_STORAGE permission to access
OBBs on external storage, but that permission has been locked down,
and we need to use the real WRITE_EXTERNAL_STORAGE permission now.
Rework the OBB error reporting flow to bubble exact error codes up
from internals, so that we can return expected CTS error codes.
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.storage.cts.StorageManagerTest
Bug: 73424392
Change-Id: Iecbc4132745d56ebf081868ad2f9c3efe1e3735f
|
|
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
|
|
Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
|
|
Add granular StorageManager APIs for key creation/destruction and
unlocking/locking. Start passing through an opaque token as part
of the unlock command, but leave it empty for now. We now have a
separate "prepare" method that sanity checks that user directories
are correctly setup.
Define a handful of system properties used for marking devices that
should be operating in FBE mode, and if they're emulating FBE. Wire
a command to "sm", but persisting will come later.
Start using new "encryptionAware" flag on apps previously marked with
coreApp flag, which were apps running in the legacy CryptKeeper
model. Small tweaks to handle non-encryptionAware voice interaction
services. Switch PackageManager to consult StorageManager about the
unlocked state of a user.
Bug: 22358539
Change-Id: Ic2865f9b81c10ea39369c441422f7427a3c3c3d6
|
|
DCS runs as owner user, but needs to measure details for other users
on the device.
Bug: 22503636
Change-Id: I6d6899fae90c4e92b94647676bda8b88bad412e6
|
|
Typical apps are restricted so they can only view shared storage
belonging to the user they're running as. However, a handful of
system components need access to shared storage across all users,
such as DefaultContainerService and SystemUI.
Since WRITE_MEDIA_STORAGE already offers this functionality by
bypassing any FUSE emulation, reuse it to grant the "sdcard_rw" GID
which is no longer handed out to third-party apps. Then we change
the FUSE daemon to allow the "sdcard_rw" GID to see shared storage
of all users.
Bug: 19995822
Change-Id: I504c2a179ba74f142ed0d32da5baa69f4212cd82
|
|
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
|
|
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
|
|
* commit '768d9e1a72ceee7d4a5f608776b87b62d6ce4a04':
Correct executable bit for source files
|
|
Many media files and source code files were marked as executable in Git.
Remove those.
Also a shell script and python script were not marked as executable.
Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
|
|
Now we can bind to just one instance of DCS, instead of requiring
one-per-user. This also means we can operate on otherwise-stopped
users.
Bug: 7003520
Change-Id: I4881e064ae8942907f6a02c6b868926223455cdc
|
|
A core app is one that has coreApp="true" in its manifest tag.
The system can successfully boot (though a little painfully) with
only framework-res.apk, SettingsProvider.apk, SystemUI.apk,
DefaultContainerService.apk, and Launcher2.apk set as core apps.
Currently this boot mode is always turned off.
Change-Id: Ieaa4a8031c2c391a12996aa8d8b1d65fc2b09d6b
|
|
If the user has supplied a backup password in Settings, that password
is validated during the full backup process and is used as an encryption
key for encoding the backed-up data itself. This is the fundamental
mechanism whereby users can secure their data even against malicious
parties getting physical unlocked access to their device.
Technically the user-supplied password is not used as the encryption
key for the backed-up data itself. What is actually done is that a
random key is generated to use as the raw encryption key. THAT key,
in turn, is encrypted with the user-supplied password (after random
salting and key expansion with PBKDF2). The encrypted master key
and a checksum are stored in the backup header. At restore time,
the user supplies their password, which allows the system to decrypt
the master key, which in turn allows the decryption of the backup
data itself.
The checksum is part of the archive in order to permit validation
of the user-supplied password. The checksum is the result of running
the user-supplied password through PBKDF2 with a randomly selected
salt. At restore time, the proposed password is run through PBKDF2
with the salt described by the archive header. If the result does
not match the archive's stated checksum, then the user has supplied
the wrong decryption password.
Also, suppress backup consideration for a few packages whose
data is either nonexistent or inapplicable across devices or
factory reset operations.
Bug 4901637
Change-Id: Id0cc9d0fdfc046602b129f273d48e23b7a14df36
|
|
Be compatible with the old DownloadProvider behavior of being able to
operate on content URIs returned from .insert()
Bug: 3242328
Change-Id: I7dad15ac0fefa867c3c8a33a579fc9899ac80262
|
|
Changes include
Add new remote call in default container service to determine
install location.
Rename INSTALL_ON_SDCARD
Remove recommentAppInstall method
Add some additional flags used in remote stubs.
Move check for protected apps prior to copy.
Unit tests
DefaultContainerService first parses the file uri(if content uri is specified
it returns a default install internal only value) and returns
a recommended location. Based on which the temporary id is determined
either a file name or a container id and the file is copied there.
This is then later renamed during install.
Todo's light weight parsing of package when determining location since we
just need the install location attribute only when finding out
recomended location. This will also enable to move the check for
updated system apps(cannot be on sdcard) prior to copying.
|
|
This implements the spec for external storage organization, and
properly reflects how the media scanner organizes the files it finds.
Also includes package manager support for removing app private
files from external storage when the application is uninstalled.
For the new APIs and paths, the main place to look is Environment
and Context.
|
|
|
|
Add new remote interface to do temporary copies. The new
remote stub handling is done on mHandler thread and doesn't need locking
for now.
Add new InstallArgs class and subclasses to isolate cases for installation.
Move resource deletion for failed installs/upgrades to later on in installation
cycle.
Fix code path for forward locked apps when using scanPackageLI
TODO's
Fix installation paths to completely use InstallArgs based design later on.
Get rid of using flags in various install/uninstall code paths.
Ideally InstallArgs should be created using these flags and used in the
rest of the code.
Function renames.
Revisit mount api's.
|