APK at v2.0.0 signed with different key

[IzzySoft]

The updater at IzzyOnDroid (where your app is listed, and was on the monthly update track as there was no release for several years) just complained about the APK:

2025-12-01 03:34:08,753 WARNING: "io.github.ratul.topactivity_23.apk" is signed by a key that is not allowed:
09252c3533c4378957d22ead9165dbd91fb252119e7fce7eb595dcca6c4b6748

What happened to your signing key? A different one means no updates are possible, as Android would reject the APK. I've just checked the previous release (1.5.9), it has the same key as 2.0.0 – but updates to an installed 1.5.5 are impossible, as that came signed with a different key.

PS: Also, what is that with the integrated update checker? Is that active by default, or opt-in? Where does it check?

[codehasan]

I made this project back when I was learning Android Development. So, I didn't upload any of my keys in the cloud. As a result, the keys were lost when I got rid of my old laptop. It was a hassle updating the app in Play Store because the keys were changed.

The update checker is active by default, it checks the GitHub Releases API to get the latest release info.

[IzzySoft]

Oh, nobody should ask you to upload any keys to the cloud – there are certainly other means of backup 😉 Recommended reading: How to keep your key safe and what measures to take for the event of loss? So we now need to confirm the key switch is legit (could as well be someone who got control over your Github account).

As for the Update Checker: that means we'll have to add the NonFreeNet anti-feature. Also, does it just check-and-report, or also download-and-install? Quoting from our App Inclusion Policy:

[the app] must not download additional executable binary files (e.g. addons, auto-updates, etc.) without explicit user consent. Consent means it needs to be opt-in (it must not be harder to decline than to accept or presented in a way users are likely to press accept without reading) and structured in a way that clearly explains to users that they’re choosing to bypass the checks performed in this repo if they activate it.

It might be a good idea to make the check itself opt-in(you can e.g. initialize a setting with NULL, and then ask on first start, including an explanation of where it checks etc. I can provide you a few example screenshots if needed.

[codehasan]

I will be happy to help with any verification needed. As for the update checker, yes it's a check-and-report type. If a newer version is available, the user is shown a popup where if they click Download, they will be redirected to the GitHub Releases page.

I will make it opt-in in the next version (2.1.0). Example screenshots are much appreciated.

[IzzySoft]

I will be happy to help with any verification needed.

Glad to read! Maybe you've missed my attempt on that via the second channel called mail? 😉

I will make it opt-in in the next version (2.1.0).

Cool, thanks!

Example screenshots are much appreciated.

Just take a few as you'd like them – e.g. using Android's built-in screenshot functionality. Or use e.g. my ADB script ssnap (serial snapper) for that.

[IzzySoft]

Thanks! Verification done, updates re-enabled – I also added a "changelog note" for this release that the key changed and folkd need to uninstall and re-install.

Apologies for the confusion with the screenshots; we were talking about the updater here, not about the missing fastlane metadata. So first things first, here are the example screenshots:

The other thing is that it would be great to have the app's metadata (description and graphics) available here in your repo, using Fastlane structures (see e.g. the IzzyOnDroid Fastlane Documentation. I can provide you a PR with a "starter kit", to make that easier for you – if you agree? That would then give it into your hands to define how your app is presented – and to keep that information in-sync with the app's "evolution". Would you accept such a PR?

Last questions: what is android.permission.SYSTEM_ALERT_WINDOW used for? Ah, the moving popup window, OK. Added that (to the permission list) for clarification. So finally, our scanner reported:

! repo/io.github.ratul.topactivity_23.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

which can be easily avoided by 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.

[codehasan]

The update checker wont be enabled by default from the next version. I added an opt-in popup for the first run of the App. It can be turned on/off from the menu.

A "starter kit" PR would be great. Thank you.

I added the dependenciesInfo block in the gradle file. Morever if it helps, I can sign the apps using a different signer when adding in GitHub.

[IzzySoft]

Thanks! But that popup does not inform about the implications (i.e. that our additional screening is bypassed). Some examples:

A "starter kit" PR would be great. Thank you.

Great! I'll prepare one for you then. Expect the PR popping up in a few minutes.

[IzzySoft]

Fastlane starter kit here. You can merge it "as-is" (reflects what is currently online with the listing at IzzyOnDroid) and update later (whenever you see fit); changes would then be synchronized whenever a new release is being pulled in at our end.