b13b9bdad2baf6ad1ec2e56b6b7598fa20f55fc4 |
|
18-Feb-2012 |
Mathias Agopian <mathias@google.com> |
frameworks/base refactoring. step 2: move libutils headers to their new home: androidfw Change-Id: I14624ba23db92a81f2cb929f104386e1fab293ef
/frameworks/base/core/jni/android_backup_BackupDataInput.cpp
|
5baa3a62a97544669fba6d65a11c07f252e654dd |
|
20-Dec-2011 |
Steve Block <steveblock@google.com> |
Rename (IF_)LOGD(_IF) to (IF_)ALOGD(_IF) DO NOT MERGE See https://android-git.corp.google.com/g/156016 Bug: 5449033 Change-Id: I4c4e33bb9df3e39e11cd985e193e6fbab4635298
/frameworks/base/core/jni/android_backup_BackupDataInput.cpp
|
a3804cf77f0edd93f6247a055cdafb856b117eec |
|
12-Apr-2011 |
Elliott Hughes <enh@google.com> |
You don't need to poke around inside FileDescriptor manually. We can help you with that. Note also that getParcelFileDescriptorFD did no such thing. All its callers were passing in a regular java.io.FileDescriptor and expecting the int. No ParcelFileDescriptors involved. Change-Id: Idc233626f20c092e719f152562601f406cc1b64a
/frameworks/base/core/jni/android_backup_BackupDataInput.cpp
|
4528186e0d65fc68ef0dd1941aa2ac8aefcd55a3 |
|
06-Mar-2010 |
Christopher Tate <ctate@google.com> |
Refactor android.backup => android.app.backup Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
/frameworks/base/core/jni/android_backup_BackupDataInput.cpp
|
5f15d151b5101fadfe6cba1e8f4aa6367e8c603e |
|
16-Jun-2009 |
Joe Onorato <joeo@android.com> |
checkpoint BackupDatAInput / RestoreHelper
/frameworks/base/core/jni/android_backup_BackupDataInput.cpp
|
2fdd428e0f18384160f7c38ce3a2cd9ba7e7b2c2 |
|
13-Jun-2009 |
Christopher Tate <ctate@google.com> |
Fix some backup reader/writer issues; make local transport do backup As of this change, LocalTransport is successfully propagating data changes from the backup data format into a repository stored in /cache/backup/[packagename]. Each backup key gets a separate file there for ease of manipulation and testing. The general semantics of BackupDataReader have been tweaked, too; it now just returns simple "we're done with the data" when it hits the end, even if no footer has been found, because on the writing side the footer isn't being written. Also, reading an entity now merely requires a "big enough" buffer, not an exactly-sized one. This is all a work in progress, but this is at least working now for purposes of this local transport. Still to do: proper change vs deletion detection, as well as expanding the data format itself to include necessary metadata etc.
/frameworks/base/core/jni/android_backup_BackupDataInput.cpp
|
03f4df4b3bf8b8828e795a0bf1f913e6e08f12f1 |
|
13-Jun-2009 |
Joe Onorato <joeo@android.com> |
Fix the jni initializer.
/frameworks/base/core/jni/android_backup_BackupDataInput.cpp
|
1cf587496fcb1d652bab9fc6792fb106b6fefaa4 |
|
12-Jun-2009 |
Joe Onorato <joeo@android.com> |
Add RestoreFileHelper, BackupDataInput, and add java wrappers for the methods on BackupDataOutput.
/frameworks/base/core/jni/android_backup_BackupDataInput.cpp
|