Incorrect Android AppSigning key for .NET MAUI app

by

Summary

This incident stemmed from an Android signing key mismatch after migrating a .NET MAUI application from .NET 9 to .NET 10 by creating a new blank project and copying files over. Although the keystore file was reused, the project-level signing configuration no longer matched the original app’s signature, causing Google Play to reject the uploaded bundle.

Root Cause

The root cause was not the keystore file itself, but the metadata and configuration that ties an Android app to its signing identity. When creating a new blank MAUI project:

  • The Android package name (applicationId) may have changed.
  • The keystore alias or password configuration may not have been copied correctly.
  • The csproj signing properties may not match the original project.
  • The Google Play App Signing configuration expects the exact same signing certificate fingerprint as the previously published version.

Even if the keystore file is correct, any mismatch in these parameters results in a different signing identity.

Why This Happens in Real Systems

Real-world build systems are sensitive to signing identity because:

  • Android treats the signing certificate as the unique identity of the app.
  • Google Play enforces strict certificate continuity for security.
  • Recreating a project often changes subtle but critical metadata.
  • MAUI templates evolve between .NET versions, introducing different default signing behaviors.

Small differences in configuration produce a different certificate hash, which Google Play rejects.

Real-World Impact

When the signing identity changes:

  • Google Play refuses the upload with a “wrong key” error.
  • The developer cannot update the existing app.
  • Users cannot receive updates.
  • The only alternatives are:
    • Fix the signing configuration, or
    • Publish a new app, losing install continuity.

Example or Code (if necessary and relevant)

Below is an example of the required signing configuration in a MAUI .csproj:


    true
    keystore.jks
    your-store-pass
    your-alias
    your-key-pass

How Senior Engineers Fix It

Experienced engineers validate the entire signing chain, not just the keystore file:

  • Compare SHA‑1 and SHA‑256 fingerprints of:
    • The original keystore
    • The new build output
  • Confirm the package name matches the original app
  • Ensure the alias and passwords are identical
  • Verify the .csproj contains all required signing properties
  • Check that Google Play App Signing is using the same certificate
  • Rebuild and re-upload only after confirming the fingerprints match

They also avoid creating new blank projects unless absolutely necessary, preferring in-place upgrades.

Why Juniors Miss It

Less experienced developers often assume:

  • “If I copy the keystore file, everything is fine.”
  • “A new blank project is equivalent to the old one.”
  • “The package name doesn’t matter.”
  • “MAUI will auto-detect the keystore.”

They overlook that Android signing is a multi-part identity, and any mismatch breaks the chain. Juniors also rarely check certificate fingerprints, which is the only reliable way to confirm signing continuity.

Leave a Comment