Description

The Android production build in build.yml runs Gradle without build caching, parallelism, or optimized JVM settings. The E2E builds already use an optimized gradle.properties.github with all these features, plus they cache Gradle dependencies across runs via cirruslabs/cache@v4. None of these optimizations exist in the production build path.

This PR brings parity by:

1. Creating android/gradle.properties.release adapted from the E2E config (keeps all 4 architectures for Play Store, disables Gradle daemon for ephemeral CI)
2. Adding GRADLE_USER_HOME and CACHE_GENERATION env vars to the build job (matching E2E pattern)
3. Adding a cp step to apply the release config before the build
4. Adding cirruslabs/cache@v4 steps for Gradle dependency caching with branch-scoped keys and main fallback

Part of MCWP-574 (PR 4 of 5).

Changelog

CHANGELOG entry: null

Related issues

Fixes: MCWP-574

Manual testing steps

Feature: Gradle optimization for Android production builds

  Scenario: First build populates Gradle cache
    Given a production Android build is triggered via workflow_dispatch on build.yml
    When the build job runs with the new Gradle config
    Then the "Restore Gradle dependencies from branch cache" step shows cache MISS
    And the build completes successfully with APK and AAB artifacts
    And the Gradle build uses parallel execution and 8GB JVM heap

  Scenario: Subsequent build uses Gradle cache
    Given a previous Android production build has completed successfully
    When a new Android production build is triggered
    Then the "Restore Gradle dependencies from branch cache" step shows cache HIT
    And Gradle dependency resolution completes faster than the first run
    And the total build duration is reduced

Screenshots/Recordings

N/A - CI pipeline change, no UI impact.

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.