I started an emulator from a script, waited, and adb devices stayed empty. The process was alive, the AVD was fine, nothing was booting. The emulator was showing a dialog asking whether it could upload the crash report of a previous run, and nobody was there to click.
TL;DR — After an emulator crash, the next start opens a consent dialog before booting; headless or scripted runs hang there. Delete the pending crash database, /tmp/android-$USER/emu-crash-<version>.db, and start again.
The setup
A Linux machine runs Android instrumented tests on a local AVD (API 34, google_apis, x86_64) started by a script with emulator -avd <name> -port 5556 -gpu host, output redirected to a log file, then adb -s emulator-5556 wait-for-device. An earlier session had crashed a different AVD of the same emulator install. Nothing in the script looks at the emulator window; it only polls adb.
What I expected
Either a booting device within about 30 seconds, or an error in the log: a missing system image, a port in use, a GPU failure. Something that exits or prints a reason.
What actually happens
The process runs forever and adb never sees a device. The log ends like this:
INFO | Storing crashdata in: /tmp/android-<user>/emu-crash-37.1.11.db, detection is enabled for process: <pid>
INFO | Showing crashdialog to get consent.
module_list[0].crashpad_annotations["command_line"] (type = 1) = -avd <other-avd> -gpu host -no-audio -no-boot-anim -no-snapshot -port 5554
module_list[0].crashpad_annotations["hw.ramSize"] (type = 1) = 1536M
module_list[0].crashpad_annotations["AVD_FLAVOR"] (type = 1) = AVD_PHONE
The annotations describe the other AVD, the one that crashed the day before. The emulator found its unsent crash report, opened a Qt dialog on the display to ask for consent, and stopped there. On a machine with a display the window is easy to miss behind other windows; on a headless CI runner there is no display to show it on at all, and the process just sits.
The fix
Kill the stuck process, remove the pending crash database, start again:
pkill -f "qemu-system.*-avd <name>"
rm -rf /tmp/android-$USER/emu-crash-*.db
emulator -avd <name> -port 5556 -gpu host -no-audio -no-boot-anim -no-snapshot \
> emulator.log 2>&1 &
adb -s emulator-5556 wait-for-device
adb -s emulator-5556 shell getprop sys.boot_completed # prints 1 once booted
After that the same AVD reached adb devices in about 25 seconds and booted normally. The only thing that changed was the missing .db file.
Why it works
The emulator ships Crashpad. When a run dies, Crashpad writes a report into a small database under /tmp/android-<user>/emu-crash-<emulator-version>.db. The next emulator start — any AVD, same emulator binary — checks that database first, and if it holds an unsent report it asks the user whether to upload it (the log line is literally Showing crashdialog to get consent.). The dialog is modal to the launch: booting waits for the answer. Removing the database removes the question. The directory is a scratch location; deleting it loses only the unsent report.
Two details worth knowing. The consent is per crash report, not per machine, so a crash-report setting saved in the emulator’s preferences does not prevent the dialog for a report that predates it. And the annotations dumped to the log are about the crashed run, which is why they mention another AVD and another port — that is not a misconfiguration of the current launch.
What I did not test
Whether a command-line flag suppresses the dialog for good; I did not find one in emulator -help for version 37.1.11 and did not try -no-metrics. Windows and macOS put the crash database elsewhere (the Storing crashdata in: line tells you where). I only reproduced this with Android Emulator 37.1.11 on Linux.
Facts
context: Android Emulator started from a script on Linux, after a previous emulator run had crashed
problem: the start hangs on a crash-report consent dialog ("Showing crashdialog to get consent."), adb never lists the device
solution: delete /tmp/android-$USER/emu-crash-<version>.db (the pending Crashpad report) and start the emulator again
verified_on: 2026-08-30
applies_to: [Android Emulator 37.1.11, Linux, scripted or headless launches]
does_not_apply_to: [launches where someone can answer the dialog on screen]