將應用程式遷移至 Android 11
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
每次發布 Android 版本時，我們都會推出新功能和行為變更，讓 Android 更實用、更安全且效能更佳。在多數情況下，您的應用程式均可立即正常運作，但在某些情況下，您可能需要變更應用程式以配合平台變更。
一旦原始碼發布到 Android 開放原始碼計畫 (Android 開放原始碼專案)，使用者就能開始接收新平台，因此應用程式必須準備就緒，以便發揮使用者預期的效能，並展現新功能與 API 的最佳優勢，讓使用者能夠充分體驗新平台效益。
本文以進階觀點提供一般開發和測試階段說明，協助您配合平台發布時程，擬定應用程式就緒度計畫，確保使用者享有出色的 Android 11 體驗。
一般遷移作業分為兩個階段，可同時進行：
- 確保應用程式相容性 (在 Android 11 最終版本推出之前)
- 以新的平台功能和 API 為目標 (在最終版本發布後盡快實現)
本頁將說明各階段的一般步驟。準備好開始使用時，請參閱「取得 Android 11」。
確保與 Android 11 相容
請務必針對現有應用程式測試 Android 11 的功能，以確保使用者更新至最新 Android 版本時，能享有良好體驗。有些平台變更可能會影響應用程式的行為，因此請儘早進行全面的測試，並對應用程式進行必要的調整。
一般而言，你不需要變更應用程式的 targetSdkVersion，即可調整應用程式並發布更新。同樣地，您應該也不需要使用新的 API 或變更應用程式的 compileSdkVersion，但這取決於應用程式的建構方式和所使用的平台功能。以下各節將概略說明這些步驟。
開始之前，請務必熟悉行為變更，即使您未變更應用程式的 targetSdkVersion，這些變更仍可能對您的應用程式造成影響。
執行相容性測試
大部分情況下，Android 11 的測試相容性與您準備發布應用程式時執行的測試類似。建議您複習核心應用程式品質指南和測試最佳做法。
只要在執行 Android 11 的裝置上安裝目前的已發布應用程式，並逐步完成所有流程與功能，同時確認是否有任何問題。為協助您專注於測試，請參閱 Android 11 中導入的行為變更，瞭解可能影響應用程式功能或導致應用程式停止運作的行為變更。請務必特別留意隱私權重大異動，並測試為因應這些異動而實作的修正。
此外，請務必檢查並測試受限制的非 SDK 介面使用情形，改用公開 SDK 或 NDK 的對應項目。請留意說明此類存取權限的 Logcat 警告，並使用 StrictMode 方法 detectNonSdkApiUsage()，以程式設計方式進行擷取。
最後，請務必完整測試應用程式的程式庫和 SDK，以確保兩者可在 Android 11 上正常運作，並遵循隱私權、效能、使用者體驗和資料處理與權限的最佳做法。如有任何問題，請試著更新至最新版本的 SDK，或向 SDK 開發人員尋求協助。
完成測試並進行更新後，建議您立即發布相容的應用程式。如此可讓使用者及早測試應用程式，協助您在使用者更新至 Android 11 時，提供流暢的移轉體驗。
更新應用程式的指定目標，並使用新的 API 進行建構
如先前所述，發布相容的應用程式版本後，下一步就是更新 targetSdkVersion，並善用 Android 11 中的新 API 和功能，提供 Android 11 的全方位支援。您準備就緒後即可進行更新，但請留意鎖定新平台目標版本的 Google Play 規定。
在您計畫全面支援 Android 11 的過程中，建議先查看適用於指定 Android 11 為目標版本應用程式的行為變更。這些與鎖定目標版本相關的行為變更可能會導致需要您善加處理的功能問題。在某些情況下，這些變更需要大規模的開發，因此建議您盡早瞭解。為協助您評估影響，您也可以使用相容性切換按鈕，測試已啟用所選變更的現有應用程式。
如要全面支援 Android 11，請按照下列步驟操作。
取得 SDK、變更指定目標、使用新的 API 進行建構
如要開始測試完整的 Android 11 支援功能，請先在 Android Studio 中下載 Android 11 SDK (和任何其他所需工具)。接著，請將應用程式的 targetSdkVersion 和 compileSdkVersion 變更為 "30"，然後重新編譯應用程式。詳情請參閱設定指南。
測試 Android 11 應用程式
編譯應用程式並將其安裝在執行 Android 11 的裝置上之後，請開始進行測試，以確保應用程式在以 Android 11 為目標的環境中能正常運作。某些行為變更僅會在應用程式鎖定新平台版本的情況下套用，因此請在測試前確認此類變更。
和進行基本的相容性測試一樣，逐步完成所有流程與功能測試，並確認是否有任何問題。將測試的重點放在指定 Android 11 版本作為目標版本的應用程式行為變更。請務必特別留意隱私權異動，並測試為因應這些異動而實作的修正。建議您根據核心應用程式品質指南和測試最佳做法，對應用程式進行檢查。
請務必查看並測試可能適用的受限制非 SDK 介面的使用情形。請留意說明此類存取權限的 Logcat 警告，並使用 StrictMode 方法 detectNonSdkApiUsage()，以程式設計方式進行擷取。
最後，請務必完整測試應用程式的程式庫和 SDK，以確保兩者可在 Android 11 上正常運作，並遵循隱私權、效能、使用者體驗和資料處理與權限的最佳做法。如有任何問題，請試著更新至最新版本的 SDK，或向 SDK 開發人員尋求協助。
使用「應用程式相容性」切換按鈕進行測試
Android 11 為開發人員推出新功能，方便您對指定行為變更的應用程式進行測試。如果是可進行偵錯的應用程式，切換按鈕可讓您：
- 在不必實際變更應用程式 targetSdkVersion 的情況下，對鎖定的變更進行測試。您可以使用切換按鈕，強制啟用鎖定的特定行為變更，藉此評估該變更對現有應用程式的影響。
- 僅對特定變更進行測試。如果以指定版本為目標的變更中，您只想測試其中某些變更，則可使用切換按鈕停用不想測試的其他變更，不需要一次處理所有變更。
- 透過 ADB 管理切換按鈕。您可以在自動化測試環境中使用 ADB 指令啟用及停用可切換的變更。
- 使用標準變更 ID 加快偵錯速度。每個可切換的變更均有專屬的 ID 和名稱，可用於在記錄檔輸出中快速找出錯誤的起因。
當您準備變更應用程式的指定目標，或在進行支援 Android 11 的開發作業時，切換按鈕可提供實用協助。詳情請參閱對應的說明文件。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-08-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-08-27 (世界標準時間)。"],[],[],null,["With each release of Android, we introduce new features as well as behavior\nchanges aimed at making the Android more helpful, more secure, and better\nperforming. In many cases your app will work exactly as expected out of the box,\nwhile in other cases you might need to make changes to your app to adapt to the\nplatform changes.\n\nSince users can start receiving the new platform as soon as the source code is\nreleased to AOSP (Android Open Source Project), it's important for apps to be\nready, performing as expected for users and ideally taking advantage of new\nfeatures and APIs to get the most out of the new platform.\n\nThis document offers a high-level view of typical development and testing phases\nthat can help you make a plan for readiness that's well-aligned with the\nplatform release timeline and ensures a great experience for your users on\nAndroid 11.\n\nA typical migration has two phases, which can be concurrent:\n\n- Ensuring app compatibility (by Android 11 final release)\n- Targeting the new platform features and APIs (as soon as possible after final release)\n\nThis page outlines the general steps for each of those phases. When you're ready\nto get started, read [Get Android 11](/about/versions/11/get).\n\nEnsure compatibility with Android 11\n\nIt's important to test the functionality of your existing app against\nAndroid 11 to ensure a great experience for users updating to the\nlatest version of Android. Some platform changes can affect the way your app\nbehaves, so it's important to test early and thoroughly, then make any needed\nadjustments to your app.\n\nTypically you can adjust your app and publish an update without needing to\nchange the app's `targetSdkVersion`. Similarly, you shouldn't need to use new\nAPIs or change the app's `compileSdkVersion`, although this can depend on the\nway your app is built and the platform functionality it's using. The following\nsections outline the steps.\n\nBefore you get started, make sure to familiarize yourself with the [behavior\nchanges](/about/versions/11/behavior-changes-all) that might affect your app, even if you don't change its\n`targetSdkVersion`.\n\nPerform compatibility testing\n\nFor the most part, testing compatibility with Android 11 is\nsimilar to the type of testing you otherwise perform when preparing to release\nyour app. This is a good time to review the [core app quality guidelines](/develop/quality-guidelines/core-app-quality) and\n[best practices for testing](/training/testing).\n\nJust install your current published app on a device running\nAndroid 11 and work through all the flows and functionality\nlooking for issues. To help you focus your testing, **review the [behavior\nchanges](/about/versions/11/behavior-changes-all)** introduced in Android 11 that can affect your app's\nfunction or cause the app to crash. In particular, make sure to review the [key\nprivacy changes](/about/versions/11/privacy) and test any fixes that you implement to accommodate the\nchanges.\n\nAlso make sure to review and **test for uses of restricted non-SDK interfaces**\nand move to public SDK or NDK equivalents instead. Watch for logcat warnings\nthat highlight these accesses and use the StrictMode method\n[`detectNonSdkApiUsage()`](/reference/android/os/StrictMode.VmPolicy.Builder#detectNonSdkApiUsage()) to catch them programmatically.\n\nLast, make sure to fully **test the libraries and SDKs in your app** to make\nsure they work as expected on Android 11 and follow best\npractices for privacy, performance, UX, data handling, and permissions. If you\nfind an issue, try updating to the latest version of the SDK, or reach out to\nthe SDK developer for help.\n\nWhen you've finished your testing and made any updates, we recommend publishing\nyour compatible app right away. This lets your users test the app early, and\nhelps you to deliver a smooth transition to users as they update to\nAndroid 11.\n\nUpdate the app's targeting and build with new APIs\n\nOnce you've published the compatible version of your app as described\npreviously, the next step is to add full support for Android 11\nby updating its `targetSdkVersion` and taking advantage of new aPIs and\ncapabilities Android 11. You can do these as soon as you are\nready, keeping in mind the [Google Play requirement](https://support.google.com/googleplay/android-developer/answer/113469#targetsdk) for targeting the new\nplatform.\n\nAs you plan your work to fully support Android 11, a good place\nto start is reviewing the [behavior changes that apply to apps targeting\nAndroid 11](/about/versions/11/behavior-changes-11). These *targeted behavior changes* may cause\nfunctional issues that you may need to address. In some cases, they can require\nsignificant development, so it's best to learn about them early. To help you\nassess the impacts, you can also use the [compatibility toggles](/about/versions/11/migration#using_app_compatibility_toggles) to test\nyour current app with selected changes enabled.\n\nThe following steps describe how to fully support Android 11.\n\nGet the SDK, change targeting, build with new APIs\n\nTo get started with full Android 11 support, first download the\nAndroid 11 SDK (and any other tools needed) into Android Studio.\nNext change the app's `targetSdkVersion` and `compileSdkVersion` to `\"30\"`and\nre-compile the app. See the [setup guide](/about/versions/11/setup-sdk) for details.\n\nTest your Android 11 app\n\nOnce you've compiled the app and installed it on a device running\nAndroid 11, begin testing to ensure that the app works properly\nwhen targeting Android 11. Some behavior changes apply only when\nyour app is targeting the new platform, so you'll want to [review those\nchanges](/about/versions/11/behavior-changes-11) before getting started.\n\nAs with basic compatibility testing, work through all the flows and\nfunctionality looking for issues. Focus your testing on the\n**[behavior changes for apps targeting Android 11](/about/versions/11/behavior-changes-11)** . In\nparticular, make sure to review the [privacy changes](/about/versions/11/privacy) and test any fixes that\nyou implement to accommodate the changes. It's also a good time to check your\napp against the [core app quality guidelines](/develop/quality-guidelines/core-app-quality) and [best practices for\ntesting](/training/testing).\n\nMake sure to review and **test for uses of [restricted non-SDK interfaces](/about/versions/11/non-sdk-11)**\nthat may apply. Watch for logcat warnings that highlight these accesses and use\nthe StrictMode method [`detectNonSdkApiUsage()`](/reference/android/os/StrictMode.VmPolicy.Builder#detectNonSdkApiUsage()) to catch them\nprogrammatically.\n\nLast, make sure to fully **test the libraries and SDKs in your app** to make\nsure they work as expected on Android 11 and follow best\npractices for privacy, performance, UX, data handling, and permissions. If you\nfind an issue, try updating to the latest version of the SDK, or reach out to\nthe SDK developer for help.\n\nTest using app compatibility toggles\n\nAndroid 11 introduces a new feature for developers that makes it easier to test\nyour app with targeted behavior changes. For a debuggable app, the toggles let\nyou:\n\n- **Test targeted changes without actually changing the app's\n targetSdkVersion**. You can use the toggles to force-enable specific targeted behavior changes to evaluate the impact on your existing app.\n- **Focus your testing on specific changes only**. Rather than having to address all targeted changes at once, the toggles let you disable all targeted changes except the ones you want to test against.\n- **Manage toggles through adb**. You can use adb commands to enable and disable the toggleable changes in your automated test environment.\n- **Debug faster using standard change IDs**. Toggleable changes each have a unique ID and name that you can use to quickly debug root cause in log output.\n\nAs you prepare for changing your app's targeting, or while you in active\ndevelopment for Android 11 support, the toggles can help. See the [corresponding\ndocumentation for more details](/guide/app-compatibility/test-debug)."]]
