行為變更：指定 Android 16 以上版本的應用程式

和先前版本一樣，Android 16 也包含可能會影響應用程式的行為變更。以下行為變更僅適用於指定 Android 16 以上版本的應用程式。如果您的應用程式指定 Android 16 以上版本，建議您視情況修改應用程式，以支援這些行為。

此外，無論應用程式的 targetSdkVersion 為何，請務必查看影響所有在 Android 16 上執行的應用程式行為變更清單。

使用者體驗和系統使用者介面

Android 16 包含下列變更，旨在打造更一致、直覺的使用者體驗。

無邊框螢幕的選擇不採用功能即將停用

Android 15 針對以 Android 15 (API 級別 35) 為目標版本的應用程式強制執行邊到邊，但您的應用程式可以將 R.attr#windowOptOutEdgeToEdgeEnforcement 設為 true，即可選擇不採用。如果應用程式以 Android 16 為目標版本，R.attr#windowOptOutEdgeToEdgeEnforcement 已淘汰且已停用，因此應用程式無法選擇不採用全螢幕模式。

如要在 Android 16 Beta 版 2 中進行測試，請確認您的應用程式支援無邊框設計，並移除所有 R.attr#windowOptOutEdgeToEdgeEnforcement 的用途。如要支援全螢幕模式，請參閱 Compose 和 Views 指南。請在意見回饋頁面中，透過 Issue Tracker 告知我們您的疑慮。

必須遷移或選擇不採用預測返回功能

如果應用程式指定 Android 16 以上版本，並在 Android 16 以上版本的裝置上執行，預測返回系統動畫 (返回首頁、跨工作和跨活動) 會預設啟用。此外，系統不會再呼叫 onBackPressed，也不會再調度 KeyEvent.KEYCODE_BACK。

如果您的應用程式攔截返回事件，且尚未遷移至預測返回功能，請更新應用程式以使用支援的返回導覽 API。或者，您也可以在應用程式 AndroidManifest.xml 檔案的 <application> 或 <activity> 標記中，將 android:enableOnBackInvokedCallback 屬性設為 false，暫時停用這項功能。

預測返回主畫面動畫。
預測跨活動動畫。
預測跨工作動畫。

Elegant 字型 API 已淘汰並停用

指定 Android 15 (API 級別 35) 為目標版本的應用程式，其 elegantTextHeight TextView 屬性預設為 true，會將精簡字型取代為更易閱讀的字型。您可以將 elegantTextHeight 屬性設為 false，即可覆寫這項設定。

Android 16 已淘汰 elegantTextHeight 屬性，且一旦應用程式指定 Android 16 為目標版本，系統就會忽略該屬性。這些 API 控制的「UI 字型」即將停用，因此您應調整所有版面配置，確保阿拉伯文、老撾文、緬甸文、泰米爾文、古吉拉特文、卡納達文、馬拉雅拉姆文、奧底亞文、泰盧固文或泰文的文字算繪作業能保持一致，並能支援日後的版本。

elegantTextHeight 行為 (適用於指定 Android 14 (API 級別 34) 以下版本為目標版本的應用程式，或指定 Android 15 (API 級別 35) 為目標版本的應用程式，但已透過將 elegantTextHeight 屬性設為 false 而覆寫預設值)。
elegantTextHeight 行為：針對指定 Android 16 為目標版本的應用程式，或是指定 Android 15 (API 級別 35) 為目標版本的應用程式，但未透過將 elegantTextHeight 屬性設為 false 來覆寫預設值。

核心功能

Android 16 包含下列變更，可修改或擴充 Android 系統的各種核心功能。

固定費率工作排程最佳化

在指定 Android 16 之前，如果 scheduleAtFixedRate 因不在有效的程序生命週期中而錯過執行工作，則應用程式返回有效生命週期時，所有錯過的執行作業會立即執行。

針對 Android 16 進行指定時，應用程式返回有效生命週期時，最多會立即執行 一次遺漏的 scheduleAtFixedRate 執行作業。這項行為異動預計可改善應用程式效能。在應用程式中測試這項行為，確認應用程式是否受到影響。您也可以使用應用程式相容性架構，並啟用 STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS 相容性標記來進行測試。

裝置板型規格

Android 16 針對大螢幕裝置上顯示的應用程式，納入下列變更。

自動調整式版面配置

由於 Android 應用程式現在可在各種裝置 (例如手機、平板電腦、折疊式裝置、電腦、車輛和電視) 上執行，且可在大型螢幕上使用視窗模式 (例如分割畫面和電腦視窗模式)，因此開發人員應建構可在任何螢幕和視窗大小下運作的 Android 應用程式，無論裝置方向為何皆可。在現今的多裝置世界中，限制螢幕方向和大小調整等模式過於嚴苛。

忽略螢幕方向、是否可調整大小和顯示比例限制

針對以 Android 16 為目標版本的應用程式，Android 16 包含系統管理方向、大小調整和顯示比例限制的方式變更。在最小寬度大於等於 600 dp 的螢幕上，系統就不會再套用這些限制。無論顯示比例或使用者偏好的螢幕方向為何，應用程式都會填滿整個顯示視窗，且不會使用上下黑邊。

這項變更會引入新的標準平台行為。Android 正朝向新模型邁進，應用程式應能根據不同的方向、顯示大小和顯示比例自動調整。固定螢幕方向或限制尺寸調整功能等限制會影響應用程式的適應性，因此建議讓應用程式具備適應性，以便提供最佳使用者體驗。

您也可以使用 [應用程式相容性架構][a16-kilo-14] 並啟用 UNIVERSAL_RESIZABLE_BY_DEFAULT 相容性標記，來測試這項行為。

常見的破壞性變更

忽略方向、可調整大小和顯示比例限制，可能會影響部分裝置上的應用程式 UI，尤其是針對小型版面配置設計的元素，因為這些元素會鎖定在直向方向：例如，會發生版面配置拉伸、畫面外動畫和元件等問題。任何有關顯示比例或方向的假設都可能導致應用程式出現視覺問題。請參閱這篇文章，進一步瞭解如何避免這些問題，並改善應用程式的自適應行為。

允許裝置旋轉會導致更多活動重建，如果未妥善保留，可能會導致使用者狀態遺失。如要瞭解如何正確儲存 UI 狀態，請參閱「儲存 UI 狀態」。

導入作業詳細資料

在全螢幕和多視窗模式下，系統會忽略大型螢幕裝置的下列資訊清單屬性和執行階段 API：

系統會忽略下列 screenOrientation、setRequestedOrientation() 和 getRequestedOrientation() 的值：

  • portrait
  • reversePortrait
  • sensorPortrait
  • userPortrait
  • landscape
  • reverseLandscape
  • sensorLandscape
  • userLandscape

就螢幕可調整大小而言，android:resizeableActivity="false"、android:minAspectRatio 和 android:maxAspectRatio 都沒有任何影響。

針對以 Android 16 為目標版本的應用程式，系統預設會忽略大型螢幕上的應用程式方向、大小調整和顯示比例限制，但所有尚未完全就緒的應用程式都可以選擇停用，暫時覆寫這項行為 (這會導致先前放入相容性模式的行為)。

例外狀況

在下列情況下，Android 16 的方向、大小調整和顯示比例限制不適用：

  • 遊戲 (根據 android:appCategory 標記)
  • 使用者在裝置的顯示比例設定中，明確選擇啟用應用程式的預設行為
  • 螢幕大小小於 sw600dp

暫時退出

如要選擇不顯示特定活動，請宣告 PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY 資訊清單屬性：

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

如果應用程式有太多部分尚未準備好支援 Android 16，您可以在應用程式層級套用相同的屬性，完全選擇拒絕：

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

健康與健身

Android 16 包含下列與健康與健身資料相關的變更。

健康與健身權限

針對指定 Android 16 以上版本為目標版本的應用程式，BODY_SENSORS 權限會轉換為 android.permissions.health 下的細項權限，Health Connect 也會使用這些權限。先前需要 BODY_SENSORS 或 BODY_SENSORS_BACKGROUND 的任何 API，現在都需要對應的 android.permissions.health 權限。這會影響下列資料類型、API 和前景服務類型：

如果您的應用程式使用這些 API，現在應要求相應的精細權限：

這些權限與保護從 Health Connect 讀取資料的權限相同，Health Connect 是用於健康、健身和保健資料的 Android 資料儲存庫。