Jenkins全流水线执行时第三方Android模拟器无法启动Appium uiautomator2

环境变量差异校验 #

• 对比两个流水线项目的环境变量，重点核查ANDROID_HOME、JAVA_HOME、APPIUM_HOME等与Android自动化相关的变量。项目1的前4个阶段可能修改了环境变量，导致后续Gradle命令无法正确识别模拟器或Appium服务。
• 可在两个项目的执行命令前添加set（Windows环境）命令导出全量环境变量，对比两者的差异项。

模拟器状态预检查 #

• 项目1的前置阶段可能占用模拟器资源或修改其状态（如占用adb端口、变更调试模式），在「Initiate AT」阶段执行自动化命令前，添加以下检查命令：

  adb devices
  adb shell pm list packages | grep io.appium.settings
  

  确认模拟器在线，且Appium Settings已正常安装。
• 尝试在自动化命令前重启adb服务：adb kill-server && adb start-server，消除端口占用或连接异常问题。

Gradle执行上下文修正 #

• 项目1的前置阶段可能修改了Gradle缓存或全局配置，导致cucumber任务执行环境与项目2不一致。可在命令中添加--no-build-cache参数禁用缓存：

  .\gradlew cucumber --no-build-cache -Pargs="-rerun ${rerun_times} -enable-report ${enable_report} -timezone GMT+08:00 -suite ${running_scope}" -b android\build.gradle && exit %%ERRORLEVEL%%
  

• 检查项目1前置阶段是否执行了clean等可能破坏依赖的Gradle任务，确保自动化所需的应用包、依赖库已正确构建。

详细日志定位问题 #

• 在项目1的自动化命令中添加--info参数提升Gradle日志级别，获取更细粒度的执行日志：

  .\gradlew cucumber --info -Pargs="-rerun ${rerun_times} -enable-report ${enable_report} -timezone GMT+08:00 -suite ${running_scope}" -b android\build.gradle && exit %%ERRORLEVEL%%
  

  对比项目2的日志，重点关注Appium初始化、设备连接、应用启动阶段的报错信息，定位具体失败节点。

工作空间清理 #

• 项目1的工作空间可能残留旧构建文件或缓存，干扰自动化执行。在「Initiate AT」阶段前添加工作空间清理步骤，确保构建环境干净。

内容的提问来源于stack exchange，提问作者Cecilia Chen