Files
DarkRoom/docs/android-signing.md
T
dtourolleandClaude Opus 5 40e6334bb1
🐳 Android image / Build and push (push) Successful in 3s
Build and test / android-image (push) Successful in 3s
Build and test / Desktop (Linux) (push) Successful in 21m23s
Build and test / Layer separation (push) Successful in 29s
Traceability / Requirement traces (push) Failing after 28s
Build and test / Android (aarch64) (push) Failing after 33m28s
Sign the APK with a real key when one is configured
The APK has been debug-signed with a key generated on the spot, which is
right for putting a build on a test device and useless for anything else:
a different signature every run, so nothing can ever update in place.

Four secrets now select a real signature -- ANDROID_KEYSTORE_BASE64 and
its password, alias and key password. The names are JellyTau's, because
that repo already signs its Android build this way against this same
runner and one convention across both is one thing to remember.

Absence of the secrets is not an error. A fork or a branch build has no
access to them and should still produce an installable APK, so the debug
path stays exactly as it was. The reverse is an error: if a keystore is
supplied and cannot be read, the build fails rather than quietly falling
back to a debug key, because a release that is silently debug-signed is
worse than no release.

Passwords reach apksigner and keytool as `env:`, never `pass:`. `pass:`
puts the password in the process table for anything on the box to read.
The keystore is written to a 0700 mktemp directory and never into the
workspace, which is both what actions/cache saves and what the upload
step globs.

Also: upload-artifact drops from v4 to v3. v4 was a guess about what this
Gitea supports. v3 is what JellyTau uploads its APK with on this runner
today, which makes it the version known to work rather than the one that
ought to.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-26 10:13:50 +02:00

2.7 KiB

Signing the Android build

Every build produces an APK. Which key signs it depends entirely on whether four secrets are present:

secret what it is
ANDROID_KEYSTORE_BASE64 the keystore file, base64-encoded
ANDROID_KEYSTORE_PASSWORD the store password
ANDROID_KEY_ALIAS the alias of the key inside the store
ANDROID_KEY_PASSWORD the key password

With none of them set, docker/android/assemble-apk.sh generates a throwaway debug key and signs with that. That is the right answer for a branch build or a fork: the APK installs on a test device and nothing pretends it is a release. With all of them set, the same script signs with the real key.

The names match JellyTau's deliberately. One convention across both Android projects is one thing to remember instead of two.

Making the key

Once, and then never again — keep it forever. Android identifies an app by its signature, so an app signed with a new key is a different app to every device that has the old one installed. There is no recovery from losing it beyond telling everybody to uninstall and reinstall.

keytool -genkeypair -v \
    -keystore darkroom-release.jks \
    -alias darkroom \
    -keyalg RSA -keysize 4096 -validity 10000 \
    -dname "CN=Duncan Tourolle, O=tourolle.paris, C=FR"

keytool prompts for the passwords rather than taking them on the command line, which keeps them out of shell history. Back the .jks up somewhere that is not this repository and not the machine that builds it.

Loading the secrets

base64 -w0 darkroom-release.jks > /tmp/ks.b64
tea api --method PUT /repos/dtourolle/DarkRoom/actions/secrets/ANDROID_KEYSTORE_BASE64 \
    -f data=@/tmp/ks.b64
shred -u /tmp/ks.b64

# and the three strings, read rather than typed so they miss the history
read -rs PW && tea api --method PUT \
    /repos/dtourolle/DarkRoom/actions/secrets/ANDROID_KEYSTORE_PASSWORD -f data="$PW"

...and the same for ANDROID_KEY_PASSWORD and ANDROID_KEY_ALIAS. Or paste them into Settings → Actions → Secrets in the web UI, which is less fiddly and just as good.

Checking which key signed a build

The packaging step prints it, and the APK carries it:

apksigner verify --print-certs darkroom.apk

A debug build says CN=Android Debug. Anything else is the real key.

Signing locally

docker/android/package.sh takes the same environment variables, so a local release-signed build is:

KEYSTORE=$PWD/darkroom-release.jks KEY_ALIAS=darkroom \
KEYSTORE_PASS=... KEY_PASS=... ./docker/android/package.sh

Without them it debug-signs, and keeps one debug keystore in the build cache so repeat installs to a device do not need an uninstall first.