BackupDataReader / BackupDataWriter were implicitly assuming that when
instantiated, the underlying fd was positioned at start-of-file. If one
tried to e.g. open an existing data stream to append further data to it,
things might randomly fail (at read time, possibly when consuming the
stream later) due to incorrect alignment of the data entities: the
appending writer would assume that no padding was needed to achieve
correct alignment, and this might easily be false.
Now the underlying native reader/writer helpers recognize the true
position within the file when constructed, and as a result it's now
safe to e.g. construct a BackupDataOutput for an existing file and
then append to it.
Change-Id: If0484921e687852f923a4b4efabff573a6c16981
Pro tem, we ignore wifi configuration data when restoring system settings.
This is not ideal, but it *does* mean we do not bounce wifi off and on
again during the extended restore process, which in turn means we don't
interfere with things like the Play Store's download of applications.
We do continue to back up wifi configuration, and will start using that
data again when the new implementation that restores AP configurations
without having to bounce wifi comes to pass.
Also, this CL fixes a longstanding bug in BackupDataInput.skipEntityData()
that was being reproduced reliably once settings restore was skipping
the wifi-related entities in the restore stream.
Bug 7249405
Change-Id: I61520a9a116b66ebdf95734d09d9afd46406df01
