| 5cb5e89d770f474031e4ab30fb7f24c66333590a |
|
17-Jun-2016 |
Christopher Tate <ctate@google.com> |
Fix adb backup/restore
* Exclude key/value-only backup participants until we have a chance to
augment the archive format with proper handling.
* Don't back up 'stopped' apps, which would un-stop them
* Fix unspecified-user bindService/startActivity invocations
* Teach adb restore about the onRestoreFinished() lifecycle method
* Implement proper app timeout handling in the adb data flows
* Backstop wallpaper backup against rare leftover-state issues
Bug 28056941
Change-Id: Ia59c71a2c74a632a2c2a527b9b7374229c440d46
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 0f101342e192c75f25f90fc3ac3000a37625d380 |
|
20-Jun-2016 |
Chris Tate <ctate@android.com> |
Merge "Let bmgr inspect the set of whitelisted transports" into nyc-dev
|
| 1c3be1a5b19b5f29eb8466d8b746a28d5a48e935 |
|
17-Jun-2016 |
Christopher Tate <ctate@google.com> |
resolve merge conflicts of cffb19c to mnc-dev am: 3f9ea2d386 am: d6c1126fab am: e2c9b1af3e
am: d2a4e1b39c
Change-Id: I8e59a88278ba50ab7e3768031611065131ed6834
|
| 3f9ea2d386507fd814b33fd9fa6c2a2824f80416 |
|
17-Jun-2016 |
Christopher Tate <ctate@google.com> |
resolve merge conflicts of cffb19c to mnc-dev
Change-Id: I4dba574de2678d851e3d82961a07de27d61f5940
|
| cffb19c812dd6d619e292519ca5ede61310aeab6 |
|
17-Jun-2016 |
Christopher Tate <ctate@google.com> |
Don\\\'t trust callers to supply app info to bindBackupAgent() am: c58054f25f am: cd777e95a7
am: ec6c3f7a32
Change-Id: Idc2b6c712078493b4186edad750d8d5beab58adf
|
| cd777e95a77ba0035566088a5432aa28a409e7d1 |
|
17-Jun-2016 |
Christopher Tate <ctate@google.com> |
Don\'t trust callers to supply app info to bindBackupAgent()
am: c58054f25f
Change-Id: I3b0bd91c38b5f13770f09f39c2eea78b63c29d7c
|
| e227ec61c24c3c33d42de4996d38fc4e44fa5e4d |
|
16-Jun-2016 |
Christopher Tate <ctate@google.com> |
Let bmgr inspect the set of whitelisted transports
Needed for compliance testing.
Bug 29072466
Change-Id: I025058ab9197f9e2db062bf0074e79f1cd04b443
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| c58054f25fb8ad624a749ed48e3f5775de4bec14 |
|
14-Jun-2016 |
Christopher Tate <ctate@google.com> |
Don't trust callers to supply app info to bindBackupAgent()
Get the canonical identity and metadata about the package from the
Package Manager at time of usage rather than rely on the caller to
have gotten things right, even when the caller has the system uid.
Bug 28795098
Change-Id: I215786bc894dedf7ca28e9c80cefabd0e40ca877
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 09893e9a4157f77938a0f688d17476df8be9441a |
|
10-Jun-2016 |
Christopher Tate <ctate@google.com> |
Don't allow restore sessions during backups
Gracefully no-op if apps attempt to restore themselves while there is
a backup pass in flight.
Bug 29135379
Change-Id: I8f0b5cd9d149b703e1de7a3a0b4b54c3aff766b6
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| c1c8325619aeae3ba23d69e2385071c26e3f57af |
|
26-May-2016 |
Christopher Tate <ctate@google.com> |
Use backstop timeouts on asynchronous countdown during preflight
Work around nebulous lost-timeout issues by adding a backstop timeout
to "wait for result" latch operations. When we hit these, the initial
conditions will be reported as final result; so make those intial states
match the error condition that is appropriate to such a timeout.
Bug 28963707
Change-Id: I4d21a86c48e87633118b1e6eaa05c1d966efec81
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 2be3de172376caa0257a59dd6646952baf90b203 |
|
21-May-2016 |
Christopher Tate <ctate@google.com> |
Backport of backup transport whitelist
Sysconfig define a whitelist of permitted backup transports
Previously any apk bundled in priv-app could insert a backup transport.
Reduce risk surface by giving the OEM explicit control over who is
allowed to handle backup data.
Bug 28406080
Backport of 494df791728f4d42d67e935c327910975993ad29 from N
Change-Id: I9f90e324169a68720d608f74754d284a7e59cf87
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 647cb6a6d82e3bb22eca0e5a27810e99084e2d5b |
|
21-May-2016 |
Christopher Tate <ctate@google.com> |
DO NOT MERGE : backport of backup transport whitelist
Sysconfig define a whitelist of permitted backup transports
Previously any apk bundled in priv-app could insert a backup transport.
Reduce risk surface by giving the OEM explicit control over who is
allowed to handle backup data.
Bug 28406080
Backport of 494df791728f4d42d67e935c327910975993ad29 from N
Change-Id: I405b49daee8c576584575c3e46877cc97632d8c6
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 3bed1c0ef8a66c4ce064b1c6ee443681070c5fcb |
|
16-May-2016 |
Christopher Tate <ctate@google.com> |
Explicitly close pipe end when we cease operations...
...because the other in-VM reference to that FD means that it won't
get GC'd after we release our local reference to the containing object,
and we wind up with the feeder end blocking on write to a still-fully-
open pipe rather than being made aware that the read end has needed
to shut down.
Bug 28756668
Change-Id: I90b6aaeaabe7d912d96d7ef57c24f68d87d9d0ab
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 494df791728f4d42d67e935c327910975993ad29 |
|
11-May-2016 |
Christopher Tate <ctate@google.com> |
Sysconfig define a whitelist of permitted backup transports
Previously any apk bundled in priv-app could insert a backup transport.
Reduce risk surface by giving the OEM explicit control over who is
allowed to handle backup data.
Bug 28406080
Change-Id: I84ed954c31b41b671825122e537971b110e00a4d
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| e2cdb20cf895b15acac5acaa43e2e6ffb13655b8 |
|
05-May-2016 |
Chris Tate <ctate@android.com> |
Merge "Ensure that the stream feeder doesn't hang in write..." into nyc-dev
|
| 35c2827c60fc8b77f97ce4d253873ff14c939581 |
|
03-May-2016 |
Christopher Tate <ctate@google.com> |
Ensure that the stream feeder doesn't hang in write...
...if the restoring data engine thread winds up operations. By closing
the engine side of the pipe unconditionally when exiting the thread,
the unanticipated-failure path is now guaranteed (instead of blocking
forever in write() to a pipe that isn't being read!).
In addition, wire agent-timeout handling into the various stream
data-handling operations (preflight, backup, restore). This were
not sufficiently robust and were in some situations leaving the
backup/restore mechanisms in a livelock state.
Finally, plug a longstanding problem in which we'd have orphaned
timeout messages coming in and producing a certain amount of "wtf?"
logging and wasted CPU. No longer!
Bug 28457158
Change-Id: I597c76c3eada378ffeb20870253847594f73e089
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 722d27f99c0b8ad4e69afdf7d8f0476b7d47053c |
|
03-May-2016 |
Christopher Tate <ctate@google.com> |
Full-data restore path needs to pass along the widget metadata
The engine itself knows about it, but that's at one remove from the
code that needs to consume it. Make sure it gets passed up the chain.
Bug 28346706
Change-Id: Ib94c9fbc512d92039bb7db5cd6b0b088a4a66027
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 98f1ff05580f85debaa245addd02777fe9e68273 |
|
28-Apr-2016 |
Christopher Tate <ctate@google.com> |
Don't wedge full data backups by blocking the data consumer thread
In particular, don't ask the producer about error overrides when
it is still relying on the consumer to do its job first. This
needs to be policy for *any* transport-side error condition, not
just the one that was previously handled safely. Any transport-
initiated error "on the fly" means that the app-facing side of
the engine doesn't know to stop feeding data, and mustn't be
consulted with any blocking request.
We also now detect unexpected PACKAGE_REJECTED by the transport
after data streaming has begun, and translate that to the general
TRANSPORT_ERROR for correct handling down the line.
Bug 28399225
Bug 28375634
Change-Id: I613dc21bc9f2d23e6520eed6c3ac2e9dbc1d88dc
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 5cf5578a457e448dda9fd47943e91f0f3b67690f |
|
26-Apr-2016 |
Christopher Tate <ctate@google.com> |
Make sure FIRST_LAUNCH is after PACKAGE_ADDED
If an app undergoes restore during install, it is considered 'started'
and the FIRST_LAUNCH broadcast needs to go out. However, this must not
take place until after the restore operation has fully completed, in
order to avoid publishing the app's existence while it may still be in
an incoherent state. We now make this broadcast part of POST_INSTALL
in the restore case.
Bundled apps are in the 'started' state regardless, so no FIRST_LAUNCH
broadcast is ever sent for them -- this CL does not change that
existing behavior even in the case of setup-time data restore of
factory-installed packages.
Bug 28173625
Change-Id: Ibcc3758576662dc447b75476173a0d008a9fe4da
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 021a48d50eb857aa912e5ca22ae0fff4a8b4c9dd |
|
29-Mar-2016 |
Makoto Onuki <omakoto@google.com> |
Merge "Extract signature related utilities" into nyc-dev
|
| 590096a0e372f640fb41d4cb97d8bc68fb7b8ea2 |
|
26-Mar-2016 |
Makoto Onuki <omakoto@google.com> |
Extract signature related utilities
So that they can be used from services/core.
Bug 27548047
Change-Id: I610e267cba320418e766c0e609fa26c485dc6e1f
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| d5f70b748351eb82a5f3567e2a1edea2de458951 |
|
22-Mar-2016 |
Christopher Tate <ctate@google.com> |
Clean up a couple of bugs about transport init staging
Using the right names for things typically works better.
Bug 27794697
Change-Id: Ic8c3c2c978536545bd669c1c12aad9ee6783f38a
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 1f4c45034235ce98fd1da171a9dcec4b7bb17efd |
|
19-Mar-2016 |
Christopher Tate <ctate@google.com> |
Fix deadlock when full data backup times out
The code was attempting to let a reported error in the app <-> engine
surface take precedence over apparent success at the engine <-> transport
handoff surface. However, in the case of timeout, this is inappropriate.
It was leading to deadlock because the engine runs free, with socket-closed
as its shutdown signals for determinism. In this case that means that
having accidentally asked it to finish and report the final result, we
locked up forever since the data it was writing dutifully to the engine
was no longer being consumed, and the actual teardown signals were never
sent.
The fix is to properly express the error-state hierarchy: only when the
engine <-> transport layer is not issuing its own abort is the app-data-
moving layer consulted about errors detected at that surface.
Bug 22348852
Change-Id: I8987be0c4f708116dfeb08098d7222241ed317f3
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 4ebf6dd961bf4f5ee0577af0cf8221af65f8c017 |
|
01-Mar-2016 |
Christopher Tate <ctate@google.com> |
Don't use restricted backup launch mode for system-ish processes
We now impose restricted launch behavior and lifetime only on "ordinary"
apps' backup/restore operations. System-ish targets such as the telephony
provider continue to get their full Application instance and providers,
and won't get killed following conclusion of the data-moving operations.
Such customers of backup/restore are expected to be able to deal
gracefully with this sort of thing.
Bug 27362301
Bug 27076602
Change-Id: Ib62483b8469cc750a20f80b7c596ad486a397564
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 50f56607d55e7e9170218fac70bc48c7dc94a1f9 |
|
24-Feb-2016 |
Christopher Tate <ctate@google.com> |
Don't use Settings for storing the backup enable state
Bug 19678828
Change-Id: Ieb572bcb2e8fe4d03f654dd52596c8dc4fdd72a9
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 43fbc5f898a488dcfa9ecf3030f05f27ce5428f9 |
|
18-Feb-2016 |
Christopher Tate <ctate@google.com> |
Add android:backupInForeground
An app can now declare that it really needs to be backed up
whenever possible even if it is currently engaged in foreground-
equivalent work. Only applies to full-data backup clients: key/value
backups are not intrusive on normal lifecycle so they can already
happen in such circumstances.
Bug 26790411
Change-Id: Ia0ebcc7a53da888ae9ae4d63cd4bcab6e3a2e866
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 2c1ba9a961d4f96c26df260ee437655ad9e7c03e |
|
17-Feb-2016 |
Jeff Sharkey <jsharkey@android.com> |
Make BackupManager encryption aware.
Backup requires both CE and DE storage to be available, so delay
spinning up the backup system until the user is unlocked, since
that's when CE storage becomes available. Note that devices without
FBE immediately transition USER_SYSTEM into the unlocked state,
since their CE is always available.
Offer to backup and restore files under both CE and DE. Since DE
is effectively the same as CE, most logic is simply duplicated for
now, but it could be simplified in the future. Since system apps
can force their default storage location to DE, we always build
explicit CE and DE paths.
Add getDataDir() to give clean access to the top-level private data
directory, but disclaim that apps shouldn't create files there.
Bug: 26279618
Change-Id: Ic34a4b330223725db93b1d0f5c9dffc88002c61f
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| cd8c13fc4e165cb67016b01fe77dbcd8309211b1 |
|
09-Feb-2016 |
Sergey Poromov <poromov@google.com> |
Synchronize results from runner thread to main full backup thread.
Previously, all results from runner thread - both for preflight
or full backup pass were ignored.
This change adds two synchronized method to get preflight result
and result of full backup pass.
This leads to better coverage of AGENT_ERROR to return in callback
as a result of backup operation.
On the other side we won't start backup pass in main thread
if preflight check hasn't been succeeded.
Change-Id: Id5f9e4c956a1bd5c396d59b7ad2098139a15e69d
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 65775b9c68a09e188fd94845ac5ef114ddcea908 |
|
11-Feb-2016 |
Sergey Poromov <poromov@google.com> |
Use long for preflight check size in BackupManagerService.
Bug: 26557141
Change-Id: I3794a91b62578044745a61bf774f5028f3e3b373
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 266190839f0be319d7c2d200c40ae3b7cf82b930 |
|
10-Feb-2016 |
Sergey Poromov <poromov@google.com> |
Don't call BackupTransport#checkFullBackupSize when preflight timeouted.
mResult in SinglePackageBackupPreflight could be set
to a negative value if preflight timeouted.
Together with ag/863259 this change will better handle this case.
Bug: 26818914
Change-Id: I171bf95f146552b3b50f044964c2b041f6303d90
(cherry picked from commit a235f7e4e046b1a69af988240ff5f0dd46f3b5f9)
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 8212ae0aee1700b9c287ebadf15af8dacdc8eae6 |
|
10-Feb-2016 |
Jeff Sharkey <jsharkey@android.com> |
Consistent naming for internal storage APIs.
Also completely remove a few confusingly named deprecated APIs.
Change-Id: Ia7e4ea3190a97f0a7dfa9bebf2118da0866ec38f
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| eee352f7a2079c4a2745179909245f4db2a04fe8 |
|
09-Feb-2016 |
Sergey Poromov <poromov@google.com> |
Fix that backupFinished() callback is not called sometimes.
Before this in case of TRANSPORT_ERROR backup pass was aborted before backupFinished() call.
Now this happens in 'finally' block so that there is no way to avoid it.
Also, now backup pass doesn't break in case of QUOTA_EXCEEDED result for single package.
And some refactoring around 'currentPackage' variable.
Bug: 27094847
Change-Id: I18df3f500b427381f32bd11ed1aa87ab9577bc91
(cherry picked from commit 2ea71ad6254c4094d0d34a39d9988c9d75b038ed)
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 0b9ea178897e1d23f32a8d2e60b22ba815ca9398 |
|
02-Feb-2016 |
Christopher Tate <ctate@google.com> |
fullBackupOnly=true means don't even think about key/value backup
Bug 26790411
Change-Id: Ifa5b97053969de958b08cbf2975c503b10f93571
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| e5f51c212cc3292a69988cd3569ce24cbb98f978 |
|
28-Jan-2016 |
Christopher Tate <ctate@google.com> |
Stage backup/restore data in a cache subdir rather than root
Also make sure not to do the restorecon() before the file is
created.
(Also fix binder identity bug in the 'bmgr fullbackup' flow.)
Bug 26834865
Change-Id: Ia8a59eeb55762264163c8b310caae5e303413571
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 7200364e8d74fc105023790eeda0fc42dac3310a |
|
27-Jan-2016 |
Sergey Poromov <poromov@google.com> |
Merge "Quota exceeded API in BackupAgent"
|
| 339b53a8e678f18da906906f5f32ed57772102bb |
|
23-Jan-2016 |
Christopher Tate <ctate@google.com> |
Prevent (and repair) poisoned full-data backup queue
An app that transitioned from full-data to key/value backup regimes
was being left in the full-data backup queue until next reboot. In
edge cases this would result in the app being inappropriately shut
down for backup; furthermore, it would potentially cause there to
exist a full-data payload for the app that was considered "newest"
and therefore be the one delivered at restore time on a new device
or app (re)installation.
Defense in depth: full-backup candidates are just-in-time reevaluated
for validity when they come up again in the queue; app update
notifications cause a reevaluation and removal from the queue if
full-data is no longer the right modality; and the common engine for
all cloud-facing full-data backups does an additional last-ditch
validation that each stated target is actually supposed to get
full-data backups rather than key/value, to backstop the checks on
queue-presence validity.
Bug 26744511
Change-Id: I55bea3e19a2cab0150dbe5a08dd9fc550f0068c4
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 872d3b6e19933af6fa9ae65214b9f6df04fc3222 |
|
12-Jan-2016 |
Sergey Poromov <poromov@google.com> |
Quota exceeded API in BackupAgent
Should be also implemented in GMS BackupTransport.
Bug: 25693504
Change-Id: I6e4b2edb6d62addca0aced3e801d7629fb9394ca
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 9448196076d5a5266b3ae7e4945216b30ee88aa7 |
|
07-Jan-2016 |
Sergey Poromov <poromov@google.com> |
Add BackupManager#isAppEligibleForBackup() method to Backup API.
Check is done only in framework.
Transport still can deny backup for the package.
Bug: 26443192
Change-Id: Ifcde67a4d11725aa4b15ab4f57d740f55ab2b265
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| d3665f1f0f2e2aefe4c5dd6b000b356dfb414783 |
|
21-Jan-2016 |
Sergey Poromov <poromov@google.com> |
Merge "Introduce BackupManager#requestBackup & BackupObserver API"
|
| fe06bf64d204c459699b0bf6465f9fb69208345e |
|
15-Dec-2015 |
Sergey Poromov <poromov@google.com> |
Introduce BackupManager#requestBackup & BackupObserver API
Introduces a way to request immediate backup for list of packages
and receive callbacks on backup progress.
Bug: 25688526
Change-Id: Ib826933d44f4ebf2b981f8be366215b2d37847e2
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 63fec3ef1adb6c447cd505679714a8e780d18263 |
|
12-Dec-2015 |
Christopher Tate <ctate@google.com> |
Don't full-data back up apps in foreground-equivalent state
We have to kill the app and bring it up in a controlled lifecycle mode
in order to do full-data backup, and if it's e.g. playing media, this
is hugely disruptive. Instead, we now check whether an app being
considered for full-data backup is in a user-observable state, and
defer its backup if so. We don't kick it all the way down the
daily-backup cycle in this situation -- we set it up to retry the
backup in just a few hours.
Bug 25960428
Change-Id: I576f25c6fb07545565f59bd685624c612b9c5ffd
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 4cfe29bdf2ee14e8316d45cfc23e4548319b3ab9 |
|
04-Sep-2015 |
Xiaohui Chen <xiaohuic@google.com> |
Cleanup USER_OWNER in backup service
This is just a straight constant replace. The feature is tracked in a
separate bug b/22388012.
Bug: 19913735
Change-Id: I7ae0953558bfdb77441e9efd749f1bb1cc77050c
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 05a24e5b59eb378ecfd4b0fc174d2141a677b1ec |
|
28-Aug-2015 |
Chris Tate <ctate@android.com> |
am a6888d6d: am b5bcd607: am 27c5cfd7: am 9b2f9bcb: am 82d14d60: Merge "Crashing the system process is inadvisable" into mnc-dev
* commit 'a6888d6d8b912a69fad189e1d53da79746aa74ae':
Crashing the system process is inadvisable
|
| 0d446c18dc84f8db522823f24983b8e71a0b0f04 |
|
28-Aug-2015 |
Christopher Tate <ctate@google.com> |
Crashing the system process is inadvisable
When asking for the set of services published by a package, it's
quite possible that there are none, in which case the returned List<>
is null rather than valid-but-empty. Don't bother looking at it
when it's null.
Bug 23614440
Change-Id: Ibebb26b9c3f75ec810a95f1b9d2663e884cb98bc
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 6578ad5bb493d43ae6a1f8a0b0d6dd180aa90b50 |
|
21-Aug-2015 |
Christopher Tate <ctate@google.com> |
am 905cb17f: am adde39d8: am b893c1ba: am 99b252ad: am ddc2536d: Make sure to kill restore-at-install full-data targets after restore
* commit '905cb17f921a804fde3679a2f8887055ec7db028':
Make sure to kill restore-at-install full-data targets after restore
|
| ddc2536d2b6f277a7828278a066be874e4f9502e |
|
20-Aug-2015 |
Christopher Tate <ctate@google.com> |
Make sure to kill restore-at-install full-data targets after restore
Specifically: correctly distinguish the "I want to restore my own data"
case, in which the app is intentionally not killed, from the single-package
restore at install operation.
Bug 23357388
Change-Id: Ic50ac39fe942af1f6ec9e04a32d81a39b70a0b2b
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 1c1dd4bc8dbad8846bbc7520dfe307099a6c05d7 |
|
18-Aug-2015 |
Chris Tate <ctate@android.com> |
am 45f88e1b: am 591b371f: am ccbb02f9: am b16cd62c: am c0a2254e: Merge "Clean up properly if outcall for doRestoreFinished() fails" into mnc-dev
* commit '45f88e1b2c0a8433b073f69c58660db843d46d04':
Clean up properly if outcall for doRestoreFinished() fails
|
| d71d7c350c76d3494dd6688c26a837fa41ea18f8 |
|
17-Aug-2015 |
Christopher Tate <ctate@google.com> |
Clean up properly if outcall for doRestoreFinished() fails
The target app crashed at an inopportune time but this shouldn't
invalidate the whole ongoing restore operation; it's a problem local to
the specific app undergoing restore. Recognize this, clean up the app's
possibly-incomplete data, and continue running the restore queue as
planned.
Bug 23228982
Change-Id: If9a19d2fe6a0ce5339c893630d7a61a5a5ccd9b1
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 1ad82779bea52865055db70ead52a8a360fcdba8 |
|
30-Jul-2015 |
Chris Tate <ctate@android.com> |
am 5f70b3b1: am e5b25915: am e625b631: am 4de7b0ff: am 74a0744e: Merge "Fix issues around process teardown after full-data restore" into mnc-dev
* commit '5f70b3b1d3360dcfa2716d610c04efa3e309521e':
Fix issues around process teardown after full-data restore
|
| 2ad7e27362f682e3358b307bef23196be1c8b126 |
|
30-Jul-2015 |
Christopher Tate <ctate@google.com> |
Fix issues around process teardown after full-data restore
The unified code path for cleanup was mistakenly looking at the
android:killAfterRestore manifest attribute even for full-data restore
operations. That attribute is only relevant for key/value payload
handling. We need to *always* kill after restore in the full-data
case because the app will otherwise be allowed to enter normal
component lifecycles without its correct Application / ContentProvider
state in force.
Bug 22704852
Change-Id: Ia63f985a35c28084c734389cfc49d3792173e5c7
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 7e744dfcfd916e510385ce81f794d69d13026bf3 |
|
29-Jul-2015 |
Chris Tate <ctate@android.com> |
am 803b73a2: am f9f837fa: am 6613ec44: am 403e22b9: am 751a96a0: Merge "Don\'t redundantly call transport.finishRestore()" into mnc-dev
* commit '803b73a29004d2f8bf0234c0619480f5e639b5d6':
Don't redundantly call transport.finishRestore()
|
| 6ab2fb61f08d87e01874114c3c204166a287e92c |
|
28-Jul-2015 |
Christopher Tate <ctate@google.com> |
Don't redundantly call transport.finishRestore()
The RestoreSession is no longer responsible for calling finishRestore();
that happens as part of tidying up after running the restore itself,
even in failure cases.
Bug 22640096
Change-Id: I0be52af2ae8c2c1ac685e9904ccb8120f7fcf522
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| a848379cabab5054e65ee29da339f5a3e8ca2481 |
|
15-Jul-2015 |
Kenny Guy <kennyguy@google.com> |
Update backup todo to mentioned admin control.
Update backup manager todo about backups for profiles
to mention the need for DevicePolicyManager control.
Change-Id: I7f17fc01a53d9608b104b70e57da7f619cb82c5f
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 2fe00adc02cb3fdcad8374bf624118d5c3d5575e |
|
07-Jul-2015 |
Christopher Tate <ctate@google.com> |
Clean up obsolete pending timeout after restoring package metadata
Bug 22040047
Change-Id: I460dbcc50a45d794392beb9ff4a4358c05c87e07
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 758de809b9e26e80b3490779f45c64aeaadf2a45 |
|
01-Jul-2015 |
Christopher Tate <ctate@google.com> |
Fix dispatch of onRestoreFinished()
The agent instance wasn't properly being conveyed from the generic
restore engine implementation to the state machine handling the
lifecycles. On top of that, the lifecycle wasn't advancing to the
restore-finished callback phase properly in the full-data restore
case.
Bug 22194736
Change-Id: Ic649d6a196adbd21a4a0f3083c7eed2fff383e52
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| ad8a96231680fae6c49bc877074b8af3562e90f1 |
|
05-Jun-2015 |
Christopher Tate <ctate@google.com> |
Don't run backups in battery-saver mode
Defer both full-data and key/value backups while in battery-saver mode.
Bug 21563473
Change-Id: I081b7bcd19af21a4c88ebb434d2d3ef4bc93951f
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 03d64a52105ce6eada02bf030e1a746c226fd8b1 |
|
26-May-2015 |
Christopher Tate <ctate@google.com> |
Don't erase backup metadata when an app is uninstalled
We still retain the data in the backup, in order to support the flow
in which a user has the app and its data is stored; then the app
is uninstalled; then later the app is reinstalled. We depend on
having correct metadata for the data in the datastore in order to
evaluate its validity for restore-at-install, so we mustn't
forget that metadata just because the app is not currently
installed.
We also now permit the sentinel pseudopackage name "@pm@" as an
argument to dataChanged(), indicating specifically that the metadata
should be scheduled for backup without having to be piggybacked on
another app's requested backup pass. That lets us now make sure to
schedule a backup pass for metadata-update in response to app
install activity.
Finally, fix a "min instead of max" bug in full backup scheduling
that was causing the OS to ignore the transport's inter-package
quiet time requirement when multiple packages were overdue for
backup.
Bug 21471973
Change-Id: I1dbc260edb91b8deadd2744e273dfa9578b9ef2a
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 62d1e1ef7e04f03c492b49e721ee9773677bba8b |
|
20-May-2015 |
Christopher Tate <ctate@google.com> |
Scan at boot time to detect newly-present full backup candidates
OTA or similar might have caused an app to appear without the usual
notifications being sent. Make sure we pick up those apps as
appropriate for full-data backup.
Bug 19462310
Change-Id: Ic17bc72b14cc7599ae8ea540548fda932606b8f2
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 1a78d8c2b88fb86801937d6cdb9e4961053d898b |
|
16-May-2015 |
Christopher Tate <ctate@google.com> |
Rebind backup transports only when clearly needed
Significantly narrow the circumstances under which transports
will be re-bound. In particular, we now do not unbind + rebind
whenever any component in a bound transport's host package changes;
rather, we do so only when the transport component itself has
changed state, or when there is a state change that might cause
a new transport to become available.
Bug 19775237
Change-Id: Ib386875df19ffe9f2d3eb9f9788187338360644a
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 5aba226d8ac28cbac5200ee3715a174683b1faa0 |
|
06-May-2015 |
Christopher Tate <ctate@google.com> |
Fix requestRestore() of an app's own package
The BACKUP permission check was being applied over-zealously.
Bug 19336200
Change-Id: Ia52b5c5cc0fd8d19b74ee624be85113d1b8dca7e
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 303650c9cdb7cec88e7ec20747b161d9fff10719 |
|
18-Apr-2015 |
Matthew Williams <mjwilliams@google.com> |
Add full backup criteria to android manifest
BUG: 20010079
Api change: ApplicationInfo now has a fullBackupContent int
where -1 is (off) 0 is (on) and >0 indicates an xml
resource that should be parsed in order for a developer
to indicate exactly which files they want to include/exclude
from the backup set.
dd: https://docs.google.com/document/d/1dnNctwhWOI-_qtZ7I3iNRtrbShmERj2GFTzwV4xXtOk/edit#heading=h.wcfw1q2pbmae
Change-Id: I90273dc0aef5e9a3230c6b074a45e8f5409ed5ce
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 511d02fcc37dce092e17354d53023db44817ebe6 |
|
09-Apr-2015 |
Christopher Tate <ctate@google.com> |
Add system API for querying the available restore dataset for a package
Bug 20123585
Change-Id: Ife6e77a224b5d4175178aacdb7c285e9944b9eab
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| e012a235569fe307d165dfd0784ae847d0b13739 |
|
02-Apr-2015 |
Christopher Tate <ctate@google.com> |
Back up / restore preferred app configuration
Bug 19848104
Change-Id: I84cdfcc44b48a9732984955d7eedf745b5586bdd
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| ab06997ed5d4599f7223f3033b5c3bc77ac7044e |
|
31-Mar-2015 |
Christopher Tate <ctate@google.com> |
Fixes to full-backup scheduling edge cases
If a scheduled full-data backup was attempted but the device had not yet
run the primary key/value backup pass, the full-data backup scheduler
would wind up in a bad state and potentially never retry until reboot.
We now properly reschedule a future retry, using the key/value
scheduling batch quantum as a backoff to be sure to give it a chance
to run before the next time full data is attempted.
Change-Id: Ic7eb7a7940fe6380f40d04813a46fc336e95815e
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| a7f038c9c3715bf29aec194bf079bf061502b1d9 |
|
28-Mar-2015 |
Christopher Tate <ctate@google.com> |
Respect the transport's requestFullBackupTime() backoff
We now make sure to pause by at least requestFullBackupTime() between full-data
backup operations, to give the transport the ability to apply traffic control
while we're running the queue of eligible packages.
Also, we now reset a package's queue position whenever a full-data backup for
that package is run explicitly via adb.
Bug 19732890
Change-Id: I6cf24495ad18eebd55557f229d11c703e5b7f529
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 11ae768cf1b8348e761ad9c09e98788da1e591b1 |
|
25-Mar-2015 |
Christopher Tate <ctate@google.com> |
Add payload-size preflight stage to full transport backup
We now peform a total-size preflight pass before committing data to the
wire. This is to eliminate the large superfluous network traffic that
would otherwise happen if the transport enforces internal quotas: we
now instead ask the transport up front whether it's prepared to accept
a given payload size for the package.
From the app's perspective this preflight operation is indistinguishable
from a full-data backup pass. If the app has provided its own full-data
handling in a subclassed backup agent, their usual file-providing code
path will be executed. However, the files named for backup during this
pass are not opened and read; just measured for their total size. As
far as component lifecycles, this measurement pass is simply another
call to the agent, immediately after it is bound, with identical
timeout semantics to the existing full-data backup invocation.
Once the app's file set has been measured the preflight operation
invokes a new method on BackupTransport, called checkFullBackupSize().
This method is called after performFullBackup() (which applies any
overall whitelist/blacklist policy) but before any data is delivered
to the transport via sendBackupData(). The return code from
checkFullBackupSize() is similar to the other transport methods:
TRANSPORT_OK to permit the full backup to proceed; or
TRANSPORT_REJECT_PACKAGE to indicate that the requested payload is
unacceptable; or TRANSPORT_ERROR to report a more serious overall
transport-level problem that prevents a full-data backup operation
from occurring right now.
The estimated payload currently does not include the size of the
source-package metadata (technically, the manifest entry in its
archive payload) or the size of any widget metadata associated with
the package's install. In practice this means the preflighted size
underestimates by 3 to 5 KB. In addition, the preflight API currently
cannot distinguish between payload sizes larger than 2 gigabytes;
any payload estimate larger than that is passed as Integer.MAX_VALUE
to the checkFullBackupSize() query.
Bug 19846750
Change-Id: I44498201e2d4b07482dcb3ca8fa6935dddc467ca
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 2c7a0cc2cfa3a0502aa23e09e6236ba09979b539 |
|
24-Mar-2015 |
Christopher Tate <ctate@google.com> |
Switch to new userActivity and package install APIs
Tracking the deprecation of older API variants and switching to the
new and more informative versions. Also tidying up a few unused
variables along the way.
Change-Id: I282a18525f9db838f4e0a77c90403b8b904e4fd7
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 27aec3c54a0319a989f7969ab6a368e9e1ae9d28 |
|
13-Mar-2015 |
Christopher Tate <ctate@google.com> |
Don't run full backups until package metadata has been pushed
Bug 19692849
Change-Id: I13615db7408b5c6fbc787c4773103c052e70f0b2
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| b538d3c06f37979a617c7c23644c23cc424f3f6a |
|
11-Mar-2015 |
Christopher Tate <ctate@google.com> |
Don't run full backups on stopped packages
We already decline to run key/value backup passes for (participating)
apps that are in the 'stopped' state. Now we also properly avoid
full-data backup passes on such apps.
Bug 19684052
Change-Id: Ieafc07b5531a91a243d57238c53db41ad3459140
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 77a2d78dbf91d4799f811385b1e39ad89052e7eb |
|
04-Mar-2015 |
Christopher Tate <ctate@google.com> |
Don't enqueue allowBackup=false apps for full backup attempts
We are correctly refusing to actually process apps for backup if they have
declared android:allowBackup="false" in their manifests, but we're still
wasting bookkeeping & a certain amount of work in tracking them as part of
the full backup queue. Fix that; now we recognize that they shouldn't be
in the queue in the first place.
When reinflating the queue at boot time we also re-verify the participation
of each mentioned app so that we properly drop ones that have been uninstalled
or altered such that they are no longer full-data backup candidates.
Finally, if an app previously implemented key/value backup, so we think
we'll be running it in that mode in a future backup pass, but has been
updated to use the full-data path instead, we don't want to go ahead and
run a key/value pass on it. Added a backstop check and proceed gracefully
in this situation.
(Also add bit more debug-build logging to LocalTransport)
Bug 19462310
Change-Id: I07ab4f2e68e92766d9e8f2595fa763c91193d743
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 73570db59f9178cf3a8affe943e96808ac404049 |
|
27-Feb-2015 |
Christopher Tate <ctate@google.com> |
Use scheduled job rather than periodic alarms for key/value backups
Instead of a runs-forever periodic alarm that drives key/value backup
passes, we instead schedule-on-demand a trigger job that will kick off
the pass after a batching interval. The key semantic change is that
we now never wake for key/value backup work unless we've been explicitly
asked to do so. We also use a rather longer batching interval than
was previously the case.
Bug 19536032
Change-Id: Ie377562b2812c9aeda0ee73770dfa94af6017778
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 12f783d6c6155a65a87511e200206a81798aa2ed |
|
25-Feb-2015 |
Christopher Tate <ctate@google.com> |
Don't crash when backup timeout races with agent completion
There's a narrow window of time in which an agent reporting that its
operation has completed races with timeouts such that we wind up
handling the completion callback just after certain fundamental state
has been reset. Detect this race and proceed gracefully instead of
crashing.
Bug 19498669
Change-Id: I5a475527db1a55a8e567366ddfb10112e427682e
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 33d3c53da021f0d044028860ace0f4ad817273f5 |
|
11-Feb-2015 |
Alex Klyubin <klyubin@google.com> |
resolved conflicts for merge of 517e0274 to lmp-mr1-dev-plus-aosp
Change-Id: Ic20b6c8851458483dd73a144bd5ae6e8d141e62a
|
| b9f8a5204a1b0b3919fa921e858d04124c582828 |
|
03-Feb-2015 |
Alex Klyubin <klyubin@google.com> |
Move hidden ApplicationInfo flags into a separate field.
The public API field android.content.pm.ApplicationInfo.flags can
support only 32 flags. This limit has been reached. As a short term
workaround to enable new public flags to be added, this CL moves flags
which are not public API into a separate new field privateFlags and
renames the affected flags constants accordingly (e.g., FLAG_PRIVILEGED
is now PRIVATE_FLAG_PRIVILEGED).
The new privateFlags field is not public API and should not be used
for flags that are public API.
The flags that are moved out of ApplicationInfo.flags are:
* FLAG_HIDDEN,
* FLAG_CANT_SAVE_STATE,
* FLAG_FORWARD_LOCK, and
* FLAG_PRIVILEGED.
NOTE: This changes the format of packages.xml. Prior to this CL flags
were stored in the "flags" attribute. With this CL, the public flags
are stored in a new "publicFlags" attribute and private flags are
stored in a new "privateFlags" attribute. The old "flags" attribute
is interpreted by using the old values of hidden/private flags.
Change-Id: Ie23eb8ddd5129de3c6e008c5261b639e22182ee5
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| e77c12ba37b7358ef6b6a6010e778926cc4194b8 |
|
29-Jan-2015 |
Christopher Tate <ctate@google.com> |
Don't run full-data backups when backup is disabled
If the scheduled job fires but backup is disabled or the device is
not yet provisioned (i.e. has not yet finished going through setup),
bow out gracefully without running any backup operations. Also, even
if a backup is directly invoked (e.g. via adb), verify again right
before we start collecting app data, and abandon the operation in
that path as well.
(This is redundant; having only the latter test would suffice, but
this lets us distinguish in the logging more easily.)
Finally, make sure that if we were waiting on setup before permitting
backup operations to begin, that we startup the full-data scheduling
as well as the [separate] key/value scheduling.
Bug 19197062
Change-Id: I3d8fb650c50f946d8ed7ac7170df361c707f2528
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| cf962601186a05a8818c02b690c1e7b5c15144f1 |
|
16-Jan-2015 |
Christopher Tate <ctate@google.com> |
Don't write widget metadata to backup unless it's new/changed
Redundant backup traffic is bad. Don't commit the widget metadata payload
(or the deletion operation for it) unless the widget state of the app has
actually changed since the last backup.
Bug 19003911
Change-Id: I93819173c0e2357b030d9e2b3d2ee57f2410bb57
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| b89e1405cf9f1da533dc0843390a1b6783abb0f4 |
|
07-Jan-2015 |
Christopher Tate <ctate@google.com> |
Support single-package backup rejection by the transport
We now cleanly handle the case of the transport blacklisting specific
packages from key/value backup. Previously we would halt the entire
backup pass and reschedule if the transport returned any error from
performBackup(pkg). Now, we recognize the TRANSPORT_PACKAGE_REJECTED
result from that invocation, and properly drop that package's work
but proceed with running the rest of the backup queue as expected.
Bug 18694053
Change-Id: Id0dd6d59492bdea9f970540d776f37db0cc5d99c
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 603ad6f7d00b6c1687102f4679314af533f18f6a |
|
06-Jan-2015 |
Christopher Tate <ctate@google.com> |
Remove the "backup_data_changed" event log
Nowadays it's just spammy and uninformative, so away it goes.
Bug 18833115
Change-Id: Ic373c596d7a892c4fedc0343e2c03dc1c295225e
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| a7e47d5d344674f4174919c4ac51e5b9c74b5802 |
|
01-Dec-2014 |
Christopher Tate <ctate@google.com> |
Don't crash if a system restore fails before constructing the PMBA
If a whole-system restore operation failed at just the wrong point,
we'd wind up in the teardown code without a certain vital bit of it
having been initialized, and crash on the null pointer. Now we
recognize this failure mode and make sure not to do that.
Bug 18574450
Change-Id: Ifa2c10ce16bb3c6bc916ed7151c5fd51b7225691
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| bbe23b31dcd0eec8af5b5198970de7ff2a9ef79a |
|
30-Oct-2014 |
Christopher Tate <ctate@google.com> |
Enable runtime turndown of backup/restore services
The heavy implementation of the backup manager service is now sitting
behind a lightweight trampoline that actually provides the binder
call interface. The indirection allows us now to tear down the
implementation on the fly without breaking callers who have cached
binder references to the backup services: these callers will simply
see their future invocations failing benignly.
In addition there is now an API for suitably privileged callers such
as device policy management to effect this turndown.
Finally, there is now a static system property, "ro.backup.disable",
that a product can use to outright remove backup/restore operation
from the system's operation. The public APIs will continue to be
safely usable on such products but no data will be moved to or
from the device.
Bug 17367491
Change-Id: I8108e386ef3b5c967938fae483366d6978fe4e04
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| a28b5c51602ccc48f2672274dabda05d3776ccd9 |
|
16-Oct-2014 |
Christopher Tate <ctate@google.com> |
Eliminate race condition around backup completion + resumption
Ensure that the callback always sees the current-operation state in sync
with the various other bits of internal backup-operation state. Previously
only the current-operation state was managed inside the critical section;
this resulted in a slim race window where a callback could see an ongoing
operation as still valid, but after the internal state on which that
operation depended had already been cleared.
Bug 17931760
Change-Id: Ia032668e7a9d22f1029c57fc98db9e86484d5719
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 0f32717a17307ee581381d7f8527b686aacb3ac4 |
|
16-Oct-2014 |
Christopher Tate <ctate@google.com> |
Fix spurious restore session timeouts
The restore-session idle timeout should not be ticking while we're
doing legitimate restore work. We now explicitly stop the timeout
ticker [a delayed message on our handler thread] whenever we undertake
a valid restore operation. The timer is already correctly resumed
when restore operations conclude.
(In practice we need to suspend the timeout tracking at exactly those
times when we're entering the wakelock-protected restore flow. The
timeout is reestablished when the wakelock is released; this part
is already in the code.)
Bug 17990544
Change-Id: I7318020ce30fd9c35bc3a644f8c101fd3d063c8b
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 2aa1d18e3acd269ed7a5f5a4843d447735f0676c |
|
10-Oct-2014 |
Christopher Tate <ctate@google.com> |
Fix bug 17931760 - spurious timeout leads to mayhem
We know a priori that the PMBA metadata package's backup pass
doesn't need to be tracked for timeout, because it's run inline
rather than as an asynchronous separate-process operation.
Change-Id: Ifd21ab3a016917f5e557a38c1c88f8d8ac1337d2
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 6067d79807653172de9772d8cfd5e914557207b7 |
|
08-Oct-2014 |
Christopher Tate <ctate@google.com> |
Actually tell the widget service that restore is starting
Before beginning a full-system restore we need to tell the widget service,
so that it can properly start remapping IDs from the ground state.
Bug 17869323
Change-Id: I152257563f5b52cae67244e936bc2c44ced7618d
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| ecae2116169e4cc7c109fcfc2aa9f5be1d105995 |
|
04-Oct-2014 |
Christopher Tate <ctate@google.com> |
adb backup/restore fixes
Bug 17811327 : teach adb restore about the new widget metadata entries
Bug 14165872 : -nosystem should not act like -onlysystem
Change-Id: I39da0ba80df7c5309a78ec1fa38016cebd80aa5f
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 64f10efab72aa7701a8d292425f4f56f04ca556b |
|
12-Sep-2014 |
Christopher Tate <ctate@google.com> |
Track enable/disable of transport components
For fallback / rollback of backup transport selection we need to
handle live enable/disable of legacy or superseded transports.
We now watch for component enable state changes in packages that
host transports, and rebind as needed.
The semantics for selecting the current transport have also been
adjusted. We no longer require that the selected transport be
live and currently bound in order to be designated as the active
instance. This prevents nondeterministic races around upgrade
and replacement.
Bug 17136637
Change-Id: Idaf45cf4522a23576444e6b11626ee3f7f47c36c
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 539b217b764562964c7f11b416da8391cb7cf93f |
|
03-Sep-2014 |
Christopher Tate <ctate@google.com> |
The transport system API needs to manage binder identity
...around writing settings. It does its own proper permission check;
it just needs to make sure not to accidentally crash the caller in
strange and wondrous ways because of failing to clear binder identity
before writing the result to secure settings.
Bug 16542048
Change-Id: I88d1f2dbeebd24eed5d86989f0ca0d834878b054
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 674d3e750133efc4b2d575d806596d1f56bda8d9 |
|
27-Aug-2014 |
Christopher Tate <ctate@google.com> |
Do not require device provisioning to do restore-at-install
Provisioning is a milestone used for gating *backup* operation,
but it's important that restores be possible during the setup
process. In particular, some applications such as home apps may
be deliberately pushed for install after platform restore, but
before the end of the setup process. We need to be able to do
install-time restores of such apps.
Bug 17288313
Change-Id: Iaff5d9919e6392b2ca5925be4d63a4116cd11f77
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 915f1dc785886ecd14a5222778f7d46f0243b1f5 |
|
27-Aug-2014 |
Christopher Tate <ctate@google.com> |
Remember having done full-data as well as key/value app backups
The "what have we ever succesfully backed up?" log is used to determine
whether we can do an install-time restore from the currently-live dataset
rather than go back to the ancestral dataset (if any). We now track
apps that have gotten a successful full-data backup through the transport,
not just key/value backups.
Bug 17263823
Change-Id: If21350a8dd8aaa4ed02fb74101617e935920e4ae
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| b8e6838583c9d784a7e8d030999d57eb2e87a561 |
|
23-Aug-2014 |
Paul Lawrence <paullawrence@google.com> |
Merge "Fix adb backup for encrypted case" into lmp-dev
|
| 5684dae9ccceb756c9b44b80931ccac9af198ea6 |
|
22-Aug-2014 |
Christopher Tate <ctate@google.com> |
Automatically bind to newly-installed backup transports
They'll be rebound automatically at boot, but need to be brought
up immediately. As always they can only be provided by privileged
apps.
Bug 16542048
Change-Id: I9f121a5c111a772deb3f0c44166002a2cbb16ad5
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 32d06732cdb7ee653a58e49a4dab13a780513db5 |
|
21-Aug-2014 |
Paul Lawrence <paullawrence@google.com> |
Fix adb backup for encrypted case
New behavior. Backup no longer uses the encryption password. This is in
part because that is hard with patterns, in part because it is a security
issue - the off line backup is much easier to brute force than the phone.
Instead, we simply insist on an encryption password if your device is encrypted
and locked.
Bug: 17159330
Change-Id: Ia22f84722522abf0b569a3ef1e16ead5527c726d
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| b2707afb0cbf955952d313e4c75fd3bfd3a35e98 |
|
20-Aug-2014 |
Christopher Tate <ctate@google.com> |
Maintain transport connection through package updates
When a package is updated, existing bindings to that package's
services are severed and must be manually re-established. Now
that the transport can be updated outside the system per se,
make sure that we detect these cases and rebind as needed.
Bug 16139912
Change-Id: I5d6fa75bb86484f8f7d4f8e93c9157773995e6a7
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 9dbba1b669eeb69316b70dbc9e457f8f8b084ea1 |
|
20-Aug-2014 |
Christopher Tate <ctate@google.com> |
Don't crash good-citizen restore session clients
If an app is trying to do the right thing and end its restore sessions
cleanly, but winds up being slow and having the session timed out from
under them, don't crash them with an illegal state exception for having
appeared to end the session twice.
Bug 17133115
Change-Id: I0a0989e2067b156569bddb6626ce045e625c6604
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 10ab095a5be2cc45354266b8fbe642c3facafd55 |
|
18-Aug-2014 |
Christopher Tate <ctate@google.com> |
Minor restore fixes
1. We were missing a 'break' in the session-timeout case of
message dispatch, so were falling through into a different
case. Oops. Fortunately it was benign; the other case's
logic was merely logging "hey it doesn't look like there's
anything to do here" and cleanly exiting.
2. After a restore operation finishes we were previously
always leaving the session timeout clock running. However,
this was not appropriate in the case of restore-at-install,
when the restore was a one-shot kicked off by the package
manager rather than an operation on an ongoing RestoreSession.
That logic now properly tidies up the session timeout when
winding up the restore in either situation.
Bug 17080648
Change-Id: I51d4a50db4feefc4c355230a3bfb926ea2fb5944
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| a63246d6daa02c6f3e4e78d0072d991387e14c87 |
|
15-Aug-2014 |
Christopher Tate <ctate@google.com> |
Tighten restore-at-install behavior
Harden the guarantee that if we're asked about a possible restore,
we always ALWAYS report back to the package manager. This involved
closing "should never happen" edge cases around provisioning/auto-restore
setting that nevertheless were happening.
Also, on the auto-restore setting front, make sure to plumb that
system API through appropriately, since going behind its back and
manipulating the secure setting directly would cause things to get
out of step.
Bug 17060654
Change-Id: I52ca9c1ffbfc0bd6b57196157500d0868bfc2989
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| bf1a4a81ebd340a18583f4ca9b5d562a01f55674 |
|
09-Aug-2014 |
Christopher Tate <ctate@google.com> |
Start using cancelFullBackup() when appropriate
The API was in place but the framework wasn't yet calling it.
Bug 16524520
Change-Id: Ie368758c830a7d0ad11e7dd3142a0ed896069944
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 0660244119243928a69e5f21ef5ea339c7f6d008 |
|
07-Aug-2014 |
Christopher Tate <ctate@google.com> |
Merge "Sanity-check paths of files to be restored" into lmp-dev
|
| 4cf9f007e6b66c0a970600f66b4229c4ede73f7f |
|
06-Aug-2014 |
Christopher Tate <ctate@google.com> |
Add event logs for full backup/restore milestones
Bug 16689703
Change-Id: If870f1b7b9cb3929ac1edc38affc688a37c2acfd
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 46db93404b27fe5ec121ab55527712e2a6692c7a |
|
30-Jul-2014 |
Michael Wright <michaelwr@google.com> |
Ensure backup schedule file is closed.
Change-Id: Ie4a62cda74815c67c62fb08e8df25a71d6102d4c
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| cce476034388383a6006555a225e2170f3b4dcd9 |
|
04-Aug-2014 |
Christopher Tate <ctate@google.com> |
Sanity-check paths of files to be restored
The duplicated implementations are an artifact of an ongoing
refactor of the full-data restore code. The adb-specific path
will be switched to use the FullRestoreEngine [as has already
been done for the 'adb backup' path using the parallel full
backup engine], at which point the extra implementation here
will be removed, but for now we need to make sure that all
bases are covered.
Bug 16298491
Change-Id: I9cdb8a1c537939a620208df3cf0e921061b981ad
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 7dfbaf52db6401ae85588e334be5af751bb813a8 |
|
29-Jul-2014 |
Christopher Tate <ctate@google.com> |
Make archive metadata idempotent
We want to make sure that the manifest and widget metadata
blocks are identical, including their in-stream headers, if
we regenerate the archive without underlying filesystem changes.
Bug 15968355
Change-Id: I828b264545d19e1d865d98d5723915d02fafc012
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| c17739d112d8e7076924c7fdd98614abafd58609 |
|
29-Jul-2014 |
Christopher Tate <ctate@google.com> |
Provide outside-facing API for data management intent+label
Bug 16346320
Change-Id: I3f4c2f4b700c77880ba3d8db7c92cdb404763d0d
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 5eeb59cceb1f95813c548c1c5937f161c1ed3571 |
|
22-Jul-2014 |
Christopher Tate <ctate@google.com> |
Schedule full backups
Initial policy: at most daily; backups only run when the
device is idle + charging + on an unmetered network.
Bug 16485874
Change-Id: I5665d890a943bac765adcef14be79d7dba6ce078
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 7ff106c20d403e3217f5f384e63737285e2668a2 |
|
25-Jul-2014 |
Christopher Tate <ctate@google.com> |
A couple of restore fixes:
* Fix crasher after transport-level failure attempting to ask for
the name of the next package to be restored
* Current-dataset single-package restore path no longer requires
that the package have its own backup agent.
Bug 16548983
Change-Id: Id37f2f0e6075d53c414d9a997bf738bbf0cfff8b
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| a4e4d68f08c1d48a3cdcf83617468370366d03d4 |
|
23-Jul-2014 |
Christopher Tate <ctate@google.com> |
Handle single-package restores properly
Bug 16346405
Change-Id: I69e3288f5a9d68d818fad6a2cd4b27ad45c1007e
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| f7cbb1fc25223bbf793f7128280ee4b00d509eb0 |
|
22-Jul-2014 |
Christopher Tate <ctate@google.com> |
Always check restore against the latest backend metadata
Bug 16484934
Change-Id: I472a7db89a94b9804f6ea94c25da206dd111a497
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 89101f7fe89134a609459e80f779c1a5114e562a |
|
18-Jul-2014 |
Christopher Tate <ctate@google.com> |
Tear down agents properly at EOD in full restore
The restore engine wasn't tearing down the bound agent after reaching
the end of data for the app, and furthermore was allowing the restore
operation to resume running the queue before all data had been delivered
to the current target.
Also make LocalTransport deliver data in 2K chunks rather than 32K,
as a first step towards making its timing characteristics more like
we'll see in networked situations.
Finally, added a bunch of MORE_DEBUG output for finding odd bugs
like this.
Change-Id: Icdbe6a070af6cc7c708a938ad044108d40ebce9a
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 5f7f252b451f94bc09e2e5b880e026c28a9c2d0b |
|
18-Jul-2014 |
Christopher Tate <ctate@google.com> |
Properly end full restore attempt if getNextFullRestoreDataChunk() fails
Don't just drop the error return on the floor and retry (forever!).
Change-Id: I5f0ef2d09ea286d813add69517f865e474341b43
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 2e40d115ca4332d88424d1b591fdd8d5f78d1831 |
|
15-Jul-2014 |
Christopher Tate <ctate@google.com> |
Add BackupAgent.onRestoreFinished() callback
The agent's onRestoreFinished() method is called after all available
data has been delivered to the app, whether via the key/value restore
API or the full-data file-at-a-time API. This gives the app a stable
opportunity to do any postprocessing that might be appropriate.
Also fixes a lingering bug in the framework's handling of backup
agent lifetimes. In cases where an existing agent instances was
being rebound, the framework was forgetting to notify the dependent
that the agent was available. This was causing timeouts and restore
failure.
Bug 16241004
Change-Id: I3f52b299312d30d38b0cba63a2cfaeb934991ef2
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| a176d22110a1670f363ba0f745f127d2b6ca2350 |
|
16-Jul-2014 |
Christopher Tate <ctate@google.com> |
Always call finishBackup() if performFullBackup() succeeded
Even if we later get an error from sendBackupData() we need to give
the transport its teardown callback. This simplifies the transport
logic considerably.
Change-Id: Ib8c0e210d4a876ee6b083a4d619dfccc462da4e5
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| a7835b6b6b00923b608a6bc3194e7840f67de7a8 |
|
12-Jul-2014 |
Christopher Tate <ctate@google.com> |
Add Context.getNoBackupFilesDir()
This is an app-private filesystem space exactly like the one
reported by Context.getFilesDir(), with one exception: files
placed here are never backed up by the full-backup infrastructure.
If an app attempts to back up any of its contents via the normal
API it's immediately ignored with a logged warning.
The restriction is also enforced on the restore side, because
apps using support libraries might wind up creating full backup
archives containing no_backup subdirs on pre-L devices (via
adb backup, Helium, &c.). We check for this before passing the
restore data to the app, and drop it if we detect the situation
so that the app never sees the bits.
Bug 16240573
Change-Id: I11216a391f1d32117ec7ce15aafc9cd93d0337de
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 8f1bb3a0d47a4cb34471464dff2af932772a7ade |
|
08-Jul-2014 |
Christopher Tate <ctate@google.com> |
Fix NPE in platform restore
Bug 16061451
Change-Id: I79d7913455886828a493a0c4ea850d259bfeeeab
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| d746057f2414cba2bdc69257cc5be8cb681bb592 |
|
07-Jul-2014 |
Jeff Sharkey <jsharkey@android.com> |
Change new file installs to be cluster-based!
Now that all the other pieces are in place, we're ready to start
installing new file-based packages as a cluster (the new unified
directory-based layout). This greatly simplifies the renaming
process.
Also add helper methods to ApplicationInfo to give a much clearer
mapping between it and internal field names, since we can't change
the public API.
Add recursive restorecon().
Bug: 14975160
Change-Id: I72a63c5ddbc594c2fec4a91dd59f73ef253fbfd7
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 51fea57e06fcb1dab1d239a5fff6e75ba2b7cee7 |
|
24-Jun-2014 |
Christopher Tate <ctate@google.com> |
Refactor restore to deal with heterogeneous datasets
Transport-based restore now handles both key/value and full-data
(stream) data delivery.
Also: PMBA now holds metadata for *all* apps, not just those with
backup agents. Since we need to consult this for every restore-
at-install operation we cache this locally now, tagged per transport
and per remote dataset, to avoid having to re-download it as part
of every future restore operation.
Also fixed a bug in LocalTransport that was preventing restore of
key/value datasets, i.e. all of them that were nominally available
prior to this change.
NOTE: at present there is no automatic full-data backup; if for
testing purposes you need to create some to then use for restore,
you still need to use 'bmgr fullbackup ...' to push them.
NOTE: at present the unified transport restore uses a refactored
"engine" implementation to handle stream data that encapsulates
the existing "adb restore" implementation. However, the adb
restore code path has not yet been refactored to wrap the newly-
extracted engine version; it still contains its own copy of all
the relevant logic. This will change in a future CL, at which
point offline/USB archive restore will simply wrap the same
shared stream-restore engine implementation.
Bug 15330073
Bug 15989617
Change-Id: Ieedb18fd7836ad31ba24656ec9feaaf69e164af8
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 6a49dd087f29cfca82d55dfabeb97439ef84b508 |
|
17-Jun-2014 |
Christopher Tate <ctate@google.com> |
Tweak restore API
We need the transport to tell the system not only what package it's going
to deliver data for next, but also what format that data is in.
Change-Id: I989cf78febf923a4208acb33ed80ccc7869356f5
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 9ff53a7100b1a40f5d2df3eb19a2f3f2fff39a46 |
|
04-Jun-2014 |
Christopher Tate <ctate@google.com> |
Implement full data backup through transport
Currently no timed/scheduled full-data backup operations are
performed by the OS, but the plumbing is now in place and can
be tested using 'adb shell bmgr fullbackup pkg [pkg2 pkg3 ...]'.
The LocalTransport test transport implementation has been augmented
to support the new full-data backup API as well.
In addition, 'adb backup' now takes the -compress/-nocompress
command line options to control whether the resulting archive is
compressed before leaving the device. Previously the archive was
always compressed. (The default is still to compress, as it will
usually reduce the archive size considerably.)
Internally, the core implementation of gathering the full backup
data stream from the target application has been refactored into
an "engine" component that is shared by both 'adb backup' and the
transport-oriented full backup task. The archive file header
generation, encryption, and compression logic are now factored out
of the engine itself instead of being hardwired into the data
handling.
Bug 15329632
Change-Id: I4a044faa4070d684ef457bd3e11771198cdf557c
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 4dd2635bf501ad1a1adc22a6ceb4c66cd61a1a23 |
|
03-Jun-2014 |
Christopher Tate <ctate@google.com> |
Add full-backup stream API to BackupTransport
Also started migrating the definition of transport success/failure constants
into BackupTransport to make them permanent.
The new methods are not yet plumbed in; this is just to allow forward
progress against a proposed stable API.
Bug 15329632
Change-Id: I27472e09b831350c140b9fa548ebda3af334eb1a
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| f97c63350abcc6715ba9fdc21fd3405d0f7ba716 |
|
29-Apr-2014 |
Elliott Hughes <enh@google.com> |
Move internal libcore.os users over to android.system.
Change-Id: I84e1ace19ba3b4e58d7bb24f3ecda1bdf5dc75a5
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| a99d02170bc0e54f729b2b735571c8eea8d5034d |
|
05-Apr-2014 |
Christopher Tate <ctate@google.com> |
Back up the preferred home app, if any
If the user has stated a preference about their home app, make sure we
capture that so that a system restore can return them to that preferred
situation. It's built into the system metadata so that we can, if
necessary, fast-path configuration of that home app while the rest of
the restore operation is in flight.
Change-Id: I64dfee8f7a2a9e40f556cd19298d7b367c6aa8dc
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| cba5941c6085dab1566bc047c1ea31f58a2dd4cf |
|
01-Apr-2014 |
Christopher Tate <ctate@google.com> |
Rejigger the invalid-key checks at backup time
Bug 13732002
Change-Id: Ic8f71234d1bbc7420eaa8e1762b999d09f308d46
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| adfe8b86e9178a553b6db9722340fa4ff5201cf1 |
|
05-Feb-2014 |
Christopher Tate <ctate@google.com> |
App widget backup/restore infrastructure
Backup/restore now supports app widgets.
An application involved with app widgets, either hosting or publishing,
now has associated data in its backup dataset related to the state of
widget instantiation on the ancestral device. That data is processed
by the OS during restore so that the matching widget instances can be
"automatically" regenerated.
To take advantage of this facility, widget-using apps need to do two
things: first, implement a backup agent and store whatever widget
state they need to properly deal with them post-restore (e.g. the
widget instance size & location, for a host); and second, implement
handlers for new AppWidgetManager broadcasts that describe how to
translate ancestral-dataset widget id numbers to the post-restore
world. Note that a host or provider doesn't technically need to
store *any* data on its own via its agent; it just needs to opt in
to the backup/restore process by publishing an agent. The OS will
then store a small amount of data on behalf of each widget-savvy
app within the backup dataset, and act on that data at restore time.
The broadcasts are AppWidgetManager.ACTION_APPWIDGET_RESTORED and
ACTION_APPWIDGET_HOST_RESTORED, and have three associated extras:
EXTRA_APPWIDGET_OLD_IDS
EXTRA_APPWIDGET_IDS
EXTRA_HOST_ID [for the host-side broadcast]
The first two are same-sized arrays of integer widget IDs. The
_OLD_IDS values are the widget IDs as known to the ancestral device.
The _IDS array holds the corresponding widget IDs in the new post-
restore environment. The app should simply update the stored
widget IDs in its bookkeeping to the new values, and things are
off and running. The HOST_ID extra, as one might expect, is the
app-defined host ID value of the particular host instance which
has just been restored.
The broadcasts are sent following the conclusion of the overall
restore pass. This is because the restore might have occurred in a
tightly restricted lifecycle environment without content providers
or the package's custom Application class. The _RESTORED broadcast,
however, is always delivered into a normal application environment,
so that the app can use its content provider etc as expected.
*All* widget instances that were processed over the course of the
system restore are indicated in the _RESTORED broadcast, even if
the backing provider or host is not yet installed. The widget
participant is responsible for understanding that these are
promises that might be fulfilled later rather than necessarily
reflecting the immediate presentable widget state. (Remember
that following a cloud restore, apps may be installed piecemeal
over a lengthy period of time.) Telling the hosts up front
about all intended widget instances allows them to show placeholder
UI or similarly useful information rather than surprising the user
with piecemeal unexpected appearances.
The AppWidgetProvider helper class has been updated to add a new
callback, onRestored(...), invoked when the _RESTORED broadcast
is received. The call to onRestored() is immediately followed by
an invocation of onUpdate() for the affected widgets because
they will need to have their RemoteViews regenerated under the
new ID values.
Bug 10622506
Bug 10707117
Change-Id: Ie0007cdf809600b880d91989c00c3c3b8a4f988b
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| cb20740ee171de3e604c07cdd02963d4d08a5fc9 |
|
06-Mar-2014 |
Christopher Tate <ctate@google.com> |
Fix build. Silly gits.
Change-Id: I8f21b7239621da500d9a73eb17d350e06dda9b20
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| ff8b037c10a7ce90cbb6130b49c8cb076e1e7c0f |
|
05-Mar-2014 |
Christopher Tate <ctate@google.com> |
am 777b8a80: am 422b2656: resolved conflicts for merge of c45ff35f to klp-modular-dev
* commit '777b8a808ee76401429f7210ebb7194632040d45':
Adapt to underlying changes in the PBKDF2 implementation
Change-Id: Ia68694a03e52693fceaedc6740dbd8e690e21257
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 5c38516e83f772fe04176f72f2ab7a1094e17430 |
|
03-Mar-2014 |
Christopher Tate <ctate@google.com> |
Don't hang installs if the transport disappears
Bug 12991308
Change-Id: Ie5d3d27fe565dd4014976f5333e37b5707acb707
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 091e8d2aefe39cec85f64d74898354fff596735c |
|
11-Feb-2014 |
Narayan Kamath <narayan@google.com> |
Fix build.
com.android.server.SystemServer was no longer imported
on master.
Change-Id: Ie712aa28940953952aa7a99cbb22f74129649249
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| cab8617b8ccea3a99b1ee15e15915c512a10c738 |
|
11-Feb-2014 |
Jeff Brown <jeffbrown@google.com> |
am 25df673b: am 1b51c9cb: Merge "Make SystemService constructor take a Context." into klp-modular-dev
* commit '25df673b849de374cf1de40250dfd8a48b7ac28b':
Make SystemService constructor take a Context.
|
| b880d880c6cd989eacc28c365fc9a41d31900da1 |
|
11-Feb-2014 |
Jeff Brown <jeffbrown@google.com> |
Make SystemService constructor take a Context.
This change simplifies the process of initializing a SystemService
by folding the onCreate() step back into the constructor. It removes
some ambuiguity about what work should happen in the constructor and
should make it possible for services to retain most of their final
fields after refactoring into the new pattern.
Change-Id: I25f41af0321bc01898658ab44b369f9c5d16800b
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 684d6f9f4d1a11069d9c9c1996fbc45cda7e7f04 |
|
13-Jan-2014 |
Christopher Tate <ctate@google.com> |
Adapt to underlying changes in the PBKDF2 implementation
We need to specify "PBKDF2WithHmacSHA1And8bit" now in order to get precisely
the same output as was previously generated with "PBKDF2WithHmacSHA1". We
also now try both when it's ambiguous which was used to generate the archive
checksums.
Bug 12494407
Change-Id: I5443f31a5e13c24f44445768b6e9a6eea221ede6
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| e58a49e411327e26b6ad9939833f53c7fa5aef20 |
|
21-Dec-2013 |
Amith Yamasani <yamasani@google.com> |
Merge commit '817ec49e' into manualmerge
Conflicts:
services/print/java/com/android/server/print/PrintManagerService.java
Change-Id: I1b9bf364ca50ee3c48f53d87ae0ce23e7f3c2bc2
|
| 817ec49e7991d4cac50b2308cd7cf5f8641e1e29 |
|
20-Dec-2013 |
Amith Yamasani <yamasani@google.com> |
Wrap some services into a SystemService
These services can now be excluded by modifying the list of REQUIRED_SERVICES (TB renamed)
Changed appwidget, devicepolicy, backup and print services.
Change-Id: Id8e2855d5c045cd57bdb02dca9ed75172803bce7
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|
| 49782e46c0eb85a25ae2abcf80880c48dbab5aea |
|
20-Dec-2013 |
Amith Yamasani <yamasani@google.com> |
am 9158825f: Move some system services to separate directories
* commit '9158825f9c41869689d6b1786d7c7aa8bdd524ce':
Move some system services to separate directories
|
| 9158825f9c41869689d6b1786d7c7aa8bdd524ce |
|
22-Nov-2013 |
Amith Yamasani <yamasani@google.com> |
Move some system services to separate directories
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
/frameworks/base/services/backup/java/com/android/server/backup/BackupManagerService.java
|