[build-tools] Early stop eas/start_android_emulator when Android emulator host setup is invalid

[gwdp]

Why

Starting an Android emulator without nested virtualization support always fails, but today that failure happens later and with less actionable context.
Adding nested virtualization detection to start_android_emulator allows us to fail fast with a clearer error message when the VM does not support emulator hardware acceleration.

How

Add an early preflight check in start_android_emulator to detect whether emulator acceleration prerequisites are present (including VMX/SVM support).
If acceleration is not available, fail fast with a clear, user-friendly error explaining that nested virtualization is required and how to enable it.

Test Plan

• CI checks (with new tests)
• Running -accel-check on nested and non nested virtualization to confirm command behavior https://staging.expo.dev/accounts/gwdp/projects/coin-flip/workflows/019d73d1-261b-793a-9db7-98cfa335c197
• Local run for failure format and checking UX

Ref ENG-17446

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 54.44%. Comparing base (8c170af) to head (074633b).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3580      +/-   ##
==========================================
+ Coverage   54.26%   54.44%   +0.18%     
==========================================
  Files         821      821              
  Lines       35327    35348      +21     
  Branches     7363     7369       +6     
==========================================
+ Hits        19166    19240      +74     
+ Misses      16074    16017      -57     
- Partials       87       91       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[linear]

ENG-17446 Better error when trying to start Emulator on a non-nested-virtual VM

[gwdp]

x-ref https://github.com/expo/workflow-orchestration/pull/738
x-ref #3579

[github-actions]

Subscribed to pull request

File Patterns	Mentions
**/*	@douglowder

Generated by CodeMention

[sjchmiela]

question: now that I'm thinking about it maybe this check should not force-fail the job, but instead only print a helpful warning? We can then add an annotation on the log to make it even more prominent. https://expo.dev/admin/annotations

What happens if a user does start_android_emulator on non-virtualized VM? Does emulator return a non-zero code or do we just "fail, waiting"?

EDIT: Ok looking more, judging by https://staging.expo.dev/accounts/gwdp/projects/coin-flip/workflows/019d73d1-261b-793a-9db7-98cfa335c197 we don't even install emulator on non-nested VMs which means emulator should fail which means start_android_emulator step fails with ENOENT or sth like that which is not too helpful. so maybe your solution is good, but maybe let's rename stuff to indicate that we're checking emulator is set up correctly or what

[gwdp]

Took this path of the early failure since my reproduction did show 9m+ of execution into the start emulator function until failure on non nested environment and thought about potential savings with the early path. Renamed things slightly, let me now if aligned

[sjchmiela]

now that it's returning false if we don't have ANDROID_HOME set let's rename it to something different?

[gwdp]

Actually, reasoning further, failure pattern when/if ANDROID_HOME is missing would be quite obscure, since spawn would not produce any logs and just assertion would be raised.

If you are aligned, I modified it to use empty sdk path and actually execute with it, so failure is more visible to us if that ever happen. Thoughts?

[github-actions]

✅ Thank you for adding the changelog entry!