how to set EXP_RUNTIME_VERSION in SDK 47

I am trying to build via on Expo using eas on Expo SDK 47.

I have this in app.config.js

“runtimeVersion”: {
“policy”: “appVersion”
},

Howver get error :-
/home/expo/workingdir/build/android/app/build/intermediates/packaged_manifests/release/AndroidManifest.xml:70: error: resource string/expo_runtime_version (aka com.xxx.appv2:string/expo_runtime_version) not found.

AndroidManifest.xml which is automatically written over by eas.

SDK 47 uses
	    <meta-data android:name="expo.modules.updates.EXPO_RUNTIME_VERSION" android:value="@string/expo_runtime_version"/>

In your post, please share:

  • Whether you are bare or managed workflow - Managed worflow.
  • Your eas-cli version >= 3.13.0" eas-cli/3.13.0 linux-x64 node-v16.16.0
  • What you have tried so far - setting sdkVersion

can you share a link to your build and your AndroidManifest.xml file please? (remove any sensitive content)

I restarted from fresh using 48, and now it is gone.
Issue is now solved.

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.

can you share a link to your build and your AndroidManifest.xml file please? (remove any sensitive content)

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.

A snippet of our manifest:

  <application android:name=".MainApplication" android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:roundIcon="@mipmap/ic_launcher_round" android:theme="@style/Theme.App.SplashScreen" android:usesCleartextTraffic="true" android:hardwareAccelerated="true">
    <meta-data android:name="expo.modules.updates.ENABLED" android:value="true"/>
    <meta-data android:name="expo.modules.updates.AUTO_SETUP" android:value="true" tools:replace="android:value"/>
    <meta-data android:name="expo.modules.updates.EXPO_UPDATES_CHECK_ON_LAUNCH" android:value="ALWAYS"/>
    <meta-data android:name="expo.modules.updates.EXPO_UPDATES_LAUNCH_WAIT_MS" android:value="0"/>
    <meta-data android:name="expo.modules.updates.EXPO_UPDATE_URL" android:value="https://u.expo.dev/........"/>
    <meta-data android:name="expo.modules.updates.EXPO_RUNTIME_VERSION" android:value="3.107.0"/>
    <meta-data android:name="iterable_notification_icon" android:resource="@drawable/ic_stat_onesignal_default"/>
    <meta-data android:name="com.facebook.sdk.ApplicationId" android:value="@string/facebook_app_id"/>
    <meta-data android:name="com.facebook.sdk.ClientToken" android:value="@string/facebook_client_token"/>
    <meta-data android:name="com.facebook.sdk.AdvertiserIDCollectionEnabled" android:value="false"/>
    <meta-data android:name="com.facebook.sdk.AutoLogAppEventsEnabled" android:value="false"/>
    <meta-data android:name="com.google.android.gms.wallet.api.enabled" android:value="true"/>
    <activity android:name=".MainActivity" android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|screenSize|smallestScreenSize|uiMode" android:label="@string/app_name" android:theme="@style/Theme.App.SplashScreen" android:launchMode="singleTask" android:screenOrientation="portrait" android:windowSoftInputMode="adjustPan" android:exported="true">
1 Like

Unfortunately, I can’t provide you the link to the build, but hopefully these links to our redacted android manifest file and build log will suffice.

AndroidManifest.xml

Build Log

Found the problem or solve it on our end. You need to add the

 <string name="expo_runtime_version">48.0.0</string>

in

android/app/src/main/res/values/string.xml

I think this is problem since I already have runtimeVersion in app.config.js, Might as well got an error on ios cd to ios folder then run this

pod update hermes-engine --no-repo-update

1 Like

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.

do you know what version of eas-cli you were using previously?

@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

We’re working on fixing this issue, you can track the progress here: [ENG-8790][eas-cli] Fix updates synchronization of native files to include strings.xml by wschurman · Pull Request #1865 · expo/eas-cli · GitHub . When it is merged it will be available in the next patch release of the cli.

In the meantime, you can unblock yourself by either reverting back to an older version of the cli (3.12.1 or lower), or write the runtime version value to string.xml (what @9winters suggested).

Sorry for any disruption to your release processes. This is definitely a bug.

1 Like