Thanks @Licaon_Kter — that log pinpointed it. The app module wasn’t pinning ndkVersion, so it silently fell back to
AGP 8.10’s default (27.0.12077973) for the strip step, while core-native used 27.2.12479018. Since only 27.2 is on the
buildserver, the strip was skipped and the libs were packaged unstripped.
Fixed by setting ndkVersion = “27.2.12479018” in the app module too, so both modules agree and the libs strip
reproducibly with 27.2 (which is present on both sides). Verified locally — libencnative.so now strips from 574 KB
down to 284 KB.
@gwitko could you bump the MR to commit: 67e29425b873e5e718e82b00c10333c867bb987b / versionCode 7 / versionName 1.3.3?
Both the .so strip and the earlier dex/baseline-profile issues should now be resolved.
Thanks for pushing this as far as it went, @Licaon_Kter. The strip fix worked, but the final RB still shows all three
— libencnative.so, classes.dex and baseline.prof. Since I build my releases on Windows and the buildserver is Linux, I
don’t think I can get a byte-identical native lib + dex out of a different-OS build, and standing up a matching Linux
build environment isn’t practical for me right now.
So I’d rather not hold the MR on reproducibility. Could we drop the reproducible path and let F-Droid build from
source and sign with its own key? i.e. remove Binaries and AllowedAPKSigningKeys from the recipe. The app builds fine
from a clean checkout (it falls back to a debug/none signing config when no keystore is present), so a normal F-Droid
build + sign should work.
I understand the F-Droid build will then carry a different signature than my GitHub/Obtainium releases — that’s the
trade-off I’ll take to get it in. Thanks again to you and @gwitko for the patience.
@gwitko , Yes, I build locally on Windows. Thanks for the GH Actions idea — but honestly I’m fine with F-Droid shipping its own signature, it doesn’t need to match my GitHub/Obtainium builds. So let’s keep it simple: please just drop the reproducible path (remove Binaries and AllowedAPKSigningKeys) and let F-Droid build from source and sign with its own key. Appreciate the offer!
@Licaon_Kter Ran the apktool diff, thanks — original/ removed from both, diff -ru against the CI build from job #15171527750. Three groups:
8 smali classes, all Compose-generated (G1/M0, G1/N0, G1/T4, e2/a, …): differing $changed bitmask constants (e.g.
0x180c08 vs 0x180c00), register counts (.locals 40 vs 41), branch/nop layout. Same source → optimizer-level,
consistent with my published APK being an incremental build rather than clean. I’ll rebuild from a clean clone.
libencnative.so: 884 bytes differ and the size differs (284048 vs 283888). With identical ndkVersion 27.2.12479018,
clang codegen on my Windows host ≠ your Linux buildserver. A native lib built on Windows will never be byte-identical
to one built on Linux — this can’t be reconciled by recipe tweaks.
baseline.prof is derived from classes.dex, so it tracks (1).
So (1) is likely fixable clean, but (2) means byte-for-byte RB isn’t achievable while I build on Windows. Rather than drop RB, I’d prefer to move release builds to a Linux GitHub Actions pipeline that matches your environment (build unsigned on ubuntu, sign locally so my key stays off CI) — that keeps one signature across GitHub/Obtainium/F-Droid. Will report back once it’s set up.
@Licaon_Kter Published v1.3.4 (versionCode 8) built reproducibly on Linux CI and signed locally with the same key. Could you bump the MR to this and drop the newline workaround — the build is native-LF on Linux now, so the postbuild/srclibs fix isn’t needed anymore. New Build block:
Thank you so much, @gwitko — really appreciate you seeing this through.
The green pipeline is great news. Getting the build to reproduce bit-for-bit and sorting out the zipalign step was exactly the part I couldn’t verify from my side, so it means a lot that you took it on. Now that the same APK and the same signing key are used everywhere (GitHub, Obtainium, Komikku), F-Droid users will be able to update seamlessly across sources — which matters a lot for an encrypted-vault app, where a signature mismatch would lock people out of their data.
Just let me know if you need anything else from me for the merge. And thanks again for volunteering the packaging work — it’s genuinely made the difference in getting Wolf Gallery onto F-Droid.
Just want to say a big thank you to everyone who made this happen.
@gwitko — thank you for volunteering to package Wolf Gallery, opening the MR, and patiently working through all the CI and reproducible-build back-and-forth. It was a real pleasure working with you, and I’m glad you had fun with it too. Hope to see you around for future updates.
@linsui — thank you for the careful review and for merging it.
@Licaon_Kter — thank you for the guidance throughout, the build diagnostics, and getting it across the finish line.
It means a lot to finally see Wolf Gallery land in F-Droid. Thanks to the whole team for the time and effort.
App update: Wolf Gallery is now at v1.3.6 (tag v1.3.6), and F-Droid should
pick it up automatically via UpdateCheckMode: Tags.
Could a contributor please make one small metadata change in fdroiddata
(metadata/dev.encgallery.yml) — expand the Categories to the four the app
belongs to:
Categories:
Gallery
Graphics
Multimedia
Security
Everything else (updated description, changelog, and the new feature
graphic) is already in the repo under fastlane/metadata and is picked up
automatically, so only the Categories field needs changing.
