History log of /frameworks/base/tests/backup/Android.mk
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
83c64e6b624a876436d2ef5d2f173b10407e27b4 21-Feb-2012 Mathias Agopian <mathias@google.com> frameworks/base refactoring

create the new libandroidfw from parts of libui and libutils

Change-Id: I1584995616fff5d527a2aba63921b682a6194d58
c882ddacc8b3085a51f8ae18d89d8fd1d055141f 20-Feb-2010 Ying Wang <wangying@google.com> Fix Proguard flags.
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

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

* 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
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.
b1a7ffef3a0007b6991b8338460f6aac8cbb11e8 07-May-2009 Joe Onorato <joeo@android.com> More backup tests
f9225f89aafa13dcbc3a69a721acf9b76c34485c 06-May-2009 Joe Onorato <joeo@android.com> Add a test app for the backup
3ad977b41c6e4ef30c2f4f316b909b742ffc04aa 05-May-2009 Joe Onorato <joeo@android.com> Add some C++ code to do raw files for backup