Reproducible Build fails for 2.0.8

[IzzySoft]

And it looks like you – maybe – built that with uncommitted changes in the tree? There are differences in classes.dex – and there's one new commit after the tagged one. Do the two somehow relate?

[AmrDeveloper]

Should not be related, but tomorrow i will clear all cache and rebuild them again, later i will automate this part, thanks for mentioning it

[IzzySoft]

OK, but please do not modify the existing release anymore (see: Never replace what was already distributed). Just compare the output of sha256sum *.apk from both APKs (the one currently attached, and the resulting one from your new build). If those differ, you can attach the APK e.g. here (just rename it to *.zip so GitHub lets you – you know the MS logic: an *.sql file is dangerous unless you rename it to *.txt), and we can run a check against this.

[AmrDeveloper]

Sure, i will do that, we can test one APK here before i create release

Thanks

[AmrDeveloper]

If we can test with 2.0.9, I already cleared all cache and build files before the APK builds

https://github.com/AmrDeveloper/Turtle/releases/tag/2.0.9

[AmrDeveloper]

I need to check the local setup, even in the case of building the same code twice, case differnt sha245

[IzzySoft]

Sure, i will do that, we can test one APK here before i create release

Unfortunately you made it a release already, before we tested. RB fails again, sorry.

even in the case of building the same code twice, case differnt sha245

That means the build is non-deterministic. If you cannot reproduce it yourself even.

  -rw-r--r--  0.0 unx      120 b-      117 defN 1981-01-01 01:01:02 2e19128d META-INF/version-control-info.textproto
- -rw-r--r--  0.0 unx     8883 b-     8883 stor 1981-01-01 01:01:02 bef192d1 assets/dexopt/baseline.prof
+ -rw-r--r--  0.0 unx     8883 b-     8883 stor 1981-01-01 01:01:02 e79ababd assets/dexopt/baseline.prof
  -rw-r--r--  0.0 unx     1050 b-     1050 stor 1981-01-01 01:01:02 b80b752d assets/dexopt/baseline.profm
- -rw-r--r--  0.0 unx  3485484 b-  1704648 defN 1981-01-01 01:01:02 75f2f9ed classes.dex
+ -rw-r--r--  0.0 unx  3485484 b-  1704655 defN 1981-01-01 01:01:02 b47fedef classes.dex
  -rw-r--r--  0.0 unx    10096 b-    10096 stor 1981-01-01 01:01:02 9734baa0 lib/arm64-v8a/libandroidx.graphics.path.so
- -rw-r--r--  0.0 unx     7784 b-     7784 stor 1981-01-01 01:01:02 57eb19ea lib/arm64-v8a/libdatastore_shared_counter.so
+ -rw-r--r--  0.0 unx    10360 b-    10360 stor 1981-01-01 01:01:02 d7b2b35c lib/arm64-v8a/libdatastore_shared_counter.so
  -rw-r--r--  0.0 unx  6073392 b-  6073392 stor 1981-01-01 01:01:02 4cb217a9 lib/arm64-v8a/libwebgpu_c_bundled.so

OK, the one in libdatastore_shared_counter.so seem to be related to Native Library Stripping – confirmed¹. As that saves only a few KB in your case, you might consider disabling that:

android {
   packaging {
       jniLibs.keepDebugSymbols.add("**/*.so")
   }
}

The one in classes.dex is weird; a repetition of this one:

Something is called util/List with your build, but lang/Object with ours. This diff remains the same, even if we take care for the library stripping and try JDK 21 instead of 17. What might help here, is disabling obfuscation – at the very least we then see in which library this happens (or the issue magically disappears, which would not be the first time). This could be done e.g. this way:

buildTypes {
  // Setup when creating a release build
  getByName("release") {
    // Remove unused code and resources, and optimize the code without
    // obfuscating so that the build is reproducible
    postprocessing {
      isRemoveUnusedCode = true
      isRemoveUnusedResources = true
      isObfuscate = false
      isOptimizeCode = true
    }
  }
}

---

¹ _{we've installed NDK 28.2 at our end for this test, and the libs were stripped here as well then. But that means quite some overhead in downloads at build time.}