Context

When building a Unity Android project (e.g., using Unity 6 with AGP/AAPT2 8.x), you may encounter intermittent build failures with an error similar to:

AAPT2 … Daemon #0: Daemon startup failed, preceded by Unexpected standard output: Ready

The build may fail at a seemingly random point (e.g., the 36-minute mark) and then succeed on an identical retry. This makes it appear like flakiness in the build environment, but it is typically caused by memory pressure on the build machine.

Answer

This error occurs when Gradle cannot successfully start AAPT2 worker processes due to insufficient available memory. On machines with limited RAM (e.g., a Mac mini M2 with 12 GB), the Unity Editor and Gradle can compete for memory simultaneously. If Gradle's JVM heap is configured too high (e.g., -Xmx8192m), there may not be enough memory left for AAPT2 worker processes to start, causing intermittent failures.

Note that in Unity projects, the JVM heap size may not be visible in gradleTemplate.properties directly. It can be set programmatically in a C# build script using UnityEditor.Android.AndroidExternalToolsSettings.maxJvmHeapSize, so be sure to check your build scripts as well as your Gradle configuration files.

To resolve this, apply one or more of the following changes:

1. Reduce the JVM heap size. Lower org.gradle.jvmargs (or maxJvmHeapSize in your Unity build script) to a smaller value such as 4096–5120 MB. A value of 5120 MB may be preferable if you have a large dependency set (e.g., Firebase, Google, ad SDKs) and want to avoid dex out-of-memory errors.

2. Limit concurrent AAPT2 workers. Add org.gradle.workers.max=2 to your gradleTemplate.properties to reduce the number of concurrent worker processes.

3. Disable parallel builds. Add org.gradle.parallel=false to your gradleTemplate.properties. Unity Android projects are typically a single Gradle module, so parallel builds provide little benefit and can multiply concurrent AAPT2 workers unnecessarily.

4. Disable the Gradle daemon. Add org.gradle.daemon=false to your gradleTemplate.properties to prevent background daemon processes from consuming additional memory.

5. Upgrade to a larger build machine. If you prefer to keep your current Gradle settings, consider switching to a machine with more RAM (e.g., a Mac mini M4 with 16 GB) to give both the Unity Editor and Gradle enough headroom.

Memory pressure from this issue can also explain unexpectedly long build times (e.g., a release build taking significantly longer than the median), since system-wide swapping slows all processes, not just AAPT2. Release builds are particularly susceptible as they tend to be heavier (e.g., compiling IL2CPP for multiple ABIs).