mobiai-community-android-github-actions

Android GitHub Actions Workflows

Create or adapt reusable GitHub Actions workflows for Android test automation.

This skill supports two modes:

• unittest
• androidtest

It is optimized for Gradle-based Android CI, test result publishing, artifacts, and emulator-backed instrumented tests.

When to Use

• The user wants a new GitHub Actions workflow for Android tests
• The user wants to refactor an existing Android test workflow into a reusable pattern
• The user wants to revise Gradle cache, artifact retention, triggers, or test-report publication for Android CI
• The user wants to review whether workflow actions such as report publishers or emulator runners should be updated

Non-Negotiable Rules

1. Ask decisions one at a time with a recommendation.
2. Do not assume hard-coded module names, branches, paths, Gradle tasks, or emulator settings.
3. Reuse repository conventions when they exist.
4. Separate common workflow blocks from mode-specific blocks.
5. Before finalizing the workflow, verify whether third-party and GitHub action dependencies should stay pinned as-is or be updated.

Workflow

Step 1: Detect the job type

Determine whether the user needs:

• unittest — Gradle unit tests running on the host
• androidtest — instrumented tests running on one or more emulators

If unclear, ask this first.

Step 2: Inspect the repository baseline

Search for these files before drafting the workflow:

find .github/workflows -maxdepth 1 \( -name '*.yml' -o -name '*.yaml' \) 2>/dev/null

Step 3: Ask the common decisions

Ask these one at a time:

1. Trigger strategy
   • push
   • pull_request
   • both
   • workflow_dispatch
   • branch filters
   • path filters
2. Test scope
   • exact Gradle task
   • test class
   • package/group of tests
3. Gradle cache strategy
   • enable/disable cache
   • restore/save behavior
   • artifact retention policy
   • which branch strategy to apply:
     • shared cache across branches, written only by the default branch (default gradle/actions/setup-gradle behavior; scope it with cache-read-only)
     • per-branch cache, where each branch keeps its own warm entry — this needs a manual actions/cache step, since neither setup-gradle nor setup-java accepts a cache-key input
   • which step owns the cache: setup-gradle or setup-java cache: gradle, never both
4. Reporting
   • publish XML results
   • upload HTML reports on failure or always
   • artifact retention days