Description

This adds a scoped trial for Namespace Gradle remote build cache on the Android E2E APK build path.

The workflow configures Namespace Gradle cache only when runner_provider=namespace and the native Android build path is active. The generated Namespace init script is passed through GRADLE_INIT_SCRIPT to scripts/build.sh, where it is added to the Android E2E APK Gradle invocation as --init-script.

Current runner behavior stays unchanged: the Namespace setup step is skipped, GRADLE_INIT_SCRIPT is empty, and the existing Gradle command shape is preserved. The non-E2E AAB release build path is intentionally unchanged.

Validation summary

This validation uses Android E2E APK builds from commit 5a8b29d6895875799466b489abe957f7bdf914ee:

• Namespace warm-cache run: https://github.com/MetaMask/metamask-mobile/actions/runs/25792837744
• Forced current-runner native build: https://github.com/MetaMask/metamask-mobile/actions/runs/25786062492/attempts/3

Important caveat: this is a validation comparison, not a production benchmark. The primary metric for this ticket is Android E2E APK job wall time because it measures the CI job as executed, including setup, cache restore/configuration, Gradle execution, and artifact handling. The data proves the scoped Namespace Gradle cache path works for the Android E2E APK build. It does not prove Namespace is faster than the existing current-runner path.

The current-runner comparison was run through a PR-event native Gradle path so the existing current-runner behavior could be checked without enabling the Namespace setup.

Results and evidence

To claim performance gains, use a dedicated benchmark design. The current PR should stay scoped to validating that the official Namespace Gradle setup can be wired into the Android E2E APK path without changing current-runner behavior.

Changelog

CHANGELOG entry: null

Related issues

Refs: INFRA-3626

Manual testing steps

Feature: Namespace Gradle cache trial for Android E2E APK builds

  Scenario: Current runner Android E2E build path remains unchanged
    Given CI is manually dispatched from this branch with runner_provider=current
    And the Android E2E APK job requires a fresh native build

    When the Build Android E2E APKs job runs
    Then the Namespace Gradle remote cache setup step should be skipped
    And the Gradle command should not include --init-script
    And the existing current-runner Gradle cache behavior should remain unchanged

  Scenario: Namespace Android E2E build path configures Gradle remote cache
    Given CI is manually dispatched from this branch with runner_provider=namespace
    And the Android E2E APK job requires a fresh native build

    When the Build Android E2E APKs job runs
    Then the Namespace Gradle remote cache setup step should create a Gradle init script under RUNNER_TEMP
    And the Gradle APK invocation should include --init-script for that generated file
    And Gradle logs should show build-cache task reuse

  Scenario: Namespace warm-cache behavior is measurable
    Given CI is manually dispatched twice from the same branch and SHA with runner_provider=namespace

    When the second Android E2E APK job runs
    Then the Gradle task cache count should be comparable or better than the first Namespace run
    And Android smoke tests should be able to consume the generated APK artifacts

Screenshots/Recordings

Before

N/A

After

N/A

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.

Performance checks (if applicable)

CI-only change. No app runtime behavior is changed, so device runtime performance instrumentation is not applicable.

• Android CI validation was run through manually dispatched Android E2E APK and smoke workflows.
• No app runtime code path was modified.

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.