Ask
71

eas build android fails at :app:mergeReleaseResources, same commit builds fine locally eas-build

SDK 54, managed workflow. On EAS the Android release job dies with Execution failed for task ':app:mergeReleaseResources' and a duplicate resource message naming a drawable that two of my dependencies both appear to ship.

The exact same commit builds green locally with npx expo run:android --variant release and installs on a device. So I cannot reproduce it on the machine where I can actually debug it, which is the frustrating part.

9 answers Share
Report

Answering anonymously — a moderator will review it first.

  • @deadbug_wiring · yesterday · 3 replies

    Local is green because you have an android/ folder that was generated at some point in the past and has been carrying stale merged resources and a warm Gradle cache ever since. EAS prebuilds from nothing every single time, so it is seeing your actual current dependency graph and you are not.

    Reproduce it properly:

    npx expo prebuild --clean
    npx expo run:android --variant release
    

    You will get the same failure, on your machine, with a debugger and no queue.

    Then the real work is finding the two packages shipping the same drawable name. ./gradlew :app:dependencies and look for the same library appearing at two versions, which is usually one direct dependency and one dragged in transitively by something that has not been updated in a while.

    108
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @rest_day_rita · 2d ago

      --clean deleting the android folder is the correct move and it is also the moment you discover you had hand-edited something in there eight months ago that is not in any config plugin. Better to find that now than at the next SDK bump.

      33
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
    • @treadmill_tara · 4d ago

      If you are in the managed workflow, android/ should not be committed at all. If it is sitting there in git, that is the bug behind the bug and it will keep producing this exact class of divergence.

      15
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @bench_dogged · 4d ago · 2 replies

    Run it once with eas build --clear-cache to rule out a poisoned cache before you spend an afternoon on dependency archaeology. One flag, and if it fixes it you have your answer immediately.

    47
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @rawfileruth · 2d ago

      Free in effort, not free in queue time, which on the free tier is the expensive part. Worth doing while you also do the local reproduction rather than instead of it.

      12
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @treadmill_tara · 4d ago

    Read the whole Gradle log, not the tail. The line naming the actual conflicting resource paths is usually a couple of hundred lines above Execution failed, and the failure line itself tells you almost nothing. Everyone scrolls to the bottom and then says the error is unhelpful.

    29
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @rawfileruth · 3d ago · 2 replies

    Bump compileSdkVersion. Resource merge errors are usually an SDK level mismatch.

    16
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @deadbug_wiring · 3d ago

      It is not, and in a managed project you should not be setting that directly anyway - expo-build-properties exists precisely so the SDK levels stay consistent across prebuilds.

      Changing platform SDK levels to resolve a filename collision is rolling dice. Sometimes the dice land right and then you have a project configured by accident.

      13
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @hemline_hana · 3d ago

    Also worth knowing generally: a different local Node or JDK version is a common source of "green here, red there", and EAS pins those from your eas.json image. Set the same versions locally and one whole category of divergence disappears.

    10
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report