使用全新 Android 模拟器工具进行持续测试

做者 / Lingfeng Yang, Android Studio team

开发者在平常的开发工做中每每会先使用 Android 模拟器来快速测试修改过的应用，而后再提交代码。此外，开发者愈来愈多地在其持续集成 (CI, Continuous Integration) 系统中使用模拟器来运行较大规模的自动化测试。为了更好地支持这些用例，咱们开源了 Android Emulator Container Script，并围绕如下两个痛点改进了开发体验:

• 可部署性: 查找并运行所需版本的 Android 模拟器。
• 可调试性: 跟踪来自 Android 模拟器远程实例的错误。

可部署性

Android 支持多种硬件和软件配置，Android 模拟器也不例外。可是，这种多样性可能会致使测试环境配置出现混乱。开发者该如何得到模拟器和系统镜像文件？须要什么驱动程序？如何打开或者关闭 CPU 或 GPU 加速？等等等等。

为了解决这些问题，咱们推出了:

• Android Emulator 下载脚本 - 该脚本提供了模拟器镜像的最新列表 (包括 AOSP 和包含了 Google Play 服务的版本) 以及模拟器二进制文件 (支持 Linux、Mac OS 和 Windows)。您能够将其与现有的 CI 系统集成。展望将来，咱们准备加强这个服务，让其能够下载除最新版本以外的已弃用版本，从而让开发者能够更轻松地复现历史测试结果。
• Android Emulator Docker 镜像生成器 – 有了 Android 系统镜像和模拟器还只是开始。运行环境、驱动程序和预安装的系统依赖项，咱们将 Docker 镜像生成器打包放在了一块儿，这些内容组合在一块儿才是 Android 模拟器的完整运行环境。启动 Docker 镜像后，1) 端口转发和 ADB 以及 2) gRPC 和 WebRTC，使与模拟器的交互成为可能。目前，Docker 镜像生成器被设计为在 Linux 上运行。咱们也在想办法支持 Mac OS 和 Windows，敬请期待！

为了提升复现能力，底层的 Dockerfile 模板使所需的命令行标识和系统依赖性更加明确 (而且能够经过从中构建 Docker 镜像来重现)。对于硬件加速，请注意传递给 run.sh 的 --privileged 标识；咱们假设在运行模拟器时可使用 CPU 加速，而且须要 --privileged 来运行启用了 CPU 加速 (KVM) 的容器。

有关如何建立和部署 Android 模拟器镜像的更多详细信息，请参阅文档里的 README 文件。

可调试性

当模拟器正在运行一个测试并且测试失败时，您可能难以介入正在运行的测试环境并诊断错误。诊断一般须要与虚拟设备直接交互，为此咱们提供了两种直接互动的机制:

• ADB
• 远程流

对于 ADB，经过将特定端口从 Docker 转发到主机，咱们支持运行全部命令 (例如 logcat 和 shell)。当前使用的端口为 5555，咱们须要收集更多反馈，并就如何最好地在不一样容器间分配端口进行更深刻的研究。

远程流

先作一个安全说明: 使用远程流时，一旦启动服务，任何能够在 80/443 端口上链接到您的计算机的人均可以与模拟器进行交互。所以在公共服务器上运行远程流时请务必注意这一点！

您可使用远程流在容器中运行模拟器，其交互能力与本地运行时一致。在容器中运行模拟器，您就能够更轻松地调试使用 ADB 命令难以发现的问题。您可使用支持 WebRTC 和 gRPC 的浏览器来访问模拟器，WebRTC 用于串流视频，而 gRPC 则将鼠标和键盘事件发送到模拟器。远程流须要三个容器:

运行最新模拟器的容器 一个带有 Envoy web proxy (用于 gRPC) 的容器 一个配备 nginx 的容器，用于运行 React web 应用

您可使用 docker-compose 将 Docker 容器组合在一块儿，如 README 中所述 。容器绑定到端口 80 和 443，所以请确保您没有运行 Web 服务器。若是将浏览器指向主机，咱们将提供一个自签名证书。将浏览器指向主机时，您应该会看到相似下图的内容:

再次提醒，任何能够链接到主机的人均可以与模拟器进行交互。所以，在公共服务器上运行时要当心！

测试、更多的测试

测试工做彷佛会把开发时间拖得更久。可是，正如许多经验丰富的开发者所看到的那样，随着项目的代码变得更多更复杂，良好的自动化测试其实能够提升开发速度。持续测试存在的目的，就是让您能够肯定每个更改都不会对应用形成负面影响。

您对 CI 和持续测试有什么心得和疑问？欢迎在评论区和咱们分享。

点击这里进一步了解 Android 模拟器