• Home
  • History
  • Annotate
  • only in /frameworks/base/packages/BackupRestoreConfirmation/
History log of /frameworks/base/packages/BackupRestoreConfirmation/
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
e2e24f8dd7dc43738d09365bcf61f3e458af05d2 13-Jul-2012 Ying Wang <wangying@google.com> Import translations. DO NOT MERGE

Change-Id: Iabb056f645a910f3fbaea1e51348c3bef385546e
Auto-generated-cl: translation import
es/values-fa/strings.xml
a23b343299783e5990370579cfc7d93e62dacb8d 13-Apr-2012 Christopher Tate <ctate@google.com> Fix full backup/restore detection of encrypted devices

The confirmation UI did not request the needed permission, so was failing
to communicate with the mount service; as a "safe" failure mode, it was
assuming the device was encrypted. Fixed; now it presents the correct
prompt text for the device's encryption state.

Bug 5958195

Change-Id: Ic03db16673b89d3377e0362a09cf51bfb572d78b
ndroidManifest.xml
rc/com/android/backupconfirm/BackupRestoreConfirmation.java
4a97ebfec5ff24fd34cdb354f0e85ca1279035f8 29-Nov-2011 Eric Fischer <enf@google.com> Import revised translations.

Change-Id: Ie43246df49b8f6ef3daef12e0d8fb5c2f573874e
es/values-af/strings.xml
es/values-zu/strings.xml
2fbd56a652f29e7a54f7aaab25ea031a1f8decb0 02-Nov-2011 Eric Fischer <enf@google.com> Import revised translations.

Change-Id: I71efb16f2c6b257dfd444728c7e56ada662e6f77
es/values-be/strings.xml
es/values-et/strings.xml
es/values-sw/strings.xml
0af56a5d4c7f60326c4efb86bf25d12c956d9586 25-Oct-2011 Eric Fischer <enf@google.com> Import revised translations.

Change-Id: I5db0a5df334833af2e2109123d05a9f76c745cf6
es/values-bg/strings.xml
es/values-de/strings.xml
es/values-es-rUS/strings.xml
es/values-hr/strings.xml
es/values-in/strings.xml
es/values-ja/strings.xml
es/values-nb/strings.xml
es/values-ro/strings.xml
es/values-ru/strings.xml
b0d150aa53ad34ea0a5b0da74bbdeb9ecd5a46b7 19-Oct-2011 Eric Fischer <enf@google.com> Import revised translations.

Change-Id: I83ab00ec220b7c0ba0d37e7f4c91e945e35aab39
es/values-af/strings.xml
es/values-am/strings.xml
es/values-ar/strings.xml
es/values-bg/strings.xml
es/values-ca/strings.xml
es/values-cs/strings.xml
es/values-da/strings.xml
es/values-de/strings.xml
es/values-el/strings.xml
es/values-en-rGB/strings.xml
es/values-es-rUS/strings.xml
es/values-es/strings.xml
es/values-fa/strings.xml
es/values-fi/strings.xml
es/values-fr/strings.xml
es/values-hi/strings.xml
es/values-hr/strings.xml
es/values-hu/strings.xml
es/values-in/strings.xml
es/values-it/strings.xml
es/values-iw/strings.xml
es/values-ja/strings.xml
es/values-ko/strings.xml
es/values-lt/strings.xml
es/values-lv/strings.xml
es/values-ms/strings.xml
es/values-nb/strings.xml
es/values-nl/strings.xml
es/values-pl/strings.xml
es/values-pt-rPT/strings.xml
es/values-pt/strings.xml
es/values-ro/strings.xml
es/values-ru/strings.xml
es/values-sk/strings.xml
es/values-sl/strings.xml
es/values-sr/strings.xml
es/values-sv/strings.xml
es/values-sw/strings.xml
es/values-th/strings.xml
es/values-tl/strings.xml
es/values-tr/strings.xml
es/values-uk/strings.xml
es/values-vi/strings.xml
es/values-zh-rCN/strings.xml
es/values-zh-rTW/strings.xml
es/values-zu/strings.xml
32418be49e5b61c2e9281528cb8fb67939e301e8 10-Oct-2011 Christopher Tate <ctate@google.com> Require device encryption password to perform adb backup/restore

This supersedes any backup-password that the user might supply. Per
design, the device encryption password is also always used to encrypt
the backup archive.

The CL introduces two new strings, used for prompting the user for
their device encryption password rather than their settings-defined
"backup password" when confirming a full backup or restore operation.

Bug 5382487

Change-Id: I0b03881b45437c944eaf636b6209278e1bba7a9f
es/values/strings.xml
rc/com/android/backupconfirm/BackupRestoreConfirmation.java
03e9d8ae0759289f4474227382caa898f398c636 08-Oct-2011 Eric Fischer <enf@google.com> Import revised translations.

Change-Id: Id046f8008aef32a1b94b4fa5b57e2beb2f9f2e80
es/values-es-rUS/strings.xml
es/values-it/strings.xml
es/values-sl/strings.xml
d3530ac774028c8d71c7ffb49033100d10056623 01-Oct-2011 Eric Fischer <enf@google.com> Import revised translations.

Change-Id: Ic8e228878fde375b90797c6e344fcb3114180f1d
es/values-am/strings.xml
es/values-ar/strings.xml
es/values-bg/strings.xml
es/values-cs/strings.xml
es/values-da/strings.xml
es/values-de/strings.xml
es/values-el/strings.xml
es/values-es-rUS/strings.xml
es/values-es/strings.xml
es/values-fa/strings.xml
es/values-fi/strings.xml
es/values-fr/strings.xml
es/values-hr/strings.xml
es/values-hu/strings.xml
es/values-in/strings.xml
es/values-iw/strings.xml
es/values-ja/strings.xml
es/values-ko/strings.xml
es/values-lt/strings.xml
es/values-lv/strings.xml
es/values-ms/strings.xml
es/values-nb/strings.xml
es/values-nl/strings.xml
es/values-pl/strings.xml
es/values-pt-rPT/strings.xml
es/values-pt/strings.xml
es/values-ro/strings.xml
es/values-ru/strings.xml
es/values-sk/strings.xml
es/values-sl/strings.xml
es/values-sr/strings.xml
es/values-sv/strings.xml
es/values-sw/strings.xml
es/values-th/strings.xml
es/values-tl/strings.xml
es/values-tr/strings.xml
es/values-uk/strings.xml
es/values-vi/strings.xml
es/values-zh-rCN/strings.xml
es/values-zh-rTW/strings.xml
es/values-zu/strings.xml
50c83888a6d1ef1ba2515e3f20bbc740c6cd1efa 20-Sep-2011 Eric Fischer <enf@google.com> Import revised translations.

Change-Id: I5e375bebc8f74d9108a929246f16608427ce9317
es/values-af/strings.xml
es/values-am/strings.xml
es/values-ar/strings.xml
es/values-bg/strings.xml
es/values-ca/strings.xml
es/values-cs/strings.xml
es/values-da/strings.xml
es/values-de/strings.xml
es/values-el/strings.xml
es/values-en-rGB/strings.xml
es/values-es-rUS/strings.xml
es/values-es/strings.xml
es/values-fa/strings.xml
es/values-fi/strings.xml
es/values-fr/strings.xml
es/values-hr/strings.xml
es/values-hu/strings.xml
es/values-in/strings.xml
es/values-it/strings.xml
es/values-iw/strings.xml
es/values-ja/strings.xml
es/values-ko/strings.xml
es/values-lt/strings.xml
es/values-lv/strings.xml
es/values-ms/strings.xml
es/values-nb/strings.xml
es/values-nl/strings.xml
es/values-pl/strings.xml
es/values-pt-rPT/strings.xml
es/values-pt/strings.xml
es/values-ro/strings.xml
es/values-ru/strings.xml
es/values-sk/strings.xml
es/values-sl/strings.xml
es/values-sr/strings.xml
es/values-sv/strings.xml
es/values-sw/strings.xml
es/values-th/strings.xml
es/values-tl/strings.xml
es/values-tr/strings.xml
es/values-uk/strings.xml
es/values-vi/strings.xml
es/values-zh-rCN/strings.xml
es/values-zh-rTW/strings.xml
es/values-zu/strings.xml
28b591c2a416d7f5955371970272bcaa2b1b303e 15-Sep-2011 Christopher Tate <ctate@google.com> Use string resources instead of inline literals for progress toasts

...in the full backup/restore confirmation UI.

Change-Id: I858a2d7017450f016afe5052aa37161a1c89c281
es/values/strings.xml
rc/com/android/backupconfirm/BackupRestoreConfirmation.java
c58cf7dd02ad227a68d62a0204152cee62c13182 14-Sep-2011 Christopher Tate <ctate@google.com> Give backup/restore confirmation a proper window title

Since the confirmation uses the same Activity but different layouts
for the backup vs restore cases, we have to do the title in code.

Along the way, fix the restore layout's padding [the backup layout
was already right].

Fixes bug 5164470

Change-Id: I4d636f666d97fc377e9cf36abf08d1625a05577f
ndroidManifest.xml
es/layout/confirm_restore.xml
es/values/strings.xml
rc/com/android/backupconfirm/BackupRestoreConfirmation.java
78cc91aa7d68f63bdfb3f1a61123f34df5a9ef4b 12-Sep-2011 Eric Fischer <enf@google.com> Import revised translations.

Change-Id: I6e7f33ff16557f7e9088c0aa66fd1c79ed376c75
es/values-ms/strings.xml
5820aeee0b101843445050f594dad82c7dde4b81 02-Sep-2011 Eric Fischer <enf@google.com> Import revised translations.

Change-Id: Iac73006cfaf846d210855496f6732cbdc6ad0de8
es/values-es/strings.xml
es/values-ro/strings.xml
es/values-th/strings.xml
es/values-zh-rTW/strings.xml
6a5134397541af058e1128baebe0451ae4befce8 26-Aug-2011 Eric Fischer <enf@google.com> Import revised translations.

Change-Id: I51e1fc94b7fa3fec13f7dddad62b978dd9a71d43
es/values-af/strings.xml
es/values-am/strings.xml
es/values-ar/strings.xml
es/values-bg/strings.xml
es/values-ca/strings.xml
es/values-cs/strings.xml
es/values-da/strings.xml
es/values-de/strings.xml
es/values-el/strings.xml
es/values-es-rUS/strings.xml
es/values-es/strings.xml
es/values-fa/strings.xml
es/values-fi/strings.xml
es/values-fr/strings.xml
es/values-hr/strings.xml
es/values-hu/strings.xml
es/values-in/strings.xml
es/values-iw/strings.xml
es/values-ja/strings.xml
es/values-ko/strings.xml
es/values-lt/strings.xml
es/values-lv/strings.xml
es/values-nb/strings.xml
es/values-nl/strings.xml
es/values-pt-rPT/strings.xml
es/values-pt/strings.xml
es/values-ro/strings.xml
es/values-ru/strings.xml
es/values-sk/strings.xml
es/values-sl/strings.xml
es/values-sr/strings.xml
es/values-sv/strings.xml
es/values-sw/strings.xml
es/values-th/strings.xml
es/values-tl/strings.xml
es/values-tr/strings.xml
es/values-uk/strings.xml
es/values-vi/strings.xml
es/values-zh-rCN/strings.xml
es/values-zh-rTW/strings.xml
es/values-zu/strings.xml
8da527d8435beda54b83e117c718c5d145c94ecd 22-Aug-2011 Eric Fischer <enf@google.com> Import revised translations.

Change-Id: I51335fa15a40d471010dbcc96e228b170f06ce7e
es/values-en-rGB/strings.xml
es/values-es-rUS/strings.xml
es/values-it/strings.xml
es/values-ms/strings.xml
es/values-pl/strings.xml
3851fa9c8d180ca636e69b25f84fdcc294150009 05-Aug-2011 Christopher Tate <ctate@google.com> Handle rotation gracefully in the backup/restore confirmation UI

We now don't automatically deny the operation if stopped, but instead
allow the activity to be destroyed and recreated as usual. We retain
the observer instance across that sequence so we keep getting progress
reports etc.

The UI now also uses the spiffy new button bar styles, and positions
the deny / confirm buttons according to ICS standards.

Bug 5115411

Change-Id: Ie760a0c8496c69f9d5881273a63ad5b5b76ff554
es/layout/confirm_backup.xml
es/layout/confirm_restore.xml
rc/com/android/backupconfirm/BackupRestoreConfirmation.java
31deacf6f59be3633a4bcdb9359b2f9f750de527 04-Aug-2011 Christopher Tate <ctate@google.com> Make backup/restore confirmation UI landscape-friendly

Now the textual content and password fields are placed in scroll view,
and the confirm/deny buttons pinned at the bottom of the layout.
Previously, in landscape mode on some devices the buttons would be
pushed off screen.

Bug 5115411

Change-Id: I8bf8fd1516735bf6111893df79636b519dbfb803
es/layout/confirm_backup.xml
es/layout/confirm_restore.xml
728a1c4d5ed3b808172013a7f5bb5065d1e964f6 29-Jul-2011 Christopher Tate <ctate@google.com> Require the current backup pw in all backup/restore operations

Specifically, we now also require the current password to confirm any
restore operation.

Bug 4901637

Change-Id: I39ecce7837f70cd05778cb7e0e6390ad8f6fe3f3
es/layout/confirm_backup.xml
es/layout/confirm_restore.xml
es/values/strings.xml
rc/com/android/backupconfirm/BackupRestoreConfirmation.java
2efd2dbbac9eac89620683696c6076463c3a1cd6 20-Jul-2011 Christopher Tate <ctate@google.com> 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
es/layout/confirm_backup.xml
es/layout/confirm_restore.xml
es/values/strings.xml
rc/com/android/backupconfirm/BackupRestoreConfirmation.java
ec5d4a0f9765f1645ab2e28ad2ef3cad247a042b 08-Jun-2011 Christopher Tate <ctate@google.com> Don't ack/nak backup redundantly at exit

Change-Id: I7293518bc2fe6c66270a7c8aea3bf0c0829754e4
rc/com/android/backupconfirm/BackupRestoreConfirmation.java
a858cb075d0c87e2965d401656ff2d5bc16406da 03-Jun-2011 Christopher Tate <ctate@google.com> Respect android:allowBackup="false" during full backup & restore

Packages with this manifest attribute set 'false' will not be backed
up even through the "full device backup" infrastructure. If someone
produces an apparent restore file with data for such an application,
it will not actually be restored onto the device.

When an apk is installed during the course of a restore operation,
it is validated against the manifest contents and deleted if there
is a mismatch. Also, if the newly-installed app is found to
disallow backups, no file content will be processed for that app.

Bug 4532159

Change-Id: I59630054584b1394e567de939192e22e597044ee
ndroidManifest.xml
e42a6058d43742fb0b51568ff6bd42f75bd34201 02-Jun-2011 Christopher Tate <ctate@google.com> Filter backup/restore confirmation buttons when obscured

I.e. don't let people fake the user out by putting some other UI over
the top of it in order to phish for a confirmation.

Addresses bug 4521629

Change-Id: I40ae057ebedeb92ed264fb52fa1c7c297c9d3ec2
es/layout/confirm_backup.xml
es/layout/confirm_restore.xml
75a99709accef8cf221fd436d646727e7c8dd1f1 19-May-2011 Christopher Tate <ctate@google.com> Restore from a previous full backup's tarfile

Usage: adb restore [tarfilename]

Restores app data [and installs the apps if necessary from the backup
file] captured in a previous invocation of 'adb backup'. The user
must explicitly acknowledge the action on-device before it is allowed
to proceed; this prevents any "invisible" pushes of content from the
host to the device.

Known issues:

* The settings databases and wallpaper are saved/restored, but lots
of other system state is not yet captured in the full backup. This
means that for practical purposes this is usable for 3rd party
apps at present but not for full-system cloning/imaging.

Change-Id: I0c748b645845e7c9178e30bf142857861a64efd3
rc/com/android/backupconfirm/BackupRestoreConfirmation.java
dc92c82b4180e8067f1acd00a7db7935afce00ff 14-May-2011 Christopher Tate <ctate@google.com> Full backup tweaks

* provide placeholder UI showing backup/restore start/stop/timeout
* don't kill the progress UI in mid stream
* tidy up the pax extended header data writing a little

Change-Id: Ife0cb78e3facb541d8327f1d5ca5fe77faa6cbca
rc/com/android/backupconfirm/BackupRestoreConfirmation.java
4a627c71ff53a4fca1f961f4b1dcc0461df18a06 01-Apr-2011 Christopher Tate <ctate@google.com> Full local backup infrastructure

This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:

1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.

2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.

3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.

4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.

5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.

The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.

The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.

Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:

apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.

For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.

The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:

shared/...

uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.

Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.

System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.

When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.

(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.

(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.

KNOWN ISSUES:

* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.

Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
ndroid.mk
ndroidManifest.xml
es/layout/confirm_backup.xml
es/layout/confirm_restore.xml
es/values/strings.xml
rc/com/android/backupconfirm/BackupRestoreConfirmation.java