从‘more than one device‘到‘appActivity‘报错：一次完整的Android自动化测试踩坑实录

从'more than one device'到'appActivity'报错：一次完整的Android自动化测试踩坑实录

那天下午，我正试图为一个简单的Settings应用自动化测试脚本搭建环境。作为一名刚接触Android自动化测试的开发者，我本以为这会是个轻松的任务——毕竟只是点击几个按钮而已。然而接下来的48小时里，我却在两个看似简单的错误中反复挣扎，最终收获的不仅是解决方案，更是一整套调试思维和细节把控的方法论。

1. 多设备连接的混乱：ADB的第一次考验

当我第一次运行adb shell dumpsys window windows | findstr mFocusedApp命令时，终端毫不留情地抛出了那个经典错误：

error: more than one device/emulator

1.1 理解问题的本质

这个报错表面上看是连接了多个设备，但实际情况可能更复杂：

• 真实多设备：确实同时连接了手机和模拟器
• 幽灵设备：某个设备处于offline状态但未被正确释放
• ADB服务异常：后台进程出现故障导致设备识别错误

我首先用adb devices命令查看当前连接状态，果然发现了两个设备：

List of devices attached emulator-5554 device HT8321KL0298 unauthorized

1.2 精准定位解决方案

针对不同情况，解决方案也有所不同：

1. 指定特定设备（适用于真实多设备场景）：

   adb -s emulator-5554 shell dumpsys window windows

2. 清理异常连接（适用于幽灵设备情况）：

   adb kill-server adb start-server

3. 授权处理（针对unauthorized状态）：

   # 在设备上点击授权提示 adb devices # 再次检查状态

提示：使用adb -s时，设备序列号可以通过adb devices获取，建议复制粘贴避免手动输入错误

2. 隐蔽的拼写陷阱：当appAction遇上appActivity

解决了设备连接问题后，我信心满满地运行测试脚本，却迎来了第二个错误：

error: activity and pkg are required to start an application

2.1 配置参数的深度检查

我的Desired Capabilities配置看似完美：

desired_caps = { "deviceName": "emulator-5554", "platformName": "Android", "platformVersion": "11.0", "appPackage": "com.android.settings", "appAction": ".Settings" # 这里埋下了隐患 }

经过半小时的反复检查，终于发现我把appActivity误写成了appAction——一个字母之差导致整个测试无法启动。

2.2 关键参数的正确配置

正确的Capability配置应该包含以下核心参数：

修正后的配置：

desired_caps["appActivity"] = ".Settings" # 这才是正确的参数名

3. 调试工具链的建立

经历了这两次错误后，我总结出一套高效的调试流程：

1. ADB基础检查

   • adb devices验证设备连接
   • adb shell pm list packages检查目标应用是否存在

2. Capability验证清单

   # 获取当前Activity adb shell dumpsys window windows | grep mCurrentFocus # 查看应用包信息 adb shell pm dump <package_name>

3. Appium日志分析技巧

   • 关注[WD Proxy]开头的日志行
   • 检查[BaseDriver]中的Capability验证结果

4. 自动化测试的防错实践

为了避免类似错误再次发生，我建立了以下防护措施：

• 参数模板库：保存标准Capability配置片段

• 预检脚本：运行测试前自动检查：

  def check_capabilities(caps): required = ['appPackage', 'appActivity', 'platformName'] for key in required: if key not in caps: raise ValueError(f"Missing required capability: {key}")

• 设备管理工具：

  def get_active_device(): devices = subprocess.check_output(['adb', 'devices']).decode() # 解析设备列表逻辑... return available_devices[0] if len(available_devices) == 1 else None

5. 那些年我们踩过的Capability坑

根据社区经验和我自己的实践，整理出这份高频错误清单：

1. 大小写敏感问题

   • platformName必须首字母大写
   • automationName的UiAutomator2拼写

2. 路径格式问题

   • Windows下的app路径需要双反斜杠：

     "app": "C:\\path\\to\\app.apk"

3. 版本兼容问题

   • 不同Android版本可能需要特殊的Capability配置
   • 模拟器与真机可能需要不同的参数组合

6. 从错误中建立调试直觉

经过这次调试之旅，我养成了三个关键习惯：

1. 逐字检查：对关键参数进行字母级审查
2. 环境隔离：测试前确保单一设备连接
3. 日志分级：区分不同级别的调试信息

这些经验后来在更复杂的测试场景中多次拯救了我，特别是当遇到那些模糊的报错信息时，系统化的排查思路远比盲目尝试有效得多。