Android 6.0 測試指南
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
您可以利用 Android 6.0 確保應用程式可與下一個平台版本搭配運作。這個版本包含許多可能會影響應用程式的 API 和行為變更,詳情請參閱「API 總覽」和「行為變更」。使用此版本測試應用程式時,請特別留意某些系統變更,確保使用者享有良好體驗。
本指南說明如何使用應用程式測試 Android 6.0 功能。由於這些功能對應用程式行為的影響程度高,因此應優先測試這些特定功能:
測試權限
新的權限模式會變更使用者為應用程式分配權限的方式。應用程式必須在執行階段要求使用者授予個別權限,而不是在安裝過程中授予所有權限。對於使用者而言,這項行為可讓他們更精細地控管各個應用程式活動,並提供更詳盡的說明,讓他們瞭解應用程式為何要求特定權限。使用者可隨時個別授予或撤銷應用程式的權限。這項功能最有可能影響應用程式的行為,並可能導致部分應用程式功能無法運作,或以降級狀態運作。
這項變更會影響在新平台上執行的所有應用程式,即使這些應用程式並未指定新平台版本,也一樣會受到影響。平台會為舊版應用程式提供有限的相容性行為,但您應立即開始規劃應用程式遷移至新權限模式,目標是在平台正式推出時發布更新版應用程式。
測試提示
請參考下列測試提示,規劃並執行應用程式的新權限行為測試。
- 找出應用程式目前的權限和相關程式碼路徑。
- 針對所有受權限保護的服務和資料,測試使用者流程。
- 測試授予/撤銷權限的各種組合情況。
- 使用
adb
工具,透過指令列管理權限:
- 依群組列出權限和狀態:
adb shell pm list permissions -d -g
- 使用下列語法授予或撤銷一或多項權限:
adb shell pm [grant|revoke] <permission.name> ...
- 針對會使用權限的服務進行應用程式分析。
測試策略
權限變更會影響應用程式的結構和設計,以及您提供給使用者的使用者體驗和流程。您應評估應用程式目前使用的權限,並開始規劃要提供的新流程。平台的正式版本提供相容性行為,但您應妥善規劃更新應用程式,不要依賴這些行為。
找出應用程式實際需要及使用的權限,然後找出使用權限保護服務的各種程式碼路徑。方法是在新的平台和程式碼分析中搭配使用測試。在測試過程中,您應將應用程式的 targetSdkVersion
變更為 API 級別 23,藉此選擇採用執行階段權限。
測試撤銷和新增權限的各種組合,以便找出需要權限的使用者流程。如果依附元件不明顯或不符合邏輯,您應考慮重構或區隔該流程,以消除依附元件,或清楚說明為何需要權限。
如要進一步瞭解執行階段權限的行為、測試和最佳做法,請參閱「使用系統權限」開發人員說明文件。
測試打盹和應用程式待命
打盹和應用程式待命的省電功能會限制應用程式在裝置處於閒置狀態或未獲得焦點時,可執行的背景處理量。系統可能對應用程式設下的限制包括:網路存取權受限或完全無法存取、暫停的背景工作、暫停通知、忽略的喚醒要求和鬧鐘等。為確保應用程式能根據這些省電最佳化功能正常運作,建議您模擬這些低耗電狀態來測試應用程式。
使用 Doze 測試應用程式
如要使用應用程式測試 Doze,請按照下列步驟操作:
- 設定搭載 Android 7.0 (API 級別 24) 系統映像檔的硬體裝置或虛擬裝置。
- 將裝置連接至開發機器,然後安裝應用程式。
- 執行應用程式並保持其處於活動狀態。
- 如要模擬裝置進入打盹模式,請執行下列指令:
$ adb shell dumpsys battery unplug
$ adb shell dumpsys deviceidle step
$ adb shell dumpsys deviceidle -h
- 觀察裝置重新啟用後的行為。請確認在裝置退出 Doze 時,該服務能順利復原。
使用應用程式待命功能測試應用程式
如要使用應用程式測試 App Standby 模式,請按照下列步驟操作:
- 設定搭載 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
- 觀察應用程式喚醒時的行為。請確認它能從待命模式中順利復原。特別是,您應檢查應用程式的通知和背景工作是否仍能正常運作。
自動備份應用程式和裝置專屬 ID
如果您的應用程式會在內部儲存空間中儲存任何裝置專屬 ID (例如 Google Cloud Messaging 註冊 ID),請務必遵循最佳做法,將儲存空間位置從自動備份中排除,如「使用自動備份功能備份使用者資料」一文所述。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間: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"]],["上次更新時間: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)."]]