有时候移动端自动化脚本失败，但 App 页面并没有明显变化。

问题可能出在 Android 权限。媒体访问、通知、存储、相机、麦克风、定位或无障碍权限，都可能在 App 更新、系统变化、重装或账号初始化后出现变化。如果脚本依赖这些权限，流程就会停住。

先给一个简单答案

Android 权限重置导致自动化失败时，先检查目标 App 是否仍然拥有媒体、通知、存储、相机、麦克风、定位和无障碍权限。还要确认权限弹窗是不是只出现在部分云手机上。最好的预防方式，是在主任务前增加权限 readiness check。

权限为什么会卡住流程

移动端脚本经常默认 App 已经可以做某些事：

  • 打开媒体选择器；
  • 上传文件；
  • 发送通知；
  • 使用相机；
  • 读取存储；
  • 执行无障碍动作；
  • 打开基于位置的页面。

如果权限缺失，脚本可能一直等待、点错按钮，或者停在系统权限弹窗。

为什么只影响部分手机

权限问题很容易让人困惑，因为它不一定影响所有云手机。

一台设备可能之前配置过，另一台是新安装；一个账号可能点过授权，另一个没有；App 更新可能只重置某一路权限。

所以权限检查应该成为流程的一部分，而不是一次性配置。

一个实用权限清单

运行主任务前先看：

  • App 是否安装并至少打开过一次；
  • 所需权限是否开启；
  • 是否出现新的权限弹窗；
  • 如果脚本依赖无障碍，权限是否可用；
  • 媒体上传入口是否能正常打开；
  • 通知权限是否影响当前流程；
  • 测试组里的权限状态是否一致。

这能提前拦住很多失败。

AI 能帮什么

AI 可以帮助判断失败是不是权限相关，而不是脚本本身坏了。

比如脚本停在媒体选择前，AI 可以对比预期页面和实际权限弹窗，建议增加预检查，或者把该设备放进设置队列。

但 AI 不应该盲目批准所有系统权限。部分权限比较敏感，应该遵循团队策略。

QCCBot 适合放在哪

QCCBot 可以帮助团队在 Android 云手机上运行 readiness check，用 xeasy code AI 生成 AutoJS 风格脚本，并在流程失败时查看日志。权限失败可以先被分类和处理，再进入活动批量运行。

如果权限问题经常导致移动端流程失败，QCCBot 可以帮助构建云手机检查流程，在 Android App 自动化扩量前发现缺失权限。

常见问题

这是脚本 bug 吗？

不一定。如果 App 被 Android 权限弹窗挡住，可能是环境没准备好，而不是脚本逻辑错。

脚本应该自动授权权限吗？

只有团队明确批准并理解风险时才适合。部分权限应该人工审核。

最好的预防方式是什么？

在主任务前先跑权限 readiness check。