It's important because entry names can be encoded in UTF-8 and can have \0
character in the middle.
Use vector instead of char* for prefix in IterationHandle.
Bug: 16162465
Change-Id: Ie34c8d7c6231cc258530c22bdde5542895213649
Add new public method to allow checkisc if an archive has entry names encoded in
UTF-8. If not then they will be encoded in IBM PC character encoding.
Bug: 16162465
Change-Id: I4468d76accca8a9b0b31cae8d43399ffc22cad42
in StartIteration. This method should always be called when the
iteration is over to make sure that we don't leak memory.
Change-Id: I5205c754dfafbab9bb5f06003c3663d2ec4e8a35
Given that all current & future android ABIs are
little endian, we can get rid of the explicit conversions
from memory regions to little endian data members.
Also cleans up a few C style casts that snuck in during
several -Werror efforts and fixes temporary file generation
on target.
bug: 15448202
Change-Id: I4fcbb3c1124cb82c82139d328344e54fc7895353
Currently CloseArchive doesn't call free and call sites don't appear
to either. I could not find any call sites which manually freed the
archive by deleting the handle. This fixes several memory leaks.
Change-Id: I21f187dde60fd87e6e54bde06de9e76fd0791104
Two minor issues were fixed:
- The offset to entry data can be the same as the
central directory offset when the last entry in the
file has length 0 and is stored (not deflated). Fix
a check that disallowed this. We already have a strict
check that entry data must end before the central directory,
so we're covered.
- We would attempt to map a segment of length 0 when writing
an entry whose length is 0. We should just return early in
this case.
bug: 12623277
Change-Id: I2a4ca0c4d170cc3cbf326e5ca13894acd9c434c9
The issue here is that the makefile sets LOCAL_LDFLAGS
and asks for -llog without declaring a dependency on it.
This will cause build breakages if liblog hasn't already
been built yet.
Change-Id: Ia38761cda44a38b6c2a88902d6108cbe64a328ce
Unlike ALOGV, messages from ALOGD are logged on
all configurations. Not finding an entry in a zip
file is a "normal" occurrence so using an ALOGD
message for it amounts to spam.
Change-Id: I2c60d11e8a750be5106afd65c3c5e335f53f01b6
We would always write uncompressed data at offset 0 instead
of the current filedescriptor offset.
Also adds a unit-test & a clarifying comment on the API.
Change-Id: If44757e96dde504ce63d81b4dec7115fc6f6d5fb
We don't need a warning if an entry isn't found in a zip
file. It can happen as part of normal operation.
Change-Id: I86c132a040371f36f0dd981b49c02b3173821439
- Add a build rule for host tests
- Add basic tests for Find / Iterate and Extract
for both deflated & stored entries.
- Fix an off by one error that the test uncovered.
Change-Id: If72009b1ea9791d5a265829f05c32ffe1c2752c4
Extract zip file processing logic from libdvm into a
standalone library.
This library is a stricter than the libdvm library in
several ways:
- Duplicate zip entry names are now disallowed. Files with
such entries will fail to parse.
- We now verify CD file size information with the individual
file header information. (This was pointed out as a deficiency
of this implementation in past discussions.)
- We also add support for crc checking, which means we might
need to parse the optional data descriptor footer (if one
exists).
We also provide an API for iterating over the entries of
a zip file. This library is optimized for two use cases :
- Lookup for a single entry in the file, with the intention
of processing or extracting the data associated with that
entry
- Iterating over all entries in a file *and* processing
/ extracting their data.
Change-Id: Ia87de6184ef753cc470b0af755c47a4f92ac8198
