When an AI Studio App Won't Install on My Phone Because the Signatures Don't Match

Ever since AI Studio started generating Kotlin/Compose apps from a text prompt and pushing them straight to a device over USB, I have been running its output directly on my Pixel more and more. Then one day, the moment I tried to deploy to my usual phone, the install stopped on a single red line.

adb: failed to install app-debug.apk:
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Existing package com.example.wallpaper
signatures do not match newer version; ignoring!]

Here is the short version up front: this is not a bug in AI Studio, and it is not a problem with the generated code. Your phone already has the Google Play build of the same app installed, and Android is refusing to overwrite it with something signed by a different key. That is all. Once you understand the cause, it takes a couple of minutes to work around safely.

I publish wallpaper and calming apps on Google Play, and my everyday phone has those production builds installed. That is exactly why I kept hitting this wall whenever I tried to put a freshly generated experiment onto the same device. Plenty of people are in the same spot, so let me leave the diagnostic path I actually use.

Read the single error line as it is

Start by separating INSTALL_FAILED_UPDATE_INCOMPATIBLE from the signatures do not match that follows it. The first half means "this can't be applied as an update to the existing package," and the second half means "the signatures differ." In other words, Android's package manager requires that, when updating an app with the same package name (applicationId), the signing certificate stays identical to last time.

What matters here is that the error is raised by the OS on the device, not by AI Studio or adb. Neither adb install -r (reinstall) nor -d (allow downgrade) changes anything, because neither of them loosens the "must be the same signature" rule. As long as the signature differs, you get the same line no matter how many times you run it.

There is a similar-looking error, INSTALL_FAILED_VERSION_DOWNGRADE, but that one is about a lowered versionCode. The wording is different, so first confirm which one you are actually seeing.

Why the signatures don't match

The reason is Play App Signing. An app delivered through Google Play ends up on the device signed not with your upload key, but with the app signing key that Google holds. Meanwhile, the build that AI Studio generates and pushes — or the one you run locally as-is — is signed with the default debug keystore (~/.android/debug.keystore).

These two are different things. When a debug-signed build tries to overwrite the Play version, Android rejects it because the certificates don't match. This is not a misconfiguration; it is the design that prevents spoofed updates. In fact, getting blocked here is what stops a third party from hijacking a user's data with a same-named app.

To put it plainly, your "published production build (Play signature)" and your "generated experiment build (debug signature)" are fighting over the same applicationId. There are two ways out: remove the production build, or shift the name of the experiment build.

The fastest path when you just need it installed now

If you only need to try the experiment build and you don't mind losing the production app's data, remove the production build first, then install.

# Find the same-named package already on the device
adb shell pm list packages | grep wallpaper
 
# Remove the production build, then install the experiment build
adb uninstall com.example.wallpaper
adb install app-debug.apk

Two cautions. Uninstalling wipes the app's local data (settings, cached purchase state, and so on), and once the production build is gone you have to reinstall it from Play to get it back. I avoid this on my everyday phone. On a spare test device or an emulator, though, this fastest path is perfectly fine.

Run them side-by-side with applicationIdSuffix

Keep using the production app on your usual phone while still installing the generated experiment — this is, I think, the most common need in indie development. In that case, shift the applicationId of the debug build so it runs as a separate app. In Gradle (Kotlin DSL) it looks like this.

// app/build.gradle.kts
android {
    defaultConfig {
        applicationId = "com.example.wallpaper"
    }
    buildTypes {
        debug {
            // Give the debug build its own package
            applicationIdSuffix = ".debug"
            versionNameSuffix = "-debug"
            resValue("string", "app_name", "Wallpaper (Debug)")
        }
        release {
            isMinifyEnabled = true
        }
    }
}

Now the debug build becomes a separate applicationId, com.example.wallpaper.debug, and never collides with the Play version (com.example.wallpaper). Two icons sit on your home screen, the signatures are treated as distinct, and that single error line disappears. Adding "(Debug)" to the display name with resValue makes it obvious at a glance which one you are touching.

If you are using the Gradle that AI Studio generated as-is, check that this applicationIdSuffix is present before you deploy. The initial setup an agent produces is often a plain single applicationId, and adding this one line removes almost every on-device install mishap. I have made this small step a fixed check before sending any generated output to a device.

So it doesn't happen again

Prevention comes down to one thing: never let a production-signed app and an experiment-signed app coexist on the same device under the same applicationId. Concretely, I keep three habits.

First, always include applicationIdSuffix in the debug build. Bake it into the template, and generated output inherits it naturally. Second, keep one verification-only device or emulator that never has the published builds of your own apps — signature collisions simply can't occur there. Third, after letting an agent touch your Gradle, always eyeball the diff of signingConfigs and buildTypes. I review whether the signing setup was quietly rewritten on every generation.

When you want to confirm the official behavior, Android Developers' Sign your app and Play App Signing are the reliable primary sources.

Now that the distance from generation to on-device testing has shrunk, signing snags are closer to everyone than before. Once the cause clicks, there is nothing to fear. I would be glad if this gets someone stuck at the same spot moving again a little sooner.