Not looking for other users right now, this is just enough to test
unzip/zip/zipinfo.
This includes tests for unzip and ziptool, along with a change to
unzip's behavior to fix AOSP `make dist` when using ziptool unzip.
Also add the boilerplate to run these tests on the device, in presubmit.
Fix command name in --help output.
Test: atest ziptool-tests
Change-Id: I5c0215a3ab8cb2cd5fc517ed9c188f81a7bf4520
Useful for debugging and hermetic builds. (Various places in the build
check to see that a file was stored uncompressed.)
Test: manual
Change-Id: I127e5689cd493ab06739b765beed50912dc9cc1d
Didn't find anything when I ran it, but it did get me to fix the
const/non-const void* in the API.
Test: treehugger
Change-Id: If3849d974965e3e5ffcbdaf5e47921316d717410
These add 16 bytes per ZIP entry, and are usually avoidable. APKs contain thousands of
deflated entries, so this overhead adds up to tens of kilobytes.
Bug: 135470635
Change-Id: Ib928aa41dd55cacc41f7394c218c4340d3bbd570
Enable native bridge support for libbase, liblog,
libziparchive and libpropertyinfoparser.
This makes it possible to use them in binaries for translated
architectures.
Bug: http://b/77159578
Test: make
Change-Id: If67ce92288b17a052ea1e79a268e284f7d941439
Enable -Wconversion (but not -Wsign-conversion). Fix up code. Handle
some actual error cases:
* too many files
* files too large
Bug: 130039052
Test: atest ziparchive-tests
Change-Id: I632af317b9e65dbc728851efefd0d11a2b5c29b9
The code in libziparchive has lots of questionable looking but not
obviously wrong integer operations. In order to shake out integer bugs
in libziparchive (for example, commit
1ee4892e66 from bug 31251826) and provide
protection against security bugs, enable some integer sanitization
options in libziparchive.
Bug: 122975762
Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=941802
Test: device boots and no obvious problems.
Change-Id: I215d81892a6eff12d692648c69a03e8200b334d7
Other CL in topic address the issue of the file pusher.
The explicit config for this module will not be required
anymore.
Test: atest -v ziparchive-tests
Bug: 124515549
Change-Id: I4dad8adbce0817009158bc191c2cce86c38d9e3e
To work around problems with the autogenerated one.
Bug: 117891984
Bug: 124515549
Test: atest ziparchive-tests
Change-Id: Ia4b352b7404255a4fe9e644a56ae9c5d41c79886
We can't add the ones that need a shared library because the
infrastructure doesn't work yet. (We also can't comment this in the file,
because there's no support for comments :-( .)
Bug: N/A
Test: N/A
Change-Id: I4d84f962bbf48fc708df336726c18e48fe206492
The libziparchive public headers that refer to `off64_t` also need the
Mac workaround.
In fastboot, there's a stray `lseek64` but since it's only for offset 0,
any kind of seek is fine.
Bug: N/A
Test: builds
Change-Id: I68b4f95202623ebf07ffe6c3e0e21437e7922c5b
This allows us to remove libziparchive's dependency on libutils.
Bug: http://b/79112958
Test: ran libbase and libziparchive tests, ran fastboot manually
Change-Id: I95c651976dad222863e5b8c37d4514b778f5dce7
Bug: http://b/91353691
Enable -Wold-style-cast only for non-Windows targets. _islower_l,
_isupper_l etc. in MinGW locale_win32.h (included from
libcxx/include/__locale) have an old-style-cast.
Test: Build and test Windows modules under Wine.
Change-Id: Ib7594559a43096885b0cc1c656cf59db8b52d38b
adbd has been built as a static executable since the same binary was
copied to the recovery partition where shared library is not supported.
However, since we now support shared library in the recovery partition,
adbd is built as a dynamic executable.
In addition, the dependency from adbd to libdebuggerd_handler is removed
as debuggerd is handled by the dynamic linker.
A few more modules in /system/core are marked as recovery_available:
true as they are transitive dependencies of the dynamic linker.
This change also includes ld.config.recovery.txt which is the linker
config file for the recovery mode. It is installed to /etc/ld.config.txt
and contains linker namespace config for the dynamic binaries under
/sbin.
Bug: 63673171
Test: `adb reboot recovery; adb devices` shows the device ID
Test: Select 'mount /system' in the recovery mode, then `adb shell`.
$ lsof -p `pidof adbd` shows that libm.so, libc.so, etc. are loaded from
the /lib directory.
Change-Id: I363d5a787863f1677ee40afb5d5841321ddaae77
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)
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)
libziparchive-host needs to include the headers correctly, too.
Bug: 37342627
Test: mmma system/core/libziparchive
Change-Id: I88a6d38ff9e494273040f9b913c71bccdda117ad
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
This patch adds two benchmarks that measure the performance of some
operations of libziparchive.
Both benchmarks are creating a temporary zip file containing file
names of uniformly distributed lengths. The creation of the zip
file is not timed in the benchmarks.
- FindEntry_no_match tries to find an inexisting entry in the files
of the zip archive, in order to force the code to examine all the
files in the archive.
- Iterate_all_files uses the iterate function to list all the files
in the archive.
Bug: N/A
Test: adb shell /data/ziparchive-benchmarks
Change-Id: Ibdb524ba1c5ae55caddf0416ebbc09f8b6df0021
libziparchive is a library which belongs to vndk-cap. Mark it
vendor_available to enable header-abi-dumper's invocation to identify it
as a part of the vndk.
Details: https://android-review.googlesource.com/368372
Test: mm -j64
Bug: 38244611
Change-Id: Ibe490cc6c2cfca0f8d58df45317bb3a491d530f0
libutils, libz and libbase are being used as shared lib by many other
modules.
So using their shared lib will reduce total image size.
Size diffs on angler build image are as follows.
libziparchive.so : 103844 -> 41680 (-62164)
libnativeloader.so: 50824 -> 25104 (-25720)
total : (-87884)
Test: building succeeded, and the image was tested on angler.
Bug: 33056637
Change-Id: I015afe5b8f4d87d495b706e2e78d60f44a910e87
On 32 bit system those calls may fail if one tries to unpack files which
are bigger than 2GB.
Use large file system support to fix this problem.
Test: unpack a file bigger than 2GB on 32 bit Android systems
Change-Id: Ibd9bd5fc4a2f8dc7df98bd595f4fd1638a4f0d4a
Signed-off-by: Christian Poetzsch <christian.potzsch@imgtec.com>
