I’ve been getting this for the last 7 days myself. I’m on Expo 48.0.17 and EAS 3.13.0. It’s only happening for my lower environment (Dev, Qa, etc) android profiles with these properties {“android”: {
“distribution”: “internal”,
“gradleCommand”: “:app:assembleQaRelease”,
“image”: “latest”
}}
I’ve upgraded my gradle properties to “org.gradle.jvmargs=-Xmx8g -Xms4g -XX:ThreadStackSize=4096 -XX:CompilerThreadStackSize=4096 -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8” and the same thing happens.
Also suddenly running into this issue with our Android EAS builds on SDK 47. The only native thing we’ve changed was bump a RN camera package, but we haven’t touched the manifest or anything else.
Builds seem to work from using eas build from the command line to build one of our alternate flavors, but the production builds are failing on the error above about the manifest, when again, we haven’t changed this at all.
I was also able to resolve this by adding the same above to our string.xml file, but why did this suddenly change? As far as I can tell, something in the build process is now overwriting the original manifest string value with this variable lookup instead
Adding that node to the xml worked! I’m just as confused as @jwalt is. That file has never needed this until recently. I can only assume it’s an issue with Gradle during the EAS build process.
@technology_eate After updating eas CLI to the latest yesterday, it started automatically replacing my fixed value in the EXPO_RUNTIME_VERSION for the value “@string/expo_runtime_version”, which I suppose it’s how to reference string.xml variables. So I think it’s intended on the expo side.
@brents, not sure if you’re one of the Expo devs, but my local is still on 3.8.1: I’m guessing the latest eas-cli switches to this new variable override. Is there no way to version lock the eas-cli that our EAS builds use? It’s pretty disruptive when there are unannounced breaking changes in the build pipeline because of things like this (and this has definitely happened in the past as well)
eas build doesn’t use eas-cli at all except to fire off the build from your local machine. once it’s running on a remote server, eas-cli is not involved