★ FEATURED ARTICLE 很多刚接触Android自动化的朋友第一反应是去研究无障碍服务或者装一个“按键精灵”类的录屏回放工具。我最近几个项目里反而一直在用Open-AutoGLM来做Android设备上的自动操作底层执行统一走ADB输入文字用ADB键盘控制这套组合跑了几周稳定性比我想象中好不少。如果你也想让自己的Android设备自动完成签到、打卡、批量操作演示或者做一台24小时无人值守的测试机这篇文章就是我这次实战的完整复盘包括环境搭建、ADB键盘配置、自动化任务落地以及几个不太容易搜到答案的坑。1. Open-AutoGLM到底在解决什么问题把“手机自动化”从脚本升级成“看得懂的自动化”1.1 先拆解一下这套组合里的三个角色Open-AutoGLM从名字上看是一个把大模型理解能力对接到Android设备操作上的开源自动化框架。它和传统“坐标点击脚本”最大的区别在于脚本是死记硬背的屏幕上按钮位置一变化就废而Open-AutoGLM是“看”屏幕内容的它先拿到当前界面的信息理解任务目标再决定下一步点哪里、输入什么、要不要滑动返回。在我实际使用的这个版本里整套体系的角色分工非常清晰感知层负责看。通过ADB截图和UI层级导出拿到“屏幕上现在有什么”决策层负责想。把截图和任务描述一起交给多模态模型模型输出类似“点击界面中央的签到按钮”的动作执行层负责动手。把模型输出的动作翻译成一条条ADB命令包括模拟点击、滑动、按键以及调用ADB键盘完成文字输入。所以你看到的实际效果是手机像有了个“遥控手”并且这个手长了个会分析界面的大脑。传统脚本是“如果坐标等于(500, 1200)就点击”Open-AutoGLM是“检测到页面顶部有一个写着签到的按钮那就点它”。后者明显更适合真实设备环境因为真实App里每个界面的元素位置都会因为屏幕尺寸、分辨率、系统导航方式而变。1.2 和其他自动化方案的横向对比为了把Open-AutoGLM这套组合放在合适的位置我当时特意把主流方案都列了一下方案识别方式稳定性权限要求适合场景无障碍服务读取界面节点中经常受App定制控件影响需要开启无障碍服务单机轻度自动化坐标点击脚本写死像素坐标低换机型或换分辨率就废几乎无录屏回放、临时演示Appium等测试框架通过UiAutomator/XCUITest驱动高但配置重需要调试授权自动化测试团队Open-AutoGLM ADB图像UI层级模型决策高且能适应界面变化ADB授权 输入法切换无人值守的智能操作这里不是说无障碍服务没有价值而是它在应对复杂弹窗、界面改版、以及需要输入中文的场景时容易因为“拿不到目标控件”而中断。Open-AutoGLM和ADB的组合把“看”和“做”拆开了感知可以选截图、选UI层级实在不行还能做模板匹配执行则全部落到ADB这一条稳定的通道上不用管App内部怎么实现控件。1.3 为什么最终选择了ADB作为执行通道开发者选项里的ADB通道本质上是Android系统在系统级提供给外部调试、控制的接口。它的优势在于“权限层级高”很多无障碍服务碰不到的输入框、被App自定义View拦截的点击事件ADB通过input命令和输入法广播都能触达。另一个关键点是ADB不依赖某个App进程即使目标App崩溃或页面卡死ADB通道还活着你可以继续发送返回键、杀掉进程、重启App。这一点对于自动化来说太重要了。我见过太多脚本因为目标App白屏、弹窗遮挡就把整套流程卡死最后只能人工介入。换成ADB做执行层之后至少你有能力在每一轮操作前后做“体检”发现不对就按返回键、关掉弹窗、重新拉起目标页面。这也是我后来把所有自动化任务都收敛到Open-AutoGLM ADB这套架构上的根本原因。2. 环境搭建ADB安装、连接授权与两种远程调试方式2.1 ADB的安装不同平台的区别和常见坑ADB本身不用编译直接用官方Platform Tools就行。macOS用户最省事的方式是brew install android-platform-toolsWindows用户一般从Android开发者官网下载Platform Tools压缩包解压后把platform-tools目录加进PATH。这里有个很常见的坑解压完直接打开cmd输入adb提示“不是内部或外部命令”就是因为没加环境变量。另外Windows下还需要装好对应手机品牌的USB驱动否则设备管理器里只会显示一个带黄色感叹号的“Android Composite ADB Interface”。Linux用户需要注意发行版差异sudo apt install android-tools-adb # Ubuntu/Debian sudo pacman -S android-tools # Arch装完以后用adb version确认即可。紧接着把手机开发者选项里的“USB调试”打开插上数据线第一次会弹出RSA密钥确认框勾选“始终允许使用这台计算机进行调试”然后保持手机亮屏。我实际测试中还遇到过一种情况有些朋友手机连电脑出现device offline反复拔插也不行。这种时候一个通用咒语是adb kill-server adb start-server adb devicesADB服务端偶尔会进入一种“以为设备还在但设备已经断开”的状态杀掉重启通常能恢复正常。还有一种情况是电脑上跑着某些手机助手类软件占用了ADB端口也会导致设备识别异常建议做自动化之前把这些软件全部退掉。2.2 连接授权不通过unauthorized状态的完整排查热搜词里“adb unauthorized怎么解决”出现频率很高这确实是新手最容易卡住的一环。当你执行adb devices看到这行输出List of devices attached XXXXXXXXXXX unauthorized完整的排查链路应该是这样的先看手机屏幕上有没有弹RSA授权框。如果弹了但点了拒绝后续就不会再弹。解决方法是到“开发者选项”里点“撤销USB调试授权”然后拔线重插重新弹窗授权如果屏幕上没弹窗检查是否勾选了“始终允许使用这台计算机进行调试”没勾选的话授权框只弹一次取消后就看不到部分国产定制系统我手上遇到的就有MIUI、ColorOS系在“USB调试”之外还单独有一个“USB安装”或“USB调试安全设置”选项不打开的话连接是unauthorized或offline这一步经常被忽略最后再考虑ADB服务端问题执行一次adb kill-server后重新连接。顺便做一张表帮大家对照常见的连接状态含义排查时一眼就能定位adb devices输出含义常见处理device正常连接可执行命令无unauthorized手机端未授权这台电脑重新弹窗授权offline设备曾经连过但现在通信异常重插/重启adb serverno permissions多为Linux下udev规则问题配置/etc/udev/rules.d/51-android.rules或换root权限重试排查这部分不要东一榔头西一棒子按这个顺序走一遍绝大多数unauthorized都能解决。我当时光是这个问题就在一台备用机上折腾了半小时最后发现其实是系统UI隐藏了授权弹窗直接进“撤销授权”再重插就搞定了。2.3 无线调试与无电脑场景的替代方案做Open-AutoGLM自动化任务时我强烈建议用无线方式连接不然测试过程中手机稍微动一下USB线连接就断了脚本全废。Android 11以上自带无线调试操作路径是开发者选项里打开“无线调试”点开详情记下配对用的IP和端口电脑上执行配对命令adb pair ip:port 配对码配对成功后在“无线调试”界面看到已分配IP和端口执行adb connect ip:port之后只要手机和电脑在同一个局域网内连接就一直保持。adbd本身会在后台运行不用每次都插线。那完全没有电脑的场景怎么办我在折腾过程中试过一条路手机网页连接ADB。像WebADB这类工具可以在手机浏览器里直接打开一个页面配合USB OTG转接线接到另一台Android设备网页上就能跑ADB命令。这在来回路程中排查设备问题时很实用尤其是Open-AutoGLM已经部署到目标手机上、手边没有PC的情况。另外还有“甲壳虫ADB助手”这类手机端App可以图形化地管理已连接的设备查看当前Activity、模拟点击、查看屏幕截图相当于把ADB调试器搬进了手机。如果你准备把自动化任务长时间跑下去无线调试几乎是必选项。记住一个小细节手机息屏后无线调试可能休眠建议在开发者选项里保持“屏幕常亮”的条件充电或者最低限度关掉自动锁屏。3. ADB键盘控制为什么需要它以及如何正确配置3.1 ADB原生输入命令的局限ADB本身有一个文本输入命令adb shell input text hello但这玩意的限制非常明显只能输入英文字符和数字中文、特殊符号基本无能为力。另一个更麻烦的问题是input text把文本直接发给当前获得焦点的控件如果目标App的输入框是自绘控件、或者页面还没完成加载你会看到内容输进去了却什么都没发生。为什么ADB键盘能绕开这些问题因为它的底层机制完全不一样ADB Keyboard本质是一个输入法IME你把它设成当前输入法之后App只知道自己调用了一个系统输入法来接收按键事件并不知道背后是ADB在发指令。这个思路有点像“伪装成你的打字手指”——系统层面认可它是输入法App层面看到的就是正常的键盘输入。所以无论是中文输入框、搜索栏还是自绘控件里的输入区域ADB键盘都能稳定地把字符逐个送进去。3.2 ADB Keyboard的安装、启用与验证ADB Keyboard的安装包在网上很容易找到一般叫ADBKeyboard.apk或AdbIME.apk。安装过程非常简单adb install -r ADBKeyboard.apk然后把它设为当前输入法adb shell ime enable com.android.adbkeyboard/.AdbIME adb shell ime set com.android.adbkeyboard/.AdbIMEime enable是让系统认识这个输入法ime set是真正把它切到前台。这里有个容易忽略的点某些定制ROM会要求在“开发者选项”里打开“USB调试安全设置”或“模拟点击”相关权限否则键盘虽然切换成功但广播发过去没有效果。配置完成后需要做一次实测。在目标App里点开一个输入框然后电脑上执行adb shell am broadcast -a ADB_INPUT_TEXT --es msg 自动输入测试手机上如果立刻出现“自动输入测试”这几个字说明链路已经通了。注意广播内容里的特殊字符如果包含换行或双引号建议先用ASCII码方式处理或者退而求其次用ADB_INPUT_KEYCODE发送按键。实测下来中英文混输都没问题个别设备上偶发字符丢失重发一次就好。3.3 从键盘输入到模拟按键一条可直接复制的链路ADB键盘不止能输入文字还能模拟按键事件。先看一段我在项目里实际用过的最小链路打开一个便签App写入一条文字然后返回桌面。把这套逻辑整理成shell脚本就是这样echo 启动便签App adb shell am start -n com.example.notepad/.MainActivity sleep 2 echo 切换到ADB键盘确保输入可用 adb shell ime set com.android.adbkeyboard/.AdbIME echo 输入文字 adb shell am broadcast -a ADB_INPUT_TEXT --es msg Open-AutoGLM 自动测试记录 echo 稍等片刻按Home返回桌面 sleep 1 adb shell input keyevent KEYCODE_HOME这里am start -n后面的包名和Activity名要换成本机目标应用的。Activity名可以通过adb shell dumpsys package 包名 | grep -A 1 android.intent.action.MAIN查到或者用adb shell monkey -p 包名 -c android.intent.category.LAUNCHER 1打开首页后执行adb shell dumpsys window | grep mCurrentFocus看当前焦点窗口。这套链路虽然简单但把ADB键盘、模拟按键、进程管理三个能力串起来了。后面Open-AutoGLM每执行一个动作本质上就是在不断重复和组合这类原子操作找元素、点按钮、输文字、返回到指定状态。4. 让Open-AutoGLM真正跑起来一次完成自动签到实战4.1 任务拆解从“签到”到可执行的步骤序列我拿自动签到来举例是因为它足够典型要打开App、等待加载、定位按钮、点击、处理结果弹窗。如果这些步骤能稳定跑通其他自动化任务基本都是同一套逻辑换个皮肤。先把任务拆成以下步骤检查设备连接状态确保ADB在线启动目标App等待首页出现获取当前界面UI信息定位“签到”按钮坐标执行点击检查是否出现签到成功或者弹窗如果弹窗则关闭截图存档记录任务结果。这里要特别强调一点不要用固定sleep来等待页面加载尤其是网络不好的时候固定等待不是等“出现”而是在赌“一定够”。更可靠的做法是循环检测每0.5秒截一次图或导出一次UI层级直到目标元素出现再继续。Open-AutoGLM的循环决策机制正好能覆盖这一点它会在每一步结束后重新感知当前界面再决定下一步动作。4.2 初始化Open-AutoGLM模型接入、工具注册和权限准备不同发行版的Open-AutoGLM可能会有配置文件差异我这里给出的是我实际用下来比较顺的一套初始化思路。它通常需要配置设备、模型、工具集和任务目标四块device: 127.0.0.1:5555 # 无线调试地址也可以直接写USB序列号 model: provider: openai-compatible model: glm-4.5v # 换成你实际可用的多模态模型 tools: - adb_tap - adb_keyboard_input - uiautomator_dump - screencap task: 打开社区App找到签到按钮并完成签到记录截图 timeout: 120工具注册是这套体系里非常关键的抽象每个能力对应一个工具函数比如adb_tap接收一个坐标参数执行adb shell input tap x yadb_keyboard_input接收一段文本发送ADB键盘广播。Open-AutoGLM要做的就是根据模型决策在工具池里挑出合适的那个来调用。启动的时候还有个权限准备步骤容易被忽略。第一是确认ADB授权状态第二是确保ADB Keyboard已经是当前输入法第三是允许目标App的必要权限比如存储、悬浮窗否则模型明明识别出了“允许”按钮点下去却被系统权限页挡了一道。4.3 运行与观测用截图、日志和UI状态监视每一步自动化跑起来之后如果看不到过程出了问题就只能从头再来。我在项目里养成了一个习惯给每个步骤都留观测点。日志观测最简单直接过滤Open-AutoGLM的输出adb logcat -s OpenAutoGLM:D *:S比纯看日志更有效的是截图证据链。Open-AutoGLM每执行一个动作我就把当前屏幕截一张图存档后续回溯是“模型看错了界面”还是“ADB命令没生效”一眼就能分辨。这里一个小技巧是用exec-out替代shell screencap输出更干净adb exec-out screencap -p step_001.png配合一个简单的循环可以把整个自动化过程变成一组连续截图相当于给任务录了个无声视频。真出问题的时候按时间线翻截图比读一千行日志快得多。4.4 失败恢复脚本挂掉之后如何自愈无人值守场景下最怕的不是任务跑得慢而是任务挂掉没人管。我实践中会做三层防护。第一层是任务级别在Open-AutoGLM配置里设置超时超过时间就放弃当前分支回到任务起点状态。有时候是目标App更新导致签到入口变了模型反复找不到目标元素此时与其无限重试不如直接放弃、写日志待查。第二层是设备级别每次任务开始前先做一次“前置体检”检查包名是否存在adb shell pm list packages | grep com.example.app如果包不见了说明App被卸载或账号异常直接拉停任务。还可以用pm uninstall --user 0 包名这种方式把应用状态重置为出厂状态但这条命令要慎用它会卸载当前用户的App数据。第三层是系统级别把任务丢进nohup后台跑并在脚本里内置“看门狗”每隔5分钟检查一次任务进程是否还在不在就重新拉起。这样即使模型服务偶尔崩溃整套任务还能自动恢复执行。我用了一个最简单的守护循环while true; do if ! pgrep -f open_autoglm_task /dev/null; then nohup python open_autoglm_task.py run.log 21 fi sleep 300 done把这几层做好之后我连续跑过一整个周末的自动测试任务中途出现过一次页面加载超时设备级防护自动把App重启并回到了任务起点后面流程顺利完成。5. 实测踩坑记录从输入框失灵到数据目录权限墙5.1 操作不响应时的排查顺序先看状态再看路径自动化跑着跑着突然“失灵”最常见的是以下几种情况屏幕灭了或者锁屏了ADB命令还在发但点不到任何东西弹窗盖住了目标元素模型还傻傻点击原来坐标ADB键盘的焦点丢了文字输入发到之前那个页面上无线连接断开所有命令报device offline。我的经验是排查时一定按顺序来先确认连接状态adb devices再截一张当前屏幕screencap然后去翻任务日志看模型决策输出和实际执行动作之间差在哪里。大多数“不响应”都是环境问题而不是框架问题把环境稳定住自动化马上就活了。这里有个细节值得单独说坐标偏移。不同分辨率的设备上同一个按钮的x和y完全不同。所以不要直接在配置里写死坐标而是通过uiautomator dump导出的UI层级文件动态解析目标控件的bounds属性。Open-AutoGLM底层如果是走图像识别模型会自己估算坐标但如果你自己拼脚本一定要走UI层级解析adb shell uiautomator dump --compressed /sdcard/ui.xml adb pull /sdcard/ui.xml然后从ui.xml里找到文本内容为“签到”的节点提取它的bounds再取其中心点作为点击坐标。这样换机型、换分辨率都不怕。5.2 Android 11的数据目录限制为什么你读不到App的缓存文件我这次实战里遇到的一个硬骨头是访问目标App私有数据目录被拒绝。现象是执行命令读取应用缓存时报错比如unable to chmod /storage/emulated/0/Android/data/xxx: Operation not permitted这句话翻译过来就是“操作不被允许”。从Android 11开始系统对/storage/emulated/0/Android/data/下的目录做了强管控普通应用包括ADB shell的默认权限不再允许随便看其他应用的数据目录。我遇到过想清理某游戏的缓存目录、想读取某个测试App生成的日志文件结果全部撞上这面权限墙。有价值的解决方案有三条如果目标App是debuggable的可以用run-as以应用身份访问它自己的私有目录adb shell run-as com.example.app ls files有些App的数据目录可通过“设置 应用 存储与缓存”导出到公共目录但自动化场景下基本不可行如果设备已root那就用root权限直接绕开限制但这属于另一个话题了。我在实际项目里的做法是尽量让目标App自己把日志写到外部公共目录比如/sdcard/Download/或者通过ADB键盘在App内部手动触发导出功能。能不改系统就不改系统这样整套自动化方案的可移植性才高。5.3 弹窗打断、屏幕休眠和版本变化的三个意外最后分享几个只有真实跑才能碰到的意外。权限弹窗是最老套但也最常见的打断方式。App首次启动会问通知权限、位置权限、悬浮窗权限每个弹窗都会让模型识别到的目标界面完全变样。对策是在任务开始前把所有能预授权的权限都先手工授予一遍自动化跑的时候提前用appops或系统设置关闭不需要的系统级通知。屏幕休眠问题我也提过像svc power stayon true这种一条命令就能解决调试期间灭屏导致的自动化中断我建议写在任务启动脚本第一行adb shell svc power stayon true还有一个容易被忽略的是App版本更新的问题。上周还好好的“签到”按钮这个周版本更新后文案变成了“立即签到”模型如果依赖文本识别就可能找不到。这就要靠Open-AutoGLM的多模态能力了纯文本dump找不到就靠截图识别截图识别不到就靠模板匹配。我实际测下来处理界面改版最好的策略不是试图一次识别对而是让任务支持“代处理”发现目标元素后先保存当前截图到异常文件夹同时尝试多种定位方式文本、UI节点、图标相似度为后续人工审核留证据。这些坑零零碎碎但很多都是不看日志就想破头也发现不了的。把每一条记录下来下次遇到同样问题十分钟内就能解决。我自己跑下来最大的感受是Open-AutoGLM这类框架的核心价值不在“能执行ADB命令”而在于把模型对界面的理解能力和ADB这种底层控制通道真正拧成了一股绳。方案本身不难搭难的是在各种真实设备上都跑得稳。最后分享一个实用小技巧在每天任务启动前先发一个Home键回到桌面再关闭所有后台应用通知然后才开始执行。这个动作看起来不起眼却能替你挡掉一大半因为弹窗、页面错位导致的自动化失败。
阅读完成 · 觉得有帮助？
