Android 中的應用程式相容性
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
以 Android 系統來說,「應用程式相容性」一詞含意,是指應用程式在平台的特定版本 (通常是最新版本) 可正常執行。每次推出新版本時,我們都會採取重要變更,改善隱私權和安全性,並且實作各項變更,全面提升 OS 中的整體使用者體驗。有時這些變更會影響您的應用程式,因此請務必查看各發布版本所包含的行為變更、針對這些變更測試應用程式,然後為使用者發布相容性更新。
應用程式相容性為何重要
不管是購買新裝置,還是在當前裝置上安裝更新,只要使用者更新至最新的 Android 版本,應用程式是否具備相容性就十分重要。他們會對最新版的 Android 充滿期待,並希望透過喜愛的應用程式體驗新版本。假如應用程式無法正常運作,可能會為使用者和開發人員都帶來重大問題。
平台行為變更類型
在新的平台版本上執行時,應用程式可能會受到以下兩種變更的影響:
針對所有應用程式的變更
無論應用程式的 targetSdkVersion
為何,在該 Android 版本上執行的所有應用程式都會受到此類變更的影響。
在各個新 Android 版本推出開發人員預覽版和 Beta 版期間,您應主動測試應用程式與這些變更的相容性。當新的 Android 版本進入 Android 開放原始碼計畫 (AOSP) 的最終發布階段時,Pixel 和其他裝置就會即時更新,因此如果您主動測試這些變更,就有助於確保使用者在這些裝置上順利轉換使用最新 Android 版本。
指定目標變更
這些變更只會影響指定該 Android 版本的應用程式。
對於此類變更,建議在準備指定最新的穩定 API 版本 (Android 16,API 級別 36) 時執行相容性測試。即使您不打算立即指定新的 Android 版本,處理這些變更可能需耗費大量開發時間,因此建議您在各個新 Android 版本推出開發人員預覽版和 Beta 版期間,盡早瞭解這些變更,以便執行初步測試並提供意見回饋。
相容性架構工具
為協助您測試相容性,我們會在相容性架構中,盡可能為每個版本納入破壞性變更。在相容性架構中加入相關變更有助於切換,方便您透過開發人員選項或 ADB 強制啟用或停用單項變更。使用相容性架構時,您無需變更應用程式的 targetSdkVersion
或重新編譯應用程式來進行基本測試。
詳情請參閱在應用程式中測試及偵錯平台行為變更。
針對非 SDK 介面的限制
為了讓開發人員能夠逐步停用非 SDK API,我們會在每個 Android 版本中更新受限制的非 SDK 介面清單。與往常一樣,歡迎您提供意見,並提出使用公用 API (同等項目) 的要求。
進一步瞭解最新的 Android 版本:
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。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,["For Android, the term *app compatibility* means that your app runs properly on a\nspecific version of the platform, typically the latest version. With each\nrelease, we make integral changes that improve privacy and security, and we\nimplement changes that evolve the overall user experience across the OS.\nSometimes these changes can affect your apps, so it's important to take a look\nat the behavior changes that are included in each released version, test against\nthem, and publish compatibility updates for your users.\n\nWhy app compatibility is important\n\nApp compatibility starts to affect your users immediately when they update to\nthe latest version of Android, whether they've purchased a new device or\ninstalled an update on their current device. They're excited to explore the\nlatest version of Android, and they want to experience it with their favorite\napps. If their apps don't work properly, it can cause major issues both for them\nand for you.\n\nTypes of platform behavior changes\n\nYour app can be affected by two different types of changes when running on a new\nplatform version:\n\nChanges for all apps\n\nThese changes affect all apps that run on that version of Android, regardless of\nan app's `targetSdkVersion`.\n\nYou should test your app's compatibility with these changes proactively during\nthe developer preview and beta releases of each new Android version. Updates to\nPixel and other devices start as soon as a new Android version reaches its final\nrelease to [Android Open Source Project (AOSP)](https://source.android.com/), so when you test proactively\nfor these changes, you help ensure that your users can seamlessly transition to\nthe latest Android version on these devices.\n\nTargeted changes\n\nThese changes only affect apps that are targeting that version of Android.\n\nFor these changes, you should perform compatibility testing as you prepare to\n[target the latest stable API version](/distribute/best-practices/develop/target-sdk), which is\nAndroid 16 (API level 36). Even if you aren't planning to target a new\nAndroid version immediately, addressing these changes can require a significant\namount of development. You should learn about these changes as early as\npossible---ideally during the developer preview and beta releases of each new\nAndroid version---so you can do preliminary testing and provide feedback.\n\nCompatibility framework tools\n\nTo help you test for compatibility, we include as many of the breaking changes\nas possible each release in the compatibility framework. Including a change in\nthe compatibility framework makes it toggleable, letting you force-enable or\ndisable the changes individually from developer options or ADB. When using the\ncompatibility framework, you don't need to change your app's `targetSdkVersion`\nor recompile your app for basic testing.\n\nTo learn more, see [Test and debug platform behavior changes in your app](/guide/app-compatibility/test-debug).\n\nRestrictions on non-SDK interfaces\n\nAs part of our ongoing effort to gradually move developers away from non-SDK\nAPIs, we update the [lists of restricted non-SDK interfaces](/guide/app-compatibility/restrictions-non-sdk-interfaces) in each Android\nrelease. As always, your feedback and [requests for public API equivalents](/guide/app-compatibility/restrictions-non-sdk-interfaces#feature-request)\nare welcome.\n\nPlatform releases\n\nLearn more about the latest Android releases:\n\n- [Android 15 (API level 35)](/about/versions/15)\n- [Android 14 (API level 34)](/about/versions/14)\n- [Android 13 (API level 33)](/about/versions/13)\n- [Android 12 (API levels 31, 32)](/about/versions/12)\n- [Android 11 (API level 30)](/about/versions/11)"]]