Mobile releases: keep Gradle's cache between builds

Why

Mobile releases take about 14 minutes, nearly all of it in Gradle, and every run starts from nothing:

Gradle User Home cache not found. Will initialize empty.
658 actionable tasks: 658 executed
Cache is read-only: will not save state for use in subsequent builds.

setup-gradle only saves its cache on the default branch (main), and releases run on dev, so nothing is ever kept.

The change

• cache-read-only: false, so dev builds save the cache.
• --build-cache, so compiled output is reused too. expo prebuild --clean regenerates the project each run, so Gradle's normal up-to-date checks find nothing without it.
• A note in docs/RELEASING.md, including how to clear the cache.

What to expect

• Not measured: this workflow only runs on dev, so it can't be tried from a branch without publishing a release.
• The first build after merging is still slow, because it fills the cache. Build #2 after merging is the real measurement.
• What stays slow: the CMake C++ builds and the JS bundle aren't Gradle-cacheable and run every time. If it's still too slow, ccache is the next step.

Signing

This job also signs the APK, and caches saved on dev can be read by runs for PRs that target dev, including forks, so I checked what gets saved. It is caches and notifications from Gradle User Home. The keystore lives in $RUNNER_TEMP and is deleted after the build, so it is not in that set. The signing password is passed as a -P property, which I don't expect to be written there, but I have not inspected a real cache entry to prove it.

The existing certificate and version checks still run on every APK.

Merging

The workflow file is on the release trigger, so merging this publishes a new APK with no app changes.

🤖 Generated with Claude Code