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