build: add F-Droid metadata and reproducibility checks

[zefutoff]

Summary

• add an F-Droid-style reproducibility verification workflow
• make release APK signing deterministic with Android Build Tools 34.0.0
• pin the signed-release runner to Ubuntu 24.04
• disable AGP release VCS metadata that depended on the Git checkout layout
• reconstruct a signed APK from a clean clone using apksigcopier
• require byte-for-byte identity with the upstream signed APK
• add upstream Fastlane-compatible F-Droid metadata in English and French
• validate F-Droid metadata as part of make check
• document the current F-Droid readiness state and remaining release work

F-Droid-style reproducibility

The new check is available through:

make fdroid-reproducibility

It performs the following process:

1. starts from the exact current Git commit
2. creates a clean Git clone
3. checks out that commit detached
4. builds the unsigned release APK
5. copies the signature from the upstream signed APK with apksigcopier
6. compares the reconstructed APK byte-for-byte with the upstream signed APK

A mismatch causes the check to fail.

Reproducibility validation

The implementation was validated locally against commit:

70dff397f6a93005a607539a8b34385e99f66e0a

The upstream signed APK and reconstructed APK both produced:

82a9dd4b1ce9aa13a90d12926b9318c903053b0b370697240ae0654c777cd1d0

Result:

F-Droid reproducibility check: IDENTICAL

This demonstrates that a clean clone can independently rebuild the unsigned
APK and reconstruct the exact signed upstream APK using its copied signature.

Android VCS metadata

During validation, the release APK was found to contain:

META-INF/version-control-info.textproto

A normal Git repository embedded the source revision, while a detached Git
worktree generated:

NO_VALID_GIT_FOUND

That caused otherwise identical release APKs to differ.

Release builds now use:

vcsInfo.include = false

The VCS metadata is not required at runtime and its removal makes the APK
independent of the physical Git checkout representation.

Signing compatibility

Release signing now deliberately uses:

Android Build Tools 34.0.0

instead of dynamically selecting the newest installed apksigner.

The signing certificate remains verified against:

config/release-signing-cert.sha256

Current certificate SHA-256:

0d8ac9f2341257482c8380be5758169f889e606691787d13edbbb9649a2f3144

The GitHub signed-release workflow installs the same Build Tools version.

CI / release workflow

The signed-release workflow now:

• runs on Ubuntu 24.04
• installs Android Build Tools 34.0.0
• installs apksigcopier
• signs the APK
• performs the F-Droid-style reproducibility check
• continues with the existing SBOM and artifact generation

F-Droid metadata

Fastlane-compatible upstream metadata is now stored under:

fastlane/metadata/android/en-US/
fastlane/metadata/android/fr-FR/

Each locale currently contains:

title.txt
short_description.txt
full_description.txt

The metadata is validated by:

tools/check-fdroid-metadata.mjs

and is included in:

make check

Documentation

Added:

docs/fdroid.md

It documents:

• upstream metadata layout
• reproducibility verification
• deterministic signing tooling
• AGP VCS metadata handling
• signing certificate fingerprint
• deferred F-Droid build recipe
• remaining work before submission

Package namespace

The final F-Droid build recipe is intentionally not added in this change.

The current development application ID is:

fr.grammalecteandroid.unofficial

The next Phase 5 task is to review and finalize the Android package namespace
before a stable public release.

Creating the final F-Droid recipe before that decision would encode an
application ID that may still change.

Validation performed

• shellcheck on release and F-Droid scripts
• actionlint
• make check
• F-Droid metadata validation
• clean-clone release build
• apksigcopier signature reconstruction
• byte-for-byte signed APK comparison
• git diff --check

Roadmap

The Phase 5 item:

F-Droid metadata and reproducibility checks

remains intentionally unchecked until this change is merged to main and the
real signed-release workflow successfully performs the reproducibility check
in GitHub Actions.