The java.util.jar implementation through Android 1.6 has a
bug where if the signature file in META-INF is a multiple
of 1024 bytes, it will throw an IOException attempting to
read it.
If signapk would produce a CERT.SF in a multiple of 1024
bytes, add an extra CRLF to the end of the file.
Bug: 3019677
Change-Id: I23d4a36e12e224be600d3ac39379b5b5a022a628
(Actually there was a tapas command that just called choosecombo).
The new better tapas command is for building unbundled apps. Run
it with one or more modules to build and optionally a build variant.
tapas [variant] App1 App2 ...
If you don't supply a build variant, it defaults to eng.
Change-Id: I02214abd0b5ad02e364fcb024e10cf6ad17a9e68
The two 0xff bytes were intended to easily distinguish files with
whole file signatures from those without, but I got the endianness
backwards. Go ahead and fix that, as long as I'm making changes to
the verifier anyway.
Check for a signature that includes the sequence 0x50 0x4b 0x05 0x06,
which looks to minzip like the start of the EOCD block.
Make SignApk generate a signature for (nearly) the entire zip file
when run with the -w option. The signature covers all of the zip file
except for the archive comment (conveniently the last thing in a zip
file); the archive comment field is used to contain the signature
itself.
SignApk fixes the timestamp of the signature files it adds. Use that
same timestamp for all the files, so that the modtime doesn't vary
from build to build. (Incremental OTAs currently spend significant
time rewriting every .apk to do nothing but patch in timestamp
changes.)
Change signapk to not propagate other signatures to the output
archive. Multiple signatures seem to confuse the package manager, as
we saw with Maps, and other partners are checking in prebuilt APKs for
google experience devices signed with random other things.
Ficus Kirkpatrick