2026 年 6 月 5 日前后，我先遇到的是 Android 模拟器打不开。这个问题看起来很像环境坏了，继续查下去才发现，窗口进程、 adb devices 里的设备状态和 Android 系统启动完成，是三层不同的状态。旧 API 36 AVD 能启动 QEMU，却长时间停在 offline，设备其实还不能用。
第一反应容易落在项目代码或磁盘空间上，可项目还没有运行到那一步。SDK 和 AVD 都存在，异常集中在旧锁文件、残留进程、adb 启动碰撞、图形兼容提示，还有一处很要命的配置，AVD 写着 2G，实际只分到 256MB。
排查顺序后来变得很固定。先确认 SDK 工具与 AVD 是否存在，再清理陈旧锁和半启动进程；随后分别观察模拟器日志、adb 的 offline 或 device 状态，以及 sys.boot completed 。修正内存后，旧 API 36 镜像仍不稳定，于是升级 emulator 与 command line tools，再新建 API 35 AVD 做对照。
这次没有找到一个漂亮的单一根因。能确认的是，新 API 35 AVD 进入 device，并返回 boot completed=1 ；随后可以安装燃日并截取实机画面。模拟器比例后来按目标手机截图调整为 1080×2354，用于后续 UI 对照。
另一次故障出现在 Compose 页面。底部导航是覆盖在内容上的浮动层，不属于普通文档流；列表只给系统导航栏留空间，没有把浮动底栏本身的高度算进去，于是末尾卡片始终被盖住。修复时没有改卡片，也没有缩小底栏，而是统一增加主页面的底部内容 padding。首页、目标、统计和我的共用这项留白，最后一项可以滚到浮动导航上方。
清单最初还写了下拉框和弹窗，但原先匹配的两个历史任务属于别的项目，不能作为燃日证据。现有材料只能确认模拟器和浮动底栏，所以正文也只保留这两件事。排查模拟器时，我会依次问进程在不在、设备是不是 device、系统有没有 boot completed=1 ；处理覆盖式导航时，先画出覆盖层占掉的空间，再决定滚动内容要预留多少。