| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Change-Id: I22e8f15798ef15540c370bb14eea6cf9af6ae43c
Auto-generated-cl: translation import
|
|\
| |
| |
| |
| | |
* commit 'e3c38a0b0ebefa0a86be944259467c8acc9e5e49':
Fix recents theme, add missing headers
|
| |
| |
| |
| | |
Change-Id: Ib8eea6153eaf7e0e93e54c69fe59e63e98a409a6
|
| |
| |
| |
| |
| | |
Change-Id: I11f3f5a70625de845a8afcbffef04e274a8a73c9
Auto-generated-cl: translation import
|
| |
| |
| |
| |
| | |
Change-Id: I735b0a0de031b145b54b9cf643b7e91bb40c426d
Auto-generated-cl: translation import
|
|/
|
|
|
| |
Change-Id: I7aef0ba2b5f45b3e60d7840408176c6a61d9d8ee
Auto-generated-cl: translation import
|
|
|
|
|
| |
Bug:11340849
Change-Id: Ib99486303927a6bce308b113d70f8e5b5bce4a13
|
|
|
|
|
| |
Change-Id: Ib85aee9822ee5258fb7ad1b2d8e7c65c71991803
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: I2dfe3d6bca7948bce139f0f0f1404214ad8c99f2
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: Ieb610ced7d3f541bc238646988904ed1cb7cee7a
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: I2d9b9480f24eed9e6ec962222d212bbfb1179cde
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: I58312f6de5060de6fdf5815a304c3ba502b717ce
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: Ib755452de5a0757b20e644634a0cfbec59cdf235
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: I400da658acf872787f81dc223a4c3cf40ceb2f50
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: I3560b16b347b71c61ad1f723d444dbd056ee0d8f
Auto-generated-cl: translation import
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"signatureOrSystem" permissions are no longer available to all apps
residing en the /system partition. Instead, there is a new /system/priv-app
directory, and only apps whose APKs are in that directory are allowed
to use signatureOrSystem permissions without sharing the platform cert.
This will reduce the surface area for possible exploits of system-
bundled applications to try to gain access to permission-guarded
operations.
The ApplicationInfo.FLAG_SYSTEM flag continues to mean what it is
says in the documentation: it indicates that the application apk was
bundled on the /system partition. A new hidden flag FLAG_PRIVILEGED
has been introduced that reflects the actual right to access these
permissions.
At some point the "system" permission category will be
renamed to "privileged".
Bug 8765951
Change-Id: I6f0fd9cdb9170e076dfc66d83ecea76f8dd7335d
|
|
|
|
|
| |
Change-Id: I6ac969ffc6fbffeb262ec79b14a4155f2123d82d
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: Ie31e6632a217b9b9c7c0ebb79b16747830370db1
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: I830962076909bd65156b0e56bc8b9a4f44b7b249
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: I2f901cb989904c4325c2064428e4b8b0b2225d06
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: Ied34352ea4e79b01a9b8549596a381fe08ee7e06
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: I8b0d4f8146956bb0569ec01ef0872ad0a7065f0c
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: I819f42df4c6909d695e78420670d76919a497c06
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: I37cdf72141038d6677c0ffe3f1ef6f65bf6fd78a
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: I4036c81a0a932e366969e9e333bbe3c5d46a9cd8
Auto-generated-cl: translation import
|
|
|
|
|
| |
Change-Id: Iabb056f645a910f3fbaea1e51348c3bef385546e
Auto-generated-cl: translation import
|
|
|
|
|
|
|
|
|
|
|
| |
The confirmation UI did not request the needed permission, so was failing
to communicate with the mount service; as a "safe" failure mode, it was
assuming the device was encrypted. Fixed; now it presents the correct
prompt text for the device's encryption state.
Bug 5958195
Change-Id: Ic03db16673b89d3377e0362a09cf51bfb572d78b
|
|
|
|
| |
Change-Id: Ie43246df49b8f6ef3daef12e0d8fb5c2f573874e
|
|
|
|
| |
Change-Id: I71efb16f2c6b257dfd444728c7e56ada662e6f77
|
|
|
|
| |
Change-Id: I5db0a5df334833af2e2109123d05a9f76c745cf6
|
|
|
|
| |
Change-Id: I83ab00ec220b7c0ba0d37e7f4c91e945e35aab39
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This supersedes any backup-password that the user might supply. Per
design, the device encryption password is also always used to encrypt
the backup archive.
The CL introduces two new strings, used for prompting the user for
their device encryption password rather than their settings-defined
"backup password" when confirming a full backup or restore operation.
Bug 5382487
Change-Id: I0b03881b45437c944eaf636b6209278e1bba7a9f
|
|
|
|
| |
Change-Id: Id046f8008aef32a1b94b4fa5b57e2beb2f9f2e80
|
|
|
|
| |
Change-Id: Ic8e228878fde375b90797c6e344fcb3114180f1d
|
|
|
|
| |
Change-Id: I5e375bebc8f74d9108a929246f16608427ce9317
|
|
|
|
|
|
| |
...in the full backup/restore confirmation UI.
Change-Id: I858a2d7017450f016afe5052aa37161a1c89c281
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the confirmation uses the same Activity but different layouts
for the backup vs restore cases, we have to do the title in code.
Along the way, fix the restore layout's padding [the backup layout
was already right].
Fixes bug 5164470
Change-Id: I4d636f666d97fc377e9cf36abf08d1625a05577f
|
|
|
|
| |
Change-Id: I6e7f33ff16557f7e9088c0aa66fd1c79ed376c75
|
|
|
|
| |
Change-Id: Iac73006cfaf846d210855496f6732cbdc6ad0de8
|
|
|
|
| |
Change-Id: I51e1fc94b7fa3fec13f7dddad62b978dd9a71d43
|
|
|
|
| |
Change-Id: I51335fa15a40d471010dbcc96e228b170f06ce7e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now don't automatically deny the operation if stopped, but instead
allow the activity to be destroyed and recreated as usual. We retain
the observer instance across that sequence so we keep getting progress
reports etc.
The UI now also uses the spiffy new button bar styles, and positions
the deny / confirm buttons according to ICS standards.
Bug 5115411
Change-Id: Ie760a0c8496c69f9d5881273a63ad5b5b76ff554
|
|
|
|
|
|
|
|
|
|
|
| |
Now the textual content and password fields are placed in scroll view,
and the confirm/deny buttons pinned at the bottom of the layout.
Previously, in landscape mode on some devices the buttons would be
pushed off screen.
Bug 5115411
Change-Id: I8bf8fd1516735bf6111893df79636b519dbfb803
|
|
|
|
|
|
|
|
|
| |
Specifically, we now also require the current password to confirm any
restore operation.
Bug 4901637
Change-Id: I39ecce7837f70cd05778cb7e0e6390ad8f6fe3f3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the user has supplied a backup password in Settings, that password
is validated during the full backup process and is used as an encryption
key for encoding the backed-up data itself. This is the fundamental
mechanism whereby users can secure their data even against malicious
parties getting physical unlocked access to their device.
Technically the user-supplied password is not used as the encryption
key for the backed-up data itself. What is actually done is that a
random key is generated to use as the raw encryption key. THAT key,
in turn, is encrypted with the user-supplied password (after random
salting and key expansion with PBKDF2). The encrypted master key
and a checksum are stored in the backup header. At restore time,
the user supplies their password, which allows the system to decrypt
the master key, which in turn allows the decryption of the backup
data itself.
The checksum is part of the archive in order to permit validation
of the user-supplied password. The checksum is the result of running
the user-supplied password through PBKDF2 with a randomly selected
salt. At restore time, the proposed password is run through PBKDF2
with the salt described by the archive header. If the result does
not match the archive's stated checksum, then the user has supplied
the wrong decryption password.
Also, suppress backup consideration for a few packages whose
data is either nonexistent or inapplicable across devices or
factory reset operations.
Bug 4901637
Change-Id: Id0cc9d0fdfc046602b129f273d48e23b7a14df36
|
|
|
|
| |
Change-Id: I7293518bc2fe6c66270a7c8aea3bf0c0829754e4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Packages with this manifest attribute set 'false' will not be backed
up even through the "full device backup" infrastructure. If someone
produces an apparent restore file with data for such an application,
it will not actually be restored onto the device.
When an apk is installed during the course of a restore operation,
it is validated against the manifest contents and deleted if there
is a mismatch. Also, if the newly-installed app is found to
disallow backups, no file content will be processed for that app.
Bug 4532159
Change-Id: I59630054584b1394e567de939192e22e597044ee
|
|
|
|
|
|
|
|
|
| |
I.e. don't let people fake the user out by putting some other UI over
the top of it in order to phish for a confirmation.
Addresses bug 4521629
Change-Id: I40ae057ebedeb92ed264fb52fa1c7c297c9d3ec2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
* provide placeholder UI showing backup/restore start/stop/timeout
* don't kill the progress UI in mid stream
* tidy up the pax extended header data writing a little
Change-Id: Ife0cb78e3facb541d8327f1d5ca5fe77faa6cbca
|