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.
The system now keeps a tag of the last version (just an arbitrary string)
that the setup wizard was run for. If this is different than the current
one in the setup wizard, then setup is launched at boot.
This introduces a new intent action for the part of the setup wizard that
gets run for an ungrade, which the system uses to find its current version
tag for comparing against what was last stored. It is up to the launched
setup activity update the stored setting to reflect its current value,
once it is happy.
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.
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.
Merge commit '6f317426e49e73ef3e50d8839877504039cd2fca'
* commit '6f317426e49e73ef3e50d8839877504039cd2fca':
Don't issue a deletion for the global metadata backup
This is a little hacky -- we just assume that if adb is enabled and power
is connected through usb, then it is active.
The icons and text are temporary until final design is provided.
It turns out this was not a problem in the resource code at all. Rather,
the system process has a cache of pre-loaded attributes it uses to avoid
continually reloading things as it needs them. Well it turns out this
cache wasn't flushed after a package was uninstalled or a configuration
changed, so you could re-install an app where you change its style resources
so its theme now points to one that is inconsistent in the cache.
This is mostly a problem for developers, where they continually install
new versions of an app where resources have changed. This could possibly
show up when updating an app on a normal phone, although the problem would
eventually correct itself since this cache uses weak references.
Anyway, the cache is now reworked to be flushed appropriately.
This change also includes an update to aapt to be able to dump the
contents of bags in resources.
We now store the app version codes and and global OS incremental version name in
the PM backup state and the actual backup record. We then use that information
to trigger a re-backup of the metadata if the OS revision changes in any way, or
to back up single apps' metadata if we notice that they've been upgraded.
Merge commit '9171749700853305f3e6abbcdbd9e02f3a71d459'
* commit '9171749700853305f3e6abbcdbd9e02f3a71d459':
Use system properties to track the current transport
We were accidentally submitting a deletion for the global metadata key in the
PM backup handling (it was falling into the usual "here's a package that we said
we'd backed up last time, but now it's no longer on device" code). Don't do
that any more, i.e. actually keep the global metadata key in the backup set.
Oops.
Merge commit '72eb0acad5cffc57ce5006f6deab29ee259e461e'
* commit '72eb0acad5cffc57ce5006f6deab29ee259e461e':
Expand support for different screen sizes.
Merge commit '8a27f923eb9dbbe3c2d0184e82d9f1a98f1e4cdc'
* commit '8a27f923eb9dbbe3c2d0184e82d9f1a98f1e4cdc':
Don't crash in various ways when using backup services too early
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.
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.
Fiddle around with event dispatching to remove calling permissions when we
enter event injection, and prevent callers from going to the PhoneWindowManager's
event processing code unless they are allowed at that point.
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.
Applications can now declare that they support small, normal, or
large screens. Resource selection can also be done based on these
sizes. By default, pre-Donut apps are false for small and large,
and Donut or later apps are assumed to support all sizes. In either
case they can use <supports-screens> in their manifest to declare
what they actually support.
BackupManager now no longer tries to use a null service binder if it's used
early during the boot process. ActivityManagerService no longer tries to
dereference null pointers if bind/unbind semantics get out of step due to things
being run too early.
Merge commit '7d562ec393d54dd9ef387c49d1283243bfdbd2b1'
* commit '7d562ec393d54dd9ef387c49d1283243bfdbd2b1':
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.
Merge commit '5cb400bd72726c22f641f334951b35ce2ddcfeef'
* commit '5cb400bd72726c22f641f334951b35ce2ddcfeef':
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.
