With the binary transparency log stored in git, it makes that more readable
and as small as possible if the index files are fully sorted. That will
reduce the differences between two copies of an index file to a bare
minimum.
If in the future we implement some kind of binary diff transfer, this will
also help there.
Google is making gradle automatically download Android SDK components that
are needed by the build, but not already present. We need to support that
since it would be a lot of work to fight it. Plus, since each build starts
from the fresh snapshot, it should not be such a big deal to let each
build install stuff during the process.
closes#268
Google has their own utility for verifying APK signatures on a desktop
machine since Java's jarsigner is bad for the task. For example, it
acts as if an unsigned APK validates. And to check whether an APK is
unsigned using jarsigner is difficult.
apksigner also does the v2 signatures, so it will have to be used
eventually anyway. It is already in Debian/stretch and can be
available in jessie-backports if need be.
https://android.googlesource.com/platform/tools/apksighttps://packages.debian.org/apksigner
There are two SHA1 git commit IDs that fdroidserver includes in the builds
it makes: fdroidserverid and buildserverid. Originally, these were inserted
into AndroidManifest.xml, but that makes the build not reproducible. So
instead they are included as separate files in the APK's META-INF/ folder.
If those files exist in the signed APK, they will be part of the signature
and need to also be included in the unsigned APK for it to validate.
This makes the jarsigner the ultimate and only judge of whether two APKs
match. This is the best tool since APK signatures are jar signatures. This
should be eventually updated to use the official Android APK signing tool
called apksigner.
https://android.googlesource.com/platform/tools/apksig/
The ZIP format allows multiple entries with the exact same filename, and on
top of that, it does not allow deleting or updating entries. To make the
`fdroid verify` procedure failsafe, it needs to create a new temporary APK
that is made up on the contents of the "unsigned APK" and the signature
from the "signed APK". Since it would be possible to give a signed APK as
in the unsigned one's position, `fdroid verify` was not able to update the
signature since it was just adding the new signature to the end of the ZIP
file. When reading a ZIP, the first entry is used.
This is a bit different than index.jar: instead of their being index.xml
and index_unsigned.jar, the presense of index-v1.json means that there is
unsigned data. That file is then stuck into a jar and signed by the
signing process. index-v1.json is never published to the repo. It is
included in the binary transparency log, if that is enabled.
If there are graphics files that are in repo/ but there is no metadata for
the associated app, then do not include the graphics in the index. Issue a
warning about this.
This looks for standard graphics assets in two standardized locations, one
in metadata/ subdirs and another in fastlane's standard dirs in the app's
source repo. When it finds them, it copies them into the repo, where they
will then be included in the index for use by fdroidclient. The images in
the metadata/ folder of fdroiddata take precendence over the files in the
app's source repo.
So like this for including graphics in fdroiddata:
metadata/packageName/locale/filename.(png|jpg|jpeg)
for example:
metadata/org.videolan.vlc/en-US/featureGraphic.png
or
metadata/info.guardianproject.ripple/zh-CN/phoneScreenshots/screenshot1.png
Including graphics in fdroiddata would be optional. The prefered way to get
graphics into the repo would be for the files to be in the git repo in a
standard location. This fastlane layout is currently supported:
https://github.com/fastlane/fastlane/blob/1.109.0/supply/README.md#images-and-screenshots
This just makes it easier for people writing build recipes. Rewriting will
output a list of strings as well.
The test index.xml and categories.txt are updated to include the new number
categories, and the changed CurrentVersionCode to 2147483647 (MAX_VALUE)
