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
First step of improving app screen size compatibility mode. When
running in compat mode, an application's windows are scaled up on
the screen rather than being small with 1:1 pixels.
Currently we scale the application to fill the entire screen, so
don't use an even pixel scaling. Though this may have some
negative impact on the appearance (it looks okay to me), it has a
big benefit of allowing us to now treat these apps as normal
full-screens apps and do the normal transition animations as you
move in and out and around in them.
This introduces fun stuff in the input system to take care of
modifying pointer coordinates to account for the app window
surface scaling. The input dispatcher is told about the scale
that is being applied to each window and, when there is one,
adjusts pointer events appropriately as they are being sent
to the transport.
Also modified is CompatibilityInfo, which has been greatly
simplified to not be so insane and incomprehendible. It is
now simple -- when constructed it determines if the given app
is compatible with the current screen size and density, and
that is that.
There are new APIs on ActivityManagerService to put applications
that we would traditionally consider compatible with larger screens
in compatibility mode. This is the start of a facility to have
a UI affordance for a user to switch apps in and out of
compatibility.
To test switching of modes, there is a new variation of the "am"
command to do this: am screen-compat [on|off] [package]
This mode switching has the fundamentals of restarting activities
when it is changed, though the state still needs to be persisted
and the overall mode switch cleaned up.
For the few small apps I have tested, things mostly seem to be
working well. I know of one problem with the text selection
handles being drawn at the wrong position because at some point
the window offset is being scaled incorrectly. There are
probably other similar issues around the interaction between
two windows because the different window coordinate spaces are
done in a hacky way instead of being formally integrated into
the window manager layout process.
Change-Id: Ie038e3746b448135117bd860859d74e360938557
Clicking on a node in hierarchyviewer1 and hierarchyviewer2 and then
clicking the new "Dump DisplayList" button will cause the display
list for the selected node (including its children) to be output into
logcat.
Change-Id: Iad05f5f6cca0f8b465dccd962b501dc18fe6e053
Clicking on a node in hierarchyviewer1 and hierarchyviewer2 and then
clicking the new "Dump DisplayList" button will cause the display
list for the selected node (including its children) to be output into
logcat.
Change-Id: Id32f62569ad1ab4d533bc62987f3a7390c1bb4e6
Introduce NetworkStats which is a collection of network statistics,
which should match the structure communicated by kernel module through
netd. Will introduce tags and fg/bg stats later. Kept entirely in a
flat data structure to optimize parcel speed.
Initial pass at returning NetworkStats from NetworkManagementService,
both summary and details. Will eventually pull data from kernel module
over netd connection.
Change-Id: I92d9f61678ec8c22e2ce26775fb035a0cf32413f
It is not safe to call into vold with a lock held on mVolumeStates
since we will receive events back from vold on a different thread.
So in the boot completed handler we make a copy of the volume list and
then call vold to mount volumes after releasing the lock
Change-Id: Iaadfb1b8be5567c8e228a8fbc69d4d483c8dc987
Signed-off-by: Mike Lockwood <lockwood@android.com>
Settable per network so you can have not timeout for some and some for others.
If you set the old NETWORK_RESTORE_DELAY_PROP_NAME system property
(android.telephony.apn-restore) it will override this value.
Change-Id: Icca706fdc74245dce679209116660e5dc4b05d23
It is not safe to call into vold with a lock held on mVolumeStates
since we will receive events back from vold on a different thread.
So in the boot completed handler we make a copy of the volume list and
then call vold to mount volumes after releasing the lock
Change-Id: Ic9836c2e1e8a5677d0c4e33476a72081f69823a0
Signed-off-by: Mike Lockwood <lockwood@android.com>
Use multiple DNS resolutions to the same IP address
as an indication to launch a web view for authentication
Bug: 4378442
Change-Id: Id3cf1e3c5b5bee4468665d0459ac945e5b12e730
* commit '75c664582c5ce5d94826f37cb725b447a4d62c50':
Backporting I57c58c4083bd59f45095c184d6ca5a302f79ff6e to HC-MR1. New change since file was renamed, making cherry-pick impossible.
* commit '8325c3a89197e47cfc2eeb4117c927fb8cb91630':
Backporting I57c58c4083bd59f45095c184d6ca5a302f79ff6e to HC-MR1. New change since file was renamed, making cherry-pick impossible.
Wrote initial suite of tests for ThrottleService, checking a variety
of edge cases. Checks going over limits, updating policies, and reset
after cycle elapses.
Moved NTP code in ThrottleService into new TrustedTime interface,
which makes it easier to understand, and allows tests to provide custom
clocks.
Change-Id: I0d62b8b3a169516a2ab2d33025f6fe30dc792be8
1. Added an Input Filter that interprets the touch screen motion
events to perfrom accessibility exploration. One finger explores.
Tapping within a given time and distance slop on the last exlopred
location does click and long press, respectively. Two fingers close
and in the same diretion drag. Multiple finglers or two fingers in
different directions or two fingers too far away are delegated to
the view hierarchy. Non moving fingers "accidentally grabbed the
device for the scrren" are ignored.
2. Added accessibility events for hover enter, hover exit, touch
exoloration gesture start, and end. Accessibility hover events
are fired by the hover pipeline. An accessibility event is
dispatched up the view tree and the topmost view fires it.
Thus predecessors can augment the fired event. An accessibility
event has several records and a predecessor can optionally
modify, delete, and add such to the event.
3. Added onPopulateAccessibilityEvent and refactored the existing
accessibility code to use it.
4. Added API for querying the currently enabled accessibility services
by feedback type.
Change-Id: Iea2258c07ffae9491071825d966dc453b07e5134
This reverts commit ac84d3ba81f08036308b17e1ab919e43987a3df5.
There seems to be a problem with this API change. Reverting for now to
fix the build.
Change-Id: Ifa7426b080651b59afbcec2d3ede09a3ec49644c
Not yet working, so turned off.
Also fix a bug where the display size configuration became inconsistent
after a configuration change -- we now figure out everything about the
display size when computing a new configuration.
1. Added an Input Filter that interprets the touch screen motion
events to perfrom accessibility exploration. One finger explores.
Tapping within a given time and distance slop on the last exlopred
location does click and long press, respectively. Two fingers close
and in the same diretion drag. Multiple finglers or two fingers in
different directions or two fingers too far away are delegated to
the view hierarchy. Non moving fingers "accidentally grabbed the
device for the scrren" are ignored.
2. Added accessibility events for hover enter, hover exit, touch
exoloration gesture start, and end. Accessibility hover events
are fired by the hover pipeline. An accessibility event is
dispatched up the view tree and the topmost view fires it.
Thus predecessors can augment the fired event. An accessibility
event has several records and a predecessor can optionally
modify, delete, and add such to the event.
3. Added onPopulateAccessibilityEvent and refactored the existing
accessibility code to use it.
4. Added API for querying the currently enabled accessibility services
by feedback type.
Change-Id: Iec03c6c3fe298de3f14cb6efdbb9b198cd531a0c
