Merge commit '5827d3eaf3c53d1dc3ab0d638d935c219a5515a6' into gingerbread
* commit '5827d3eaf3c53d1dc3ab0d638d935c219a5515a6':
Properly note the current active restore set's token
- Move PackageInfo out of ActivityThread, renaming to LoadedApk.
- Rename some of the other PacakgeInfo inner classes to better
represent what they are.
- Rename HistoryRecord to ActivityRecord.
- Introduce AppGlobals, to eventually let ActivityThread become
package scoped.
Change-Id: Ib714c54ceb3cdbb525dce3db9505f31042e88cf0
Merge commit '7e93aad42d5f96e4e3a471e49384e1ce794c9411' into kraken
* commit '7e93aad42d5f96e4e3a471e49384e1ce794c9411':
Fix security hole in Google backup transport registration
Previously, it was conceivable that a 3rd party application on a non-GED
device could publish a service that supported the (hidden) IBackupTransport
interface and spoofed the Google backup transport's package and component
name. This could allow it to secretly intercept all data moved through the
backup mechanism.
Fix by ensuring that the package in question exists and is part of the
OS itself (FLAG_SYSTEM in its ApplicationInfo description) before binding
to it.
Fixes bug #2457063
Change-Id: I3487572be45c2014fa209beacfe3ac6f8270f872
This transaction can involve the transport having to query a remote backend
over the wire, so it can take a Long Time(tm). Make it main-thread-safe by
making it asynchronous, with the results passed as a callback to the invoker's
RestoreObserver. We also make the IRestoreObserver callback interface
properly oneway.
Bug #2550665
Bug #2549422
Change-Id: If18a233a0a3d54c7b55101715c9e6195b762c5a0
* @hide the android.app.backup.RestoreSession class and functionality
* Provide a public method on android.app.backup.BackupManager that apps
can use to request a restore pass of their last-known-good dataset.
The new method is called requestRestore().
* Provide the name of the package being restored, not just its ordinal,
in the RestoreObserver's onUpdate() callback.
Part of bug #2545514
Change-Id: I9689bf8d6e2b808b4ee412424a36a835be0a5ca8
Fixes bug #2507582 by doing the following:
- Un-@hide the FLAG_ALLOW_BACKUP, FLAG_KILL_AFTER_RESTORE, and
FLAG_RESTORE_ANY_VERSION mask constants in ApplicationInfo. These
correspond, respectively, to the <application> manifest tag's
android:allowBackup, android:killAfterRestore, and
android:restoreAnyVersion attributes.
- Remove the android:restoreNeedsApplication attribute and the
corresponding FLAG_RESTORE_NEEDS_APPLICATION constant [which was still
marked @hide]. We now always use the application's own Application
class when performing a normal restore. In the future when we support
an externalized full-filesystem backup/restore operation, we will use
an OS-defined agent class with a base-class Application instance, but
this will not happen until a future release.
Also expands real documentation on the above ApplicationInfo constants;
that work is part of bug #2465360
Change-Id: I735d07a963ae80a01343637d83bef84e4c23fdcc
Also sanity-check the package name on the Backup Manager side, failing gracefully
if the given package is not a backup/restore participant.
Bug: 2293977
Change-Id: I3575046ffcaa3cf45c1c602824baeadd64082f70
If a backup-participating app sets android:restoreAnyVersion="true" in its
manifest <application> tag, then its agent will be invoked for restore
even if the available dataset was created by a later version of the app
than is currently installed on the device. This will not typically be
a problem for third party applications, since for them the installation
and initial data restore are tightly coupled, but it can cause serious
problems for applications which are both preinstalled on the system
partition and overridden by later updates. The primary difficulty
that this new attribute addresses is this:
1. User buys a Nexus One, Market self-updates, and the user installs some apps.
At this point the backup data on the server may indicate that the version of
Market which originated its bookkeeping is newer than the stock N1 Market app.
2. User loses their phone, and buys a replacement N1. At setup time, Market
has not yet had a chance to self-update, so when the restore comes in, it's
tagged as being from "the future" and so the restore is refused. No apps get
reinstalled.
Bug: 2442127
Change-Id: I076a9553dc613e5c3189350e778315718ed1ed2b
When an application being installed defines a backupAgent in its manifest, we
now automatically perform a restore of the latest-known-good data for that app.
This is defined as "data backed up by this app from this handset, if available;
otherwise data for this app as it existed when the device was initially
provisioned." If neither option exists for the app, no restore action is
taken.
The CL involves major changes in the Backup and Package Managers...
* The Package Manager's act of installing an application has now been split
into two separate phases, with a data-restore phase optionally occurring
between these two PM actions. First, the details of the install are performed
as usual. Instead of immediately notifying install observers and issuing the
install-related broadcasts, the in-process install state is snapshotted and
the backup manager notified that a restore operation should be attempted. It
does this by calling a new API on IBackupManager, passing a token by which it
identifies its in-progress install state.
The backup manager then downloads [if possible] the data for the newly-installed
application and invokes the app's backupAgent to do the restore. After this
step, regardless of failure, it then calls back into the Package Manager to
indicate that the restore phase has been completed, supplying the token that
was passed in the original notification from the Package Manager.
The Package Manager then runs the final post-install actions: notifying install
observers and sending out all the appropriate broadcasts. It's only at this
point that the app becomes visible to the Launcher and the rest of the OS.
... and a few other bits and pieces...
* The ApplicationInfo.backupAgentName field has been exposed to the SDK. This
can be reverted if there's a reason to do so, but it wasn't clear that this
info needs to be hidden from 3rd party apps.
* Debug logging of restore set IDs and operation timeout tokens [used during
any asynchronous Backup Manager operation] are now consistently in hex for
readability.
* We now properly reset our binder identity before calling into the transport
during restore-set operations. This fixes a permissions failure when a
single-app restore was attempted.
* The 'BackupTest' test app is no longer lumped onto the system partition
by default.
Change-Id: If3addefb846791f327e2a221de97c8d5d20ee7b3
The core backup/restore classes [BackupManager, BackupAgent, RestoreSession, and
RestoreObserver] are now published for 3rd party developers, as well as the suite
of helper classes that exist so far to aid authorship of backup/restore agents.
In conjunction with the API change, the restore-time automatic data wipe has now
been removed: applications are responsible for managing the logic of wipe vs
merge themselves. If the app's agent onRestore() callback throws, the data
is presumed to be incoherent and a wipe is issued via the Activity Manager;
otherwise, no automatic action is ever taken.
Change-Id: I0b3418b829d4689b58b88be3d9c4ace37a8583a9
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
When we perform a full-system restore, remember the set of applications which
have data available in our ancestral dataset. This is a key filter for not
having to do a round trip to the [remote] storage backend at app-install time
unless it is likely to be fruitful.
Change-Id: I7c77b490c560c581888d84f02f258b2e2d73bc69
This got lost in the shuffle when the backup process was retooled to run
synchronously within a single spun-off HandlerThread. Formerly it was okay
to hold the lock around the point in time when the backup service thread was
being spun off, but once that became synchronous it wound up locking out
apps' calls to dataChanged(), which in turn led to ANRs.
Bug: 2421333
Change-Id: Icf378e5733af5f28a689c564494486cd3555eca7
Renamed the RestoreSession performRestore() method to restoreAll(), and
added a new restorePackage() method that only restores the single
specified app. In order to restore an app other than itself, the
caller must hold the android.permission.BACKUP permission.
This change also introduces dataset tracking: the Backup Manager
persistently remembers both the current backup dataset's identity
and that of the "ancestral" dataset, i.e. the one most recently used
for a whole-device restore such as performed by SetupWizard. When a
single package is restored via restorePackage(), the selection of
most-recent dataset to use is this:
1. The data from the currently-active backup dataset, if such exists.
An app that has ever backed up data will therefore get its last-
known-good data.
2. The app's data from the ancestral dataset, if such exists. This
covers the case of a factory reset followed by reinstallation of
an app at a later time. The app had not yet backed anything up
post-wipe, but the old data is in the ancestral dataset and should
be brought forward when the app reappears.
3. If neither 1. nor 2. exist, there is no data to restore, so just
skip it and return failure.
Note that the infrastructure to automatically attempt a restore after
an application has been installed does not yet exist; that's coming.
Change-Id: I0ba170df9885128000c46ed28d3dddda3a63a143
This setting, like BACKUP_ENABLE, should never be set directly in the secure
settings database. Instead, it should be manipulated through the new IBackupManager
method setAutoRestore(boolean).
Change-Id: I5c3226ca85b6148bb756d753d7f9e4ea76e878c4
Add new broadcasts ACTION_MEDIA_RESOURCES_AVAILABLE and
ACTION_MEDIA_RESOURCES_UNAVAILABLE that get broadcast by
PackageManagerService when sdcard gets mounted/unmounted
by MountService so that packages on sdcard get recognized by
various system services as being installed/available or
removed/unavailable by the system.
The broadcasts are sent before the actual package cleanup which includes
mounting/unmounting the packages and we force a gc right after so
that any lingering file references to resources on sdcard get
released.
Now that backup/restore/etc operations are queued and serialized, we no longer
need to use external state tracking to prevent overlapping operations.
Change-Id: I14f2a5d740cb97ae062aad55a06f49a2be5dd985
Callouts to app backup agents are now asynchronous, and timeouts are applied if
they take too long, hang, etc. The initial timeouts are set to 15 seconds on
backup, 60 seconds on restore. These operations typically run at background
priority, so it's necessary to give them ample time to run.
As part of setting up this asynchronicity, the Backup Manager's internal thread
management has been overhauled. It now spins off a single HandlerThread at
startup, and runs backup/restore/etc operations *synchronously* in that thread,
applying timeouts as appropriate. This means we're no longer spinning up new
threads all the time, and furthermore it ensures that we can never have more
than one operation in flight at once. Later CLs will remove the now-redundant
logic that previously ensured that operations didn't stomp on each other.
Bug: 2053560
Change-Id: Ie4315c219c7ff6dd8f51f2ad6c0872595b18cff1
This commit makes a few changes towards establishing a formal application
interface for interacting with the backup/restore mechanism:
1. Introduce public wrapper classes around the various binder interfaces; 3rd
party code will never see the binders directly.
2. Progress update callbacks during a restore sequence now occur on the main
thread, not in a binder thread [and not with system-process permissions!].
3. Rename the BackupManagerService's inner "RestoreSession" class to avoid
ambiguity with the new public "RestoreSession" class.
We can now locate event log tag definitions in individual packages
(and java constants for the tag numbers get auto-generated), so move
all the tags used by the system server into the package.
The underlying issue is that ordinarily, the restore mechanism checks the
signature block of the package which uploaded the restore data against the
signature of the package on-device that will be handling the restore. This is
to ensure that the restore goes to the "same" application as the one that
uploaded it.
However, applications bundled on the system partition as part of the device
build are signed not with a permanent, app-identifying signature, but rather
with the device's signature block, which is different for each kind of device
and potentially between kinds of build for the same device. That renders the
stored backup data unusable when changing devices / builds / etc.
This change works around the problem by explicitly privileging applications that
reside on the system partition: they have been built into the device, and so
are trusted to be able to handle data that is marked as coming from its package
name.
Change-Id: I561011bce2b54cff3e695e82e7544b126b6ac31e
and add some random fuzz to the scheduling times, to make sure we aren't
creating hour-aligned server load spikes.
See bug 2226553 for details & Dr. No information.
to defensively work around a still-mysterious bug where the
list of saved packages ends up being empty even though we still
have state pending. If we do re-initialize, then wipe all state
to make sure the right thing happens.
Don't keep open journal files -- close them after every update.
A bit less efficient, but possibly more reliable (again, this is
defensive programming here). Also change "rwd" to "rws" mode
for fully synchronous operation.
on success, record "backup_initialize" event; on failure,
record "backup_transport_failure" event (and add tags to
"backup_transport_failure" events that aren't associated
with a particular package -- namely "(initialize)" and
"(finish)").
If a backup pass had been skipped (either because the transport was unavailable
or -- in a common case! -- because there was simply no work pending when the
periodic backup check fired), we were forgetting to reset the "backup currently
in progress" flag. Once we'd done that, the device would *NEVER* perform a
backup until it was rebooted, since it would forever think that there was one
currently in operation that must not be interfered with.
Change-Id: I0d6d7375dc6de99b599222a449934e70fe13ebb9
* We now check for in-progress backups when asked to perform one, and don't
bother firing off another one concurrently (nor do we adjust the scheduling;
after all, someone asked to do a backup "now" and we're doing one, so we are
in line with expectations). We also defer backup passes while a restore is
in flight, and abort attempts to perform a restore during a backup pass.
* When a backup attempt fails, we now ask the transport how far in the future we
should put our retry. Previously we were simply not bothering to consult with
the transport, so we would wind up retrying backup while network connectivity
was known to be down, etc.
Change-Id: Ic7758010b74e06e90c50d46b7b0dd01b17af7c90
Turning off backup in the Settings UI constitutes an opt-out of the whole
mechanism. For privacy reasons we instruct the backend to wipe all of the data
belonging to this device when the user does this. If the attempt fails it is
rescheduled in the future based on the transport's requestBackupTime()
suggestion. If network connectivity changes prompt the transport to indicate a
backup pass is appropriate "now," any pending init operation is processed before
the backup schedule is resumed.
The broadcasts used internally to the backup manager are now fully protected;
third party apps can neither send nor receive them.
(Also a minor logging change; don't log 'appropriate' EOF encountered during
parsing of a backup data stream.)
return TRANSPORT_NOT_INITIALIZED (in fact that's typically how it comes).
For consistency, make other IBackupTransport methods return int instead of
boolean, and handle accordingly.
Make initializeDevice() its own method instead of a flag on performBackup().
This will be needed when un-checking the settings box anyway, and is
conceptually unrelated to whatever happens to be the first post-initialization
backup we perform. (Note that even if the init is sent separately from the
backup operation, the server will remember that an init has been done and
will *not* return NOT_INITIALIZED for the subsequent backup.)
Fix LocalTransport accordingly (trivial changes).
Handle failures more robustly in BackupManagerService -- most notably,
doQueuedBackups() was ignoring the result code of processOneBackup(), so
a NOT_INITIALIZED error would go past unseen (at least until the next
backup pass). Keep track of error code returns more universally now.
(This includes finishBackup(), of course.)
When attempting a backup, the transport may inform us that the backend is in an
uninitialized state. This typically means that the device's data has been wiped
after a period [e.g. 90 days] of inactivity. This means that we need to
re-store all data subject to backup, and all of our incremental state tracking
on the device is now stale.
In response, we wipe all of our recorded backup state and restart the backup
pass on all participants.
