| 71beeab14a891297b6658c4aeb47557083091aa1 |
|
25-Jun-2010 |
Christopher Tate <ctate@google.com> |
Properly note the current active restore set's token
Bug: 2796780
Change-Id: Iad601ed96ae73cf34910a276350712e6af19bb4e
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| a32504fce826fb66b53991d04819ece3e6bf105e |
|
22-Apr-2010 |
Christopher Tate <ctate@google.com> |
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 5923c9718390bf6d50c52661263f15c1f863012b |
|
05-Apr-2010 |
Christopher Tate <ctate@google.com> |
Fix 'dumpsys backup'
"for (Type foo : mSetOfType)" doesn't work when mSetOfType is null.
Change-Id: Iac667c7309f99b12d3147830e166b542b29cba5f
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 2d449afe3d075020bdd1115bcc15c9383cbce122 |
|
30-Mar-2010 |
Christopher Tate <ctate@google.com> |
Make RestoreSession.getAvailableRestoreSets() asynchronous
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 1f4df90bfab8ca42eabe95f19eadff3432eee7fd |
|
27-Mar-2010 |
Oscar Montemayor <oam@google.com> |
DO NOT MERGE
Removing unused features from source tree.
Please refer to Bug#2502219.
Change-Id: I879c29bfd5ffe933f64bb1082aaae7c956450a5a
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 9c3cee9824026764275e4d84ba9b5d9fdc5da690 |
|
26-Mar-2010 |
Christopher Tate <ctate@google.com> |
API CHANGE: Backup/restore API changes requested by the API Council
* @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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 3de55bcd34afd5871816526294f9514d1adf3fe5 |
|
13-Mar-2010 |
Christopher Tate <ctate@google.com> |
API CHANGE: expose the backup-related ApplicationInfo flag masks
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 4528186e0d65fc68ef0dd1941aa2ac8aefcd55a3 |
|
06-Mar-2010 |
Christopher Tate <ctate@google.com> |
Refactor android.backup => android.app.backup
Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 8a9b22056b13477f59df934928c00c58b5871c95 |
|
27-Feb-2010 |
Joe Onorato <joeo@android.com> |
Switch the services library to using the new Slog
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 7d411a3b947ba82d1d57f73c0fa698c3b9c95892 |
|
26-Feb-2010 |
Christopher Tate <ctate@google.com> |
Add single-package restore to Bmgr feature set
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 5035fdab3dbb60b226bc6bb2f03e9944bcb964cd |
|
26-Feb-2010 |
Christopher Tate <ctate@google.com> |
Default the auto-restore setting to "enabled."
Change-Id: I7d8710466214a1b09aabdd71e77b9b34d3d62365
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| ae06ed97382429f51075d257e3290cdd86f66326 |
|
26-Feb-2010 |
Christopher Tate <ctate@google.com> |
Fix the build
Change-Id: I41616afc75a3366ea7e9e79ac7ea4c46d1863d83
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| f087272d56ff84157e2481b7ca34d4d077affa74 |
|
26-Feb-2010 |
Christopher Tate <ctate@google.com> |
Start respecting the auto-restore-at-install setting
Change-Id: I420ff6b4ba72f87bee56f45d8906f086f7a2b114
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 3dda518a4fd57cdded3afa50d8aa206501de7fc6 |
|
25-Feb-2010 |
Christopher Tate <ctate@google.com> |
Add 'restoreAnyVersion' attr for apps that want to restore "future" data
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 1bb6906c7a903ee6427c8ff37bdc5896c386ff73 |
|
20-Feb-2010 |
Christopher Tate <ctate@google.com> |
Automatically restore app data at install time
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 1168baae849f03ad655bff74360b286b2f10b4a8 |
|
17-Feb-2010 |
Christopher Tate <ctate@google.com> |
Tone down a non-error log message about lack of ancestral dataset tracking
Change-Id: I2e5e48c9b695d6225016365907fe8edc73ab2c8e
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| e28290e21f908b4e917099ff2aa41e3aab9310c2 |
|
17-Feb-2010 |
Christopher Tate <ctate@google.com> |
API CHANGE: expose backup/restore to the SDK
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| a87240c2270e83c3e865ffa1e56f79bfa74daffc |
|
12-Feb-2010 |
Christopher Tate <ctate@google.com> |
Remove BACKUP_DATA permission and associated checks
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| b49ceb3b8b17656984fd969d548dc912e7d2c7c1 |
|
09-Feb-2010 |
Christopher Tate <ctate@google.com> |
Remember which apps have available restore info in the ancestral dataset
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| b56ae20b22fd7283df32072a431ab6d4965f3c1b |
|
05-Feb-2010 |
Suchi Amalapurapu <asuchitra@google.com> |
Rename media resource broadcasts
Add checks for fwdlocked and updated system apps
add more tests
remove duplicate adds
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| c61da3136b1ffce9152f54ff19cab2782cb8450b |
|
05-Feb-2010 |
Christopher Tate <ctate@google.com> |
Don't hold the backup queue lock across a backup operation
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 8472581aa32eee1368de379c2c079ea0a66baa3c |
|
05-Feb-2010 |
Christopher Tate <ctate@google.com> |
Add single-package restore from an app's most-recent data
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| cce9da5dc3d515f98c260af41a03e61e57b4e7a6 |
|
04-Feb-2010 |
Christopher Tate <ctate@google.com> |
Add auto-restore setting and Backup Manager awareness thereof
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 08675a3376819a82aa5ab344bc3e7b1635c30b05 |
|
28-Jan-2010 |
Suchi Amalapurapu <asuchitra@google.com> |
Apps on sdcard: Add new broadcasts
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.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| c2af5d3bf84fa66570081d30ce0210458e46b1b8 |
|
03-Feb-2010 |
Christopher Tate <ctate@google.com> |
Get rid of now-superfluous "backup or restore in progress" tracking
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| b0dcaaf108d70040e4e4e4ac65df1a7eae732d1e |
|
30-Jan-2010 |
Christopher Tate <ctate@google.com> |
Don't crash on transport unregistration if there is no current transport
Change-Id: Icd0962254ba224a7be27d408dffb25b634f67863
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 44a2790374bf27116cbd91060d4f096ca5999709 |
|
28-Jan-2010 |
Christopher Tate <ctate@google.com> |
Make backup/restore asynchronous and enforce timeouts
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 80202c8cb8c8e4ab507079e79b864c61a8eeeee9 |
|
26-Jan-2010 |
Christopher Tate <ctate@google.com> |
Move towards a formal public API for backup and restore
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.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| dfa47b56e1c10c001adcb9dd6c32613b4ce50ff7 |
|
23-Dec-2009 |
Christopher Tate <ctate@google.com> |
Don't crash the system process when a backup transport unregisters
Bug: 2342503
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 18803d37e2ce47407b7ac52513e3254207e8b287 |
|
07-Dec-2009 |
Doug Zongker <dougz@android.com> |
resolved conflicts for merge of 5a2fdbba to master
|
| ab5c49c7e7f5f61040650109a76f38a443fb852d |
|
04-Dec-2009 |
Doug Zongker <dougz@android.com> |
move event log tags used by system server into this package
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.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| a8529f68671a8a118751cb6ad577f44eaf076b96 |
|
18-Nov-2009 |
Oscar Montemayor <oam@google.com> |
Encrypted File Systems Project. Installer modifications.
Started to modify isntaller for data redirection to a secure location.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 78dd4a737172afe98c25ad19dacc0106a6f5474a |
|
04-Nov-2009 |
Christopher Tate <ctate@android.com> |
Fix #2176803 - restores from userdebug to user builds not working
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| c1c49c024f990bf54b2a7d16fdf5110263693aea |
|
31-Oct-2009 |
Dan Egnor <egnor@google.com> |
Use setRepeating() rather than setInexactRepeating() for backup scheduling,
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.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 13f4a64ddd0d81ffa04cb2ff4fd4c6500d6d21ed |
|
01-Oct-2009 |
Christopher Tate <ctate@android.com> |
Turn off the last of the STOPSHIP verbose debugging
Change-Id: Id93f4c9e9fb8468a554ae1e5c5c767f72903662c
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 852f8e4660302a4163bfdc4a9b1e8012296522b0 |
|
30-Sep-2009 |
Dan Egnor <egnor@google.com> |
Only re-initialize backup state if @pm@ metadata is missing,
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.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 726247ca6153d801e56ba5c574e0d9ba48135a5c |
|
30-Sep-2009 |
Dan Egnor <egnor@google.com> |
Better event log tracking for initializeDevice() requests --
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)").
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 55f931a375cf6da96c525aa70d97541c0878951e |
|
30-Sep-2009 |
Christopher Tate <ctate@android.com> |
Add more useful-for-debug info to 'dumpsys backup'
Change-Id: I52e20bac01ff63feaf28920a79311881992293a3
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| a253f16cf8e70e0dcb0bcd6338441c83c3e44c3a |
|
28-Sep-2009 |
Christopher Tate <ctate@android.com> |
Don't forget to clear "backup in progress" state when finishing a pass
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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 21ab6a5bdb791c138f284442cdac9e73ca6c5c11 |
|
25-Sep-2009 |
Christopher Tate <ctate@android.com> |
Disallow concurrent backups; consult transport requestBackupTime()
* 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
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 4cc86e1ae80eb1938500fe5fa06bbdf8b4b7b50d |
|
22-Sep-2009 |
Christopher Tate <ctate@android.com> |
Clear the device's data from the transport when backup is disabled
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.)
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| b03b3bbd6833f7c6fbd8100fa3958220554f66a3 |
|
22-Sep-2009 |
Christopher Tate <ctate@android.com> |
If backup fails, reenqueue all of the affected packages for next time.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 313b29faafab789ab7253be84c84ac560e72db7c |
|
22-Sep-2009 |
Dan Egnor <egnor@google.com> |
Add parameter for the restore set (device id) data is being restored from to the restore_start event
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 0144516e19b9fd5415a56f8b41191187e2344bb0 |
|
22-Sep-2009 |
Dan Egnor <egnor@google.com> |
Make IBackupTransport.finishBackup() also return an int code, since it too can
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.)
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| d55e18acbe444b74dc9e71eff6ea2c3eaf25fbd0 |
|
21-Sep-2009 |
Christopher Tate <ctate@android.com> |
Reset backup tracking in response to transport data-wipe notification
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.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 90967f4f0d5ba38ae7225788b111289516d1dda1 |
|
21-Sep-2009 |
Christopher Tate <ctate@android.com> |
Fix up the first-backup-ever tracking
This changes a couple of bits of the Backup Manager's logic around
first-backup-ever handling. First, it uses the same "what we've ever backed up"
handling as the rest of the system for purposes of instructing the backend to do
a wipe when the metadata is initialized for the device, instead of looking at
the presence of the @pm@ file. Secondly, for the time being we won't be using
the saved state produced by agents' doRestore() logic. Until the server is
migrating each restored package's data over to the new dataset, this was
resulting in the client holding an agent state blob for which no data existed on
the server under this device's identity but which the device thought was fully
up to date.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 25a747f5c47f25c1a18961b03507f309b84924fe |
|
20-Sep-2009 |
Christopher Tate <ctate@android.com> |
Add an 'init everything' operation to the first backup pass
IBackupTransport.performBackup() now takes a flag "wipeAllFirst", which if set
will result in the entire restore set for the current device/account being wiped
clean prior to the storage of the provided package. This ensures that a device
on which backup has just been enabled will not confront potentially-stale
information, nor will the restore set potentially contain mismatched data from
orphaned packages.
The Backup Manager has also been revised to pass this flag when first backing up
its master metadata block (and never pass it thereafter unless something has
caused the backup state tracking to be erased, e.g. the user has opted out of
backup and then later re-enabled it).
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 83861e74c3c89337b0cc43fb38daedfef19e6edf |
|
18-Sep-2009 |
Dan Egnor <egnor@google.com> |
Inefficient but correct fix for 2122381: call finishBackup after every performBackup
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| b8eb1cb79b2912b91a1b0198ba3e61776af07a79 |
|
16-Sep-2009 |
Christopher Tate <ctate@android.com> |
Be sure to include shared lib path info when dealing with agents
In particular, this ensures that on the client side the full classpath is known
and used by the class loader during execution of the agent.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 5e1ab335e6e8fbfa19c64d53880a22f472010953 |
|
02-Sep-2009 |
Christopher Tate <ctate@android.com> |
Expand apps' control over the settings restore process
Applications can now specify two more aspects of the restore process: whether
they need to run with their own custom Application subclass rather than being
launched in the usual restricted mode during restore, and whether it's okay for
the backup manager to kill the app process once restore has completed. The new
manifest attributes for these are, respectively, android:restoreNeedsApplication
and android:killAfterRestore.
If unspecified in the manifest, restoreNeedsApplication is false, and
killAfterRestore is true.
In order to support kill-after-restore cleanly, this change also adds a new
system-process-only interface to the Activity Manager, which will schedule a
"commit suicide" event on the target app's main thread looper.
The framework backup agents have been given the appropriate new backup
attributes as well.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 0749dcd19301fe4093f9cf8677c722d17bceabfb |
|
14-Aug-2009 |
Christopher Tate <ctate@android.com> |
Backup participants must now hold the BACKUP_DATA permission
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.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 0e0b4ae5bc5c652c8339d71ed9667e1e37baaa03 |
|
11-Aug-2009 |
Christopher Tate <ctate@android.com> |
Don't let bmgr leave a restore session hanging on error
Specifically, don't wait for the RestoreObserver to be informed that the restore
has completed unless performRestore() ran. We were winding up in a case where
bmgr was hanging forever waiting on a nonexistent restore process instead of
calling endRestoreSession().
Also improve the documentation, explicitly calling out the need to call
endRestoreSession() even if previous operations on the session were
unsuccessful.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| f2c321aeff64ac0b980c34b948755d52ddd52516 |
|
11-Aug-2009 |
Christopher Tate <ctate@android.com> |
Print restore tokens in hex
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 2e6bca690197978bb23cdcf31d948383bdb14c91 |
|
08-Aug-2009 |
Amith Yamasani <yamasani@google.com> |
Temporarily rollback a change that's causing SetupWizard failures during restore. #2042337
Don't kill the process of the package that's being restored. This is causing a chain
reaction of killing a provider needed by the setup process.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 9dfdac5b088d91b905f4f24822b76f4a0883f9d6 |
|
06-Aug-2009 |
Christopher Tate <ctate@android.com> |
Clear app data via the Activity Manager, not Package Manager
This is because doing it through the Activity Manager also makes sure that the
app has been shut down first, which is quite a desirable invariant for restore
handling.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| aa93b0418fe5a13d696841074bb6d8e690456cda |
|
06-Aug-2009 |
Christopher Tate <ctate@android.com> |
Correct the backup manager's identity around wakelock use
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| dfec20b10bb5cc1125217168690779d11ed8ea5a |
|
04-Aug-2009 |
Christopher Tate <ctate@android.com> |
Bootstrap the ever-backed-up bookkeeping properly
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 0084da561e9830c17068435cb398635145fca5c0 |
|
29-Jul-2009 |
Dan Egnor <egnor@google.com> |
Allow zero-length lists in EventLog entries.
(I'm verifying that the consumers of EventLog -- logcat, checkin -- are OK with this.)
Improve the error handling in RestoreSession.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| bb9001c69a313b28d805fe1cfbb7e848eb6aa55f |
|
27-Jul-2009 |
Dan Egnor <egnor@google.com> |
clean up error recovery; log events tracking backup activity
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| ab9a2a52c5fe9046216bffefca4a540814b4260b |
|
27-Jul-2009 |
Joe Onorato <joeo@android.com> |
Backup manager should default to not "provisioned" so backups don't start until the setup wizard is
done.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 1531dc80e621b29636e24bae54cab2e0ad25f6ca |
|
25-Jul-2009 |
Christopher Tate <ctate@android.com> |
Don't leave restore data lying around after the operation
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 5933a497227c6ecb99ae89bc35482ffc49bca2b3 |
|
24-Jul-2009 |
Joe Onorato <joeo@android.com> |
Need to be able to call the backup manager from the system process.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 967330496438a7f28273b0220a444a30dbdc9fb9 |
|
20-Jul-2009 |
Christopher Tate <ctate@android.com> |
Clean up when an attempted restore throws
When a restore agent throws an exception back into the framework, assume that it
may have left the app's data in an inconsistent state and clear the data for
that app (again -- it was cleared just prior to the attempted restore, too).
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| e97e807a468bf64ad614fca77d350b016f3ce4a9 |
|
16-Jul-2009 |
Christopher Tate <ctate@android.com> |
The rest of ever-backed-up tracking
When a package is uninstalled we now remove our notion of its having been backed
up, thereby forcing a backup pass if it is reinstalled at some point in the
future. Removal from the log means rewriting it and doing an atomic rename to
the canonical version. The temporary existence used during the rewrite is *not*
written synchronously; there's no need and it keeps the load on the flash part
much lower.
Because we might crash & reboot in the middle of the rewrite operation, there's
now code during init that sanity-checks the contents of the ever-backed-up log
and ensures that it's in a coherent state.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 73e025296fd8712c775fe75c5f5d6981155b0867 |
|
15-Jul-2009 |
Christopher Tate <ctate@android.com> |
Ensure that everything gets backed up at least once
We now schedule a backup pass for any new application we see (at boot or
package-install time) for which we have never performed a backup. The
bookkeeping is a log file with the names of all the packages we've successfully
completed a backup pass on, maintained with synchronous journal-type behavior.
Also, make a bunch of private fields package-scoped to permit cheaper access
from the various worker / binder threads that run under the Backup Manager's
aegis.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| de83ab9fce4d02ddfde785e193bc787497d45138 |
|
15-Jul-2009 |
Christopher Tate <ctate@android.com> |
Grant adb the BACKUP permission
This also means we should no longer do explicit calling-identity fiddling in
dump(), relying instead on the usual permission enforcement mechanism to handle
things.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 433830452dac5dc353f1db7a80023e889d522a82 |
|
14-Jul-2009 |
Christopher Tate <ctate@android.com> |
Don't NPE if a restore session is requested for an invalid transport
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| b407f22c9d960b48ed49ed2a1cee0042d9f2a92e |
|
08-Jul-2009 |
Christopher Tate <ctate@google.com> |
Don't invoke the transport if doBackup supplied no data
If there's no data to be backed up, we no longer invoke the transport. We *DO*
still require that the agent have emitted a valid new state file, however.
This change also finally uncomments the code that removes the backup data file
after it has been sent to the transport, so there will be no more
packagename.data files lying around in the staging area.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 22b60d8fd055171d7abe6be60a24ea8ac1af25b0 |
|
08-Jul-2009 |
Christopher Tate <ctate@google.com> |
Remove a lot of debug-log verbosity
We now log in dataChanged() only when an app is added to the backup set (and
*not* if it redundantly asks to be added after it's already there) and on error.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| a7de3845507b7bf57a2c7b26fb08f05b193697d6 |
|
07-Jul-2009 |
Christopher Tate <ctate@google.com> |
Only write to the pending-backup journal when necessary
We now only commit to the pending-backup journal on disk the first time that a
given package is added to the backup set. This avoids a lot of write thrashing
of the disk, particularly since Settings tends to call dataChanged() a great
many times during boot, while the Settings UI is in use, etc.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 3d7cd13e772bde1c4a72fa4e740baa03cb042e6c |
|
07-Jul-2009 |
Christopher Tate <ctate@google.com> |
Fix the metadata-available test during restore
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 8031a3df2fd0c38d85eeae39c1ea2c83e813f4ff |
|
07-Jul-2009 |
Christopher Tate <ctate@google.com> |
Make enable/provisioning of the backup service a two-step process
This CL adds the concept of 'provisioned' to the backup manager. No backups
will be scheduled until the user has indicated that backups are to be enabled
*and* has clicked all the way through the setup wizard.
When the user first turns on the backup system, the delay before the initial
backup pass is different from the periodic backup interval. Currently that
initial delay is 12 hours. The intent here is to guess at a less-active time
for performing that first backup pass.
NOTE: currently the backup service defaults to 'provisioned'. Once the real
code goes live in Setup Wizard, this will be changed to default to
not-provisioned until the user has confirmed all the relevant UI.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 34ebd0e1bbd54def9fea020f4a9083382160fd3d |
|
07-Jul-2009 |
Christopher Tate <ctate@google.com> |
Fix up permissions for 'dumpsys backup'
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| b6787f2ee535338bb96df0ab8ad70a9f82760a25 |
|
03-Jul-2009 |
Christopher Tate <ctate@google.com> |
Hold a wakelock during backup/restore/clear operations
We need to make sure we stay alive for the duration of a backup or (especially)
restore operation. The existing Handler-based timing system was simply not
properly functional, so it's been retooled to use a repeating alarm delivering a
broastcast PendingIntent to our registered receiver.
We acquire a partial wake lock in the broadcast receiver [i.e. while the Alarm
Manager is holding one for the duration of broadcast delivery] and pass the
wakelock object to the backup thread, which eventually releases it when it's
finsihed operations. A similar pattern is used for the threads handling restore
and clear.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 8c0324752a7f47afd9e84f0a3088954b5d05a94b |
|
02-Jul-2009 |
Christopher Tate <ctate@google.com> |
If we can't get the restore set's metadata, don't continue
Without the metadata we can't verify the version number or the signatures of the
apps whose data we'd be trying to restore against the apps present on device.
This is not acceptable; we need to refuse to give data to an unauthenticated
app.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 4e3e50cfa7cf02270ed0dd454d5c51bf7065bd14 |
|
02-Jul-2009 |
Christopher Tate <ctate@google.com> |
Clean up the last two literal permission string usages
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| ee0e78af5af3bf23dd928fe5e0ebeb39157eaf66 |
|
02-Jul-2009 |
Christopher Tate <ctate@google.com> |
Add a "clear backed-up data" method to the backup mechanism
It's now possible to ask that the backup manager wipe the saved data for a given
application from the backing store. LocalTransport implements this now but the
Google backend does not yet. When the data is wiped, the on-device backup state
is also wiped to ensure that the next backup pushes all necessary data.
Bmgr has not yet been modified to actually call into this method, but it will
be soon.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| cf098294da7a820d5c30d8ed2006ed5446ee1da9 |
|
02-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Move backup state to settings, change permission checks to use symbol.
This changes the backup service to use the settings provider instead
of system properties, correspondingly making it off by default and
allowing specific devices to define the transport. Also tweaks
the permission checks to use the permission symbol instead of raw
strings.
This requires some corresponding changes in the vendor projects.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 9a5e3e115fc69181e143bdb9ec455e0f94fbc11f |
|
02-Jul-2009 |
Joe Onorato <joeo@android.com> |
Less logging in some places. More in others.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 49401ddb9ac11ad5caead4e4cefcaa81d2418ed2 |
|
01-Jul-2009 |
Christopher Tate <ctate@google.com> |
Revamp backup scheduling policy
We now schedule a periodic check of pending backups; if any apps have requested
a backup since the last check, we perform all of the pending backups. The
periodic backup scheduling matches the enable/disable state of the backup
manager; while backups are disabled entirely there are no periodic wakeups.
The period is set here to one hour. If an external caller (transport, the
'bmgr' command line tool, etc) requests an immediate backup pass, that is
performed and then the periodic backup check is rescheduled using that pass as
the starting point of a new interval.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| ce0bf069fe8c5c93f91cb70b0cd9365245d144c1 |
|
01-Jul-2009 |
Christopher Tate <ctate@google.com> |
Use secure settings for backup enable / transport selection
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 7958834e0e8adb42ca5183541c4bbcd8aaa7d3aa |
|
01-Jul-2009 |
Christopher Tate <ctate@google.com> |
Run backups at background priority
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 6ef58a1509b9d3348a33ca5686917796c2759aa5 |
|
29-Jun-2009 |
Christopher Tate <ctate@google.com> |
Implement persistent enable/disable of the backup manager
Backup & restore is still enabled by default, but with the expectation that it
will be enabled during the course of the Setup Wizard or some other privileged
entity that has notified the user about the ramifications. While disabled,
data-changed notices will still be collected, but no backup pass will be
scheduled. When the backup manager is later enabled, any pending data-changed
notices will then be processed and the apps invoked for backup.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 9171749700853305f3e6abbcdbd9e02f3a71d459 |
|
27-Jun-2009 |
Christopher Tate <ctate@google.com> |
Use system properties to track the current transport
This change retools the transport selection mechanism a fair bit. Transports
are now specified by name rather than by numeric ID, and the name of the
currently selected transport is stored in a persistent system property under the
name "persist.service.bkup.trans".
The name -> IBackupTransport translation is now handled by maintaining a map
from the names to the live IBackupTransport objects that correspond. The Google
transport service observer now registers and unregisters the transport as the
service goes up and down.
The bmgr command has been expanded to include real transport interrogation and
selection by name, and some documentation has been written for it.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| f7c886b4fe27cd9ab4a9991958ff931054556a24 |
|
27-Jun-2009 |
Christopher Tate <ctate@google.com> |
Respect android:allowClearUserData=false during restore
Ordinarily we wipe the data of apps we are restoring. This is problematic for
packages that expect that their data can never be wiped back to nothing,
especially system packages, so we now respect the android:allowClearUserData
manifest attribute.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 466ef345d17104076e03674cc49c368e6bd46df2 |
|
26-Jun-2009 |
Christopher Tate <ctate@google.com> |
Trim some superfluous imports.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 156411df4627336b246db78cddca8248ed615b67 |
|
26-Jun-2009 |
Dan Egnor <egnor@google.com> |
Use a long for restore token
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 7d562ec393d54dd9ef387c49d1283243bfdbd2b1 |
|
26-Jun-2009 |
Christopher Tate <ctate@google.com> |
Add a new IRestoreObserver callback class to the restore process
The observer is told when restore begins how many packages are being restored.
It then gets an onUpdate() call telling it that the Nth package is now
undergoing restore. Ultimately, its restoreFinished() callback is invoked,
passing a simple success/fail error code, to let it know that the restore
operation has concluded.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 5cb400bd72726c22f641f334951b35ce2ddcfeef |
|
26-Jun-2009 |
Christopher Tate <ctate@google.com> |
Keep track of backup state independently for each transport
Backup transports now provide the Backup Manager with a suggested name with
which it can disambiguate any transport-specific bookkeeping that it needs to
maintain. The Manager keeps separate application backup 'state blobs' for each
transport now, preventing things from getting out of step if the device is
switched among multiple transports.
Also, the metadata backup agent is always invoked now on each backup pass. This
is cheap when there is nothing to do, but also strongly ensures that we never
wind up in a situation where a given transport destination has not been given
all of the metadata necessary for the backup set.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 6f21128d1fc949828b1a4c2a0023f07bfd280e2e |
|
25-Jun-2009 |
Dan Egnor <egnor@google.com> |
Switch the default transport to GOOGLE.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 111bd4acdb378266221b430a284f88a3990a3958 |
|
25-Jun-2009 |
Christopher Tate <ctate@google.com> |
Start backing up wallpaper
This CL does the following:
+ adds an AbsoluteFileBackupHelper class for managing backup of files
known by absolute path, not based off of the app's getFilesDir() root
+ bumps up the collection interval from its testing-only default of 1 second
to 3 minutes
+ adds a SystemBackupAgent class to the main system package and names it as
the android:backupAgent for the main OS package. Right now this agent
only backs up & restores the wallpaper file.
+ amend the Wallpaper Service to inform the Backup Manager when the wallpaper
changes.
On the subject of the 3-minute collection interval before the backup actually
occurs: this can be short-circuited from an adb shell. Running the command
'bmgr run' will cause the Backup Manager to kick off any pending backup
operations immediately.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| efe52647f6b41993be43a5f47d1178bb0468cec8 |
|
24-Jun-2009 |
Dan Egnor <egnor@google.com> |
Modify the IBackupTransport API to support bulk restore operations.
Change the BackupManagerService and LocalTransport to support the new API.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 5cbbf5652a78902ac3382dc4a3583bc5b0351027 |
|
23-Jun-2009 |
Christopher Tate <ctate@google.com> |
Pass the originating app's versionCode along with a restore set
This change amends the doRestore() / onRestore() interface to backup agents to
provide the integer android:versionCode of the app that stored the backup set.
This should help agents figure out how to handle whatever historical data set
they're handed at restore time.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 3a31a93b8a195ae2d0180e6dfbf292da2e581f50 |
|
23-Jun-2009 |
Christopher Tate <ctate@google.com> |
Add some global metadata to the restore set
In addition to the signatures of each participating application, we now also
store the versionCode of each backed-up package, plus the OS version running on
the device that contributed the backup set. We also refuse to process a backup
from a later OS revision to an earlier one, or from a later app version to an
earlier.
LocalTransport has been modified as well to be more resilient to changes in the
system's use of metadata pseudopackages.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 06290a4bb9b280fa14a2bbeb2d3ceb09396a78c3 |
|
19-Jun-2009 |
Joe Onorato <joeo@android.com> |
Helper API cleanup. Allows multiple helpers to function,
because they'll always go in the same order, and this lets
us not have to write headers to keep them paired.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 6aa41f4c575479672661f7eb4c704ef59d26a629 |
|
19-Jun-2009 |
Christopher Tate <ctate@google.com> |
Add app version to the backup metadata
We now record the version number of the app (drawn from its manifest versionCode
attribute) along with its signatures. At restore time, we compare the version
associated with the restore set with the version present on the device. If the
restore set is from a newer version of the app than is present on device, we do
not perform the restore operation.
Also fix the pending-backup iteration in 'dumpsys backup'.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 20efdf6b56e54b0520d8629cd706045dc8d280d3 |
|
19-Jun-2009 |
Christopher Tate <ctate@google.com> |
Make signature checks on restore work with unsigned apps
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 5d605dc56b036232e885f6ec36b888b729673060 |
|
19-Jun-2009 |
Joe Onorato <joeo@android.com> |
backup stuff
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| abce4e8714bed26a2b37b20ad3f02cf619d71c9a |
|
19-Jun-2009 |
Christopher Tate <ctate@google.com> |
Use signatures on restore
On restore now, the backup manager gets the signature blocks corresponding to
the restore set from the transport. It then validates those signatures against
the on-device app signatures, and refuses to restore data to an app whose
on-device sig block does not match the backup image's.
Also actually implement 'bmgr transport N' so that we can select the local
transport easily during runtime.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 6785dd842075889e5230d93ed9c0ab9c204ab432 |
|
19-Jun-2009 |
Christopher Tate <ctate@google.com> |
Store the app signatures as part of the backup set
Under a pseudo-app for the Package Manager, we store the app signatures for all
participating applications installed on the device. At restore time we will
restore this first, then ensure that the current on-device signature chain is
compatible with the one in the backup set. If there's a mismatch, this may be a
spoof attempt and we will refuse to restore that app's data.
The restore side of this is not implemented, but the Package Manager agent is
here as well as the backup side theoretically pushing the data now.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 87a02bcf68dd4cc1f6d9fdcee3d1ebc9b04cf1f8 |
|
17-Jun-2009 |
Dan Egnor <egnor@google.com> |
Replace the stub GoogleTransport with callout to the
GoogleTransportService (which lives in vendor/google).
Use the Google transport by default.
Also, fix a bug: Thread.run() != Thread.start()
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| aa088447baadd2e0bbcfd18cc529645610c13ddc |
|
17-Jun-2009 |
Christopher Tate <ctate@google.com> |
Hold the current transport instantiated all the time.
We no longer instantiate the transport just for the duration of handling a
backup or restore operation. Instead, we hold the object forever (replacing it
if instructed to do so). This makes it easier for transports to watch system
state and help set backup timing policy.
Also fixes up the IBackupTransport documentation a bit.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 63d2700036d0f73cbde27f0fa724d30045b4bb07 |
|
17-Jun-2009 |
Christopher Tate <ctate@google.com> |
Allow privileged callers to schedule a backup pass for any app.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| f68eb500f99361541049e09eb7f9ddd6f4ef4efa |
|
16-Jun-2009 |
Christopher Tate <ctate@google.com> |
More bmgr work; fix clear-data signalling
The 'list sets' and 'restore token#' commands from bmgr now do what they are
supposed to. At this point we see the restore target's data being cleared
properly and its agent being launched and invoked for restore.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| ace7f094bf07bbd90cb998b9462e4f2d101a498c |
|
16-Jun-2009 |
Christopher Tate <ctate@google.com> |
Sketch out a 'bmgr' command line tool
Not finished, but eventually will allow adb shell access to the Backup Manager
for testing purposes etc.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| cde87f45e0fa052d070b88ae33fb03c89870536a |
|
12-Jun-2009 |
Christopher Tate <ctate@google.com> |
Journal backup requests so that they won't be lost in a crash
When an application requests a backup via dataChanged(), we now journal that
fact on disk. The journal persists and is only removed following a successful
backup pass. When the backup manager is started at boot time, it looks for any
existing journal files and schedules a backup for the apps listed in them, on
the expectation that the device shut down or crashed before a backup could be
performed.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 9bbc21a773cbdfbef2876a75c32bda5839647751 |
|
11-Jun-2009 |
Christopher Tate <ctate@google.com> |
Flesh out restore interface on manager; work up most of LocalTransport
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| c7b31e3c3cd71129557d4bf9e3fbcebb9235aba5 |
|
11-Jun-2009 |
Christopher Tate <ctate@google.com> |
The rest of the basic flow for restore
Also moved the processOneBackup() implementation into the Thread class that runs
the backup sequence.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| df01deaacff82b918b4f0ba774d5ad3087543629 |
|
10-Jun-2009 |
Christopher Tate <ctate@google.com> |
More restore plumbing, plus add suggested-backoff to transport API
Adds most of the code for a background-thread restore process, structured much
like the backup thread. Broke some common functionality out into a helper
function for doing a synchronous wait for a requested agent to attach.
Added a method to IBackupTransport whereby the transport will be asked for
an opinion on whether this is a good time for a backup to happen. It will
reply with the results of its policymaking around backoff intervals, time-of-day
selection, etc.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 9b3905c4a25f2d785ce7535d1f2e1540b46bb561 |
|
09-Jun-2009 |
Christopher Tate <ctate@google.com> |
Revamp IRestoreSession a bit
We now supply an array of RestoreSet objects instead of wacky Bundle
shenanigans. Also, pushed beginRestoreSession() out to the BackupManager
concrete interface class so that SetupWizard can use it.
(beginRestoreSession() is @hide, non-privileged apps cannot use it. It's
also guarded by android.permission.BACKUP enforcement.)
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 8c850b792f2d371fd8a4aff146d9d757ee982539 |
|
08-Jun-2009 |
Christopher Tate <ctate@google.com> |
Add IRestoreSession interface for the restore flow
Restore is a fairly complicated, somewhat stateful process, so we introduce
a new interface to encapsulate the various bits and pieces into a nicely
separable component. In particular, this will make it much cleaner to
open and interrogate an expensive-to-construct transport and then reuse it
for the actual restore process itself.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 7b88128e08ba45b071cd714dad9681ce66920d32 |
|
07-Jun-2009 |
Christopher Tate <ctate@google.com> |
Adjust IBackupTransport interface
Instead of just passing a package name to performBackup, pass the whole
PackageInfo struct, explicitly including the list of signatures for the package.
No need to make each transport look this up individually when it's a necessary
part of the backup payload for each app.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| cd4ff2e72d42d66ea2d6a27f1c87cfffd16b1791 |
|
05-Jun-2009 |
Christopher Tate <ctate@google.com> |
Fix tracking of backup participants across package remove/update
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 1885b37913181230c36d6485bdd389f89fa90f43 |
|
05-Jun-2009 |
Christopher Tate <ctate@google.com> |
Fix backup agent unbind
The handwritten binder transaction passing wasn't propagating the agent-destroy
transaction to the client side. Oops.
Also, remove obsolete run-one-agent code from the backup manager service.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 043dadc7516d20c3b3ccbcb20c53aaeef076a237 |
|
03-Jun-2009 |
Christopher Tate <ctate@google.com> |
More backup work
* Put in some permission enforcement around agent connection notification
and full-backup scheduling.
* Full backup now applies to any package, not just backup participants who
have declared their own android:backupAgent
* The process of running the backup operation on the set of apps who have
been queued for it is now done in a separate thread, with a notification
mechanism from the main Backup Manager service to pass along new-agent
binding knowledge. There's no longer one do-backup message on the primary
Handler per target application.
* The new backup thread sets up the desired transport now and passes
along the newly backed-up data to it for each backup target. Two
transports have been defined so far, GoogleTransport and AdbTransport;
both are stubs at present.
Note that at present the backup data output file seems to be properly
created, but after doBackup() is called on the test app's agent it's
still zero size.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 181fafaf48208978b8ba2022683ffa78aaeddde1 |
|
14-May-2009 |
Christopher Tate <ctate@google.com> |
Retool the backup process to use a new 'BackupAgent' class
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.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| d2110dbce071a236b6176de344ca797b737542eb |
|
19-May-2009 |
Joe Onorato <joeo@android.com> |
Hook up the backup data writer, and add a utility to read the backup data files.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 290bb011c5c1a9ba1f2116810b06cf52a9c36b3e |
|
14-May-2009 |
Joe Onorato <joeo@android.com> |
Get the backup calling through to the file backup helper.
This includes some cleanup to make the parameters match
between BackupService.onBackup and FileBackupHelper.performBackup.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 8ad028117d4b99883bbc52b29f097b2fb1d9b0c2 |
|
13-May-2009 |
Joe Onorato <joeo@android.com> |
With this, the BackupService onBackup method is called.
It took a bunch of refactoring inside BackupManagerService,
which is unfortunately all temporary anyway, but it unblocks
a bunch of stuff.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| b1a7ffef3a0007b6991b8338460f6aac8cbb11e8 |
|
07-May-2009 |
Joe Onorato <joeo@android.com> |
More backup tests
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 3799bc241b5cfc876cf082fbf39acc67c90a25b7 |
|
07-May-2009 |
Christopher Tate <ctate@google.com> |
Track install/removal/update of packages that provide backup services
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| b1d790b63e2115be558d451efbc914d1f8dfa846 |
|
06-May-2009 |
Christopher Tate <ctate@google.com> |
Pass null as savedState to indicate a full backup is required
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 46758123868d91e7b186aebb27c4c4988dede43e |
|
06-May-2009 |
Christopher Tate <ctate@google.com> |
Add a Backup Manager interface to request a full backup
Given a package name, the Backup Manager schedules a *full* (i.e. non-
incremental) backup pass for that package. Also added the state-file
handling for distinguishing to the target between the full and incremental
backup requests.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| f417247fa68524f2f34960f7389168eed7eb4a88 |
|
06-May-2009 |
Christopher Tate <ctate@google.com> |
Further development of backup file handling
Put backup data in flight into /cache
Close the files and delete the intermediates after backup pass
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 22b8787ed4be8d4b7ed5d54802f9913fedb41425 |
|
05-May-2009 |
Christopher Tate <ctate@google.com> |
Squashed commit of the following:
Author: Christopher Tate <ctate@google.com>
Date: Mon May 4 16:38:11 2009 -0700
IBackupService now passes ParcelFileDescriptors rather than int fds
The outlines of backup state file / data file handling are now in place as well
in the BackupManagerService.
Author: Christopher Tate <ctate@google.com>
Date: Thu Apr 30 12:40:19 2009 -0700
Hide the backup stuff for now
Also adjust based on comments:
+ changed service intent string to conform to usage guidelines
+ only publish the IBackupService binder when invoked with the right
intent action
+ docs tweaks
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| a8bf815c6153290b173f34b071dddb0a0034a115 |
|
30-Apr-2009 |
Christopher Tate <ctate@google.com> |
Add android.backup.BackupManager
Also tweak the dataChanged() api to have the client supply a package name. We
don't necessarily TRUST this, but we use it to narrow the set of packages requesting
a backup pass, no longer blithely scheduling a pass for all packages associated
with the caller's uid.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|
| 487529a70cd1479ae8d6bbfb356be7e72542c185 |
|
29-Apr-2009 |
Christopher Tate <ctate@google.com> |
First baby steps towards settings backup
This change adds a sketched outline of the backup system architecture, with
all of the major pieces represented other than client-side helpers for
specific types of data. IBackupManager and BackupService are public so that
we can write test apps against SDK-domain symbols from the outset.
What code exists in this change hasn't been tested and may crash. It's the
beginnings of the real implementation but of course is barely begun.
/frameworks/base/services/java/com/android/server/BackupManagerService.java
|