Age | Commit message (Collapse) | Author |
|
Test: compile
Bug: 26552300
Bug: 31289077
Change-Id: I578b15b48f0fc2807a92abbc69a377c3d2191496
|
|
Exposed by switching the target to Clang, and GCC 4.9 used by
MIPS.
Change-Id: Icb79285ab2306c39c2d381e53ea2e643ee2d2947
|
|
Turn on -Wall -Werror in libs/androidfw. Fix warnings. Refactor
some code.
Change-Id: I66fe54ace433c15dee5de328b149ca142f74b2dd
|
|
Change-Id: Ic037261eedd6e224938c960d2b4597590c81ed9d
|
|
Changes in this patch include
[x] Use %zu for size_t, %zd for ssize_t
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
Change-Id: Id1aaa7894a7d0b85ac7ecd7b2bfd8cc40374261f
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
|
|
resolve 64-bit build issues"
* commit '9ca25502c05854288733ee5142e8bf6594821f83':
androidfw: resolve 64-bit build issues
|
|
- uid_t/gid_t cast to unsigned long
- unused argument warnings
- tab and space requirements
Change-Id: Ib446d8165b9082be02edb55e6b71fd1a03ea3431
|
|
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
|
|
This reverts commit 84b6292c33d71b5739828d08aa8101d1954577f2.
|
|
Change-Id: Ic5b8a2742c7141156ab0f00ca29097bfe92bce60
|
|
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
|
|
create the new libandroidfw from parts of libui and libutils
Change-Id: I1584995616fff5d527a2aba63921b682a6194d58
|