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
We need this to allow MTP to access secondary external storage devices
This reverts commit 35a2ea2fbf.
Conflicts:
data/etc/platform.xml
Change-Id: I9faf54526182a786a1c0ca1fd01a09baabca186d
Signed-off-by: Mike Lockwood <lockwood@android.com>
You can remove sub-tasks inside of a task, or an entire task.
When removing an entire task, you can have its process killed
as well.
When the process is killed, any running services will get an
onTaskRemoved() callback for them to do cleanup before their
process is killed (and the service possibly restarted).
Or they can set a new android:stopWithTask attribute to just
have the service automatically (cleanly) stopped at this point.
Change-Id: I1891bc2da006fa53b99c52f9040f1145650e6808
The NFC service relies on this permission
for it's dispatching mechanism and it is
no longer signed with the platform cert.
Bug: 4173610
Change-Id: I598ad2889c4af307f04433093923255fe7daedbb
- In Connectivity service, start WiMAX service
- 4G icon display in StatusBarPolicy
- Add DHCP renew
- Add radio for WiMAX
Change-Id: Iffff012b270d80e84ec8fbd4486921a8adb847dd
Signed-off-by: TK MUN <tk.mun@samsung.com>
New APIs:
UsbManager.hasPermission returns true if the caller has permission
for the given device or accessory
UsbManager.requestPermission poses a dialog to allow the user to give the caller
permission for the device or accessory.
Result is returned via a PendingIntent.
No dialog is displayed if the caller already has permission.
Also moved UsbResolverActivity to SystemUI package
BUG: 4069037
Change-Id: I93be769501a8776b49ac26e468af19f8fa2114c9
When a USB device or accessory is connected, the UsbService now asks the
user which application to associate with the device or accessory.
Applications interested in devices or accessories must specify the
devices they work with via meta-data attached to their manifest.
Permission to communicate with the device is assigned when the user chooses
the activity to use for the device.
The user has the option of clicking the "always use this application" checkbox
to make the assignment automatic in the future.
The user may later clear this preference and revoke permission for an application
to have permission to communicate with the device by clicking the "Clear defaults"
button for the activity in the Manage Applications panel in Settings.
Added class UsbResolveActivity (a subclass or ResolveActivity for choosing
an activity for a USB device or accessory)
Added UsbDeviceManager, which manages the mapping between USB devices/accessories
and applications, including default applications for devices and accessories,
and manages application permissions.
Add interface to allow Settings to clear device and accessory
preferences and permissions for an application.
Remove obsolete ACCESS_USB permission.
Add new signatureOrSystem MANAGE_USB permission to allow administrating
preferences and permissions.
Moved UsbService.java to a "usb" subdirectory, along with new classes
UsbResolveActivity and UsbDeviceManager.
Change-Id: I92554381e9779e68ce380daaee4e1401fb875703
Signed-off-by: Mike Lockwood <lockwood@android.com>
The package manager now keeps track of whether an application is
stopped. There are new intent flags to control whether intent
filters in a stopped application will match the intent. This is
currently used in one place, sending broadcasts, so that stopped
apps can not be launched due to background processes.
The package manager during first init makes sure no applications
are in the stopped state. When new applications are installed,
that begin in the stopped state. When the activity manager is
launching a component of an application, it ensures the application
is taken out of the stopped state.
The "force stop" button in manage applications will now put an
application back in to the stopped state; it can't go back out
of the stopped state until one of its components is launched by
the activity manager.
There will probably be a few more places where we need to filter
stopped applications out of intent matches, but doing this for
broadcast is a very big first step.
This also introduces a new broadcast that is sent to an application
after it is replaced with a new .apk. But only if the app is not
in the stopped state. This makes it a lot easier for developers to
implement code to get their application back in proper running shape
after an upgrade.
Finally another new broadcast is added that is sent to a package's
installer at the first time it is launched. This allows the installer
to tell the package about it being installed only when it is first
actually used.
Change-Id: I589c53ff0e0ece868fe734ace4439c0d202dca2d
USB accessories are peripherals that connect to android devices as a USB host.
When connected, the accessory will first identify itself to the android device
by sending manufacturer, product, accessory type and version strings
to the device, and then request the device to enter USB accessory mode.
The device will then enable the USB accessory kernel driver and disable
all other USB functionality except possibly adb
(adb can be used while the android device is connected to the PC
and the PC is running software that emulates a USB accessory)
The class android.hardware.UsbAccessory is used to describe the
currently attached USB accessory.
UsbAccessory contains the manufacturer, product, accessory type
and version strings to identify the accessory.
The accessory can be opened as a ParcelFileDescriptor, which can be used
to communicate with the accessory over two bulk endpoints.
The Intents UsbManager.USB_ACCESSORY_ATTACHED and
UsbManager.USB_ACCESSORY_DETACHED are broadcast when accessories are
connected and disconnected to the device. The USB_ACCESSORY_ATTACHED
contains a UsbAccessory object for the attached accessory as an extra.
The Intent also contains string extras for the manufacturer, product,
accessory type and version strings to allow filtering on these strings.
Change-Id: Ie77cbf51814a4aa44a6b1e62673bfe4c6aa81755
Signed-off-by: Mike Lockwood <lockwood@android.com>
- change from signatureOrSystem to normal
- no longer associate this permission with the "usb" unix group
- add to public API
Change-Id: I3be3a5d138719dd126ff0a798824a77f9ce79e24
Signed-off-by: Mike Lockwood <lockwood@android.com>
UsbManager:
- is now a service retrievable via Context.getSystemService(Context.USB_SERVICE).
- provides support for returning a list all connected USB devices
- broadcasts ACTION_USB_DEVICE_ATTACHED and USB_DEVICE_DETACHED when devices
are added and removed from the USB host bus
UsbDevice:
- represents an attached USB device.
UsbInterface:
- represents an interface on a USB device
- devices may have multiple interfaces if they provide multiple
sets of functionality (for example, android phones typically have interfaces
for both USB mass storage and adb)
UsbEndpoint:
- represents an endpoint on a USB interface
- endpoints are used for sending or receiving data
(only in one or the other direction)
UsbRequest:
- encapsulates a send or receive request to be sent over an endpoint
Change-Id: Ieef3e434c62760770ea839070cf5eba1a705967a
Signed-off-by: Mike Lockwood <lockwood@android.com>
- Moving the service binding to AppWidgetService to prevent arbitrary apps from binding to widget services
- Requiring RemoteViewsServices to require android.permission.BIND_REMOTEVIEWS permission
Change-Id: Id135bafba998299eb278067712b8a5d8487cfd04
Access to the /data/media directory is now restricted exclusively to the
sdcard daemon, so there is no longer a need for this permission.
Change-Id: Iea8400f0eee167df19cc231c502d251a364f98b3
Signed-off-by: Mike Lockwood <lockwood@android.com>
This permission is not needed for non-system or unbundled apps,
so we don't need it in the public API
Change-Id: I1a2a0349c6c5b7b5dc3104d69f4e39e95b878db9
Signed-off-by: Mike Lockwood <lockwood@android.com>
Since the "usb" group and ACCESS_USB permission will be used by regular apps
to access USB devices in host mode, we need a separate permission for the
device side MTP driver.
Change-Id: Id03f7c4f3d2712c489b4b74cf17a72a182084501
Signed-off-by: Mike Lockwood <lockwood@android.com>
These broadcasts no longer exist, so remove their <protected-broadcast> elements from the manifest.
Signed-off-by: Mike Lockwood <lockwood@android.com>
Change-Id: I4a724509d3058f16283870f02e5e1b51dfb21a43
It was moved so it was no longer in the location that
SyncManager expected. I fixed it by (a) moving it to the
SyncManager directory and by (b) changing the SyncManager to
refer to it by class rather than by class name, which means
it will now check for it at compile time, not run time.
Bug: 3289922
Change-Id: I24f8bac371a16c62c2a38ed1024702c6d0913b93
ACTION_TAG_DISCOVERED is a start activity intent, not a broadcast intent, so
its presence in this list is redundant.
Change-Id: I05419ec9c4471b7b11c9ae50a02e5ac3d9e572d2
