| Age | Commit message (Collapse) | Author |
|---|
|
Part of bug #2545514
Change-Id: Ic775e3b942c485252149c1b6c15c88517fa4e3e5
|
|
Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
|
|
+ Now rechecks the cached IBinder each time the wrapper is used, and if it's
still null (i.e. the BackupManager was constructed before the system service
came up) it's refetched. This lets even system code cache a single
BackupManager instance and just keep making calls through it without worrying
about interactions with the life cycle of the backup service.
+ Added a static dataChanged(packageName) method as a convenience for code that
needs to indicate that some other package needs a backup pass. This is useful
even for third party code in the case of multiple packages in a shared-uid
situation.
|
|
(which nobody had ever tested. I like it when stuff
just works the first time).
|
|
(It turns out that we do. It didn't used to work, I'm not
sure what changed)
|
|
the backup is done.
|
|
|
|
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.
|
|
because they'll always go in the same order, and this lets
us not have to write headers to keep them paired.
|
|
|
|
- BackupTestAgent calls the DispatchHelper
- Make BackupAgent.onRestore take a BackupDataInput, not just a
generic ParcelFileDescriptor.
|
|
|
|
methods on BackupDataOutput.
|
|
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.
|
|
This includes some cleanup to make the parameters match
between BackupService.onBackup and FileBackupHelper.performBackup.
|
|
It took a bunch of refactoring inside BackupManagerService,
which is unfortunately all temporary anyway, but it unblocks
a bunch of stuff.
|
|
|
|
|
