This cl supports the parsing and extraction of the zip entry who
has a large size than UINT32_MAX. Also add a few checks in the
entry writers to make sure callers have enough space for extraction.
As many users of the library assume the entry size to be 32 bits long,
we keep the 32 bit ZipEntry. We also keep the functions that expect
the 32 bit ZipEntry in the public header file. These 32 bit wrappers
could be removed later once all users recognize the 64 bit ZipEntry.
Bug: 150900468
Test: unit tests pass
Change-Id: Ia6760638ccf51e97dbef6bd55dff352f1e7ce816
Vendors may add additional functionfs mounts. Since these
will never be remounted, we can safely filter these out.
Bug: 153008210
Test: Test device with previously unfiltered entries.
Change-Id: I7f384b8a0ce93dd6701fe3c4d9dd2557370b31e1
Merged-In: I7f384b8a0ce93dd6701fe3c4d9dd2557370b31e1
Add VTS10 variant of vts_libsnapshot_test so that
it can be added to vts-kernel test.
Bug: 142513589
Test: vts10-tradefed run vts-kernel -m VtsLibnsapshotTest
Change-Id: I4e2516b94d84acb16f595aab87dd3c0cadad6166
am skip reason: Change-Id I811c75e9a4739db149f502b9a43c99a8ed883341 with SHA-1 a806a7153f is in history
Change-Id: I2ab04b34b593a94e355c93a4f503cca19fb3f50b
This reverts commit 2b859925ea.
Reason for revert: Not needed
The original change was made in an attempt to close a perceived hole in
the apex availability checking. However, there is no such hole and so
this change is unnecessary. While there is a dependency path from the
apex to this module one of the dependencies in that path is from a
static library to a shared library. That dependency does not result in
the code that includes the static library being linked to the shared
library at either build time or runtime. Therefore, the shared library
is not part of the APEX and so does not need to be marked as such.
Bug: 152762638
Test: m droid
Change-Id: I77c3b23d28eca99fcb133cb38eb8863277ac7179
am skip reason: Change-Id I6fd7d3a25d3225081388e39a14c9fdab21b592ba with SHA-1 10615eb397 is in history
Change-Id: I05faca41a3d6ba5a64e7fe0d8d3e9131c91c14a4
These are provided to userspace by newer kernels.
Test: builds
Bug: 150648313
Change-Id: I811c75e9a4739db149f502b9a43c99a8ed883341
Merged-In: I811c75e9a4739db149f502b9a43c99a8ed883341
Make it easier to benchmark file sync performance by ignoring the file
system.
Bug: https://issuetracker.google.com/150827486
Test: test_device.py
Change-Id: Icfa4b28eb5206f1914c0c163833d070a3748c3ea
Add support for LZ4 compression, which compresses and decompresses far
more quickly than brotli, at the cost of worse compression ratio.
`adb sync -d system` speeds (in MB/s) on aosp_blueline-eng:
none brotli lz4
USB 3.0 120 110 190
USB 2.0 38 75 63
Bug: https://issuetracker.google.com/150827486
Test: python3 -m unittest test_device.FileOperationsTest{Uncompressed,Brotli,LZ4}
Change-Id: Ibef6ac15a76b4e5dcd02d7fb9433cbb1c02b8382
More groundwork to support more compression algorithms.
Bug: https://issuetracker.google.com/150827486
Test: python3 -m unittest test_device.FileOperationsTest{Uncompressed,Brotli}
Change-Id: I638493083b83e3f6c6854b631471e9d6b50bd79f
am skip reason: Change-Id I1264078f53ed3ff54638c7f3b6846b7437f98ee5 with SHA-1 92116e4129 is in history
Change-Id: I072de643588f5d9c915ff9d6fea498c0c80f875b
Devices in the lab are hitting an issue where they're getting stuck
likely in the sync() call in DoReboot() before we start the reboot
monitor thread and before we shut down services.
It's possible that concurrent writing to RW file systems is causing
this sync() call to take essentially forever. To protect against
this, we need to remove this sync(). Note that we will still call
sync() after shutting down services.
Note that the service shutdown code has a timeout and there is a
reboot monitor thread that will shutdown the device if more than 30
seconds pass above that timeout. This change increases that timeout
to 300 seconds to give the final sync() calls explicitly more time to
finish.
Bug: 150863651
Test: reboot functions normally
Test: put an infinite loop in DoReboot and the the reboot monitor thread
triggers and shuts down the device appropriately
Merged-In: I6fd7d3a25d3225081388e39a14c9fdab21b592ba
Change-Id: I6fd7d3a25d3225081388e39a14c9fdab21b592ba
(cherry picked from commit 10615eb397)
This should help in debugging issues related to the mismatch between
actual last reboot reason property and the expected one (see attached
bug).
Test: adb reboot
Test: adb logcat | grep bootstat
Bug: 152900920
Change-Id: I085cf1fb80a30389fd3ba821d40b6111a3294d95
Merged-In: I085cf1fb80a30389fd3ba821d40b6111a3294d95
(cherry picked from commit 49062f3b72)
Previously, after `adb reboot userspace` is called on a device that
doesn't suppor it, init would've logged an error and quietly exit the
shutdown sequence. This was leaving adb handing forever.
With this approach, init will fail setprop
"sys.powerctl=reboot,userspace" in case userspace reboot is not
supported.
Test: adb root
Test: adb setprop init.userspace_reboot.is_supported 0
Test: adb reboot userspace
Test: atest CtsInitTestCases
Bug: 146639622
Change-Id: I1264078f53ed3ff54638c7f3b6846b7437f98ee5
Merged-In: I1264078f53ed3ff54638c7f3b6846b7437f98ee5
(cherry picked from commit 92116e4129)
am skip reason: Change-Id I7552d5ccc6e9b750a6081947eef8fcb027be13e1 with SHA-1 663cd35030 is in history
Change-Id: Iea491137db1f9dd047c3d82ecc6f97d83e860712
This should help in debugging issues related to the mismatch between
actual last reboot reason property and the expected one (see attached
bug).
Test: adb reboot
Test: adb logcat | grep bootstat
Bug: 152900920
Change-Id: I085cf1fb80a30389fd3ba821d40b6111a3294d95
