F-Droid reproducible-build parity: apply fdroid strip-patches in the GitHub-Releases APK build

[dzianisv]

Split from #86 (PART 1). PART 2 (stale committed versionCode) is handled in its own small PR.

Problem: F-Droid rebuilds the APK from source and strips Firebase/Google-Sign-In/Sentry via the recipe's fdroid/*-patches. But the app-release.apk on GitHub Releases (referenced by Binaries:, also fed to IzzyOnDroid) is built by .github/workflows/build.yml without those patches, so it still contains Firebase/GMS/Sentry and F-Droid's from-source rebuild diverges → fdroid build fails.

Fix direction: apply the same fdroid/expo-application-patches / fdroid/expo-notifications-patches (or a reproducible build profile) in the tag-triggered release path so the published binary matches F-Droid's rebuild.

Why split out / not auto-applied: it changes the shipped artifact's feature set (removes push notifications + Sentry), build.yml's build job is shared between CI validation and tag releases so it needs tag-only conditional branching, and verification needs real fdroid build tooling (manual).

Acceptance: fdroid build reproduces the published APK; https://f-droid.org/packages/cc.agentlabs.opencode/ progresses. Dedicated branch, human review + local fdroid verification before merge.

[dzianisv]

Reopening because the acceptance criterion is not met in the real F-Droid channel.

Verified 2026-07-22:

• F-Droid MR !39530 is open and labeled waiting-on-response; latest pipeline 2683408757 failed.
• The MR recipe still targets 0.4.3 / versionCode 5, commit c46f273e, and the old app-release.apk URL.
• The pipeline reached APK comparison but failed reproducibility (CHUNKED_SHA256 digest mismatch; built binary differed from the supplied reference).
• Release v0.4.10 now includes the dedicated app-release-fdroid.apk, so the artifact-path part of this issue was implemented. However, its APK manifest reports versionName 0.4.7, versionCode 34, while app.json/package release version is 0.4.10 and versionCode 37. This version-source divergence prevents a clean metadata update using F-Droid’s v%v binary URL.
• Mainline package URL still returns HTTP 404.

Next acceptance path:

1. Align the committed Android Gradle version with the release version/code before the next tag.
2. Publish a new tag whose app-release-fdroid.apk manifest matches that tag and source metadata.
3. Update !39530 to the new full source commit, dedicated F-Droid asset URL, and matching version fields.
4. Require green checkupdates, fdroid build, and binary comparison before closing this issue.

No runtime app change is justified until that release/version alignment is planned and reviewed.

[dzianisv]

F-Droid mainline update: rebased upstream MR !39530 onto current fdroiddata master and corrected the structural binary mismatch. Metadata now uses the dedicated app-release-fdroid.apk, reads version/code from Expo app.json, pins v0.4.10/code37 to full commit 6aee78e..., and removes the obsolete v0.4.3 build whose matching F-Droid reference APK does not exist. Current pipeline https://gitlab.com/dzianisv/fdroiddata/-/pipelines/2697577349 has checkupdates/schema/rewritemeta/lint/tools/redirect green; the 0.4.10 source build and byte-for-byte verification remain running. MR evidence: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/39530#note_3589354489. Keep this issue open until the reproducibility gate and upstream merge pass.

[dzianisv]

Implementation plan for the verified release-metadata blocker:

1. Add a deterministic check that package.json, app.json, and committed android/app/build.gradle carry the same version name, and that app.json and Gradle carry the same version code.
2. Align the committed Gradle metadata to the current v0.4.10 / 37 source metadata.
3. Run the check before Android test/build jobs so future tags cannot publish stale APK manifests.
4. Validate locally, open a PR, require CI green, then merge.

This does not cut a new tag or claim F-Droid reproducibility. A future release still must publish a matching app-release-fdroid.apk, update fdroiddata MR !39530, and pass its binary comparison.

[dzianisv]

Implemented the version-parity guard in PR #141: #141

Verified locally:

• npm run check:versions → 0.4.10 / 37 aligned
• typecheck passed
• 199 tests passed
• diff check passed

This prevents future CI and self-hosted F-Droid builds from publishing when package/app/Gradle versions disagree. It does not establish reproducibility for the already-published v0.4.10 artifact; #95 must remain open until a future release and updated fdroiddata recipe produce matching binaries.

[dzianisv]

Final validation confirms the remaining blocker is the published release artifact, not the F-Droid source recipe.

• fdroiddata pipeline 2697616059 passed checkupdates, schema, rewritemeta, lint, tools, and source scan.
• The v0.4.10 source build completed successfully: 1,190 tasks, BUILD SUCCESSFUL in 21m 16s.
• fdroidserver then correctly rejected it because the produced/tagged APK metadata is code 34 while app metadata expects code 37.
• Direct aapt dump badging of the published v0.4.10/app-release-fdroid.apk confirms versionName='0.4.7' versionCode='34'.
• PR fix(release): enforce Android version parity #141 is now merged at 5f9dd2a80c55073706d1aaed0b5b9ce82ec37b9a; it aligns committed Gradle metadata and adds a CI parity guard.

No metadata-only edit can make the existing v0.4.10 binary reproducible. Keep this issue open until the next planned release publishes a correctly versioned dedicated F-Droid APK, then point fdroiddata MR !39530 to that exact tag and require green byte-for-byte verification.

[dzianisv]

Release repair plan for v0.4.11:

1. Bump package, Expo, and committed Gradle metadata together to 0.4.11 / code 38.
2. Add matching Play and F-Droid release notes; no runtime code changes.
3. Run version parity, typecheck, and unit tests in an isolated worktree.
4. Open a PR and require Android/iOS CI green before merge.
5. After merge, create v0.4.11, verify the dedicated F-Droid APK manifest from the published release, then update fdroiddata MR !39530 to the exact tag commit and require byte-for-byte verification.

This is deliberately a metadata-only release to replace the unreproducible stale-version v0.4.10 artifact.

[dzianisv]

Release metadata is implemented in PR #142: #142

Local verification: version parity reports 0.4.11/code38, typecheck passes, 199 tests pass, diff check passes, and Play notes are 218/500 characters. CI test/typecheck jobs are green; Android and iOS build jobs are still running. No runtime paths changed, so this PR does not require pre-merge Android CUA. Do not tag until all PR checks pass.