drgreen/android_frameworks_base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
android_frameworks_base/packages/DefaultContainerService/AndroidManifest.xml

27 lines
1.4 KiB
XML
Raw Normal View History

AppsOnSd feature - Add default container 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.
2010-01-25 12:19:12 -08:00
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
Add boot mode where only "core apps" are started. 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
2011-09-12 12:29:43 -07:00
package="com.android.defcontainer" coreApp="true">
Clear identity to handle ALLOCATE_AGGRESSIVE. 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
2017-04-14 16:28:59 -06:00
<uses-permission android:name="android.permission.ALLOCATE_AGGRESSIVE"/>
Add asec permission to DefaultContainerService
2010-01-27 15:02:41 -08:00
<uses-permission android:name="android.permission.ASEC_ACCESS"/>
<uses-permission android:name="android.permission.ASEC_CREATE"/>
<uses-permission android:name="android.permission.ASEC_DESTROY"/>
<uses-permission android:name="android.permission.ASEC_MOUNT_UNMOUNT"/>
New external storage APIs. 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.
2010-02-04 17:38:14 -08:00
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
Permission to view shared storage for all users. 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
2015-07-06 09:45:55 -07:00
<!-- Used to improve MeasureUtils performance on emulated storage, and to
view storage for all users -->
Improve performance of storage measurement. 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
2013-03-01 16:12:55 -08:00
<uses-permission android:name="android.permission.WRITE_MEDIA_STORAGE" />
Include install location preference when installing packages. 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.
2010-02-12 09:43:29 -08:00
<uses-permission android:name="android.permission.ACCESS_CACHE_FILESYSTEM" />
Give DCS permission needed to measure all users. DCS runs as owner user, but needs to measure details for other users on the device. Bug: 22503636 Change-Id: I6d6899fae90c4e92b94647676bda8b88bad412e6
2015-07-15 09:58:22 -07:00
<uses-permission android:name="android.permission.INTERACT_ACROSS_USERS" />
AppsOnSd feature - Add default container 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.
2010-01-25 12:19:12 -08:00
Support full-backup encryption and global backup password 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
2011-07-19 16:32:49 -07:00
<application android:label="@string/service_name"
More file-based encryption work. 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
2015-11-08 16:46:05 -08:00
android:allowBackup="false"
Refactoring FBE APIs based on council feedback. 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
2016-03-16 16:25:45 -06:00
android:defaultToDeviceProtectedStorage="true"
android:directBootAware="true">
AppsOnSd feature - Add default container 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.
2010-01-25 12:19:12 -08:00
<service android:name=".DefaultContainerService"
android:enabled="true"
android:exported="true"
android:permission="android.permission.COPY_PROTECTED_DATA"/>
</application>
</manifest>
Reference in New Issue Copy Permalink