Build libdartjni.so without a GNU build ID (#49)

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: aquasolterra

AGENTS.md

@@ -1719,7 +1719,10 @@ Three smaller traps, each found by a test that had to be written twice:
   human to check the signing fingerprint before publishing. So never build and upload a
   release artifact by hand — the point of the workflow is that the environment which
   produced a published APK is knowable, which is also what a later move to F-Droid's
-  verified builds would need. `CONTRIBUTING.md` has the steps.
+  verified builds would need. `CONTRIBUTING.md` has the steps. The same goal is why
+  `android/build.gradle.kts` passes `-Wl,--build-id=none` to `jni`'s CMake: that build ID
+  was the only thing making two builds of one tag differ, and the comment there says how
+  it was measured.
 - **The build CI hands out installs beside a real one, not over it.** Every
   pull request's `Build Android APK` job uploads the arm64-v8a APK as an
   artifact, so a change can be installed rather than only read. It is built with

CHANGELOG.md

@@ -3,6 +3,12 @@
 Notable changes per release. Dates are release dates; the git tags carry the
 exact commits.
 
+## 1.11.1 — 2026-09-05
+
+- **Nothing changes in the app.** This release exists so that two builds of the same source
+  come out byte for byte identical, which is what lets somebody else check that a published
+  APK really was built from the code in this repository.
+
 ## 1.11.0 — 2026-09-04
 
 - **This version installs fresh rather than as an update, and you should export your data

android/build.gradle.kts

@@ -1,3 +1,5 @@
+import com.android.build.gradle.LibraryExtension
+
 allprojects {
     repositories {
         google()
@@ -17,6 +19,39 @@ subprojects {
 }
 subprojects {
     project.evaluationDependsOn(":app")
+
+    // `package:jni` compiles libdartjni.so through CMake, and the linker stamps a
+    // GNU build ID into it by default -- a hash that comes out different on every
+    // machine even when the library itself does not. Measured on this project: the
+    // APK published from CI and one built locally from the same tag differ in
+    // exactly 20 bytes, and those 20 bytes are the build ID. Nothing reads it here,
+    // and it is the one thing standing between two builds of the same source being
+    // byte for byte the same.
+    //
+    // That matters because of what F-Droid can then do: with `binary:` in the build
+    // recipe it rebuilds a release from source, compares it against the APK
+    // published here, and on a match ships *this project's* signed APK rather than
+    // one of its own -- so somebody moving from a GitHub download to F-Droid keeps
+    // their install and their database. The comparison is a signature copy, which
+    // v2 signatures make equivalent to byte equality, so 20 bytes is as fatal as a
+    // megabyte.
+    //
+    // Scoped to `jni` rather than applied to every subproject: it is the only module
+    // here that builds native code of its own, and a flag that reaches libraries
+    // nobody has looked at is a change whose effects nobody has looked at either.
+    plugins.withId("com.android.library") {
+        if (name == "jni") {
+            extensions.configure<LibraryExtension>("android") {
+                defaultConfig {
+                    externalNativeBuild {
+                        cmake {
+                            arguments += "-DCMAKE_SHARED_LINKER_FLAGS=-Wl,--build-id=none"
+                        }
+                    }
+                }
+            }
+        }
+    }
 }
 
 tasks.register<Delete>("clean") {

pubspec.yaml

@@ -7,7 +7,7 @@ publish_to: 'none'
 
 # In Android, build-name is used as versionName while build-number is used as
 # versionCode; both can be overridden with `flutter build --build-name/--build-number`.
-version: 1.11.0+12
+version: 1.11.1+13
 
 environment:
   sdk: ^3.12.0