Reproducible Build fails for v6.0.0 – and it uses the wrong signing key

[IzzySoft]

with a lot of differences in the APKs:

diff.zip

First, the APK was not built from the tagged commit (but most likely with the changes of it before it was committed). Then, there seem to be a lot of file ordering differences in the APK, so I wonder what you were using to build and sign it? Last (meaning, at that point I stopped checking), there are more differences in the AndroidManifest.xml:

     </receiver>
-    <meta-data android:name="com.android.dynamic.apk.fused.modules" android:value="base"/>
-    <meta-data android:name="com.android.stamp.source" android:value="https://play.google.com/store"/>
-    <meta-data android:name="com.android.stamp.type" android:value="STAMP_TYPE_STANDALONE_APK"/>
-    <meta-data android:name="com.android.vending.splits" android:resource="@7F110006"/>
   </application>

suggesting that… oh shit, indeed: you've let Google sign your APK?

Signer #1 certificate DN: CN=Android, OU=Android, O=Google Inc., L=Mountain View, ST=California, C=US
Signer #1 certificate SHA-256 digest: 120261541228efd464fa58d8b5255edc7d4d993ad6943952c14e44671a77c2e6
Signer #1 certificate SHA-1 digest: 2085f344412c14fd31e2ce42ea3c127903adcd04
Signer #1 certificate MD5 digest: 89ca4220ffed227c1baaf65364ad4d18
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 4096
Signer #1 public key SHA-256 digest: 883f312dec4155a5bad399660356bdb1755df299a4e92a8b6cc2f7be2cc15b01
Signer #1 public key SHA-1 digest: 2f919b0441f51f72124b26d98b5fe846d49f3bf6
Signer #1 public key MD5 digest: 614e7123a99a8c87428a431859996267
Source Stamp Signer certificate DN: CN=Android, OU=Android, O=Google Inc., L=Mountain View, ST=California, C=US
Source Stamp Signer certificate SHA-256 digest: 3257d599a49d2c961a471ca9843f59d341a405884583fc087df4237b733bbd6d
Source Stamp Signer certificate SHA-1 digest: b1af3a0bf998aeede1a8716a539e5a59da1d86d6
Source Stamp Signer certificate MD5 digest: 577b8a9fbc7e308321aec6411169d2fb
Source Stamp Signer key algorithm: RSA
Source Stamp Signer key size (bits): 4096
Source Stamp Signer public key SHA-256 digest: 4c53c1d28f2ecceadcb1351603f0b702615b3454b6e30070de759359f241b802
Source Stamp Signer public key SHA-1 digest: 188b067a9ee881bde55dabe0f8f7ecb320b1a091
Source Stamp Signer public key MD5 digest: 965afac83f033aa037a54482eb6922d5

No chance to get that RB then, sorry. Hope you're still in possession of the key, so you can sign the next release yourself again? Afraid this one we have to declare failed. Or wait, our repo of course rejected the APK as well:

2025-12-15 19:47:20,780 WARNING: "ca.cgagnier.wlednativeandroid_46.apk" is signed by a key that is not allowed:
120261541228efd464fa58d8b5255edc7d4d993ad6943952c14e44671a77c2e6

So can you please provide us with the correct APK? Thanks in advance!

PS: until then, we'll have to disable updates at IzzyOnDroid, as the signing does not match (meaning, existing installations cannot be updated anyway, as Android would reject that).

[Moustachauve]

Sorry, it has been so long since I had done this, I didn't remember what I had done last time. I used the APK from the Google store.

It was built at the tagged commit however. Since the APK from the Google store is not the right option for this, I will update the release soon with a new APK built at the tagged version and signed properly, like I used to do.

Sorry for the mistake.

[IzzySoft]

Thanks a lot! And hey, mistakes happen. Please let me know when I shall check again!

[Moustachauve]

@IzzySoft I uploaded a new version of the APK to the release.

Btw, is there any way I can contact you if I have any questions related to this release process in the future? Feel free to ping me on Discord (Moustachauve on there too)

[IzzySoft]

You succeeded, congrats! That's RB again – and the signature matches as well, so updates are re-enabled now.

While I'm here, our scanner reported:

! repo/ca.cgagnier.wlednativeandroid_46.apk declares flag(s): usesCleartextTraffic
! repo/ca.cgagnier.wlednativeandroid_46.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

What explanation shall we put for usesCleartextTraffic? As for DEPENDENCY_INFO_BLOCK, that can easily be avoided with adding a few lines to your build.gradle:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs (for IzzyOnDroid/F-Droid)
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles (for Google Play)
        includeInBundle = false
    }
}

For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. in our documentation on Signing Block Checks at our website, and in our blog article Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.

[Moustachauve]

What explanation shall we put for usesCleartextTraffic?

usesCleartextTraffic: This is required to communicate with WLED devices since they do not support encrypted communications.

Related to DEPENDENCY_INFO_BLOCK, would it work fine if I only set includeInApk = false? That would allow me to continue including it in the Bundle I submit to the playstore, while not having it in the APKs I publish here that get used in your repository?

I will do apply this change in the next version.

[IzzySoft]

required to communicate with WLED devices

Thanks! Added.

would it work fine if I only set includeInApk = false?

Sure, we mostly care for the APKs here (and don't use the AABs). If you want to ship that blob to Playstore, we have no issue with that – after all, it's Google who injected it, and they can read it and make sure it is what it claims to be.

I will do apply this change in the next version.

Wonderful, thanks! 🤗

[IzzySoft]

Guess we can close this issue now: 6.0.1 is listed RB here.

As for the contact question I seem to have missed: just send me a ping from an issue here, Github should notify me then 😉

[IzzySoft]

Maybe I was too fast: v6.1.0 fails again. Even built 10 times in a row, it brings the exact same APK here – just not matching yours:

  -rw-r--r--  0.0 unx      120 b-      118 defN 1981-01-01 01:01:02 ed425035 META-INF/version-control-info.textproto
- -rw-r--r--  0.0 unx     5646 b-     5646 stor 1981-01-01 01:01:02 c0dadc9d assets/dexopt/baseline.prof
+ -rw-r--r--  0.0 unx     5646 b-     5646 stor 1981-01-01 01:01:02 4a097c88 assets/dexopt/baseline.prof
  -rw-r--r--  0.0 unx      813 b-      813 stor 1981-01-01 01:01:02 1674974b assets/dexopt/baseline.profm
- -rw-r--r--  0.0 unx  4454988 b-  2185177 defN 1981-01-01 01:01:02 39619fa2 classes.dex
+ -rw-r--r--  0.0 unx  4454980 b-  2185244 defN 1981-01-01 01:01:02 2bc7e9da 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

So the main thing is the diff in classes.dex here (baseline usually fails if DEX failes, so that might just be a "follow-up"). Was the APK built from a clean tree, or might there have been artifacts left from previous builds? I've tried with JDK 17 & 21, identical results – so it's no flakiness. And while the DEX diff looks rather small (7.5k), diffoscope is rather huge (21 MB 🙈 Most of it just pointing out a different .source·"r8-map-id, making it hard to find the real differences). Some line differences in smali/c0/b.smali, smali/k7/c.smali, smali/k7/d.smali, smali/k7/e.smali, smali/k7/h.smali (lines shifted by one, as if your build had inserted a line somewhere) – that seems to be mostly it:

diff.zip

[Moustachauve]

I'm sorry. I've uploaded an updated APK built from the v6.1.0 tag.

I'm doing all this manually currently, so this can be very error prone for me. I plan on implementing some form of CI/CD in the future that should help me make this more foolproof.

[IzzySoft]

I'm sorry. I've uploaded an updated APK built from the v6.1.0 tag.

Thanks! But "never replace what has already been distributed": the "old" APK is already present in our repository. So even if the new one can be confirmed as RB now, that won't bring up the "green shield", as it's a different APK (with a different checksum). That said: the APK currently attached is identical to the one that had been there before: same checksum. Any changes in your build process since the last release, so we should match that? How are you building, and on what OS?

I'm doing all this manually currently, so this can be very error prone for me.

I'm not "complaining", but rather informing (but sure it would make our life easier wouldn't we have to analyze and fix 2..3 failed builds each day 🙈). I'm sure you're doing your best, and hope my hints can help you with that!

I plan on implementing some form of CI/CD in the future that should help me make this more foolproof.

👍 🤗

[Moustachauve]

Hmm, strange. I checked out the v6.1.0 tag and I'm building with the latest version of Android Studio (2025.2.2 Patch 1). I use "Generate signed APK" and I use the same options as before.

I'm building on a Mac with MacOS 26.2

But "never replace what has already been distributed": the "old" APK is already present in our repository.

What should I do instead, give the fixed APK a new name? Or it will stay "broken" until the next release?

[IzzySoft]

I'm building with the latest version of Android Studio

Ah. Two potential culprits there:

• did you run clean before your build? Studio is known to "happily reuse artifacts from previous builds" – which might be technically fine (faster build, fully working APK), but often breaks RB
• it uses Jetbrains JDK by default, which sometimes causes issues with RBs.

My guess would be the first bullet point, as that would match how the diff looks.

I'm building on a Mac with MacOS 26.2

Thanks! That should be no issue here (and should it ever get one, you can always give Github actions (or comparable CI) a go.

What should I do instead, give the fixed APK a new name? Or it will stay "broken" until the next release?

Well… The APK is not exactly broken – it's just not reproducible. So options are making a new (maintenance-)release, or (if another release is planned within a couple of days/weeks) simply wait for the next regular one.

There are rare exceptions to this "general rule": if an APK turns out to be broken, or a security risk, remove it – and make a new release with versionCode increased (to ensure even those already having updated to the bad one will receive a replacement).

Btw: If you want a potentially fixed APK test-run, you can attach it to an issue (rename it to *.zip so Github lets you – remember GH is run by MS, so whether a file is good or bad is just decided by its extension 🙈), we can pick it up from that.