企业官网建设流程全解析

在实际的 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 环境要求与版本确认

建议满足以下条件：

在终端执行：

adb version

如果提示命令不存在，需要先安装。Windows 可以从官方页面下载 platform-tools 压缩包，解压后把目录加入 PATH；Linux 可以使用系统包管理器；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

状态字段说明：

如果输出为空，先执行：

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 2>&1; then echo "错误：未找到 adb，请先安装 platform-tools" exit 1 fi SERIAL="$($ADB devices | awk 'NR==2 {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 5037，Linux/macOS 使用lsof -i :5037。

处理建议：

• 关闭占用端口的程序。
• 重启 adb 服务。
• 如果依旧 offline，重启设备，并把设备恢复普通模式再试。

5.3 device not found 常见原因

现象：adb devices不显示任何设备。

检查顺序：

1. USB 线是否支持数据传输。
2. 状态栏 USB 模式是否从“仅充电”切换为“传输文件”。
3. Windows 设备管理器是否识别到设备，是否缺少驱动。
4. 开发者选项里的“USB 调试”是否开启。
5. 如果是虚拟机，USB 重定向是否正确。

处理建议：

• 换原装线。
• 安装厂商 USB 驱动。
• 在 Linux 下使用lsusb查看 USB 设备是否被系统识别。
• 检查 adb 版本，避免多个版本共存导致识别异常。

5.4 演示机处于演示模式时的处理路径

不少演示机在供电后自动循环播放演示视频，桌面被锁定为展厅模式。此时开发者选项可能被隐藏，adb devices可能仍然显示device，但安装应用或读取属性会受到限制。

正确路径：

• 先在设备设置里寻找“退出演示模式”或“恢复出厂设置”入口。
• 部分展示固件需要按厂商提供的恢复流程走，不能直接用第三方工具强刷。
• 在恢复普通模式后，再重新开启开发者选项并完成 adb 授权。

如果设备已经被非官方渠道二次封包或锁定，不要自行绕过激活策略，联系厂商或采购渠道处理。

6. 测试机安全基线与管理建议

6.1 新测试机环境检查清单

拿到演示机或二手测试机后，先做一次基线检查，再录入设备库：

这份清单可以做成一张纸质表格贴在测试机柜旁边，也可以在内部 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 等框架，把“设备能连上”升级为“设备能稳定跑完用例”。