本页面提供了问题排查帮助，以及有关使用 Developer Device Platform 运行测试的常见问题解答。如果您找不到所需内容或需要其他帮助，请与我们联系。
问题排查
您有哪些资源可用于从 Firebase Test Lab 迁移到 Developer Device Platform？
如果您要从 Firebase Test Lab 迁移到 Developer Device Platform，请参阅我们的迁移指南、命令和标志转换以及面向 AI 代理的迁移技能。
为什么我的测试需要很长时间才能完成运行？
如果您在 Developer Device Platform 目录中选择容量级别为“高”的设备，您的测试可能会较快开始；但如果所选设备的容量级别为“低”，则测试可能需要更长时间才能开始运行。此外，如果调用的测试数量远远超过所选设备的容量，则测试可能需要更长时间才能完成。
在以下因素的影响下，在任意设备容量水平运行的测试都可能需要更长时间来完成：
- 流量（会影响设备可用性和测试速度）。
- 设备或基础架构故障（可能随时发生）。如需查看 Developer Device Platform 是否有基础架构报错，请参阅 Google Cloud Personalized Service Health 信息中心。
如需详细了解 Developer Device Platform 中的设备容量，请参阅设备目录。
为什么我会收到不确定的测试结果？
出现不确定测试结果的原因通常是因为测试运行被取消或者基础架构存在错误。除了 PASSED 和 FAILED 之外，Developer Device Platform 还可能会返回 ERROR、TIMED_OUT 和 CANCELLED。
基础架构错误是由内部 Developer Device Platform 问题（例如网络连接错误或意外设备行为）导致的。Developer Device Platform 会在内部多次重试产生基础架构错误的测试运行，然后报告不确定结果。
如需确定错误的原因，请按以下步骤操作：
- 在 Google Cloud Service Health 信息中心检查是否存在已知的服务中断故障。
在 Developer Device Platform 中重试测试，以验证能否重现错误。
尝试在其他设备或设备类型上运行测试（如果适用）。 如需了解详情，请参阅设备目录。
为什么启用分片后测试的运行时间延长？
如果您指定的分片数量超过 Developer Device Platform 中可用的设备数量，分片就可能会导致测试的运行时间延长。为避免这种情况，请将设备数量限制为分片数量。如需详细了解如何选择其他设备，请参阅设备目录。
为什么我的测试需要很长时间才能启动？
在您提交测试请求后，系统会先对应用完成验证、重新签名等操作，为在设备上运行测试做好准备。通常，此过程会在几秒钟内完成，但可能会受到应用大小等因素的影响。
应用准备就绪之后，系统会安排测试作业并将其放入队列，直到有设备准备好运行测试。
为什么我的测试需要很长时间才能完成？
测试作业完成后，系统会从设备下载测试工件、进行处理并将其上传到 Cloud Storage。此步骤的时长可能会受工件数量和大小的影响。
Android 专用问题排查
应用没有返回数据，无法找到屏幕截图
测试作业工件（例如，屏幕截图和日志文件）存储在 Cloud Storage 中，并直接呈现到 Google Cloud 控制台中。检查您是否已分配项目级层角色。
另请注意，Developer Device Platform 有专门的服务代理，该代理使用自己的凭据（而不是您的凭据）来执行以下操作：
- 读取和写入 Cloud Storage 存储桶和对象
- 将 Cloud Storage 输入文件下载到内部系统
- 将文件从内部系统上传到 Cloud Storage 输出存储桶
您可能拥有对某个 Cloud Storage 存储桶和文件的访问权限，但该存储桶归与 DDP 中使用的项目不同的 Google Cloud 项目所有。因此，Developer Device Platform 服务账号无权访问该存储桶。
您还可以对各个存储桶设置额外的访问权限控制。如需了解如何在测试中包含文件，请参阅设备运行；如需了解如何向外部存储桶授予开发者设备平台访问权限，请参阅共享存储空间。
为什么我会收到部分插桩测试用例结果，或者收不到任何结果？
运行插桩测试时，您可能会发现测试用例总数少于预期。这通常是因为 Developer Device Platform 无法对通常由 AndroidJUnitRunner 生成的测试用例开始或结束标记进行 Logcat 解析。
以下是导致此问题的常见原因：
| 问题描述 | 可能的解决方案 |
|---|---|
| 由于超时导致测试用例未能运行。如果测试的总时长超过您指定的超时设置或超过超时上限，Developer Device Platform 便会取消未完成的剩余测试用例。 |
|
| 由于过早退出或卡住，测试用例未能完成。测试用例可能会因某个未捕获到的异常或断言错误而过早退出。测试用例可能会陷入无限循环，或者无法继续完成，例如，由于应用未能显示正确的视图而导致测试用例无法在相应的界面中执行所需的操作。 |
请检查相关视频和 logcat，调查测试停止在哪个位置。 |
某个自定义测试运行程序（包括扩展的 AndroidJUnitRunner）意外崩溃或向 logcat 写入了意外的测试用例开始或结束标记。 |
检查测试运行程序代码。 |
写入 logcat 的日志过多，导致缓冲区过载或导致 logcat 进程崩溃。 |
减少对 logcat 执行的写入操作。 |
| 被测应用崩溃。 | 调试应用。 |
常见问题解答 (FAQ)
在哪里可以找到 Developer Device Platform 的价格信息？
如需了解详情，请参阅价格和结算问题。
在哪里可以找到设备详细信息，例如分辨率等？
详细的设备信息可通过 API 获取，并且可以通过 Developer Device Platform CLI 使用 device-run devices describe <device-id> 命令进行访问：
gcloud beta device-run devices describe DEVICE_ID
如何确定到达后端的流量是否来自 Developer Device Platform？
您可以在后端对照我们的 IP 范围检查源 IP 地址，从而确定流量是否来自 Developer Device Platform 托管的测试设备。
Developer Device Platform 是否支持 VPC-SC？
Developer Device Platform 不支持 VPC-SC，后者会阻止在 Developer Device Platform 的内部存储空间与用户的结果存储桶之间复制应用和其他测试工件。
如何在 Developer Device Platform 中减少不可靠的测试？
如需在测试中检测不稳定行为，建议您使用 --flaky-test-attempts 选项。若为解决稳定性问题而重新运行作业，会计入相关费用或每日配额，就与正常的测试作业一样。
请注意以下几点：
- DDP 默认会按顺序运行重试，以节省费用。用户需要将
--flaky-test-parallel-retry设置为并行运行。 --flaky-test-retry-level标志用于定义是按shard还是按单个test级别进行重试，默认值为shard。将其设置为test可减少重试测试的大小和时长。
iOS 专用常见问题解答
Developer Device Platform 是否支持 Appium、Flutter/FlutterDriver、ReactNative/Jest 或 Cucumber？
尽管其中部分内容已列入我们的路线图，但我们无法承诺会支持这些测试和应用开发平台。
为什么我的 iOS 测试结果中缺少视频？
我们计划在 iOS 18 或更高版本中支持在搜索结果中显示视频。
Android 专用常见问题解答
Developer Device Platform 是否支持穿戴式设备？
是的！Developer Device Platform 支持 Google Pixel Watch。您现在可以在 Google Pixel Watch 上的独立 Wear OS 应用中运行测试。如需详细了解 Developer Device Platform 设备，请参阅设备目录。
Developer Device Platform 是否支持最新的 Google 设备？
是的！Developer Device Platform 支持 Google Pixel Tablet 和 Google Pixel Fold。您可以在独立实体设备上运行测试。如需详细了解 Developer Device Platform 中提供的设备，请参阅设备目录。
Developer Device Platform 是否支持 Appium、Flutter/FlutterDriver、ReactNative/Jest 或 Cucumber？
尽管其中部分内容已列入我们的路线图，但我们无法承诺会支持这些测试和应用开发平台。但是，如果您使用支持 Espresso 的框架（例如 Flutter）构建应用，则可以使用 Espresso 编写插桩测试，然后在 Developer Device Platform 上运行测试。
Developer Device Platform 是否支持对经过混淆处理的应用（例如，使用 ProGuard 或 R8 进行过混淆处理）执行测试？
Developer Device Platform 未明确表明支持混淆处理或去混淆处理。虽然应用可能会正常运行，但任何经过混淆处理的应用数据（如堆栈轨迹）在日志中都会被记录为经过混淆处理的内容。
在 Developer Device Platform 上进行测试时，我可以在不同的可折叠状态和姿势下使用可折叠设备吗？
是的！您可以在可折叠状态和姿势下测试可折叠设备。
可折叠设备可能会处于各种折叠状态，例如 FLAT（完全展开）或 HALF_OPENED（介于完全展开和完全闭合之间）。
另一方面，姿势包括特定的设备屏幕方向和可折叠状态，例如桌面姿势（在水平屏幕方向下为 HALF_OPENED 状态）或图书姿势（在垂直屏幕方向下为 HALF_OPENED 状态）。
如果您运行插桩测试，可以使用 Jetpack WindowManager 库并按照在可折叠设备上测试应用文档测试不同的状态和姿势。
或者，可用状态因设备而异，并且可以使用 adb
shell command cmd device_state 与之交互。
- 如需列出当前状态，请运行
adb shell cmd device_state state。 - 如需设置或替换当前状态，请运行
adb shell cmd device_state state <IDENTIFIER>。 - 如需重置状态，请运行
adb shell cmd device_state state reset。 - 如需检查可用状态，请在可折叠设备上运行
adb shell cmd device_state print-states命令。
Google Pixel Fold（型号 ID felix）
$ adb shell cmd device_state print-states
Supported states: [
DeviceState{identifier=0, name='CLOSED', app_accessible=true},
DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true},
DeviceState{identifier=2, name='OPENED', app_accessible=true},
DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true},
]
Samsung Galaxy Z Fold4（型号 ID q4q）
$ adb shell cmd device_state print-states
Supported states: [
DeviceState{identifier=0, name='CLOSE', app_accessible=true},
DeviceState{identifier=1, name='TENT', app_accessible=true},
DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true},
DeviceState{identifier=3, name='OPEN', app_accessible=true},
]
如果我没有应用，可以试用 Developer Device Platform 吗？
与其他开发者设备平台产品不同，您无需添加开发者设备平台 SDK 即可使用开发者设备平台。如果您还没有应用，可以在线下载 APK，或者通过 AndroidX GitHub 代码库中的某个示例构建应用和测试 APK。请注意，插桩测试需要通过源代码构建的应用和测试 APK。如需了解详情，请参阅插桩测试。
如需详细了解 Developer Device Platform 功能，请参阅 DDP 产品概览。
哪些设备最适合进行屏幕截图差异测试？
屏幕截图差异测试是指将运行测试期间获得的屏幕图片与代表预期行为的黄金映像进行比较，从而得到测试断言。在某些设备类型上，此类测试可能会更容易出错。对于此类测试，我们建议使用 Arm (*.arm) 模拟器设备。Arm 模拟器设备使用与 Android Studio 通用模拟器高度相似或相同的映像。
我们还建议您调查测试库，这些库有助于在存在预期变更时提高屏幕截图测试的可靠性。
Developer Device Platform 是否会更新虚拟设备？
是的！在进行以下更改时，虚拟设备会更新：
- 更新现有映像
- 废弃早期 API 级别
- 添加新的 Android API 级别
如何启用覆盖率报告？
如需启用覆盖率报告，请将 coverage=true 添加到 additional-test-options 字段。如果您在使用 Android Test Orchestrator，则必须提供一个目录路径来存储覆盖率结果，如下所示：
--additional-test-options coverage=true,coverageFilePath=/sdcard/Download/
如果您没有使用 Orchestrator，则可以指定一个文件路径，如下所示：
--additional-test-options coverage=true,coverageFile=/sdcard/Download/coverage.ec
如何在没有手机的情况下登录 Wear 应用？
如果您的应用通常需要使用手机登录，您可以创建一个 build 变体，该变体跳过登录并使用嵌入在测试 build 中的令牌，或者从磁盘上的文件中读取数据（通常使用 --other-files-to-push 标志推送）。