FOSS #5: build both flavors in CI, publish foss APK, F-Droid metadata + reproducible builds

[Monkopedia]

Part of #460. Depends on all of #461–#464 landing (or at least the flavors + foss impls).

Goal

Build both flavors in CI, publish the foss APK on GitHub Releases, and get the app into F-Droid.

How F-Droid actually works (so the plan is right)

• You don't upload an APK to F-Droid. You submit a metadata recipe to fdroiddata; F-Droid's buildserver builds the foss flavor from a tagged source commit and signs it with F-Droid's key. The recipe specifies the flavor and scrubs any non-FOSS traces.
• Better path — reproducible builds: publish our own signed foss APK on GitHub Releases and add the Binaries: + AllowedAPKSigningKeys directives. F-Droid builds from source, compares byte-for-byte against our published APK, and if they match ships our APK with our signature. Same signature means users can move between the GitHub APK and the F-Droid APK with no uninstall. This requires deterministic builds (extra work) but is the gold standard. (F-Droid reproducible builds)

Work

• Extend the release workflow (.github/workflows/release.yml) to build both flavors on tag: a signed google APK (current distribution) and a signed foss APK, both as GitHub Release assets. The release notes should distinguish the two.
• Author the fdroiddata metadata recipe: Builds block targeting the foss flavor, correct versionName/versionCode, scanner-clean (no bundled binaries / non-FOSS deps).
• Pursue the reproducible-builds path: make the foss release build deterministic, add Binaries: + AllowedAPKSigningKeys, and verify with diffoscope against our published APK.
• Document the dual-distribution story in docs/ (which flavor ships where, how a user picks, signature implications).

Acceptance

• Tagging a release produces both a google AAB and a signed foss APK as artifacts.
• A documented, scanner-clean fdroiddata recipe builds the foss flavor from source.
• Reproducible-build verification passes (or a tracked list of the remaining non-determinism blockers if it doesn't on first attempt).

Note

This ticket is mostly CI + packaging + external-metadata authoring; the actual F-Droid submission/merge into fdroiddata is a manual step the user performs (separate repo).

[monkopedia-coder]

Triage: reclassifying blocked → needs-decision. Dependencies #461–#464 have all landed, clearing the blocker. Remaining work (reproducible-build verification + the manual fdroiddata submission) is user-gated rather than autonomously dispatchable.

[Monkopedia]

Reproducible-builds investigation (FOSS release variant)

Empirical double-build of the default FOSS variant on one machine. Tooling: AGP 8.13.2, Kotlin 2.2.21, build-tools 36.0.0, JDK 21. Command: ./gradlew clean :app:assembleRelease ×2 (FOSS = default; -Pgoogle opts into Firebase).

(a) Is the same-machine double-build identical?

Almost — identical except the APK v2 signature block. Both APKs are exactly the same size (5,754,503 bytes). Unzipped contents are byte-for-byte identical (diff -r clean: classes.dex, classes2.dex, resources.arsc, all lib/*/*.so, assets/dexopt/baseline.prof[m], AndroidManifest, every META-INF/*.version). Zip metadata is identical too: same entry ordering, same per-entry CRCs / compressed sizes / methods, and all entry timestamps normalized to 1981-01-01 (AGP already zeroes these).

cmp finds exactly one differing region: bytes 5,670,095–5,683,527 (~13.4 KB, contiguous). That region sits entirely inside the APK Signing Block (which spans 5,668,652–5,685,036; magic APK Sig Block 42). Everything before the signing block (all zip entries) and everything after it (central directory + EOCD) is identical.

Root cause of the only difference

The APK is signed v2-only with a 2048-bit RSA / SHA256withRSA key. For RSA keys, apksigner emits multiple v2 signatures including RSASSA-PSS, which uses a random salt → the signature bytes differ on every run. This is the single, well-understood source of non-determinism, and it is confined to the signing block. The signed content (everything apksigner actually hashes) is fully deterministic.

(b) Determinism blockers + fixes

There are effectively no content-level blockers. Specifically checked and found clean:

• No build-time/git-sha embedding. buildConfigFields are static (BASE_DOMAIN/RELAY_HOST/PORT/SCHEME); versionCode=4/versionName="1.0.3" are hardcoded. No resValue or BuildConfig field captures wall-clock time, hostname, or git state.
• Zip timestamps / ordering already normalized by AGP (no preserveFileTimestamps work needed).
• R8/D8 dex is reproducible here — classes.dex/classes2.dex matched bit-for-bit across builds (R8 from AGP 8.13.2).
• Native libs: four androidx prebuilts (libdatastore_shared_counter.so, libandroidx.graphics.path.so × 4 ABIs) pulled from Google Maven, identical across builds. Not committed to the repo.
• Baseline profile (assets/dexopt/baseline.prof[m]) reproduced identically.

The only "fix" is the signature non-determinism, and it does not need fixing for F-Droid: F-Droid's reproducible path (apksigcopier) compares the unsigned APK and copies the developer's signature block over. PSS-salt variance in the signing block is exactly what that path tolerates. (If we ever wanted bit-identical signed APKs outside F-Droid, the lever is forcing PKCS#1 v1.5-only signing, e.g. via apksigner flags / a re-sign step — not required here.)

(c) F-Droid fit

This app is a strong fit for the Binaries: + AllowedAPKSigningKeys (signature-reuse) path — users could move between the GitHub APK and the F-Droid APK with no uninstall.

• Scanner: clean. No committed .jar/.aar/.so/.apk/.dex/.keystore except the standard gradle/wrapper/gradle-wrapper.jar (F-Droid validates the wrapper). Native .sos come from Maven deps at build time, not the source tree.
• Non-free deps: the default FOSS build is genuinely Firebase/GMS-free — 0 Lcom/google/firebase/… or Lcom/google/android/gms/… type descriptors in the dex (the "firebase" strings present are app log/field literals and UnifiedPush's own embedded_fcm_distributor class names). Firebase/google-services are declared in the version catalog but only linked under -Pgoogle, so they never enter the FOSS artifact. FOSS wake/crash path is UnifiedPush 2.5.0 + ACRA 5.13.1 (both FOSS). No google-services.json required to assemble.
• Recipe (high level): build command gradle assembleRelease (no -Pgoogle); sudo= none; output=app/build/outputs/apk/release/app-release.apk; Binaries: pointing at the GitHub release asset; AllowedAPKSigningKeys=5394b7c725925737dae18a320609efb0f69f8d028b0a1204157e1962dfe51dca (the release cert SHA-256). Pin AGP/Kotlin/build-tools as already in the catalog. local.properties (sdk.dir) is generated by F-Droid, not committed.

Verdict

Reproducible builds are achievable now — effectively already achieved. The FOSS release is byte-identical run-to-run apart from the RSASSA-PSS-salted v2 signature, which F-Droid's apksigcopier flow handles by design. No hard blockers. Remaining work is integration plumbing, not determinism fixes: (1) CI publishes the signed FOSS app-release.apk as a GitHub release asset; (2) write the fdroiddata metadata (Builds entry + Binaries: URL + AllowedAPKSigningKeys); (3) confirm reproducibility on a clean/different host (this run was same-machine — a second host would catch any path/locale/toolchain-version leakage, though none is expected given the config). Rough estimate: ~1–2 days, dominated by the fdroiddata RB-verification round-trip, not by app changes.

Method note: diffoscope was unavailable; fell back to diff -r on unzipped trees + zipinfo metadata compare + cmp -l byte-region mapping + APK Signing Block offset analysis. Investigation only — no build files changed, no PR.