PAYATHON 2026

IntelliJ 和 Android Studio 中 Android 模拟器一直等待设备上线怎么办？

排障赵师傅

结论

先检查 AVD 的快照状态，以及 IDE 使用的 ADB 能否识别已经启动的模拟器。现有日志还无法确定根因，不能直接归咎于 GPU、KVM 或某个插件。

同一个 AVD 使用 -wipe-data -no-snapshot 后能够启动，这是目前最有价值的线索。接下来应比较默认启动与这组参数的差异。不过，这条命令同时清除了用户数据、禁用了快照，还无法判断是哪一项起了作用。

命令行启动模拟器后，应用仍需由 IDE 或 ADB 安装、启动。对于绿色运行按钮一直等待的问题，应先确认设备在 ADB 中的状态。

为什么命令行能启动，IDE 却一直等待？

参数作用
-wipe-data重置 AVD 用户数据，会清除已安装应用及其数据
-no-snapshot禁用快照加载和保存
-verbose输出详细诊断日志
-show-kernel显示内核日志

前两个参数会直接改变持久状态和启动方式，-verbose 和 -show-kernel 主要用于观察启动过程。

硬盘恢复和图形硬件切换都值得纳入快照兼容性排查，但目前没有证据证明其中某一项就是根因。既然已经分别尝试过 Cold Boot 和 Wipe Data，接下来应做控制变量测试，继续重复重装的意义有限。

IDE 运行应用时，还要等待设备连接、检查启动状态、安装 APK，再启动应用。即使模拟器已经显示桌面，也需要分别确认这些步骤是否正常。

1. 先统一 SDK 和 ADB 路径

排查时只打开一个 IDE，避免 IntelliJ 和 Android Studio 同时启动或连接设备。

确认以下配置都指向同一个 SDK：

  • Android Studio 的 Android SDK 设置。
  • IntelliJ 中配置的 Android SDK。
  • 项目 local.properties 中的 sdk.dir，如果存在。
  • 终端中的 ANDROID_HOME 和 PATH。

以题目中的路径为例，local.properties 应写成：

sdk.dir=/home/my_user/Android/Sdk

这里要使用绝对路径，不要写成 ~/Android/Sdk。

终端中可以临时设置：

export ANDROID_HOME="$HOME/Android/Sdk"
export PATH="$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH"

command -v adb
command -v emulator
"$ANDROID_HOME/platform-tools/adb" version

后续命令直接使用这个 SDK 下的可执行文件，避免混用路径。如果还设置了 ANDROID_SDK_ROOT，也要检查它是否指向其他 SDK。

~/Library/Android/Sdk 通常是 macOS 的路径示例，不适用于这里的 Linux 环境。即使终端中的变量正确，从 Toolbox 启动的 IDE 也未必获得了相同环境。修改 .bashrc 不会更新已经运行的 Toolbox 或 IDE 进程。

2. 单独验证“不加载快照”是否足够

关闭目标 AVD，确认没有同名实例仍在运行，然后执行：

"$HOME/Android/Sdk/emulator/emulator" \
  -avd MyVirtualDeviceName \
  -no-snapshot \
  -verbose \
  -show-kernel

先不要加 -wipe-data，以便验证保留当前用户数据、仅禁用快照能否正常启动。

根据结果继续排查：

  • 仅加 -no-snapshot 就能启动：优先检查快照加载或保存。可在 AVD 编辑界面查找启动选项，将启动方式设为 Cold Boot，再测试 IDE 启动。选项位置可能随版本变化。
  • 必须再加 -wipe-data 才能启动：还需要检查 AVD 用户数据。建议新建一个测试 AVD，不导入旧数据或快照，验证能否连续启动。
  • 命令行正常，IDE 启动仍失败：比较两者使用的 emulator 路径、AVD 路径和启动参数，并检查 IDE 嵌入式模拟器设置。

Cold Boot 会绕过快照恢复，但不会长期禁止快照保存。如果一次冷启动正常，之后再次失败，要记录失败是否发生在恢复快照时。

-wipe-data 会清除数据，不适合放进日常启动命令反复执行。

3. 用 ADB 区分“设备没连接”和“系统没启动完成”

保持能够正常启动的模拟器运行，在另一个终端执行：

"$HOME/Android/Sdk/platform-tools/adb" devices -l

输出示例：

List of devices attached
emulator-5554 device product:... model:... device:...

根据实际输出选择下一步：

结果下一步
没有模拟器条目检查 ADB 连接、SDK 路径和实际运行的模拟器实例
状态为 offline先排查 ADB 通信，暂时不要修改项目构建配置
状态为 device继续检查 Android 启动完成状态

设备状态为 device 时，执行以下命令，将 emulator-5554 替换为实际序列号：

"$HOME/Android/Sdk/platform-tools/adb" \
  -s emulator-5554 shell getprop sys.boot_completed

"$HOME/Android/Sdk/platform-tools/adb" \
  -s emulator-5554 shell getprop dev.bootcomplete

"$HOME/Android/Sdk/platform-tools/adb" \
  -s emulator-5554 shell pm path android

如果 sys.boot_completed 返回 1，且 pm path android 能返回系统包路径，就有了系统启动和包管理服务已就绪的较明确信号。

日志显示 IDE 正在读取 dev.bootcomplete，也应记录这个属性的返回值。不同系统镜像的属性表现可能不同，不能仅凭空值认定系统没有启动，也不要通过 setprop 伪造启动完成状态。

如果设备缺失或处于 offline，可以关闭 IDE，再用同一个 SDK 的 ADB 重启服务：

"$HOME/Android/Sdk/platform-tools/adb" kill-server
"$HOME/Android/Sdk/platform-tools/adb" start-server
"$HOME/Android/Sdk/platform-tools/adb" devices -l

这会暂时中断当前 ADB 会话。不要使用 sudo adb，以免引入另一套用户环境和权限问题。

4. 让 IDE 使用已经启动的设备部署应用

确认 ADB 能正常访问设备后，再打开 IDE：

  1. 选择项目的 Android 应用运行配置。
  2. 在目标设备列表中选择已经运行的模拟器。
  3. 点击 Run。
  4. 查看 Run 或 Build 输出，确认流程停在等待设备、构建、安装还是启动阶段。

KMP 项目的 JVM 运行配置成功，只能说明对应的 JVM 构建和运行流程正常。运行 Android 应用时，需要选择对应的 Android 运行配置。

如果 IDE 仍在等待，可以用已经构建好的 APK 验证能否安装：

"$HOME/Android/Sdk/platform-tools/adb" \
  -s emulator-5554 install -r /absolute/path/to/app-debug.apk

将 APK 路径替换为实际产物路径。

如果命令行安装成功，IDE 却仍卡在设备就绪判断，应重点检查 IDE 的设备识别、运行配置和 Android 插件。如果安装失败，则根据具体错误继续处理，例如 minSdk、ABI 或签名不兼容。

5. 检查 IDE 嵌入式模拟器的差异

命令行启动的模拟器使用独立窗口，IDE 则可能使用 Running Devices 工具窗口。两种方式的启动参数和显示集成存在差异。

在 IDE 设置中搜索 Emulator 或 Running Devices。如果当前版本提供“在工具窗口中启动模拟器”之类的选项，先关闭它，完全退出 AVD，再从 Device Manager 启动测试。

如果独立窗口正常、嵌入窗口失败，应优先检查这两种启动方式的差异，比继续切换系统镜像更有诊断价值。

从 idea.log 中找到 IDE 实际使用的 emulator 路径和启动参数，与成功启动的命令行比较，重点检查：

  • 是否使用同一个 SDK 下的 emulator。
  • 是否打开同一个 AVD 和数据目录。
  • 快照、图形和嵌入窗口相关参数是否不同。
  • 硬盘恢复后，实际 AVD 目录是否仍属于当前用户并且可写。

可以先检查恢复后的目录权限：

ls -ld "$HOME/.android" "$HOME/.android/avd"
ls -ld "$HOME/.android/avd/MyVirtualDeviceName.avd"

确认所有者或权限确实异常后再修正，不要直接对整个 SDK 或 .android 执行大范围权限修改。

这些日志能说明什么？

需要继续追踪的日志是：

Emulator not ready yet, dev.bootcomplete = null
AdbCommandRejectedException getting properties for device emulator-5554
Failed to read boot status

这些日志说明 IDE 未能完成设备就绪检查，具体原因还需要结合当时的 adb devices -l 和 getprop 输出判断：Android 是否尚未启动完成，设备连接或属性读取是否出了问题。

其他警告也不足以单独确定根因：

  • quickbootChoice.ini 读取失败，需要检查文件状态和权限，但不能据此认定快照损坏。
  • ProcessTrackerAgent not found 指向进程跟踪代理及 ABI 支持，不足以解释整个系统为什么无法启动。
  • 多显示器功能不可用、Qt 信号连接警告，也不能直接等同于模拟器启动失败。

如果系统已经可以操作，ADB 属性读取和 APK 安装也均成功，而 IDE 仍持续等待，应保留这组对照结果，并检查与当前 IDE 配套的 Android 插件、Android Emulator 和 Platform-Tools 更新情况。现有材料无法确定哪个版本一定能修复问题。

哪些设置暂时不用继续改？

compileSdk 无需与模拟器 API level 相同。在 API 24 设备上运行，首先要满足应用的 minSdk 不高于 24，并正确处理较新 API 的调用。反复把编译 SDK 改成 21、24 或 36，通常无法解决 IDE 等待设备上线的问题。

uname -m 显示的是宿主机架构，不能据此断定每个 AVD 都必须使用 x86_64。应根据可用系统镜像和应用的原生库支持选择 ABI。

AVD 可写数据默认位于 ~/.android/avd/，下载的系统镜像通常位于 SDK 的 system-images/ 下，需要分开检查。清理 IDE 缓存或重装 IDE，不一定会重置这些共享数据。

确认问题解决前，需要验证同一个 AVD 能连续正常启动、ADB 能读取其状态，且 IDE 能选择该设备并完成应用安装和启动。完成这些验证后，再恢复快照等便利功能。

备注：内容仅供参考。