e88d1e5926d3f3e8a4ceaced7dad7bdc8bc61fa4 |
|
18-May-2015 |
Stefan Kuhne <skuhne@google.com> |
Revert "Backup/restore recents task list" Reverts commits 92dd1abef4c0a22db40c5f7bbd100e6b471a1ad3, 18795a2299fefd88ee16393f22324b999ace6ce4, and ac6a3a5e9d90edb533e5b377a4a14ef514be955a which make-up changes required for backing-up and restoring recent tasks from one device to another. The implementation had too many unresolved issues including the ordering of the restored recent tasks which was depending on when the task package is installed on the new device that puts the restored recents list out of order compared to the old device. Bug: 15986349 Bug: 19014377 Bug: 20763296 Change-Id: I06fd35a43036ef0b7260cf4db9c42890df63b95d
/frameworks/base/core/java/com/android/server/backup/SystemBackupAgent.java
|
f7cb8a0b50968f51994279b0ae3fede0a586ba45 |
|
21-Apr-2015 |
Christopher Tate <ctate@google.com> |
Compress the preferred-app backup payloads They can be Very Very Large, so take advantage of the new BlobBackupHelper infrastructure to keep them tiny! Also fix an issue in which the restore path wasn't properly passing notification payloads along for processing, and an issue in which the blob helper wasn't handling empty states properly. Change-Id: I11a7ca3cd2e26f634a8971e874ac97385b0b500c
/frameworks/base/core/java/com/android/server/backup/SystemBackupAgent.java
|
f9767d680d63ac1771a17ccc5775cd337ff967b8 |
|
08-Apr-2015 |
Christopher Tate <ctate@google.com> |
Infrastructure for notification backup/restore Introduce a fairly general "store byte[] blobs as backup keys" helper, and use that to integrate with the Notification Manager. The helper provides all the machinery of managing prior state, compressing the blob on the wire, etc. Bug 19848954 Bug 20105530 Bug 17755700 Change-Id: I4aa808172244af6db0ab2f4440cc266a797655d7
/frameworks/base/core/java/com/android/server/backup/SystemBackupAgent.java
|
e012a235569fe307d165dfd0784ae847d0b13739 |
|
02-Apr-2015 |
Christopher Tate <ctate@google.com> |
Back up / restore preferred app configuration Bug 19848104 Change-Id: I84cdfcc44b48a9732984955d7eedf745b5586bdd
/frameworks/base/core/java/com/android/server/backup/SystemBackupAgent.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/core/java/com/android/server/backup/SystemBackupAgent.java
|
a6533256ac1de9d0860688ca743aa7a2468470cc |
|
24-Nov-2014 |
Marvin Paul <marvinpaul@google.com> |
Implemented backup and restore for account sync settings. Bug: 18506992 Parent Bug: 17967106 Change-Id: Iecf5ce3a24ac5f12192e65aa61f1560bc76d75a8
/frameworks/base/core/java/com/android/server/backup/SystemBackupAgent.java
|
18795a2299fefd88ee16393f22324b999ace6ce4 |
|
03-Dec-2014 |
Wale Ogunwale <ogunwale@google.com> |
Add support from restoring recent's backup. Bug: 15986349 Change-Id: I899f81d317fcd5277a75db7ba50ecca14112df26
/frameworks/base/core/java/com/android/server/backup/SystemBackupAgent.java
|
ac6a3a5e9d90edb533e5b377a4a14ef514be955a |
|
18-Nov-2014 |
Christopher Tate <ctate@google.com> |
Recents backup helper Handles backup/restore of recent tasks for the system. Currently the thumbnails are not saved. At restore time the historical task records are placed in a designated separate location rather than directly in the live bookkeeping; this avoids ID duplication issues and makes it easier to deal with lazy adoption of the historical task state as apps are installed on the device post-restore. Bug 17303286 Bug 15986349 Change-Id: Ie156c1e2ab9c9a7e7ac0447b27016fdcef55dded
/frameworks/base/core/java/com/android/server/backup/SystemBackupAgent.java
|
8def5cbb3a1a68bb66fbe7ce63fcc8eadcbb238d |
|
22-Aug-2014 |
Brian Carlstrom <bdc@google.com> |
Move SystemBackupAgent from services.jar to frameworks.jar Bug: 17168017 Change-Id: I89b98ca839a78eeb7fb43930e0699ee235deafad
/frameworks/base/core/java/com/android/server/backup/SystemBackupAgent.java
|