The buildserver VM has not been upgraded yet to bullseye, so it is still on
Debian/stretch. The buildserver VM does not need to run `fdroid update`,
`fdroid signindex`, etc. so this new apksigner requirement should not
affect app builds even though they are stuck on Debian/stretch.
The current signing method uses apksigner to sign the JAR so that it
will automatically select algorithms that are compatible with Android
SDK 23, which added the most recent algorithms:
https://developer.android.com/reference/java/security/Signature
This signing method uses then inherits the default signing algothim
settings, since Java and Android both maintain those. That helps
avoid a repeat of being stuck on an old signing algorithm. That means
specifically that this call to apksigner does not specify any of the
algorithms.
The old indexes must be signed by SHA1withRSA otherwise they will no
longer be compatible with old Androids.
apksigner 30.0.0+ is available in Debian/bullseye, Debian/buster-backports,
Ubuntu 21.10, and Ubuntu 20.04 from the fdroid PPA. Here's a quick way to
test:
for f in `ls -1 /opt/android-sdk/build-tools/*/apksigner | sort ` /usr/bin/apksigner; do printf "$f : "; $f sign --v4-signing-enabled false; done
closes#1005
If a project uses fdroidserver as a library, then just calls
common.get_apk_id(), it will now work. Before, that project would have had
to include something like `common.config = {}` to avoid a stacktrace.
With the previous code, a trailing newline would result in an empty
space being part of the list. When this is passed to keytool, it fails
with "Illegal option: ".
Instead of doing overly complicated regex based string substitution
followed by parametrized splitting, we can simply use `.split()`
without any parameters, and Python will automatically strip any
whitespace.
This is related to androguard features that fdroidserver does not use:
WARNING: Requested API level 31 is larger than maximum we have, returning API level 28 instead.
When using rsync or s3cmd, the upload is done in multiple passes. This
reduces the chance of interfering with an existing client-server
interaction.
- rsync: In the first pass, upload without the index files and delay
the deletion as much as possible. That keeps the repo functional
while this update is running. Then second pass uploads the index
files.
- s3cmd: In the first pass, only new files are uploaded. In the
second pass, changed files are uploaded, overwriting what is on the
server. On the third/last pass, the indexes are uploaded, and any
removed files are deleted from the server. The last pass is the
only pass to use a full MD5 checksum of all files to detect changes.
