expo run android: signatures do not match previously installed version

I used eas build to generate an apk with the Expo cloud build, and installed it onto my phone. I got this same error ([INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rooday.Prio signatures do not match previously installed version; ignoring!]) from adb so I uninstalled the app so that I could do the adb install. Once I confirmed that was working, I now wanted to go back to expo run android so that I could do quick local development, but then I got the same error about signatures not match. I tried using eas credentials to download the credentials for the profile I build with eas, but I still get this error. How do I get the signatures to match between eas cloud builds and expo run android?

Hi @rooday, maybe the data of your old app is not removed completely. Did you try `adb uninstall “com.yourpkgname.yourappname”?

Hi @amanhimself

When you use expo run, what profile does it use? It sounds to me like this is a similar issue that you run into if you want to install both a dev client and a preview/production build on your phone at the same time.

I don’t really use expo run myself, so haven’t run into this issue, so I’m not really sure what the advantages might be of using expo run for a managed app over using a dev client.

@rooday, is this a bare or managed app? Would a dev client not give you the “quick local development?”

Not sure if this will help with expo run, but have a look at this:

1 Like

Hi @wodin, I haven’t looked into dev clients before, would that be similar to how expo run provides a development server with hot reload? This concept of having app flavors/variants does sound really useful to test multiple versions of the app, but I don’t want to have to run eas build and install an APK every time I make a change (plus I’m on Windows so I can’t do local eas builds, I tried setting up WSL but ran into tons of issue with gradle not finding my Java install so I gave up there).

Oh my bad, I just checked the docs for dev-client Getting Started - Expo Documentation and if I understand correctly, as long as I’m only changing Typescript/Javascript code, it will hot-reload the changes?

Yes, that’s right.

If you are only using stuff that is in the Expo SDK or dependencies that are pure JS/TS, then you can use the Expo Ho apo on a device or Emulator/Simulator and it will hot reload as you make changes to your JS/TS code.

If you are using some dependencies that include native code, you can build a dev client. That is like a custom version of Expo Go, with only your dependencies built-in. You use it instead of Expo Go and it will hot reload your JS/TS changes. You only need to rebuild the dev client if you install another dependency that needs native code.

Btw, if expo run:android works for you I would expect eas build -p android --local to work too, although I haven’t tried either of those on Windows myself.

Unfortunately that’s not the case, as when I tried the local build I got this error:

PS R:\Documents\GitHub\Prio-Client> eas build --platform android --local
★ eas-cli@0.56.0 is now available, please upgrade.
Proceeding with outdated version

✔ Linked to project @rooday/Prio (https://expo.dev/accounts/rooday/projects/Prio)
Specifying "android.package" in app.json is deprecated for bare workflow projects.
EAS Build depends only on the value in the native code. Please remove the deprecated configuration.
✔ Using remote Android credentials (Expo server)
✔ Using Keystore from configuration: Build Credentials hf_ALkNRnF (default)
✔ Compressed project files 1s (471 KB)
Android builds are supported only on Linux and macOS
    Error: npx exited with non-zero code: 1

This doesn’t make sense to me though, as based on this doc it seems to equate expo run and eas build (at least to me it implies that they both call on Android Studio/gradle under the hood), so it doesn’t make sense why one just refuses to work on Windows. I assume this is an intentional choice by Expo, but what’s the reasoning? If expo run works just fine, why not let eas build run without forcing users to install and configure WSL?

As for expo-dev-client, I’m currently stuck trying to get eas build to work, the cloud build worked once but now just keeps giving me errors and debugging the cloud build is difficult, so I’m forced to end up configuring WSL anyways to debug locally, sigh.

hmmm… OK, I didn’t know that eas build -p android --local is only supported on Linux and macOS. I’m not sure why that would be, but maybe some EAS-specific stuff had issues on Windows that nobody has looked into.

What are the issues with WSL? I would have expected that to work, at least. You could run into issues with expo start because that needs an incoming connection. (The easiest workaround for that would be to use --tunnel.) But I don’t believe EAS Build would need any incoming connections.

Maybe start a new thread about that.

I didn’t have any WSL specific issues per se, just that my SSD is running low on space and I didn’t want to have to install WSL. The errors I did end up getting seem to be related to react-native-reanimated so I can follow up on their GitHub page, but I think I’ll first just try making a fresh Expo project with the latest SDK and copy over my code (because when I was thinking about it there was no reason why I needed native code at this point, so perhaps something in my bare workflow is messed up and returning to managed will solve some errors). Thanks for your help though, if I do end up needing native code again it’s good to know about the dev-client!

I guess this did get side-tracked from the original issue of signatures not matching (still have no idea why a build from eas uses different credentials than expo-run, but I guess the solution would be to stick with one, e.g. expo run for managed apps and eas + expo-dev-client for bare apps).

1 Like

Just bear in mind that expo run calls expo prebuild, so it effectively turns your app into a bare app, unless you revert all of the changes again afterwards.

1 Like

I was not aware, thanks for the headsup!

1 Like