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
Remember, the system and main logs are
- Shared resources
- Primarily for recording problems
- To be used only for large grained events during normal operation
Bug: 3104855
Change-Id: I136fbd101917dcbc8ebc3f96f276426b48bde7b7
Several people are seeing odd behaviors around backup/restore at present.
Enable expanded logging to help pin down exactly what is happening.
Change-Id: I95ca013017cb07e633f2ba765583de3cf0e056af
This fixes a problem where applications could ask the location
manager to do very heavy-weight things (like... say... update
location every minute), which would get accounted against the
system instead of the application because ultimately it is the
system making the heavy calls (wake locks, etc).
To solve this, we introduce a new class WorkSource representing
the source of some work. Wake locks and Wifi locks allow you
to set the source to use (but only if you are system code and thus
can get the permission to do so), which is what will be reported
to the battery stats until the actual caller.
For the initial implementation, the location manager keeps track
of all clients requesting periodic updates, and tells its providers
about them as a WorkSource param when setting their min update time.
The network location provider uses this to set the source on the
wake and wifi locks it acquires, when doing work because of the
update period.
This should also be used elsewhere, such as in the GPS provider,
but this is a good start.
Change-Id: I2b6ffafad9e90ecf15d7c502e2db675fd52ae3cf
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
