When signing a file with -w (ie, an OTA package), add the file
META-INF/com/android/otacert, which is a copy of the public key
certificate. While this can be extracted from the CERT.RSA file,
having a copy of it more easily accessible makes it easier to write
tools.
Bug: 6477365
Change-Id: I8cdb19536eca9a223c2b954e3f8ea0d9f3f86f02
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
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.
