在实际的 Android 真机测试和自动化测试项目里演示机往往是最容易出问题的一台设备。常见的演示机来自厂商展厅、门店演示或项目交付系统里可能带有演示固件、展示循环脚本、访客限制甚至被不同渠道提前开启过各种调试选项。很多开发者在拿到演示机后第一反应是找各种工具把系统限制全部打开认为只有拿到最高权限才能做测试。但在正式开发流程中这个思路需要修正对一台用于回归测试和兼容性验证的演示机最高权限并不是必需品过度提权反而会带来测试失真、安全风险和合规问题。正确做法是先把设备还原到受控状态再通过开发者选项、USB 调试授权和 adb 命令把调试链路打通然后去做设备信息采集、自动化用例执行和日志回传。下面按一条完整链路来介绍先理解演示机在测试体系里的定位再准备 adb 环境完成开发者授权最后通过 adb 采集设备信息并排查连接问题。这套链路不依赖任何提权操作适用于大多数 Android 设备也适用于部分 REDMI 系列等常见演示机。1. 演示机调试之前先分清 root、授权和开发者选项1.1 演示机与普通开发机的用途差异演示机这个词在不同场景里有不同含义。在厂商侧它可能是门店里的展示样机系统里带有演示视频、循环播放脚本和访客限制在项目交付侧它可能是客户提供的验证样机系统版本和普通零售机不完全一致。演示机与普通开发机有几个明显差异系统镜像可能来自定制演示固件开机后自动进入演示循环而不是普通桌面。可能存在桌面锁定、应用安装限制、访客账号限制。部分演示机需要通过系统自带的“退出演示模式”入口才能恢复普通用户模式。不同厂商的演示固件策略不同不能把同一套处理方式套用到所有机型。在测试团队里演示机的正确用途应该是稳定的回归测试设备、性能基线设备或兼容性验证设备。它需要的是可重复、可追踪的运行环境而不是一个被改动过的系统。1.2 为什么 root 属于安全基线而不是常规步骤root 在 Android 里通常指获得 Linux 用户态的超级用户权限。获得这个权限后可以读写更多系统分区、加载内核模块、修改系统应用但代价也很明显系统完整性会被破坏依赖完整性的应用可能不可用。在 root 环境下测出的启动耗时、内存占用、隐私行为可能与普通用户环境不一致测试结果失真。提权工具本身可能携带未知后门对测试网和生产数据造成风险。部分厂商不再提供保修或系统更新。所以在安全基线检查里root 状态应该被检测和审计而不是被主动引入。对测试机团队来说确认设备处于官方未提权状态恰恰是测试环境可信的前提。注意在测试环境里root 状态检查属于安全审计动作不是为了绕过应用保护而是为了确认设备没有被非预期提权。1.3 开发者授权与系统权限是两条不同的链路开发者选项和 USB 调试授权属于 Android 系统提供的标准调试链路。它不需要 root开发者选项系统隐藏的调试开关集合由普通用户开启。USB 调试通过 ADB 协议与主机通信执行安装、日志、信息读取等操作。RSA 密钥授权主机首次连接时设备端弹窗确认是否信任该主机。这套链路允许开发者完成大部分调试操作安装 APK、查看日志、读取设备属性、拉取数据库、投屏截图、运行自动化测试等。也就是说把调试环境准备到位和获取系统最高权限是两条完全不同的技术路线。调试环境可以随时随地重建而提权操作往往会破坏设备初始状态。1.4 本流程的边界说明下面给出的命令都来自官方 platform-tools不包含提权、解锁 Bootloader、绕过防回滚机制等操作。实际项目如果必须更换系统镜像需要先向厂商申请正式固件并走审批流程不要使用来路不明的工具包。无论工具包的名字听起来多方便在正式测试设备上执行未知脚本都等于把设备状态交给不可控的第三方。2. 准备工作安装 platform-tools 并开启开发者选项2.1 环境要求与版本确认建议满足以下条件项目建议要求说明操作系统Windows 10/11、macOS 12、Ubuntu 20.04adb 支持跨平台platform-tools34.0.0 或更高旧版本可能不支持新机型数据线支持 USB 2.0/3.0 数据传输不要使用仅充电线设备系统Android 8.0 及以上低版本授权流程相同但界面不同驱动Windows 需要安装设备厂商 USB 驱动Linux/macOS 一般免驱在终端执行adb version如果提示命令不存在需要先安装。Windows 可以从官方页面下载 platform-tools 压缩包解压后把目录加入 PATHLinux 可以使用系统包管理器macOS 可以通过 Homebrew 安装。# Linux以 Ubuntu/Debian 为例 sudo apt update sudo apt install android-sdk-platform-tools # macOS brew install --cask android-platform-tools安装后重新执行adb version确认输出版本号。这一步是后面所有操作的基础。2.2 在演示机上开启开发者选项打开“设置 - 关于手机”找到“版本号”或“内核版本”连续点击 7 次。屏幕下方会提示“您已进入开发者模式”。之后再进入“设置 - 系统 - 开发者选项”打开“USB 调试”。如果演示机正处于演示模式设置界面可能不是普通 Android 设置甚至找不到“关于手机”。这时不要尝试通过外部工具绕过而是进入系统自带的“退出演示模式”或“还原出厂设置”入口。具体路径因厂商而异常见包括连续点击屏幕四个角。在拨号盘输入厂商规定的测试代码。通过“设置 - 系统 - 重置选项”恢复普通模式。这类操作使用的是设备自带功能不涉及 Bootloader 解锁。如果设备已经无法进入设置页直接联系厂商售后处理不要自行用第三方工具强刷。2.3 USB 调试授权的 RSA 指纹机制开启“USB 调试”后主机第一次通过 adb 连接设备时设备会显示一个包含 RSA 密钥指纹的确认弹窗。用户选择“允许 USB 调试”并可以勾选“一律允许使用这台计算机进行调试”。这个授权会被写入设备端的/data/misc/adb/adb_keys文件。理解这一机制对排查问题很有帮助unauthorized状态意味着设备端尚未信任当前主机密钥。在开发者选项里选择“撤销 USB 调试授权”会清空所有已信任主机。如果弹窗被误点“取消”需要重新插拔数据线或执行adb reconnect。换句话说USB 调试授权是一次基于密钥的信任建立过程不是简单的开关。3. 连接演示机并完成 adb 授权3.1 连接前的硬件与 USB 模式检查用数据线连接演示机和电脑后下拉状态栏把 USB 连接方式从“仅充电”切换为“传输文件/MTP”或“USB 调试”模式。很多设备在连接后默认是“仅充电”这会导致 adb 无法识别设备。还需要检查数据线是否支持数据传输。USB 端口是否需要安装驱动。设备是否被其他调试工具占用。Windows 设备管理器里是否出现未知设备。这一步看起来简单但实际工作中大量连接失败都是因为线材和 USB 模式不对。3.2 首次弹窗中的“允许 USB 调试”如何处理第一次连接时设备端会有确认弹窗。点击“允许”后主机才能执行 adb 命令。如果看不到弹窗先断开重连或在开发者选项里撤销授权后再重试。不要直接点击“一律允许”后交给不信任的脚本使用。在做演示机环境准备时主机密钥一定要记录清楚尤其是多团队共用的测试机。3.3 用 adb devices 确认设备状态执行adb devices -l输出样例List of devices attached RF3N2K...P device product:redmi model:23117RK66C device:xxx transport_id:1状态字段说明状态含义处理device授权正常可以进行 adb 操作继续后续步骤unauthorized设备端未确认授权或密钥被撤销重新允许 USB 调试offline设备在线但通信异常重新插拔、重启 adbno permissionsLinux 下 udev 规则或用户权限不对配置 udev 规则重新插拔如果输出为空先执行adb kill-server adb start-server adb devices再检查线材和 USB 模式。3.4 撤销授权与重新授权当一台演示机被多台电脑连接过或者误允许了不信任主机时可以在设备端执行“开发者选项 - 撤销 USB 调试授权 - 撤销”然后重新插拔数据线按弹窗确认。命令行侧不要直接删除电脑上的 adbkey否则下次连接会生成新密钥又会触发弹窗。多团队共享设备时建议在设备上保留登记主机的密钥并在设备标签上记录主机标识避免每次连接都要重新授权。4. 设备信息采集与调试链路验证4.1 通过 getprop 读取关键属性连接成功后可以用 getprop 读取设备属性adb shell getprop ro.product.model adb shell getprop ro.product.device adb shell getprop ro.build.version.release adb shell getprop ro.build.version.sdk adb shell getprop ro.serialno这些字段分别表示型号、设备代号、系统版本、SDK 版本和序列号。查看完整属性可以执行adb shell getprop再配合 grep 过滤。4.2 用 settings 和 pm 查看系统状态adb shell settings get secure android_id adb shell wm size adb shell wm density adb shell pm list packages -3 adb shell dumpsys battery各命令的含义settings get secure android_id设备的 Android ID常用于测试标识。wm size当前屏幕分辨率检查是否符合预期。wm density屏幕密度自动化测试里常用来计算坐标。pm list packages -3列出第三方应用方便确认出厂状态是否被改动。dumpsys battery查看电池状态。这些命令都来自系统标准接口不需要提权。4.3 用一段脚本自动化采集设备信息日常巡检演示机时把上面命令组装成脚本更省事。下面是一个 bash 版本示例#!/usr/bin/env bash set -euo pipefail ADB${ADB:-adb} if ! command -v $ADB /dev/null 21; then echo 错误未找到 adb请先安装 platform-tools exit 1 fi SERIAL$($ADB devices | awk NR2 {print $1}) if [ -z ${SERIAL:-} ]; then echo 错误未检测到设备 exit 1 fi echo Device Serial: $SERIAL echo Model: $($ADB -s $SERIAL shell getprop ro.product.model 2/dev/null | tr -d \r) echo Device: $($ADB -s $SERIAL shell getprop ro.product.device 2/dev/null | tr -d \r) echo Android: $($ADB -s $SERIAL shell getprop ro.build.version.release 2/dev/null | tr -d \r) echo SDK: $($ADB -s $SERIAL shell getprop ro.build.version.sdk 2/dev/null | tr -d \r) echo Screen: $($ADB -s $SERIAL shell wm size 2/dev/null | tr -d \r) echo Density: $($ADB -s $SERIAL shell wm density 2/dev/null | tr -d \r) echo Android ID: $($ADB -s $SERIAL shell settings get secure android_id 2/dev/null | tr -d \r)脚本只取adb devices输出的第二行设备适合单设备场景。多设备场景要改进为循环并为每个设备指定-s参数。4.4 结果验证与常见字段说明执行脚本后把输出与设备“设置 - 关于手机”里的信息做对比。如果型号字段为空或为 unknown说明设备还没有完全退出演示模式或者系统处于异常状态需要先恢复普通用户模式。在自动化测试框架里这些字段也常被写入测试报告用于标注设备规格。设备登记表里的型号、序列号、系统版本一旦缺失后续用例归因会非常困难。注意不要只验证脚本能跑通还要验证关键字段是否与实验室设备登记表一致。型号、序列号、Android ID 是设备身份的核心标识。5. adb 连接异常排查5.1 unauthorized 状态怎么处理现象adb devices -l输出unauthorized设备无法执行命令。可能原因首次连接时没有在设备端点击“允许 USB 调试”。误点了“取消”。执行过“撤销 USB 调试授权”。设备端弹窗被投屏工具拦截没有显示出来。检查方式观察设备屏幕是否有调试授权弹窗。进入“开发者选项 - USB 调试”确认开关已打开。再次查看adb devices的输出状态。处理建议重新插拔 USB。在设备端撤销授权后重新授权。如果一直不弹窗执行adb reconnect或重启设备。5.2 offline 状态怎么处理现象状态为 offline设备在但通信异常。常见原因adb 版本过旧。USB 线接触不良。电脑端 5037 端口被占用。设备系统出现假死。检查方式执行adb kill-server adb start-server adb devices。换一条支持数据传输的线。查看端口占用Windows 使用netstat -ano | findstr 5037Linux/macOS 使用lsof -i :5037。处理建议关闭占用端口的程序。重启 adb 服务。如果依旧 offline重启设备并把设备恢复普通模式再试。5.3 device not found 常见原因现象adb devices不显示任何设备。检查顺序USB 线是否支持数据传输。状态栏 USB 模式是否从“仅充电”切换为“传输文件”。Windows 设备管理器是否识别到设备是否缺少驱动。开发者选项里的“USB 调试”是否开启。如果是虚拟机USB 重定向是否正确。处理建议换原装线。安装厂商 USB 驱动。在 Linux 下使用lsusb查看 USB 设备是否被系统识别。检查 adb 版本避免多个版本共存导致识别异常。5.4 演示机处于演示模式时的处理路径不少演示机在供电后自动循环播放演示视频桌面被锁定为展厅模式。此时开发者选项可能被隐藏adb devices可能仍然显示device但安装应用或读取属性会受到限制。正确路径先在设备设置里寻找“退出演示模式”或“恢复出厂设置”入口。部分展示固件需要按厂商提供的恢复流程走不能直接用第三方工具强刷。在恢复普通模式后再重新开启开发者选项并完成 adb 授权。如果设备已经被非官方渠道二次封包或锁定不要自行绕过激活策略联系厂商或采购渠道处理。6. 测试机安全基线与管理建议6.1 新测试机环境检查清单拿到演示机或二手测试机后先做一次基线检查再录入设备库检查项建议现象设备来源确认采购渠道和单据来源不明先隔离系统版本出厂固件或厂商正式固件不刷第三方 ROM退出演示模式能进入普通桌面无法退出先联系厂商开发者选项由测试组统一开启不开放给普通用户USB 调试授权只允许登记主机密钥清理多余主机root 状态检测确认未被提权发现异常及时重刷官方固件未知应用清理预装第三方应用可疑应用先卸载设备登记记录型号、序列号、IP便于资产追踪这份清单可以做成一张纸质表格贴在测试机柜旁边也可以在内部 Wiki 里做成设备准入模板。6.2 设备 root 状态检测的合规用途在安全审计里检测 root 状态是常见基线检查。可以执行adb shell which su adb shell pm list packages | grep -i magisk adb shell getprop ro.debuggable注意这些命令只用于检测设备是否被提权不能用来获取提权能力。ro.debuggable为 1 只表示系统允许调试不等于 root。如果发现设备存在 su 或 Magisk 迹象说明系统完整性已被改动需要按厂商官方固件重刷并重新走安全审批流程。对于合规测试环境应保持设备为官方未提权状态。6.3 不要把 adb 端口暴露到不可信网络adb 默认监听本地 5037 端口。如果在局域网内使用adb tcpip 5555设备会把 adb 服务开放到 5555 端口容易成为网络扫描目标。测试环境里如果必须使用无线调试建议只在隔离的内部测试网使用。用完立即关闭无线调试。不要跳过首次 USB 授权直接adb connect。不要用 adb 传输生产数据。简单来说无线调试要当成临时通道而不是设备的常驻服务。6.4 从手工调试走向设备管理平台当测试机上量后逐台手工执行adb devices很难管理。可以引入设备信息采集脚本把型号、系统、Android ID 写入统一台账。用例执行框架通过adb -s serial把用例分发到指定设备。无线调试结合设备管理平台统一记录设备在线状态和授权主机。告警机制发现设备弱网、耗电异常、root 状态变化时及时通知管理员。这一步扩展方向是自动化测试资源池。核心不是把设备权限打开而是把设备状态管住让每台设备都处于已知、可信、可复现的状态。回到开头的问题演示机不需要靠提权来变成“万能测试机”真正可靠的是标准调试链路加资产管理流程。先理解设备处于什么模式再通过官方接口获取信息然后把设备纳入测试资源池统一管理这套做法在设备数量少时可以手工执行设备多了可以脚本化、平台化。对于刚接触 Android 真机调试的新手建议先完成一个最小闭环在同一台演示机上跑通开启开发者选项、USB 授权、信息采集和异常排查再逐步扩展到多设备管理和自动化测试。下一步可以基于 adb 命令、Appium、uiautomator2 等框架把“设备能连上”升级为“设备能稳定跑完用例”。