Omni历史31.926%与本轮三条件：录音附件对照
身份相同到什么程度
| 项目 | 历史高覆盖 | 本轮Pure / StartLux / Jev |
|---|---|---|
| Run | run_6fbac6f1f5c740a38f6336c65e9fb5aa |
run_7eb476413bc249f69220d61747889a9b / run_0c300af1c9614168998ce1f37b6aadfe / run_ad46e2ac9d7e407da53250b006f6c382 |
| 设备 | server49:emulator-5560 | 三条相同 |
| seed | 746994860 | 三条相同 |
| Android | 15 / SDK35 Emulator | 相同，boot_id也相同 |
| APK SHA | 90ea98d9efe6d5786dcc706ee4f5f4aa1c6789d568c6f98fbfa616a5f7bfb4b8 |
相同 |
| 实际JAR SHA | c08fdb34321c760112383b9afc2c11360d35f01120259492ea25d39fb95ea370 |
相同 |
| 初始化 | clear_and_launch，初始XML SHA 048f652928eab18f54b2235f41b6a967743e36968a9540fdf012592de8789506 |
初始XML相同 |
| 初始完整权限快照 | NA | NA；不能据初始XML一致推定权限一致 |
| 评价标签 | guitaboo-formal-c161e65-apkwide-60min-v1 |
guitaboo-formal-fixab-apkwide-60min-v1 |
完整原始身份；比较门禁。历史评价标签和本轮不同，通用分析器因此没有把它冒充严格兼容的当前配对；这里单列为历史功能路径参照。历史归档raw结果11680，本次另按其既有严格设备formal-start+[0,3600)窗口观察11654=31.926%，排除26个仅在归档窗口外出现的方法。raw结果保持不变。方法差集用严格11654，历史曲线也另用严格窗口，不混用raw终值。
直接可读的时间线
时间均为设备formal-start后的相对时间。权限授予行自身没有独立wall时间，表中标记“约”的授予时间是同step最近输入时间；权限原始行保留行号和上下文，不把它伪造成精确授予时间。
| 阶段 | 历史31.926% | 本轮Pure28.373% | 本轮SL27.968% | 本轮Jev28.499% |
|---|---|---|---|---|
| 最早可观察分叉 | step43约0:59.476长按笔记后FUZZ，同step有EVENT_START；step44 1:09.520点OK | step43同类FUZZ及EVENT_START；step44 1:09.359点OK | step43 1:00.113开始FUZZ；step44 1:22.556点CANCEL | step43 0:59.673开始FUZZ；step44 1:22.082点CANCEL |
| 早期设置页 | step47 1:13.462在Interface点LinearLayout | step47 1:13.096同样Interface | step47 1:25.914在Behaviors点switch | step47 1:25.555在Behaviors点switch |
| 进一步分叉 | 历史与当前Pure的首个已记录具体MODEL输入差在step165：历史点10，4:05.821 | 同step点1，4:04.160 | 早已不同；到step62返回时首次方法0 | 早已不同；step62首次方法0 |
| 早期录音/权限尝试 | steps160/284/295/371/388出现permissioncontroller启动被拒 | Record372 9:35.981、Record526 12:55.329后权限界面被拒 | Grabar190 5:15.759，315.781秒有startRecording，权限界面被拒；571/620/626仍有拒绝记录 | Grabar190 5:18.260，权限界面被拒 |
| 第一次明确授予记录 | Info Probe439 11:51.500本身失败（activity_start）；恢复同step日志32432–32433显示grant RECORD_AUDIO | 约step664 15:53.712恢复时grant | 约step1286 34:08.748 EVENT_CLEAN_RESTART时grant | 约step1395 38:19.143恢复时grant |
| 授予后的录音 | 普通APE Record521 13:45.732；普通APE Stop528 13:52.783 | Record733 17:26.720调用startRecording；紧随Timestamp734、Video735；没有Stop | 授予后没有再观察到Record/Stop | Record1552 42:04.647、1559 42:11.760；随后Files/Location/Sketch等；没有Stop |
| 附件结果 | Stop后至下一输入1071首次=1033Glide+27业务+11AndroidX；step531长按附件格，精确step532图显示null (84 KB)菜单 |
无录音附件结果证据，Glide=0 | 无录音附件结果证据，Glide=0 | 无录音附件结果证据，Glide=0 |
关键执行片段：历史Record521、历史Stop528及全部1071方法、附件操作531、Pure733、SL190、Jev1552。
图支持存在84 KB附件菜单，与Stop后的处理方法相互印证；不是“听过录音、验证了音频内容”。部分Record前后图只是同State的早期代表图，不用于证明该步录音UI的细节；历史step529截图空白也不能直接当附件已显示。
上次为什么走通，这次没有
已经证实的区别是：历史在较早恢复中记录录音权限授予，后续普通APE执行了Record和Stop，附件处理实际出现；本轮SL在早期拒绝后很晚才恢复授予，之后没有继续点Record；Pure/Jev虽在授予后再次尝试，也没有到Stop和附件处理。这条缺失路径能解释Glide1047→0及一大块附件差集，但不是全部方法净差都属于Glide。
历史严格集合中，本轮Pure没有1392、SL没有1622、Jev没有1439个方法。反向本轮也有历史没有的方法，因此净差不能等同“缺失全部录音方法”。完整签名、类别、首次时间及附近输入见差分和库差分。
两模型从step44即和历史选择不同控件，早于第一个录音动作和Omni清单Probe。这里不是在同一弹窗随意选择了OK或CANCEL：精确step44图显示历史是Settings的版本变更日志弹窗、点击OK；本轮SL已是Behaviors下“What to do when an item is checked?”清单行为选项、点击CANCEL。也就是说，FUZZ后的可见功能页面在step44输入前已经分叉。历史44精确图；本轮SL44精确图。相同seed没有保证相同GUI、FUZZ结果、任务栈和后续输入。当前Pure到step165才出现首个已记录具体MODEL输入差；这是“记录到的输入差”，不保证低层FUZZ事件、设备异步工作和权限时序此前完全相同。
Info439之后，恢复日志确实有grant RECORD_AUDIO；历史Info Probe本身却按activity_start失败。本轮SL Info656是Completed 0 (0%)信息弹窗，首次明确授予仍在1286，而非Info656。不能说Info弹窗授予了权限，也不能说它是录音成功的必要条件。录音请求实际经过权限路径，支持录音依赖权限这一运行事实；但授予权限并不足以解释所有结果，因为本轮Pure/Jev之后仍没Stop。
尚不知道的底层原因：后期Record为何没有留下可停止录音的UI/行为，是媒体服务错误、任务栈、附件配置还是其他情况。缺少完整Android错误logcat、录音底层异常及每次精确UI帧，不能从startRecording方法名自动推断MediaRecorder成功启动，也不能用一个推测给所有Run套相同原因。
Jev另有一条外部任务异常：step192点Video后，step193、5:31.329出现Wikipedia EditHistoryListActivity，实际点击org.wikipedia:id/selectButton；随后EVENT_START重新启动Omni。精确图和executor同时支持这是外部Wikipedia界面，不能算Omni新功能。原图与完整步骤。记录可证明出现和恢复，不能证明为何这个外部任务成为前台。该step的113首次方法还包含Omni恢复启动，不能归给Wikipedia点击。
因此答案是：历史普通APE走完了录音、停止和附件处理，本轮没有；权限恢复时间和早期设置轨迹明显不同，但后期失败的具体底层原因仍缺证据。不能把历史录音覆盖归功于Info Probe，也不能说本轮只是没点Record。