Even if we were shipping 64-bit Windows host tools (which we still
aren't), this would still be a bug. Windows is LLP64 instead of LP64,
so the long that ftell()/fseek() uses isn't big enough for a 64-bit off_t.
Test: treehugger
Change-Id: I4e24afe811ff9b7d5696887cc5ee92e54e4a3b76
In preparation for including them in prebuilts/build-tools.
acp: We use a prebuilt in prebuilts/sdk, but it's not part of the sdk.
ijar: We use the host libstdc++ to workaround the lack of libc++ on
some unbundled branches.
ziptime: We disable this on unbundled builds, due to the lack of libc++.
Change-Id: Ib9766b1dbddd151c38ff27c529865200ab37fce1
getLongLE would return a 64-bit number with the upper 32-bits set when
decoding a 32-bit number with the top bit set. Per the zip file format,
it was only expected to return a 32-bit number. Use explicitly sized
types so that we use the proper sizes and don't do any implicit
extensions.
Change-Id: I5a4304dc99ce5f8f17284d4ca3094ae115207a1e
Pass -X to zip so that Unix UID/GID and extra timestamps aren't
saved into the zip files.
Add a new tool, ziptime, that uses a very stripped down copy of
zipalign. It no longer depends on libandroidfw, and now rewrites the
timestamps in place instead of making a copy of the zipfile. This should
improve speed and reduce disk requirements, especially with the large
packaging zip files.
Bug: 24201956
Change-Id: I50f68669f659da1b4393e964ad40b6aafb00c1e7
