我們在 2025 年發布 Android 16 時，分享了對裝置生態系統的願景，希望應用程式能順暢地適應任何螢幕，無論是手機、摺疊式裝置、平板電腦、桌機、車輛螢幕或 XR 裝置。使用者希望應用程式在任何地方都能運作。無論是在平板電腦上執行多工處理、展開裝置舒適閱讀，還是在電腦分割視窗環境中執行應用程式，使用者都希望使用者介面能填滿可用的顯示空間，並配合裝置姿勢調整。

我們大幅調整螢幕方向和視窗大小調整 API，以利適應性行為，同時提供暫時選擇不採用選項，協助您完成轉換。我們發現許多開發人員在指定 API 級別 36 時，已成功適應這項異動。

隨著 Android 17 Beta 版發布，我們將進入自動調整式藍圖的下一個階段：Android 17 (API 級別 37) 會移除開發人員的停用選項，針對大螢幕裝置 (sw > 600 dp) 限制螢幕方向和大小調整功能。指定目標 API 級別 37 時，應用程式必須能配合各種螢幕大小調整。

這些行為異動可確保 Android 生態系統在所有裝置板型規格上，都能提供一致的高品質體驗。

Android 17 的異動內容

以 Android 17 為目標的應用程式，必須確保與 Android 16 中淘汰的資訊清單屬性和執行階段 API 相容。我們瞭解這項異動對部分應用程式來說可能影響很大，因此這篇網誌文章稍後會提供最佳做法和工具，協助您避免常見問題。

自 Android 16 以來，我們未推出任何新變更，但開發人員無法再選擇不採用這些變更。提醒您，如果應用程式是在大螢幕上執行 (大螢幕是指螢幕的較小尺寸大於或等於 600 dp)，系統會忽略下列資訊清單屬性和 API：

注意： 如先前在 Android 16 中所述，這些變更不適用於小於 sw 600 dp 的螢幕，也不適用於根據 android:appCategory 旗標歸類為遊戲的應用程式。

此外，使用者仍保有控制權。使用者可以在長寬比設定中，明確選擇使用應用程式要求的行為。

準備應用程式

應用程式必須支援橫向和直向版面配置，以配合使用者可選擇使用的顯示大小 (包括可調整大小的視窗)，因為系統不再允許將顯示比例和螢幕方向限制為直向或橫向。

測試應用程式

首先，請測試應用程式是否能因應這些變更，在各種螢幕尺寸上正常運作。

在 Android Studio 中，使用 Android 17 Beta 1 搭配 Pixel Tablet 和 Pixel Fold 系列模擬器，並設定 targetSdkPreview = “CinnamonBun”。或者，如果您的應用程式尚未指定目標 API 級別 36，可以啟用 UNIVERSAL_RESIZABLE_BY_DEFAULT 標記，使用應用程式相容性架構。

我們提供額外工具，確保版面配置能正確調整。您可以使用 Compose UI Check 自動稽核 UI 並取得建議，讓 UI 更具適應性，也可以使用 DeviceConfigurationOverride 在測試中模擬特定螢幕特性。

如果應用程式過去限制了螢幕方向和顯示比例，通常會發生相機預覽畫面傾斜或方向錯誤、版面配置遭到延展、按鈕無法存取，或是在處理設定變更時遺失使用者狀態等問題。

我們來看看如何解決這些常見問題。

確認攝影機是否相容

在橫向摺疊式裝置上，或在多視窗模式、電腦分割視窗或連線螢幕等情境中計算顯示比例時，常見的問題是相機預覽畫面出現延展、旋轉或裁剪情形。

確認攝影機預覽畫面未經過延展或旋轉。

在大螢幕和摺疊式裝置上，應用程式會假設相機功能 (例如顯示比例和感應器方向) 與裝置功能 (例如裝置方向和自然方向) 之間存在固定關係，因此經常發生這個問題。

為確保相機預覽畫面能正確配合任何視窗大小或方向，請考慮下列四種解決方案：

解決方案 1：Jetpack CameraX (建議) 

最簡單且最穩健的解決方案是使用 Jetpack CameraX 程式庫。其 PreviewView UI 元素可自動處理所有預覽複雜度：

• PreviewView 正確調整感應器方向、裝置旋轉和縮放
• PreviewView 會維持相機影像的長寬比，通常是透過置中和裁剪 (FILL_CENTER)
• 如有需要，您可以將調整類型設為 FIT_CENTER，在預覽畫面加上上下黑邊

詳情請參閱 CameraX 說明文件中的「實作預覽」。

解決方案 2：CameraViewfinder 

如果您使用現有的 Camera2 程式碼集，CameraViewfinder 程式庫 (可回溯相容於 API 級別 21) 也是另一種現代解決方案。它會使用 TextureView 或 SurfaceView，並為您套用所有必要的轉換 (顯示比例、縮放和旋轉)，簡化攝影機畫面的顯示方式。

詳情請參閱「Introducing Camera Viewfinder」網誌文章和「相機預覽」開發人員指南。

解決方案 3：手動實作 Camera2 

如果無法使用 CameraX 或 CameraViewfinder，您必須手動計算螢幕方向和顯示比例，並確保每次設定變更時都會更新計算結果：

• 從 CameraCharacteristics 取得攝影機感應器方向 (例如 0、90、180、270 度)
• 取得裝置目前的螢幕旋轉角度 (例如 0、90、180、270 度)
• 使用相機感應器方向和螢幕旋轉值，判斷 SurfaceView 或 TextureView 的必要轉換
• 請確保輸出內容的顯示比例 Surface 與相機預覽畫面的顯示比例一致，以免畫面扭曲

重要事項：請注意，相機應用程式可能會在部分畫面上執行，無論是多視窗模式、電腦分割視窗模式或連線螢幕都一樣。因此，螢幕大小不應用於判斷相機觀景窗的尺寸，請改用視窗指標。否則相機預覽畫面可能會延展。

詳情請參閱「相機預覽」開發人員指南和「在不同板型規格上使用相機應用程式」影片。

解決方案 4：使用 Intent 執行基本相機動作 

如果不需要太多相機功能，簡單明瞭的解決方案是執行基本相機動作，例如使用裝置的預設相機應用程式拍攝相片或影片。在這種情況下，您可以直接使用 Intent，不必整合相機程式庫，方便維護及調整。

詳情請參閱「相機意圖」。

避免 UI 遭到延展或按鈕無法存取

如果應用程式預設為特定裝置螢幕方向或螢幕顯示比例，當應用程式在不同螢幕方向或視窗大小下使用時，可能會發生問題。

確認按鈕、文字欄位和其他元素在大螢幕上不會延展。

你可能已將按鈕、文字欄位和資訊卡設為 fillMaxWidth 或 match_parent。在手機上看起來很棒。不過，在橫向模式下，平板電腦或摺疊式裝置的 UI 元素會延展至整個大螢幕。在 Jetpack Compose 中，您可以使用 widthIn 修飾符為元件設定最大寬度，避免內容延展：

Box(
    contentAlignment = Alignment.Center,
    modifier = Modifier.fillMaxSize()
) {
    Column(
        modifier = Modifier
            .widthIn(max = 300.dp) // Prevents stretching beyond 300dp
            .fillMaxWidth()        // Fills width up to 300dp
            .padding(16.dp)
    ) {
        // Your content
    }
}

如果使用者在折疊式裝置或平板電腦上以橫向模式開啟應用程式，畫面底部的動作按鈕 (例如「儲存」或「登入」) 可能會顯示在螢幕外。如果容器無法捲動，使用者可能無法繼續操作。在 Jetpack Compose 中，您可以將 verticalScroll 修飾符新增至元件：

Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(rememberScrollState())
        .padding(16.dp)
)

將寬度上限限制與垂直捲動功能結合，即可確保應用程式維持正常運作，且無論應用程式視窗大小如何變化，都能正常使用。

請參閱建構自動調整版面配置指南。

在設定變更期間保留狀態

移除螢幕方向和顯示比例限制後，應用程式視窗大小的變化頻率會大幅增加。使用者可能會旋轉裝置、摺疊/展開裝置，或在分割畫面或電腦分割視窗模式中動態調整應用程式大小。

根據預設，這些設定變更會刪除並重新建立活動。如果應用程式未妥善管理這項生命週期事件，使用者就會有令人沮喪的體驗：捲動位置重設為頂端、填寫到一半的表單遭到清除，以及瀏覽記錄遺失。為確保提供順暢的自適應體驗，應用程式必須在這些設定變更期間保留狀態。使用 Jetpack Compose 時，您可以選擇不重新建立，而是允許視窗大小變更重新組合 UI，以反映可用的新空間大小。

請參閱儲存 UI 狀態指南。

2027 年 8 月前將目標 API 級別設為 37

如果應用程式先前指定 API 級別 36 時選擇不採用這些變更，則只有在應用程式指定 API 級別 37 後，才會受到 Android 17 停用選項移除作業影響。為協助您提前規劃並對應用程式進行必要調整，以下是這些異動的生效時間表：

• Android 17：上述變更將成為指定目標 API 級別 37 的應用程式，在大螢幕裝置 (最小螢幕寬度 > 600 dp) 上的基本體驗。開發人員無法選擇不採用。

指定特定 API 級別的期限因應用程式商店而異。Google Play 規定新應用程式和更新必須指定 API 級別 37，因此這項行為將於 2027 年 8 月成為發布的必要條件。

為 Android 17 做好準備

如要瞭解 Android 17 中影響應用程式的所有變更，請參閱 Android 17 變更頁面。如要測試應用程式，請下載 Android 17 Beta 版 1 並更新至 targetSdkPreview = “CinnamonBun”，或使用應用程式相容性架構啟用特定變更。

Android 的未來是適應性，我們很樂意協助您達成目標。準備迎接 Android 17 時，建議您參閱建構自適應版面配置指南，以及大螢幕品質指南。這些資源可協助您輕鬆處理多種板型規格和視窗大小。

別再觀望了，立即開始為 Android 17 做好準備！