装上了却没打开：monkey 的退出码陷阱与 am start -W -n 拉起机制

改包这件事，最让人泄气的一刻不是"打包失败"——失败至少会报错，你知道下一步该查哪。真正让人泄气的是"打包成功、安装成功、流程提示全部绿了"，抬头一看模拟器却还停在桌面，什么也没发生。你去翻日志，日志也写着成功。这种"假成功"比真失败更难查，因为它把问题藏在了回执的措辞里。

这篇文章只讲一个环节：打包完成之后，程序怎么把刚装好的应用拉起来。这是智改工坊"打包后自动运行"功能里的最后一段链路，也是踩坑最多的一段。它牵涉三件事——拉起命令选谁、要拉起的组件名从哪来、以及凭什么说"真的起来了"。把这三件事讲透，你就能明白为什么我们宁愿多写几层判断，也不肯用一个"看起来更省事"的老办法。

一、装上了、没打开：一次典型的"成功失败"

先把场景还原一下。你在智改工坊里对一个自家应用的安装包提了一句需求，点了「立刻修改」，AI 改完在项目目录留了标志文件，主窗口每 2 秒轮询一次、读到就自动弹出打包窗口，打包四步依次跑完：回编（apktool b）、对齐（zipalign -p 4）、签名（apksigner + testkey）、校验（apksigner verify）。四步全绿，产物落在项目的 build 目录下，unsigned.apk / aligned.apk / signed.apk 一应俱全，pack.log 里一条条都记着。

接着勾了"打包后自动运行"。程序用 adb 找设备、装包，屏幕上跳出"已安装到 127.0.0.1:7555"，也会跳一句"已在设备上打开应用"。可你盯着模拟器窗口看了三秒，桌面还是桌面，图标都没动一下。你把这句话读了两遍——"已在设备上打开应用"——然后开始怀疑自己是不是看错了设备。

这类问题的可怕之处在于：它不会报错。安装是真的成功了，拉起命令也是真的执行了，只是执行的那条命令根本没有能力打开应用——而它的失败方式，恰好是"静默"。

旧版本的实现用的是很多教程里都会推荐的一招：adb shell monkey -p 包名 -c android.intent.category.LAUNCHER 1。它的思路是"让 Monkey 发一个启动类 Intent 出去"，在很长一段时间里确实好使。问题在于它的时代背景变了：这句话能成立的前提是设备上得有 monkey 这个命令，而且失败时会被如实报出来。在新版安卓镜像里，这两个前提都不成立了。

在换掉它之前，我们试过一堆"绕过去"的办法，这里如实记一笔，也许你正在走同样的弯路。第一种是给 monkey 加各种参数、换 category，想让它别走那条不存在的路径——没用，因为问题不在参数，在命令本身。第二种是改看日志：把 adb 的输出整段保存下来人工比对，结果是"每次都得盯着看"，自动化名存实亡。第三种是干脆跳过拉起、只在界面上提示"请手动点开应用"——最省事，但也把"打包后自动运行"这个功能的意义抹掉了一半。真正把问题解决的，是换一条根本不依赖 monkey 的命令。

二、monkey 为什么会被弃用：命令不在了，退出码却还是 0

monkey 是安卓自带的压力测试工具，本意是往应用里灌随机事件看它稳不稳。"用 monkey 打开应用"其实是顺手借用——因为 monkey 需要一个目标包名，而它发出去的第一个事件往往就是启动 Activity。这个借用很聪明，但它依赖一个正在消失的组件。

实测中，在雷电那套 Android 12 镜像上执行 monkey 拉起，设备回的是这样一句：

/system/bin/sh: monkey: inaccessible or not found

注意这句话的措辞：不是"monkey 执行失败"，而是"找不到 monkey"。也就是说，设备上压根没有这个命令了。厂商在裁剪系统镜像时把这类调试/测试工具剔了出去，这在模拟器镜像和部分定制 ROM 上越来越常见。

真正要命的是第二层：这种失败发生时，进程退出码依然是 0。原因是执行链是"shell 去启动 monkey"——shell 本身跑得好好的，它只是找不到那个可执行文件，于是把错误信息写到 stderr，然后就正常退出了。退出码反映的是"shell 有没有把事情办完"，而不是"monkey 有没有把应用拉起来"。所以只要你的判据是"退出码为 0 就算成功"，这条链路上就一定会出现假成功。

把三代"拉起应用"的做法放在一起对比，这件事的演进脉络就清楚了：

做法	典型命令	优点	软肋
人工点图标	无命令	最可靠，眼见为实	没法自动化，改一版点一次
monkey 发 Intent	monkey -p 包名 -c ...LAUNCHER 1	不用知道组件名，老设备上长期可用	新镜像里没有这个命令；失败退出码仍为 0，会静默假成功
am start 精确指定	am start -W -n 包名/Activity	系统自带、不会被裁；结果有语义可判读	必须知道启动组件名——用三档查找解决

怎么选？如果把"可靠性"和"通用性"当成一根轴的两端，monkey 站在通用那一端（不用知道组件名），am start 站在可靠那一端（结果明确但需要名字）。我们最终选择用 am start 当主力，其实是接受了"必须先把组件名找出来"这个额外成本——因为这件事的成本是可以一次性付清的（导入时 aapt 解析一次、必要时问设备一次），而 monkey 带来的不确定性是每次都要付的利息。

反过来说，这也解释了为什么 monkey 没有被彻底删掉，而是留作第三档兜底：在一些老设备上它还在，而且那些设备的 am 输出结构比较旧，用它兜一下比直接放弃更友好。工程上这种"保留旧路径但降权"的处理，比"一刀切删掉"更实际。

所以智改工坊的做法是：把 monkey 从"主力"降级为"兜底"，只在最末一档才会用到它；而且即便用到它，也不是看退出码，而是看输出里有没有 inaccessible or not found 这类字样——一旦看到，就直接判定失败，并给出一句人话的解释："设备上既问不到启动入口，也没有 monkey 可用，只能手动点开应用。"

顺便说一个同源的坑：adb install 也是一样的道理。它的输出里，"Performing Streamed Install" 这一行永远先出现，真正的原因写在后面带 Failure [INSTALL_FAILED_xxx] 的那一行。曾经有一版实现取的是"最后一行非空内容"，结果提示就变成了"装不上：Performing Streamed Install"——报错报了个寂寞。现在改成专门去找 Failure 行，找不到才退回最后一行。同一个教训：回执的第一行和最后一行都不一定是答案，要按语义去找。

三、am start -W -n：一条"会回话"的拉起命令

既然要找一条"本身带结果语义"的命令，答案就落到了 ActivityManager 的命令行入口上。智改工坊现在用的这一条是：

adb -s <设备号> shell am start -W -n 包名/Activity

逐段拆开看，每个参数都有明确目的：

• am start：启动一个 Activity。它是系统服务自己的命令行接口，只要有 adb 就有它——不存在"被镜像裁掉"的风险，这是它比 monkey 稳的根本原因。
• -n：直接指定组件（n 是 component name 的意思），也就是"包名/Activity"这种精确写法。相比"发一个 Intent 让系统去猜"，精确指定不会有解析歧义：指向哪个 Activity 就是哪个，成功失败一目了然。代价是——你必须知道那个 Activity 叫什么，这就引出了下一章的"三档查找"。
• -W：Wait，等启动完成再返回。加上它之后，命令会给出一段带 Status:、LaunchState:、TotalTime、WaitTime 的结果汇报。这是"命令会回话"的关键：它不只告诉你"我发出去了一条请求"，还会告诉你"这条请求的结果是什么"。

为什么不用"发一个 MAIN / LAUNCHER 的 Intent"那种写法

am start 还有另一种用法：不写 -n，而是写"动作 + 类别 + 包名"，也就是 am start -a android.intent.action.MAIN -c android.intent.category.LAUNCHER -p 包名。这条命令的语义和 monkey 更接近——把"找入口"这件事交给系统的 Intent 解析。看上去更通用，但我们没有选它。

原因在于"不确定性该放在哪一段"。用 -a/-c/-p 的写法，是把不确定性留到了执行阶段：如果这个包声明了多个 LAUNCHER 入口（这在多入口应用、渠道包、插件化壳子里并不罕见），系统挑哪个由解析规则决定，你只能接受结果，连"为什么是它"都不容易说清。而 -n 的写法是把不确定性提前到了查找阶段——三档查找有明确的优先级、有回退、有日志，每一步都能复述出来。同样是不确定，一个摆在明处、一个藏在暗处，长期维护的成本完全不同。

顺带说一句工程上的细节：这条命令的超时给的是 30 秒，比 adb devices -l（20 秒）宽，但比装包（3 分钟）窄得多。原因很直接：装包要写盘、要校验、要合并——慢是正常的；拉起应用是内存里的事，30 秒还没回话基本就是"卡住了"，早点报错比死等有用。

这一步为什么被放进打包流程里，而不是单独做成一个按钮

从界面设计上说，把"装到设备"和"打开应用"做成两个按钮，看起来职责更清楚。但真实使用里，这两件事几乎总是连在一起发生的：装完不看，等于没装。所以智改工坊把它们合成了一条流水线——打包含四步（回编 → 对齐 → 签名 → 校验），勾上"打包后自动运行"之后，流程会继续往下走：找设备 → 装包 → 拉起 → 手机走 scrcpy 投屏、模拟器把窗口提到最前面。

这条链路上有几个细节值得注意。第一，装不上不影响"包已经打好"：设备相关的步骤即使失败，也只标成跳过或失败，产物照样在 build 目录里，你随时可以「保存 APK」或「打开所在文件夹」。第二，装包本身也做了分档重试：常规覆盖安装用 install -r；如果设备上已经装了更高版本、报 VERSION_DOWNGRADE，就加 -d 允许降级覆盖（数据保留）；如果这个包是 testOnly，就加 -t。第三，如果报的是"签名不一样"，那是真的装不上，程序会把设备号记下来弹窗问你——卸载会清掉那个应用的数据，所以这一步必须由你点头，程序不替你决定。

还有一处容易被忽略的体验设计：打包过程中窗口不给关。这不只是"防误操作"，更是因为拉起这一步在流程末端——如果用户以为"跑完了"就把窗口关掉，恰好会错过拉到设备上的那几秒。等到流程走完，界面会明确列出每一步的结果，包括"已在设备上打开应用"或"（已安装，但没能自动打开应用：……）"。

四、组件名从哪来：三档查找与 resolve-activity 的解析细节

-n 要求精确，精确就要求"知道"。一个包里可能有十几个 Activity，哪个才是启动页？智改工坊按三档来找，从最准的往最兜底的排：

1. 第一档：项目自己的记录。导入 APK 时会用工作目录里的 aapt 解析包信息，其中 launchable-activity: 这一行就是启动页组件名，解析出来写进项目 config.ini 的 LaunchableActivity 字段。这是最准的一档：它来自"这个包自己声明的启动入口"，不需要跟设备商量，也不用联网。
2. 第二档：问设备。如果项目记录里没有（比如某些包 aapt 解析不出启动页，或者项目是从 jar / class 这类文件建起来的），就执行 adb shell cmd package resolve-activity --brief 包名。Android 7 以上都有这条命令，它会告诉你"这个包默认的启动组件是谁"。
3. 第三档：monkey 兜底。两档都拿不到才退回 monkey——就是上一章说的那条，只在老设备上还可能有效，属于"聊胜于无"的兼容路径。

这里有一个很容易写错的细节，值得单独拎出来讲：resolve-activity 的输出不能整段当答案。它的回报是几行结构化文本，形如属性行加结果行：

priority=0 preferredOrder=0 match=0x108000 ... isDefault=false
com.yourcorp.demo/yourcorp.demo.view.base.WelcomeActivity

所以解析规则是"从后往前找第一行满足三个条件的"：没有空格、带斜杠、且包含包名。这三条同时满足，才说明它是"包名/组件"的答案，而不是上面那串属性。这段判断看起来啰嗦，但它挡住的是"把一个属性行当组件名，然后 am start 报 Error"的低级故障——而这种故障在自动化里是会一路静默下去的。

还有一个拼接规则：项目里记的启动页可能是完整组件名（自己带斜杠，例如 包名/Activity），也可能只有 Activity。实现里做了统一：只要记录里已经含斜杠就原样使用；不含斜杠才用"包名 + / + Activity"拼起来。原因是不同来源的写法不一致——aapt 读出来的一般是全名，而老项目/手工改过的 config.ini 里可能只写后半段。拼错一次，am start 就会回你一句 Error: Activity class {...} does not exist。

再补一句第一档的来源细节：aapt 报出的 launchable-activity 来自清单里 android.intent.action.MAIN + android.intent.category.LAUNCHER 这一组声明——也就是"这个包自己承认的启动入口"。它和"我们猜哪个 Activity 像首页"是两回事：前者是清单里的声明，后者是阅读代码得出的猜测。这也是"项目里记一份"的价值所在：导入那一刻的这份记录，是整条链路上唯一不依赖设备状态的信息源，设备换了、系统升级了，它都不变。

五、怎么确认"真的起来了"：三层判据与四条使用技巧

命令发出去了、也回话了，接下来就是判读。这一段的实现逻辑是按顺序扫输出，先判失败、再判成功、最后给老设备留一条宽容路径。

第一步，先抓明确的失败信号。输出里只要出现这几类字样之一，直接判失败，并把那一行原文带回去给用户看：Error: 开头、含 Exception、含 does not exist、含 Permission Denial、含 unable to resolve、含 not found。为什么先抓失败？因为"报错里恰好包含成功字样"是存在的（比如某些机型的中文提示），而反过来很少见——先判负、再判正，是更稳的顺序。

第二步，看 Status: 行。-W 模式下设备会回一行 Status，内容含 "ok" 才算成功；不含 ok 就原样回给用户——"启动失败：设备回了「Status: xxx」"。这样用户看到的不是一句笼统的"启动失败"，而是设备的原话，拿去搜索也能搜到东西。

第三步，老设备宽容。老设备上的 am 可能没有 -W 这套输出结构。这种情况下，只要没看到上面那些失败字样，就先当作起来了——但不算完，后面还有一道独立的前台复核兜底（就是你会在下一篇文章里看到的 dumpsys 检查）。这是很典型的工程取舍：判据可以宽容，但必须有第二道独立判据兜住，否则宽容就变成了放任。

判读逻辑说完了，下面是四条可以直接拿去用的技巧：

把这几条判据搬进你自己的脚本里

如果你平时也在写自己的装机脚本，这套判据是可以直接照搬的。把思路写成伪代码，大致是下面这几步——注意每一步的顺序都不是随意的：

1) 装包：跑 adb install -r，先找带 INSTALL_FAILED / Failure 的那一行
        —— 不是取最后一行，因为 "Performing Streamed Install" 永远是第一行
2) 取组件名：先读项目里记下的启动组件；没有再问设备
        —— 问设备要 cmd package resolve-activity --brief，从后往前挑"无空格、带 /、含包名"的那行
3) 拉起：adb shell am start -W -n 包名/Activity（超时 30 秒）
4) 判读：先扫 Error / Exception / does not exist / Permission Denial /
        unable to resolve / not found —— 命中即失败，并把原话带回
        再看 Status: 行是否含 ok
5) 复核：adb shell dumpsys activity activities，看前台是不是它
        —— 第 5 步是独立判据，不依赖第 4 步的结论

为什么第 4 步要"先扫失败、再看成功"？因为成功判据是"某一类行里包含某个词"，而失败判据是一组明确的信号词。假设先判成功，那么一条"看起来成功"的输出可能带着一句被忽略的异常；反过来先扫失败，最坏情况只是把一条宽泛的成功判成失败——而"多说一句怀疑"永远比"假成功"便宜。

为什么第 5 步必须独立？因为第 4 步读的是"命令的自我报告"，第 5 步读的是"系统当前的实际状态"。两者之间隔着好几种可能：命令报告成功但系统把它拦下了、命令报告成功但应用瞬间崩溃退回桌面、命令报告成功但被别的应用抢了前台。任何"自我报告"都可能与实际状态不一致，所以判据必须来自两个互不依赖的信息源——这也是我们把前台复核单独列成一步的原因。

拉起成功之后，为什么还要再看一眼前台

-W 的回报里除了 Status，还有 TotalTime / WaitTime 这类时间字段。它们对普通用户没什么用，但对手感判断很有帮助：冷启动（进程完全没起来）和热启动（进程已在后台）的等待时间能差出好几倍。如果你发现同一个包"有时拉起很快、有时明显卡顿"，多半是这两种状态在切换，而不是你的改法有问题。

但时间字段再全，它回答的仍然只是"系统接受了这条请求并且完成了启动流程"。它没有回答的是："这个应用现在真的在屏幕上吗？"可能的情况有三种：系统接受了请求但把应用拦在了后面（部分定制系统有这样的策略）；应用接收到了启动但进程立刻崩掉、退回桌面；或者启动过程中恰好有别的东西抢了前台。这三种情况在 -W 的回报里都可能看着"没问题"。

所以在这套实现里，拉起之后还有一步独立的复核：去系统的活动记录里看当前最顶端、处于 resumed 状态的那个 Activity 属于哪个包。是目标包，才说明"真的显示出来了"。这一步独立于前面的判读，读的是系统当前状态而不是命令的自我报告。细节我们留到下一篇文章展开——这里只需要记住一个结论：拉起成功只是一半，显示出来才算完成。

几个常见疑问

六、两个自家应用的实操对照

下面两个例子都是我们内部在用的应用，也正好覆盖了"拉起机制"最容易出问题的两种情形：入口没动、入口动了。

七、速查表：am start 的输出怎么读

把上面几章的判据压成一张表。遇到"装上了没打开"的时候，可以照着这张表从上往下对号入座。

你看到的现象	设备回的原文（关键片段）	真正的原因	怎么办
装上了，桌面没反应	monkey: inaccessible or not found	镜像里没有 monkey，且退出码仍为 0	改用 am start -W -n 拉起（本工具已默认如此）
拉起报错	Error: Activity class {...} does not exist	组件名写错，或入口 Activity 已改名	让工具走"问设备"那一档，或核对项目里的 LaunchableActivity
拉起报错	Permission Denial ... not exported	该 Activity 未导出，外部进程拉不起来	确认入口 Activity 是导出的启动页，而不是内部页面
拉起报错	unable to resolve Intent ... not found	包名对不上：设备上根本没有这个包	确认装的是同一个包、同一台设备
命令成功但没到前台	Status: ok，屏幕仍是桌面	被系统拦下或启动后自动退回桌面	用 dumpsys 复核前台（见下一篇），日志会记一笔"已启动但没到前台"
压根连不上设备	adb 报找不到设备 / 没有可用设备	手机没授权，或模拟器没被 adb 连上	手机上点「允许 USB 调试」；模拟器端口连接见第三篇

表格右侧列出来的"怎么办"，绝大部分都可以归结成一句话：先拿到设备的原话，再决定改哪一处。而设备原话在这套工具里是留痕的——每次 adb 调用（列设备、装包、拉起、复核）都会连参数带输出一起写进诊断日志，形如"adb 参数 → 输出"，出问题时顺着时间线往下看，能清楚知道是"没连上设备""装不上"还是"装上了没起来"。这三类问题的处理方向完全不同，先分清类别再动手，比在界面上反复点重试有效得多。

至于日志文件的分工，也值得记一下：吸附与布局自检、预览相关的记录在 dock.log；打包全过程（四步各自的命令与输出）写在项目目录的 pack.log；反编译的输出在 apktool.log；未处理异常单独进 error.log。日常排查"拉起失败"时，pack.log 和 dock.log 是最先该看的两个。它们的位置不必特意去找——程序在「参数设置」里能直接看到工作目录，所有项目与日志都在那下面。

这张表的用法不是"背下来"，而是知道去哪看原话。智改工坊把每次 adb 调用的输出都写进诊断日志，出问题时先看原话，比在界面上反复重试有用得多。

八、用户评价、合规提醒与写在最后

回过头看，"装完自动打开"这个动作很小，但它把整条链路串成了一个闭环：改完就能看到，看到就能判断，判断完就能接着改下一版。这也是安卓修改大师智改工坊想做的事——把改 APK 变成一句话：拖入安装包 → 中文写需求 → AI 改 smali 与资源 → 自动回编 / 对齐 / 签名 / 校验 → 一键装到手机或模拟器看效果。只需说话，就能让应用变成你想要的样子。更多说明见 https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn。下一篇我们把"装完之后的复核"讲透：为什么"命令返回成功"和"应用显示出来"是两回事，以及 dumpsys activity activities 里该看哪一行。