Android Mac Mini POC

Objective

Evaluate the capacity of a self-hosted Mac Mini for running Android emulators and GitHub Actions runners for E2E testing, with the goal of running multiple test suites in parallel to reduce PR feedback time.

Machine spec: Mac Mini M4 · 10 cores · 32GB RAM

Emulator config: API 34 · google_apis · arm64-v8a · Pixel 6 profile (1080x2400) · 2048MB RAM (hw.ramSize) · 2 cores

GPU rendering: -gpu host

Emulator capacity on the current machine

Android emulators are fundamentally different from iOS simulators — they run a full guest OS under QEMU with a separate ADB server:

• Constant QEMU overhead — each emulator consumes ~4.5GB real RAM regardless of configured heap size
• Separate ADB server per runner — required to prevent cross-talk between emulators

Actual Android emulator capacity on the current Mac Mini (10 cores, 32GB):

Runners	Peak RAM	Viability
2	64%	Stable — confirmed viable, 0 pageouts
3	98%	Not viable — over-committed from the start
4	—	Not viable — OOM kills during startup

Each runner slot carries an emulator, ADB server, and Appium server. 3 emulators × ~4.5GB + ~20GB baseline exceeds the machine's 31GB — the 3-runner config was over-committed from the start.

What Was Tried

RAM consistently hits 98–99% under 3-runner load — the combined QEMU, rendering, and ADB overhead saturates 32GB. The key variable is whether suites are actually completing cleanly or being held together by retry logic.

Metric	2 runners	3 runners	4 runners
Suites passed	4/4	6/6*	0/6
Peak RAM	64%	98%	—
Avg CPU	~71%	~92%	—
Pageouts	0	+16k	—
OOM kills	0	Yes (hidden)	Yes
Duration	~22 min	~19 min	—

2 runners — all 4 suites passed in 22 min post-reboot. 64% RAM, zero pageouts. Confirmed stable.

3 runners — appeared to pass but was running in a degraded state throughout. Emulators were crashing and restarting mid-test; retry logic masked the failures. CPU was below 5% idle for 58% of the day. Not viable.

4 runners — OOM killed during startup. Not viable on 32GB.

Observed Resource Usage

3 runners (2026-03-19, 10:32–10:51)

Metric	Peak	Sustained	Notes
System RAM	98% (31G / 31G)	95–98% for entire run	Effectively no headroom
System CPU	100% (0% idle)	Hit 0% idle multiple times	Both user and sys saturated
Per-emulator CPU	696.9% (~7 cores)	100–600% range	Bursts during app install/boot
Per-emulator RAM	~14% each (~4.3GB)	~12–14%	2x configured 2048MB due to QEMU/rendering overhead
Pageouts	+18,230 during run	Active throughout	System was continuously paging to disk

During this run, emulator PID 47179 (runner_1) was OOM-killed mid-test and replaced by a new process (PID 55082) — visible in the logs as a PID change partway through.

2 runners (2026-03-20, 12:52–13:14)

Metric	Peak	Sustained	Notes
System RAM	64% (20GB)	53–64%	~11GB headroom throughout
System CPU	100% (0% idle)	~29% avg idle	Bursts at emulator boot only
Per-emulator CPU	779% (~8 cores)	317–659% range	Spikes during boot/install
Per-emulator RAM	~4.5GB each	Consistent	Same QEMU overhead as 3-runner config
Pageouts	0	0	No paging at any point

One emulator (S22_runner_3) crashed and restarted once during a CPU spike when both emulators were booting concurrently. It recovered and the suite completed.

Limitations Discovered

3 runners was never actually viable

• Each emulator consumes ~4.5GB real RAM regardless of the configured hw.ramSize — 3 emulators + ~20GB baseline = ~33.5GB on a 31GB machine. The setup was always over-committed.
• Tests appeared to pass during the POC but were doing so by brute force — emulators would crash, restart, and retry until the test eventually got through. The logs confirm this was happening continuously.
• 10 CPU cores are fully saturated under parallel load. Individual emulators burst to 600-700% CPU (6-7 cores) during app install and rendering, leaving nothing for the other runners.

Memory compressor drift requires regular reboots

macOS accumulates compressed page data from emulator launches and OOM-kills in the memory compressor. This memory is not released until reboot. After 8 days of uptime, the compressor had consumed 7.4GB of RAM — enough to push even a 2-runner config into failure. A scheduled weekly reboot is required to keep the baseline stable.

Screen recording is unlikely to be feasible

Both RAM and CPU are at their ceiling even at 2 runners — adding ffmpeg or any video capture process per runner would push the machine further into resource pressure.

Things to Try

• GitHub Actions hosted runners — GHA's macos-latest and Linux runners support Android emulation without the overhead of managing self-hosted hardware. This is what we ended up adopting — see the Android GHA hosted POC for details.
• Linux runners — macOS is not well-suited to Android emulation at scale. A Linux-based runner (KVM-accelerated, hardware GPU passthrough) could support more parallel runners at a lower cost.

Maintenance

• Runner logs are stored at ~/Desktop/e2e-logs/ and retained for 30 days.
• A weekly reboot (e.g. Sunday 3 AM) is required to clear macOS memory compressor drift — after 8 days of uptime, the compressor had consumed 7.4GB of RAM, destabilising even the 2-runner config.

Incident

Throughout the POC, 3 runners was at the limit but appeared to be holding — controlled test runs were completing and the hope was that it would be stable enough for general use. Attempt 6 (dropping to 2 runners) triggered a full collapse: the emulators, Appium, and ADB processes all crashed. The Mac Mini itself was restarted to recover, and a post-mortem was run against the monitor logs.

The logs revealed that 3 emulators was never actually stable — it had been running in a degraded state throughout the POC. CPU was below 5% idle for 58% of the day, 4.2GB was paged out to disk, and RAM hit 96-99% for approximately 2 hours of wall time.

A contributing factor was memory compressor drift — the machine had been running for 8 days without a reboot, and the macOS memory compressor had accumulated 7.4GB of RAM holding compressed page data from previous emulator launches and OOM-kills. This is not released until reboot. It pushed the idle baseline from the normal ~20GB up to ~25GB, meaning even 2 emulators exceeded available memory.

The underlying root cause: each emulator consumes ~4.5GB real RAM regardless of configured heap size. 3 × 4.5GB + ~20GB baseline = ~33.5GB on a 31GB machine. The machine was over-committed from the start.

Final Recommendation

The Mac Mini is not recommended for Android E2E testing. 2 runners is the maximum viable configuration, costs €125/month, and requires ongoing maintenance (weekly reboots, memory compressor management) to stay stable. GitHub Actions hosted runners are a more reliable and cost-effective alternative — see the Android GHA hosted POC.