so that PackageManagerService can iterate over files with a
specific file extension like ".so".
Bug: 21957428
Change-Id: I76ed9560d4d1e00d297a97d518ec357166be1981
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
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
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
Yusuke Sato