How to handle different metadata in PNG files for reproducible builds

1

Hello, thanks to your help I managed to reach the end of the build process for my app, but now it fails to pass the validation because some files are different from the reference APK. There are two groups of problems: different PNGs and different shared libraries. I would like to know what are my options for the former.

For the PNGs there is a difference due to ImageMagick. There is a run of convert during the build of the app and the output differs in the metadata. For example, see the output of pngcheck:

$ pngcheck -v  ref/assets/texture/bomb-stencil.png f-droid/assets/texture/bomb-stencil.png

File: ref/assets/texture/bomb-stencil.png (1820 bytes)
  chunk IHDR at offset 0x0000c, length 13
    128 x 128 image, 16-bit grayscale+alpha, non-interlaced
  chunk bKGD at offset 0x00025, length 2
    gray = 0x0000
  chunk tIME at offset 0x00033, length 7: 31 Jan 2025 21:09:17 UTC
  chunk IDAT at offset 0x00046, length 1730
    zlib: deflated, 32K window, maximum compression
  chunk IEND at offset 0x00714, length 0
No errors detected in ref/assets/texture/bomb-stencil.png (5 chunks, 94.4% compression).

File: f-droid/assets/texture/bomb-stencil.png (1934 bytes)
  chunk IHDR at offset 0x0000c, length 13
    128 x 128 image, 16-bit grayscale+alpha, non-interlaced
  chunk gAMA at offset 0x00025, length 4: 0.45455
  chunk bKGD at offset 0x00035, length 2
    gray = 0x0000
  chunk tIME at offset 0x00043, length 7: 15 Feb 2025 19:38:44 UTC
  chunk IDAT at offset 0x00056, length 1730
    zlib: deflated, 32K window, maximum compression
  chunk tEXt at offset 0x00724, length 37, keyword: date:create
  chunk tEXt at offset 0x00755, length 37, keyword: date:modify
  chunk IEND at offset 0x00786, length 0
No errors detected in f-droid/assets/texture/bomb-stencil.png (8 chunks, 94.1% compression).

No errors were detected in 2 of the 2 files tested.

As you can see ImageMagick, as available in the F-Droid pipeline, inserts additional chunks: gAMA and tEXt. I guess I could tweak the build to remove them before assembling the APK but there is still the tIME chunk. I can’t remove it from upstream without releasing a new version (which I won’t do anytime soon), so what are the alternatives?

For reference, the pipeline showing the error.

1 Like
2

Try the 2 tricks in Reproducible Builds | F-Droid - Free and Open Source Android App Repository ?

3

What stops you from releasing a fixed version?

4

What stops you from releasing a fixed version?

I may fix the PNG problems with a new version but then I still have the problem with the shared libraries. Then I may publish another new version for it, but then maybe I’ll have another problem, and thus a new version, etc. In short, I don’t want to have public new versions with nothing else in the changelog than “Attempt to create a build for F-Droid” :slight_smile:

I’ll do a proper release candidate flow for the next version, this will leave room for iterating on these issues, but it is in months and I would love to have the current version on F-Droid.

5

why do you need public? we can build in the Gitlab CI and you can test the APKs until you’re ready

6

we can build in the Gitlab CI and you can test the APKs until you’re ready

I thought I had to publish an APK for the ‘Binaries:’ rule but I can actually host it anywhere. Thanks for the suggestion :slight_smile:

1 Like
7

We can check the apk manually. You just need to release the code and give us the reference binary.