Android 6.0 测试指南
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Android 6.0 让您有机会确保应用可使用下一平台版本。此版本包含一些可能会影响您的应用的 API 和行为变更,如 API 概览和行为变更中所述。使用此版本测试应用时,您应重点关注一些特定的系统变更,确保用户拥有愉悦的体验。
本指南介绍可使用您的应用测试 Android 6.0 的哪些功能以及如何测试。您应确定优先测试以下特定功能,因为它们可能会对应用行为产生较大影响:
测试权限
新的权限模型改变了用户向您的应用分配权限的方式。您的应用必须在运行时要求用户提供各项权限,而不是在安装过程中授予所有权限。对于用户而言,此行为有助于他们更精细地控制每个应用的 activity,并更深入地了解应用为何请求提供特定权限的上下文信息。用户可以随时向应用授予某项权限或撤消其权限。版本的此功能最有可能对应用的行为产生影响,并且可能会阻止某些应用功能正常运行,或者它们可能会在降级状态下运行。
这一变更会影响在新平台上运行的所有应用,即便这些应用并非面向新平台版本开发亦是如此。该平台为旧版应用提供有限的兼容性行为,但您现在应当开始计划将应用迁移到新权限模型,以便在官方平台启动时发布更新的应用版本。
测试提示
使用以下测试提示有助于您计划并通过新权限行为执行应用测试。
- 识别应用的当前权限和相关的代码路径。
- 在各种受权限保护的服务和数据中测试用户流程。
- 使用授予/撤销权限的各种组合进行测试。
- 使用
adb
工具通过命令行管理权限:
- 按组列出权限和状态:
adb shell pm list permissions -d -g
- 使用以下语法授予或撤消一项或多项权限:
adb shell pm [grant|revoke] <permission.name> ...
- 针对使用权限的服务对应用进行分析。
测试策略
权限更改会影响应用的结构和设计,以及您为用户提供的用户体验和流程。您应评估应用的当前权限使用情况,并开始规划您要提供的新流程。平台的正式版本提供兼容性行为,但您应计划更新应用,而不是依赖于这些行为。
确定应用实际需要和使用的权限,然后找出各种使用受权限保护的服务的代码路径。为此,您可以结合使用新平台上的测试和代码分析。在测试中,您应通过将应用的 targetSdkVersion
更改为 API 级别 23,重点关注选择运行时权限。
使用已撤销和已添加权限的各种组合进行测试,突出显示依赖于权限的用户流程。如果依赖关系不明显或不符合逻辑,则您应考虑重构或划分该流程,以消除依赖关系或阐明需要权限的原因。
如需详细了解运行时权限行为、测试和最佳实践,请参阅使用系统权限开发者文档。
测试低电耗模式和应用待机模式
当设备处于空闲状态或应用未聚焦时,低电耗模式和应用待机模式的节能功能将限制应用可执行的后台处理工作量。系统可对应用施加的限制包括:限制或禁止访问网络、暂停后台任务、暂停通知、忽略唤醒请求和闹钟。为确保应用在完成这些节能优化后正常运行,您应通过模拟这些低功耗状态对应用进行测试。
在低电耗模式下测试您的应用
要在低电耗模式下测试您的应用,请执行以下操作:
- 使用 Android 7.0(API 级别 24)系统映像配置硬件设备或虚拟设备。
- 将设备连接到开发计算机并安装应用
- 运行应用并使其保持活动状态
- 通过运行以下命令,模拟进入低电耗模式的设备:
$ adb shell dumpsys battery unplug
$ adb shell dumpsys deviceidle step
$ adb shell dumpsys deviceidle -h
- 观察重新激活设备时的应用行为。确保应用在设备退出低电耗模式时正常恢复。
在应用待机模式下测试您的应用
要在应用待机模式下测试您的应用,请执行以下操作:
- 使用 Android 7.0(API 级别 24)系统映像配置硬件设备或虚拟设备。
- 将设备连接到开发计算机并安装应用
- 运行应用并使其保持活动状态
- 通过运行以下命令,模拟进入待机模式的应用:
$ adb shell am broadcast -a android.os.action.DISCHARGING
$ adb shell am set-idle <packageName> true
- 使用以下命令模拟唤醒应用:
$ adb shell am set-idle <packageName> false
- 观察唤醒后的应用行为。确保应用从待机模式中正常恢复。特别地,您应检查应用的通知和后台作业是否按预期继续运行。
自动备份应用和设备特定的标识符
如果应用坚持在内部存储空间中使用任何设备特定的标识符,如 Google 云消息传递注册 ID,请确保遵循最佳实践将存储位置从自动备份中排除,如使用自动备份功能备份用户数据中所述。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-07-27。"],[],[],null,["# Android 6.0 Testing Guide\n\nAndroid 6.0 gives you an opportunity to ensure your apps work with the next\nversion of the platform. This release includes a number of APIs and behavior changes that can\nimpact your app, as described in the [API\nOverview](/about/versions/marshmallow/android-6.0) and [Behavior Changes](/about/versions/marshmallow/android-6.0-changes). In testing\nyour app with this release, there are some specific system changes that you should focus on to\nensure that users have a good experience.\n\n\nThis guide describes the what and how to test Android 6.0 features with your app. You should\nprioritize testing of these specific features, due to their high potential impact on your\napp's behavior:\n\n- [Permissions](#runtime-permissions)\n- [Doze and App Standby](#doze-standby)\n- [Auto Backup and Device Identifiers](#ids)\n\nTesting Permissions\n-------------------\n\n\nThe new [Permissions](/guide/topics/permissions/overview) model\nchanges the way that permissions are allocated to your app by the user. Instead of granting all\npermissions during the install procedure, your app must ask the user for individual permissions\nat runtime. For users this behavior provides more granular control over each app's activities, as\nwell as better context for understanding why the app is requesting a specific permission. Users\ncan grant or revoke the permissions granted to an app individually at any time. This feature of\nthe release is most likely to have an impact on your app's behavior and may prevent some of your\napp features from working, or they may work in a degraded state.\n\n\nThis change affects all apps running on the new platform, even those not targeting the new\nplatform version. The platform provides a limited compatibility behavior for legacy apps, but you\nshould begin planning your app's migration to the new permissions model now, with a goal of\npublishing an updated version of your app at the official platform launch.\n\n### Test tips\n\n\nUse the following test tips to help you plan and execute testing of your app with the new\npermissions behavior.\n\n- Identify your app's current permissions and the related code paths.\n- Test user flows across permission-protected services and data.\n- Test with various combinations of granted/revoked permission.\n- Use the `adb` tool to manage permissions from the command line:\n - List permissions and status by group: \n\n ```text\n adb shell pm list permissions -d -g\n ```\n - Grant or revoke one or more permissions using the following syntax: \n\n ```text\n adb shell pm [grant|revoke] \u003cpermission.name\u003e ...\n ```\n- Analyze your app for services that use permissions.\n\n### Test strategy\n\n\nThe permissions change affects the structure and design of your app, as well as\nthe user experience and flows you provide to users. You should assess your app's current\npermissions use and start planning for the new flows you want to offer. The official release of\nthe platform provides compatibility behavior, but you should plan on updating your app and not\nrely on these behaviors.\n\n\nIdentify the permissions that your app actually needs and uses, and then find the various code\npaths that use the permission-protected services. You can do this through a combination of\ntesting on the new platform and code analysis. In testing, you should focus on opting in to\nruntime permissions by changing the app's `targetSdkVersion` to API level 23.\n\n\nTest with various combinations of permissions revoked and added, to highlight the user flows that\ndepend on permissions. Where a dependency is not obvious or logical you should consider\nrefactoring or compartmentalizing that flow to eliminate the dependency or make it clear why the\npermission is needed.\n\n\nFor more information on the behavior of runtime permissions, testing, and best practices, see\n[Working with System Permissions](/training/permissions) developer.\n\nTesting Doze and App Standby\n----------------------------\n\n\nThe power saving features of Doze and App Standby limit the amount of background processing that\nyour app can perform when a device is in an idle state or while your app is not in focus. The\nrestrictions the system may impose on apps include limited or no network access,\nsuspended background tasks, suspended Notifications, ignored wake requests, and alarms. To ensure\nthat your app behaves properly with these power saving optimizations, you should test your app by\nsimulating these low power states.\n\n#### Testing your app with Doze\n\nTo test Doze with your app:\n\n1. Configure a hardware device or virtual device with an Android 7.0 (API level 24) system image.\n2. Connect the device to your development machine and install your app.\n3. Run your app and leave it active.\n4. Simulate the device going into Doze mode by running the following commands: \n\n ```bash\n $ adb shell dumpsys battery unplug\n $ adb shell dumpsys deviceidle step\n $ adb shell dumpsys deviceidle -h\n ```\n5. Observe the behavior of your app when the device is re-activated. Make sure it recovers gracefully when the device exits Doze.\n\n#### Testing apps with App Standby\n\nTo test the App Standby mode with your app:\n\n1. Configure a hardware device or virtual device with an Android 7.0 (API level 24) system image.\n2. Connect the device to your development machine and install your app.\n3. Run your app and leave it active.\n4. Simulate the app going into standby mode by running the following commands: \n\n ```bash\n $ adb shell am broadcast -a android.os.action.DISCHARGING\n $ adb shell am set-idle \u003cpackageName\u003e true\n ```\n5. Simulate waking your app using the following command: \n\n ```bash\n $ adb shell am set-idle \u003cpackageName\u003e false\n ```\n6. Observe the behavior of your app when it is woken. Make sure it recovers gracefully from standby mode. In particular, you should check if your app's Notifications and background jobs continue to function as expected.\n\nAuto Backup for Apps and Device-Specific Identifiers\n----------------------------------------------------\n\nIf your app is persisting any device-specific identifiers, such as Google\nCloud Messaging registration ID, in internal storage,\nmake sure to follow best practices to exclude the storage\nlocation from auto-backup, as described in [Back Up User\nData with Auto Backup](/guide/topics/data/autobackup)."]]