We need to (a) tell soong to copy our data and (b) automatically find
our data relative to our executable.
The real point of this is to be able to run these tests in APCT and
presubmit.
Bug: N/A
Test: ran tests on host and device, from a variety of directories
Change-Id: I4c0be1ac60f03953fdd5ba6e3d15b1aaa37ed019
libziparchive is explicitly marked as double_loadable since it is one of the
(indirect) dependencies of the LLNDK library libvulkan
and at the same time the lib itself is marked as VNDK. Such lib can be
double loaded inside a vendor process.
Note: even without this change, the library is already capable of being
double loaded due to the dependency graph around it. This change is to
make it explicit so that double loading of a library is carefully
tracked and signed-off by the owner of the lib.
Bug: 77155589
Test: m -j
Merged-In: Id0a731d553bbb68b84bca421500c94b7b35eca14
Change-Id: Id0a731d553bbb68b84bca421500c94b7b35eca14
(cherry picked from commit 730728cbb4)
Fix failures in DataDescriptor related tests due to to a bad call to
SetZipString (undefined behaviour). Also fix a typo in the test for
invalid descriptors, we were asserting things on the wrong array.
Test: zip_archive_test
Change-Id: I8c9a632443fdf1d5c115670d6e9317e1f4bf6ef4
Moving to std::hash changed iteration order but these tests should
not have relied on hash_map iteration order anyway.
Test: zip_archive_test
Change-Id: I712bf2307c8770f03ea6f074bfc506a40cdcb066
Both Extract...() functions don't need dynamic allocation
for the writers, as those are strictly scoped. This CL
changes heap allocation to stack allocation.
Test: zip_archive_test
Change-Id: Id727e4b9848235cd063cc67ecbe052d21ca21326
Only compute the crc32 if required. In addition :
- Add unit tests for Inflate that cover this addition.
- Fix an inconsistency in return codes that was revealed
by this new test.
Bug: 35246701
Test: zip_archive_tests
Test: make; zipalign.
Merged-In: I31d7554378f94fc8995f707471d57cb98311e2c2
Change-Id: I05111bfa665c610f93d1c1dee987a509bf87aa65
Previously fastboot would carry on regardless if decompression failed:
fastboot: archive does not contain 'vbmeta.img'
fastboot: extracting vendor.img (260 MB)...
fastboot: W/ziparchive(56777): Zip: unable to allocate 272781472 bytes at offset 0 : No space left on device
fastboot: failed to extract 'vendor.img': I/O error
fastboot: archive does not contain 'vendor_other.img'
fastboot: wiping userdata...
This is because all but "boot" and "system" are considered "optional",
and the implementation of "optional" was "ignore any failures". What it
_should_ have meant was "it's okay if these don't exist, but if they do,
failures matter".
Fix this logic, use die() more aggressively, and remove spurious "\n"s
from die() format strings.
Also fix spurious whitespace in the libziparchive format string. Before:
Zip: unable to allocate 272781472 bytes at offset 0 : No space left on device
After:
Zip: unable to allocate 272781472 bytes at offset 0: No space left on device
Bug: http://b/68383022
Test: `fastboot update` on marlin
Change-Id: I3cbf55f1a33ca125f293f873eafbcfb86c880ba8
Remove dependencies on zip_archive specific data structures. In follow
up changes, this method will be promoted to a public API and used from
androidfw/ZipUtils as well as tools/zipalign, thereby allowing us to
remove a near-exact copy of this code and to simplify depdencies.
Test: zip_archive_test
Bug: 35246701
Change-Id: If24a9965fbd6fff308c8758859026684fd2af3b9
As a VNDK module, Android.bp must have 'vndk' tag as well as
'vendor_available: true'.
The 'vndk' tag for VNDK module is formated as below:
vndk: {
enabled: true,
},
VNDK modules will be installed both in system/lib(64) as normal and
in system/lib(64)/vndk as a vendor variant.
Bug: 63866913
Test: build and boot with BOARD_VNDK_VERSION=current
Merged-In: Iec5d3496e91a99f3e6b0c816c67ad279672ff36a
Change-Id: Iec5d3496e91a99f3e6b0c816c67ad279672ff36a
(cherry picked from commit 4e7e5b3ba053d013f2c4ae79d02722b874c629fb)
As a VNDK module, Android.bp must have 'vndk' tag as well as
'vendor_available: true'.
The 'vndk' tag for VNDK module is formated as below:
vndk: {
enabled: true,
},
VNDK modules will be installed both in system/lib(64) as normal and
in system/lib(64)/vndk as a vendor variant.
Bug: 63866913
Test: build and boot with BOARD_VNDK_VERSION=current
Change-Id: Iec5d3496e91a99f3e6b0c816c67ad279672ff36a
The use of ReadAtOffset is meant to allow concurrent access
to the zip archive once it has been loaded. There were places
where this was the case, and some places that did a seek + read
combination, which could lead to data races.
NOTE: On Windows, we are not using pread as the implementation of
ReadAtOffset, therefore the guarantees on Windows are weaker.
On Linux, pread allows the file descriptor to be read at a specific
offset without changing the read pointer. This allows inherited fd's
and duped fds to be read concurrently.
On Windows, we use the ReadFile API, which allows for an atomic seek +
read operation, but modifies the read pointer. This means that any mix
use of ReadAtOffset and Read will have races. Just using ReadAtOffset is
safe.
For the Windows case, this is fine as the libziparchive code now only
uses ReadAtOffset.
Bug: 62184114
Bug: 62101783
Test: make ziparchive-tests (existing tests pass)
Change-Id: Ia7f9a30af2216682cdd9d578d26e84bc46773bb9
libziparchive-host needs to include the headers correctly, too.
Bug: 37342627
Test: mmma system/core/libziparchive
Change-Id: I88a6d38ff9e494273040f9b913c71bccdda117ad
By forward-declaring zstream, we don't need to re-export zlib headers.
Bug: 37342627
Test: build
Test: BOARD_VNDK_VERSION=current m -j dumpstate (or any other module
using libziparchive)
Change-Id: Ia69e5d459c79878d491cfe4ca21a7cc8fed4a5d8
libziparchive headers are moved from the global include directory
(/system/core/include) to the local directory inside libziparchive.
Note: /system/core/include/ziparchive still exists as a symlink to
libarchive/include/ziparchive. This will be removed when there is no
header-only dependency to libziparchive.
Bug: 37342627
Test: build
Change-Id: I3631ffc2df7be8a064d64a625d10436090c3bb0f
We should check the boundary of central directory before checking its
signature. Swap the order of these two checks.
Bug: 36392138
Test: libziparchive doesn't read the signature after boundary check fails.
Merged-In: Ie89f709bb2d1ccb647116fb7ccb1e23c943e5ab8
Change-Id: Ie89f709bb2d1ccb647116fb7ccb1e23c943e5ab8
(cherry picked from commit 74464a1361)
Add a check to ensure the filename boundary doesn't exceed the mapped
memory region. Also add the corresponding unit test.
Bug: 28802225
Test: New unit test passes.
Merged-In: Ibf543a7da3d7898952e9eb332c84cdfc67cf5aa4
Change-Id: Ibf543a7da3d7898952e9eb332c84cdfc67cf5aa4
(cherry picked from commit bcc4431f24)
The boundary check of an invalid EOCD record may succeed due to the
overflow of uint32_t. Fix the check and add a unit test.
Test: Open the crash.apk and libziparchive reports the offset error as expected.
Bug: 31251826
Merged-In: I1d8092a19b73886a671bc9d291cfc27d65e3d236
Change-Id: I1d8092a19b73886a671bc9d291cfc27d65e3d236
(cherry picked from commit ae8180c06d)
