public class BackupDataOutput extends Object
BackupAgent commits
information to the backup data set, via its onBackup() method. Data written for backup is presented
as a set of "entities," key/value pairs in which each binary data record "value" is
named with a string "key."
To commit a data record to the backup transport, the agent's
onBackup() method first writes an "entity header" that supplies the key string for the record
and the total size of the binary value for the record. After the header has been
written, the agent then writes the binary entity value itself. The entity value can
be written in multiple chunks if desired, as long as the total count of bytes written
matches what was supplied to writeEntityHeader().
Entity key strings are considered to be unique within a given application's backup
data set. If a backup agent writes a new entity under an existing key string, its value will
replace any previous value in the transport's remote data store. You can remove a record
entirely from the remote data set by writing a new entity header using the
existing record's key, but supplying a negative dataSize parameter.
When you do so, the agent does not need to call writeEntityData(byte[], int).
Here is an example illustrating a way to back up the value of a String variable
called mStringToBackUp:
static final String MY_STRING_KEY = "storedstring";
public void onBackup(ParcelFileDescriptor oldState, BackupDataOutput data, ParcelFileDescriptor newState)
throws IOException {
...
byte[] stringBytes = mStringToBackUp.getBytes();
data.writeEntityHeader(MY_STRING_KEY, stringBytes.length);
data.writeEntityData(stringBytes, stringBytes.length);
...
}BackupAgent| Constructor and Description |
|---|
BackupDataOutput(FileDescriptor fd) |
| Modifier and Type | Method and Description |
|---|---|
protected void |
finalize()
Invoked when the garbage collector has detected that this instance is no longer reachable.
|
void |
setKeyPrefix(String keyPrefix) |
int |
writeEntityData(byte[] data,
int size)
Write a chunk of data under the current entity to the backup transport.
|
int |
writeEntityHeader(String key,
int dataSize)
Mark the beginning of one record in the backup data stream.
|
public BackupDataOutput(FileDescriptor fd)
public int writeEntityHeader(String key, int dataSize) throws IOException
writeEntityData(byte[], int).key - A string key that uniquely identifies the data record within the applicationdataSize - The size in bytes of this record's data. Passing a dataSize
of -1 indicates that the record under this key should be deleted.IOException - if the write failedpublic int writeEntityData(byte[] data,
int size)
throws IOException
data - A raw data buffer to sendsize - The number of bytes to be sent in this chunkIOException - if the write failedpublic void setKeyPrefix(String keyPrefix)
protected void finalize()
throws Throwable
ObjectNote that objects that override finalize are significantly more expensive than
objects that don't. Finalizers may be run a long time after the object is no longer
reachable, depending on memory pressure, so it's a bad idea to rely on them for cleanup.
Note also that finalizers are run on a single VM-wide finalizer thread,
so doing blocking work in a finalizer is a bad idea. A finalizer is usually only necessary
for a class that has a native peer and needs to call a native method to destroy that peer.
Even then, it's better to provide an explicit close method (and implement
Closeable), and insist that callers manually dispose of instances. This
works well for something like files, but less well for something like a BigInteger
where typical calling code would have to deal with lots of temporaries. Unfortunately,
code that creates lots of temporaries is the worst kind of code from the point of view of
the single finalizer thread.
If you must use finalizers, consider at least providing your own
ReferenceQueue and having your own thread process that queue.
Unlike constructors, finalizers are not automatically chained. You are responsible for
calling super.finalize() yourself.
Uncaught exceptions thrown by finalizers are ignored and do not terminate the finalizer thread. See Effective Java Item 7, "Avoid finalizers" for more.