Switching activity stacks
Cache ContentProvider per user
Long-press power to switch users (on phone)
Added ServiceMap for separating services by user
Launch PendingIntents on the correct user's uid
Fix task switching from Recents list
AppWidgetService is mostly working.
Commands added to pm and am to allow creating and switching profiles.
Change-Id: I15810e8cfbe50a04bd3323a7ef5a8ff4230870ed
The special shared-storage step was mistakenly writing its data directly
to the USB output pipe rather than to the proper stacked data handling
chain that applies compression and encryption. Fix this by getting rid
of the custom handling of the shared-storage data, instead folding it
into the normal data handling flow [with a small amount of additional
management because e.g. it doesn't need a "manifest" pseudofile in the
archive stream].
Fixes bug 5897791
Change-Id: I3995b07963334d2f8cce49b247c87d3d3ff93bed
Plug a couple of apparent code paths (one not obviously reachable, but
fixed here on general principles) that could lead to a backup pass
getting confused partway through and simply never properly completing.
In this state it would leave its wakelock held forever until next
reboot. Bug 5828859.
Those fixes are a total of two lines of code. The rest of the patch
adds a textual journal of the most recently completed (or ongoing!)
backup pass's progress, with an eye to being able to isolate any such
issues that may crop up in the future.
Change-Id: If8a5e8aba11db5a1e618d8b9c9ba3038dd5377a1
In particular, don't do O(asec_apps * installed_apps) work during the
broadcast receiver's operation. On devices with many installed apps
and a large number of them moved to ASECs, this was causing the system
process to become unresponsive and the watchdog to fire -- which in turn
would initiate a restart loop, as the same package-installed broadcast
would then be issued again once the package manager rescanned the ASEC
containers, ad infinitum. With this change, the expensive call to the
package manager is only made once rather than asec_apps times.
Bug 5850283
Change-Id: I14e280ea1fa6af19cebc58869a20fbb599c92c8c
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
Although it's typical for a backup transport to report that it
needs an explicit initialization opportunity when the backup is
initiated, it can sometimes come to pass that the "needs init"
error condition is reported at backup *finish*. In this case the
framework side was failing to properly reset all of the relevant
state. The end result was to spin hard forever, holding wakelocks
and continually failing to actually perform the necessary init
operation, possibly continuing even after a reboot. Fixed.
Bug 5434579
Change-Id: If1d72c338526e4019ea524c48a11e71e44e77f71
We've seen cases (bug 5417779) where the transport kicked off an immediate
backup operation but then was perfectly content to allow the periodic
timer to start *another* pass concurrently while the first was still in
progress. This wound up with the backup manager getting mightily
confused and leaking wakelock acquisitions, which is Very Bad(tm).
This patch adds a little bookkeeping so that the backup manager is aware
of backups in flight, and refuses to kick off a new one until the ongoing
one has finished.
Change-Id: If12b54f4db3effc8af36d31c58d8f9b415ddc01e
This makes it easy to back up everything that belongs to 3rd party apps, but
nothing that comes with the system per se. If any system packages are
explicitly named on the command line they will be included in the backup
even if -nosystem was passed. So, for example, this will back up all 3rd
party apps as well as system settings, but nothing else belonging to
system-deployed apps:
adb backup -all -nosystem com.android.provider.settings
Bug 5361503
Change-Id: Iebe04b7d7027ca58b9f55e8eb7f219d6cca69269
The text of the dumped output can potentially include an email address;
we don't want random code to be able to read it.
Bug 5389201
Change-Id: If84886357a36b7015878e4d72017abba83b4c511
Casualty of the recent refactoring: in this particular error case,
the restore sequence wasn't being directed into the finalization
state. Fixes bug 5336295.
Change-Id: Ibf5570cd1003e123da8b561685de8479663340ce
On the restore side, there's a bunch of one-time setup, device
provisioning, etc that we're very much not prepared to do in
lieu of running setup wizard, at least at this time.
On the backup side, it simply doesn't make sense to back up
stuff before the device has been set up.
Part of bug 5290261
Change-Id: If1c65e88e2da589d6204232d2b59c3e994f4ed3f
Running full backup/restore on the Backup Manager looper thread causes problems.
It not only interfered with the delayed-Message timeout processing; in the case
of installing apks during restore it also interfered fatally with the interaction
between the Package Manager and install-time restore of data from the cloud.
The long-term right thing to do here will be a refactoring of full backup and
restore to be structured as the sort of state-machine process that incremental
backup and restore now use. This is particularly thorny in the case of full
restore (due to the Package Manager interactions), and full backup/restore are
considered experimental at this point, so that refactoring is deferred to a
future release. The current process is essentially standalone, so the bug is
fixed here pro tem by letting it run to completion on its own thread, freeing
the looper for normal work.
Fixes bug 5173450
Change-Id: I659a61afa18ffe7fde1a07f7fa0e860d5e8d5a89
This patch parallels the previous one that fixed backup timeouts.
It establishes the same sort of state-machine process for walking
through the restore steps solely as events posted to the backup
manager's HandlerThread.
Fixes the rest of bug 5074923
Change-Id: I122a021cb1e9bb1342de0b71e5d4bc84cc630c58
Away in the misty span of very-long-ago, it was suggested that spinning
a separate thread to run the backup process was wasteful, and that it
could just run it inline on the dedicated HandlerThread that the
backup manager uses for its own operations. That was indeed true,
except that the timeout management was also using delayed messages
to that handler. You see where this is going: timeouts were never
actually being processed, with the effect that a badly-behaving
app's backup agent could lock up the entire backup / restore system
until the device was rebooted.
This is bad.
Backup operations are now driven as an asynchronous state machine:
each step (init, call one agent to obtain data, send resulting
data to the transport, finalize the backup) is handled as a formal
state transition on-looper. No synchronous wait-for-completion
or -timeout is performed on any thread.
As an additional effect this greatly tightens up the serialization
and locking semantics. We no longer have to worry about an in-
flight operation involving a standalone thread spinning off on
its own; everything is on the HandlerThread and can be coherently
manipulated from that perspective.
Along the way, this CL tightens up the per-agent error handling
logic. Previously a single failed agent would abort the entire
backup process, tantamount to a transport-level failure. This could
mean that the aforesaid badly-behaving app's agent could in effect
starve out other apps whose agents were routinely showing up later
in the queue. There's some nondeterminism involved, but in practice
it could and did happen. Furthermore, the failure case would
reschedule *immediately* in this case, because the transport itself
would see that all is well and sure, why not run a backup soon?
This, as you might imagine, causes battery-life issues.
Now we note that the single agent has failed, mark it for a future
repeat attempt, and process the rest of the queue normally, pretending
success at the transport level even though we didn't actually send
any data for that app. This means that (a) we now finish running
backups for everything in the queue, (b) reschedule backups only for
those apps whose agents individually failed during this run, and
(c) perform the retry after the normal interval [typically on the
order of an hour] rather than immediately.
NOTE: this CL does not retool the restore code path, just backup.
Restore is similarly vulnerable to misbehaving apps, though, so a
future CL will address that bug vector.
Addresses bug 5074923
Change-Id: I67e3f8d06f322607881eaa4093de6d675b85ff2c
Certain kinds of application update generate this broadcast regime rather
than the REMOVE / ADD sequence that results from e.g. using the -r option
when invoking 'adb install'.
We also push the agent classname lookup to the last moment before
actually running the backup, rather than caching it as part of the
record of what apps need a backup pass in the future. This was causing
a bug in which a package reinstall that renamed the app's agent class
would wind up with a crash at backup time, trying to load the wrong
class.
Fixes bug 5156094 / bug 4308977
Change-Id: I4e3e12d86e6ee40809f14fd12ab762116dbee0b5
...by once and for all making all of the code deal appropriately with
expected partial reads. We also now produce a properly conformant
underlying 'tar' EOF sequence [which will be compressed to almost
nothing] to doubly bulletproof the end-of-archive logic.
Fixes bug 5133658
Change-Id: I24a785574861d64ef10fc727b9f6b235575696b0
There was a hole where if no backup pw was supplied and the current
pw authentication field was also left blank, it wound up not verifying
and just proceeding with the backup.
Change-Id: I857d8e83cbb2b3bf6b6b04848c5696ef0cf393a1
The old version of this code would silently truncate odd-length
Signatures. However, this masks some bugs. Add a throw of
IllegalArgumentException so users can easily see where they're getting
bad input for Signatures.
Also, go through the existing code and catch this exception or
pre-check the input strings so system_server doesn't crash later.
Bug: 5092338
Change-Id: I8c672c5eaeb738a92c4581ce0df09baf719980ef
Specifically, we now also require the current password to confirm any
restore operation.
Bug 4901637
Change-Id: I39ecce7837f70cd05778cb7e0e6390ad8f6fe3f3
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
The backup format now includes a stream header. That header begins with
a magic string and version number, then includes a flag stating whether
the archive data is compressed, and then in the case of encrypted archives
states the password salt used during encryption key stretching.
When compression is used, everything following the header is run through
a standard zlib "deflate" compressor before being sent downstream.
Change-Id: Ica72753e4ef2c3d13e63b45e7722a00652940a55
Zlib compression, with a full flush between each application's
data. Encryption will be performed on the already-compressed data
once that's implemented.
On restore, the streamed data is similarly uncompressed on the fly.
Change-Id: I19b65c88e759a66527d10913d18fffa9df0bc011
Adds the ability to filter a restore of an historical dataset so that it
only restores certain apps' data regardless of what is actually present
in the dataset. This is currently only used by the bmgr command-line tool,
for debugging / developer support.
Bug 2021590
Change-Id: I7685e5d609b0f5506f71d70c26410602bb387659
New methods for full backup/restore have been added to BackupAgent
(still hidden): onFullBackup() and onRestoreFile(). The former is the
entry point for a full app backup to adb/socket/etc: the app then writes
all of its files, entire, to the output. During restore, the latter
new callback is invoked, once for each file being restored.
The full backup/restore interface does not use the previously-defined
BackupDataInput / BackupDataOutput classes, because those classes
provide an API designed for incremental key/value data structuring.
Instead, a new FullBackupDataOutput class has been introduced, through
which we restrict apps' abilities to write data during a full backup
operation to *only* writing entire on-disk files via a new BackupAgent
method called fullBackupFile().
"FullBackupAgent" exists now solely as a concrete shell class that
can be instantiated in the case of apps that do not have their own
BackupAgent implementations.
Along with the API change, responsibility for backing up the .apk
file and OBB container has been moved into the framework rather than
have the application side of the transaction do it.
Change-Id: I12849b06b1a6e4c44d080587c1e9828a52b70dae
Don't emit tar blocks for directories with an invalid nonzero size. Also, if
such an entry is encountered during restore, don't actually attempt to treat
it as valid and thus skip over the next actual tar entry.
This patch also adds tracking of the data actually consumed during restore,
and reports a total at the end of stream.
Change-Id: I625173f76df3c007e899209101ff2b587841f184
Every available shared-storage volume is backed up, tagged with its
ordinal in the set of mounted shared volumes. This is an approximation
of "internal + the external card". This lets us restore things to the
same volume [or "equivalent" volume, in the case of a cross-model
restore] as they originated on.
Also fixed a bug in the handling of files/dirs with spaces in
their names.
Change-Id: I380019da8d0bb5b3699bd7c11eeff621a88e78c3
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
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
* 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
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
Lock ordering bug. The fix is to avoid having to hold both locks
simultaneously in one prong of the deadlock. (Further strengthening:
the code path for potentially acquiring both simultaneously now
begins at a common method, ensuring that lock ordering is always
consistent.)
Change-Id: If9433aff8326fec2ba0e97e96ad2d835b01e2cda
If a restore set lookup took a long time, the client's restore
session could be declared timed out even though the client was
not at fault. Handle this properly by resetting the timeout clock
when control of the session is returned to the client.
Bug 3477324
Change-Id: I43afaf1063e8e706ef16b70be77f9eeeea6a321f
Repeated install/replace of an app before it ran its first backup pass
would wind up enqueueing multiple backup requests, all of which would
run back to back when the time came. This no longer happens.
Also, if a backup request is queued for an app that is then uninstalled
before that request is honored, we no longer fail in expensive and log-
intensive ways; we now fail cleanly, early.
Bug 3133212
Change-Id: I745f5b2f966a1c874f34a0107a438ad42fa7f005
An app that fires up a restore session but then crashes or drops its
session reference will currently render restore functions totally
unavailable until the device is rebooted. This CL introduces an
inactivity timeout [currently 60 seconds] on restore sessions, after
which the session is shut down and becomes unavailable to the app
who nominally still held it.
Synchronization between the timeout and the normal asynchronous
use of the session by the application is managed by running both
the timeout action and the normal teardown process on the backup
manager service's handler thread.
Bug 3276362
Change-Id: I1f63b83e96e66b0e7eb15a1e20e375049babf06e
Privileged callers can now ask the transport for a string describing
its current state, and for an Intent that can be passed to startActivity()
in order to bring up its exported configuration UI. These will be used
in Settings in order to e.g. show the user the currently active account
being used for backup, and allow the user to choose an account.
The data being funnelled through IBackupManager here are the ones
already exposed by the transports in their implementation of the
IBackupTransport interface.
Bug: 2753632
Change-Id: I2227a2b111d8d0ddf221d63020e20c1316fff55b
Some restore passes bring an ancestral dataset to the application, but
others instead act to bring an app back into sync with its own most-
recently-saved data. In the latter case the state file written by the
app after the restore is a correct basis for generating future backup
deltas, but in the former case it is not.
The app should not be required to distinguish between these cases;
the framework has all the information necessary to handle the saved
state correctly following any flavor of restore operation. This
patch makes the Backup Manager properly cause a full backup pass
following an ancestral-dataset restore. After a current-set
restore the saved state file is an accurate description for
purposes of continued backup operations, so is preserved.
Change-Id: I5982f32c9bb17fb7c953b465673ced11c40b0d95
The public API is not supposed to require the BACKUP permission in order
for an application to restore its own last-known-good backup data. However,
as currently implemented, BackupManager.requestRestore() [the public API
in question] depends on private Backup Manager methods that *do* enforce
that permission. The net result is that the method cannot be successfully
used by third party applications: it will throw an exception if attempted.
This CL restructures the permission checking involved.
First, the underlying beginRestoreSession() operation can now be passed a
'null' transport name; if this is done, then the restore session is begun
on whatever the currently-active transport is. Looking up the name of the
active transport is one of the permission-guarded actions that was required
with the initial implementation.
Second, a package name can now be passed to beginRestoreSession(). If
this is done, then the restore session can only be used to perform a
single-package restore of that one application. The BACKUP permission is
not required if the caller is tying the restore to its own package name.
In combination, these changes permit BackupManager.requestRestore() to
function without the calling app needing to hold any special permission.
The no-permission case is intentionally quite narrow: the caller must
hold the permission unless they both (a) pass 'null' for the transport
name, thereby accepting whatever the currently active transport is, and
(b) pass their own package name to restrict the restore session only
to their own app.
External bug http://code.google.com/p/android/issues/detail?id=10094
Internal bug 3197202
Change-Id: Ibc9d652323f2da03727d850f991b4096af6520d2
