summaryrefslogtreecommitdiffstats
path: root/tests/backup/AndroidManifest.xml
Commit message (Collapse)AuthorAgeFilesLines
* Remove BACKUP_DATA permission and associated checksChristopher Tate2010-02-121-1/+0
| | | | | | | | Any package can now participate in backup/restore, without requiring any manifest-declared permission. *Control* of the backup manager is still guarded by the BACKUP permission, which is signatureOrSystem. Change-Id: I116fcfcd4cd255e3c976330da1c4dea7d4faae9d
* Backup participants must now hold the BACKUP_DATA permissionChristopher Tate2009-08-131-0/+1
| | | | | | | | Packages that do not use android.permission.BACKUP_DATA will neither be backed up nor restored. That permission is currently signature-only. In the future if access to the backup/restore infrastructure is made available to arbitrary 3rd party applications, the permission checks (and indeed, the permission itself) can simply be removed.
* Retool the backup process to use a new 'BackupAgent' classChristopher Tate2009-05-311-6/+1
| | | | | | | | | | | | | | | Backups will be handled by launching the application in a special mode under which no activities or services will be started, only the BackupAgent subclass named in the app's android:backupAgent manifest property. This takes the place of the BackupService class used earlier during development. In the cases of *full* backup or restore, an application that does not supply its own BackupAgent will be launched in a restricted manner; in particular, it will be using the default Application class rather than any manifest-declared one. This ensures that the app is not running any code that may try to manipulate its data while the backup system reads/writes its data set.
* More backup testsJoe Onorato2009-05-071-1/+1
|
* Add a test app for the backupJoe Onorato2009-05-051-0/+17