Usage: adb restore [tarfilename]
Restores app data [and installs the apps if necessary from the backup
file] captured in a previous invocation of 'adb backup'. The user
must explicitly acknowledge the action on-device before it is allowed
to proceed; this prevents any "invisible" pushes of content from the
host to the device.
Known issues:
* The settings databases and wallpaper are saved/restored, but lots
of other system state is not yet captured in the full backup. This
means that for practical purposes this is usable for 3rd party
apps at present but not for full-system cloning/imaging.
Change-Id: I0c748b645845e7c9178e30bf142857861a64efd3
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
The onUpgrade path was upgrading the database version to 65, but the
current version was marked as 64. That led to the database being
upgraded to 65 and then wiped because it didn't match 64.
This was introduced in HC change 54d068ec6af0ee6d261a135400efe6816c6f5ffe
Bug: 4319406
Change-Id: Ib6efcf34e820948d23d3a2b8ef3afc9012a93c22
bug:3505060
Since we want to have some settings that are used very frequently
by many applications (long-press timeout is one example) these should
be managed efficiently to reduce lookups from different processes
because in the case of a cache miss a disk I/O is performed. Now
the system manages such core settings and propagates them to the
application processes.
Change-Id: Ie793211baf8770f2181ac8ba9d7c2609dfaa32a7
Modified default volume control logic in AudioService:
1 IN_CALL volume if in video/audio chat
2 NOTIFICATION if notification is playing or was playing less than 5s ago.
3 MUSIC
Modified silent mode:
- now also affect MUSIC stream type
- entering silent mode when VOL- hard key is pressed once while selected
stream volume is already at 0 (except for VOICE_CALL stream).
- exiting silent mode when pressing VOL+ hard key while in silent mode
Play sound FX (audible selections, keyboard clicks) at a fixed volume.
Modified audio framework:
- isStreamActive() method now implemented in AudioPolicyManagerBase (previously AudioFlinger)
- iStreamActive() now specifies a time window during which the stream is considered
active after it actually stopped.
Change-Id: I7e5a0724099450b9fc90825224180ac97322785f
Enable retrieving the default download manager settings from
a resource, when the SettingsProvider database is created
The default setting for these values is -1, which will cause
DownloadManger to not enforce a limit.
Bug: 3341145
Change-Id: I25294d0f75fb0bdf20d4bef54457056c25c31add
Bug: 3365600
This doesn't affect upgrades, only new installs.
Don't backup/restore NOTIFICATIONS_USE_RING_VOLUME anymore as it doesn't
work well across device types and can wedge the device into a state
where you can never hear notification sounds.
Change-Id: I703e1db539eb4ac45b273f46ada0b4bbf3b981bb
bug:3341772
1. Now a key in the binding is represented as a long with 32 MSB for modifiers and 32 LSB for keyCode.
bug: 3340732
1. Added check in the WebView key handling code to diable the accessibility injector/injected script in
case accessibility is been disabled after loading the content.
Change-Id: Ic3746dff16ec77ba682a5b139cec0e6afd8fc839
why is settingsprovider doing getReadbleDatabase() in onCreate() method?
it shoul do getWritableDatabse() so that sqlite's WAL
feature can be enabled on it.
Change-Id: I60e46ce240a6474bbb50ab26fb1d979242b0c9ad
1. Added a mechanism to select the cursor ring content if accessibility is
enabled - This is achieved by sending an event to the WebCore thread
(if accessibility is enabled) to select the content of the cursor when
the latter moves. Added code in WebViewCore to select the given node
and notify the UI thread for the selection markup which is delivered
of the accessibility injector which manages sending accessibility
events. This is relevant for adding accessibility to WebView if
JavaScript is not enabled. (If JS is enabled we inject a screenreader
written in JS).
2. Fixed the event delegation to the accessibility injector since it
should be able to consume key events of interest and perform some
action which leads to sending appropriate accessibility event.
In the previous implementation it was possible that the injector
consumes the event but the latter was bubbled up.
3. Added function to scroll the selection into view while moving it
around based on user commands.
Note: This is a part of two project commmit.
Change-Id: Ibb81d0468726efbe3bf6e3add1b19c69e3206638
Also modified the shortcut key handling so that it drops chorded
Search+X keys when even if no shortcut was found. Without this
change, pressing an unhandled shortcut causes the Search widget to
pop up and the character to be typed.
Bug: 3022227
Change-Id: Ic0921428bd1270604ca28caf1f8493727127f4ed
IWindowManager now supports two new methods,
freezeRotation() and thawRotation(), that allow a caller to
temporarily stash the device's current rotation as the
default rotation (when no other constraints are present).
The system bar uses this to implement a user-accessible
rotation lock by calling freezeRotation() and then turning
off accelerometer-based display rotation; unless overridden
by an app, the display will continue to appear in the frozen
rotation until the rotation is unlocked by the user (either
via the rotation lock icon in the system bar or by checking
"rotate screen automatically" in Settings).
Bug: 2949639
Change-Id: Icd21c169d1053719590e72401f229424b254622f
Don't be tricky when trying to set the seed for the secure
random number generator. Setting the seed manually eliminates
the internal randomization the SecureRandom class does automatically,
reducing randomness. Just use the default seed, which is designed
to be safe.
Change-Id: I5747c2b3a10cf04e33d2202195951ed5cb82b2fe
Merge commit '04bc807057d1c336a5d1340595b790eee4c5b372'
* commit '04bc807057d1c336a5d1340595b790eee4c5b372':
Allow Bluetooth radio to be toggled in Airplane mode.
Add "bluetooth" to the list of toggleable radios. Because this string
is in the Settings DB, I had to bump the version number. Why is this in
the settings DB anyway, rather than a carrier config option?
I also discovered that the SystemUI package copied the entire contents of
res/values/defaults.xml from SettingsProvider, when I originally tried
to update the unreferenced SystemUI version of the setting. To prevent
future confusion, I removed all of the values from the SystemUI version
of res/values/defaults.xml.
Change-Id: Ib8a75c85b9db5c1963b65538ee2765d5087e67d2
This can be used as a compatibility workaround for host operating systems
without MTP support.
Change-Id: If4f1856206056ca8e40c3ffbfa382f185c413598
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit '603a1f59703109c89ec0fdeceb0f8d28c7cede22'
* commit '603a1f59703109c89ec0fdeceb0f8d28c7cede22':
Fix some bugs in SettingsProvider that I introduced the other day.
Merge commit '384759b1c5e39d0f99fa551a369ae73197ab26c5'
* commit '384759b1c5e39d0f99fa551a369ae73197ab26c5':
Make the default backup configuration "disabled; local transport selected"
Merge commit '02e18d4d4eed949da02fd8aa87801858d99b902a' into gingerbread
* commit '02e18d4d4eed949da02fd8aa87801858d99b902a':
Make the default backup configuration "disabled; local transport selected"
The settings database cache is tiny (or should be tiny) and can be
slurped into memory. Once it's in memory and we know we have it all
we can avoid going to disk at all for keys not in the cache.
This is a big percentage of the StrictMode violations & latency.
Change-Id: I649411be0c40d348f58376ccfb3eda059fd69fbc
By default out of the box, an Android build will have the backup mechanism in
its "disabled" state and pointed to the LocalTransport test transport. We
do not want retail devices built without the Google backend to have backup
enabled out of the box; it would cause them to gradually grind away the
cache partition for no good reason. On those devices with this change,
developers would need to enable backup manually (possibly using the normal
Settings UI; more probably using the 'bmgr' shell tool), but would no longer
also have to manually configure the active transport name.
Device vendors producing Google-enabled products will simply use resource
overlays to configure the default state and transport name for their builds.
When building a product that points to the Google backup transport by default,
the "def_backup_enabled" boolean resource should still be set to 'false' --
the Google backup disclosure activity supplied by GSF will take care of
enabling the backup services if the user opts in to it. (Basically, vendors
will never have to overlay the def_backup_enabled resource -- the default
value of 'false' is correct for any retail device regardless of whether it
can use the Google backup transport.)
In the SDK build, the default transport will remain the local one, but
the default enable state overridden and set to "true". This is the ideal
situation for developers: all aspects of the backup mechanism immediately
operative with no manual configuration needed.
Change-Id: I866f8f627b023b338bc7757e61604e6d8a901a34
Merge commit '36c051c717391afe12a1fe8163960286175f2f7e'
* commit '36c051c717391afe12a1fe8163960286175f2f7e':
make android_id random seed depend on time as well as ro.serialno
Merge commit '0fe27cf5bd1407bc7b4eabefaa91ff535582badc' into gingerbread
* commit '0fe27cf5bd1407bc7b4eabefaa91ff535582badc':
make android_id random seed depend on time as well as ro.serialno
