Fdroid Reproducible Foss

What F-Droid requires of the foss flavor

Two independent hard requirements. Both must hold or the fdroiddata pipeline goes red:

1. A clean source scan — the checked-out source must contain no "unknown maven repos" and no proprietary "usual suspects" once scandelete has run. Maintainers disallow scanignore (F-Droid docs: it is only "where there is a very good reason"); the sanctioned mechanism is scandelete, which deletes files not needed by the build before scanning.
2. A byte-for-byte reproducible build — F-Droid rebuilds assembleFossRelease from the release tag and it must match our published campfire-foss-release.apk exactly, so F-Droid ships our-signed APK (AllowedAPKSigningKeys).

The MR: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/46619 (metadata metadata/app.campfire.android.yml).

Invariants you must not break

• The foss flavor never depends on a proprietary module. Firebase, Cast, Block Store, ML Kit, Mixpanel, Play in-app-updates, App Distribution are wired to standard* / alpha* / beta* configurations only — never foss* (see app/android/build.gradle.kts). If you add a proprietary integration, follow the same pattern, and put its build files where F-Droid can scandelete them (see below).
• No custom Maven repository literal in any scanned .gradle/.gradle.kts. The scanner flags any maven(...) / maven { url … } call whose URL isn't on F-Droid's allow-list — and it captures whatever is inside the parens, so even maven(someVariable) is flagged as unknown maven repo 'someVariable)'. Reading the URL from a property does not help. Custom repos must live in a scandelete-able standalone script (see the emulator.wtf pattern).
• Reproducibility hooks stay in place:
  • Project.normalizeFossReleasePgMapId() (in gradle/build-logic/convention/.../Reproducible.kt), called from app/android/build.gradle.kts — zeroes R8's pg-map-id in the foss DEX (the one thing that varied per build environment).
  • baselineProfile { variants { create("foss") { dexLayoutOptimization = false } } } in app/android/build.gradle.kts — keeps the baseline profile but drops the non-deterministic startup DEX layout for foss only.
• campfire.version / campfire.versionCode stay in lockstep (MMmmppRR, asserted by verifyVersionCode + scripts/release). F-Droid's UpdateCheckData reads campfire.versionCode from gradle.properties on the tag.

How the scanner actually works (so you can reason about it)

Source: fdroidserver/scanner.py, scan_source(). F-Droid CI runs fdroidserver master (installed from the tarball on debian:trixie-slim, not pip), so test against master.

• Only these file types get content-scanned: .java (DexClassLoader only), .gradle / .gradle.kts (usual-suspects + maven-URL), and binaries (.apk/.jar/.aar/.class/.dex/.so/.zip/.gz/.wasm, extensionless/.bin/.out/.exe, executables). gradle.properties, .kt, .py, and shell scripts are NOT scanned for repos or suspects — confirmed by reading the dispatch and by A/B test.
• Usual suspects resolve libs.* version-catalog accessors through libs.versions.toml, so libs.firebase.crashlytics.gradlePlugin in a .gradle.kts is flagged even though the coordinate is in the TOML. // comments are ignored; only real implementation(...)-style lines match.
• scandelete deletes listed paths before the scan runs, so a flagged file that the foss build doesn't need is removed and never scanned. This is why the isolated files below can each carry the flagged content.

Pattern: isolating a proprietary Gradle plugin so it can be scandelete'd

Firebase's plugins can't sit in build.gradle.kts (root) or gradle/build-logic/convention/build.gradle.kts — those are scanned and can't be deleted. So:

• The proprietary plugin deps + the convention plugin live in a separate build-logic module gradle/build-logic/firebase/ (its build.gradle.kts carries libs.firebase.*.gradlePlugin).
• gradle/build-logic/settings.gradle.kts includes it only if (file("firebase/build.gradle.kts").exists()).
• convention/build.gradle.kts does runtimeOnly(project(":firebase")) under the same if (file(...).exists()) guard.
• The plugin is applied from a convention plugin (AndroidApplicationConventionPlugin) via pluginManager.apply("app.campfire.firebase"), guarded by rootProject.file("gradle/build-logic/firebase/build.gradle.kts").exists() — the same presence check, so it is never requested once scandeleted. Don't guard it on google-services.json: the plugin also adds the alpha/beta App Distribution SDK that src/preRelease compiles against, and it already skips the Firebase Gradle plugins itself when that file is missing (fork PRs, local builds).
• fdroiddata scandeletes gradle/build-logic/firebase/build.gradle.kts → module not included, plugin never applied, build-logic still compiles.

Gotcha: legacy apply(plugin = "id") does NOT resolve an included-build plugin — it must be applied from inside a convention plugin (on the build-logic classpath) or via the plugins {} block.

Pattern: a custom Maven repo needed only for tooling (emulator.wtf)

The emulator.wtf Gradle plugin resolves from mavenCentral; only its ew-cli runner is exclusive to maven.emulator.wtf, and only when actually running on emulator.wtf (CI baseline generation) — never a foss/normal build. So:

• The repo is declared in a standalone gradle/emulatorwtf-repo.gradle.kts (a settings script adding it via dependencyResolutionManagement).
• settings.gradle.kts applies it only if (file("gradle/emulatorwtf-repo.gradle.kts").exists()) — the apply line has no maven call, so it isn't flagged.
• app/baselineprofile/build.gradle.kts sets emulatorwtf { repositoryCheckEnabled.set(rootProject.file("gradle/emulatorwtf-repo.gradle.kts").exists()) } (extension name is lowercase emulatorwtf).
• fdroiddata scandeletes gradle/emulatorwtf-repo.gradle.kts → deleted before scan (0 errors), apply skipped, repo check off. Any real emulator.wtf use just needs the file present — no extra flags.

Use this same shape for any future third-party repo that only serves build/test tooling.