調整應用程式，準備因應 Android 17 的大小調整和螢幕方向變更

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

我們對螢幕方向和可調整大小 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 中，搭配 Pixel Tablet 和 Pixel Fold 系列模擬器使用 Android 17 Beta 1，並設定 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，並套用所有必要轉換 (顯示比例、縮放和旋轉)，簡化顯示攝影機畫面的程序。

詳情請參閱「CameraViewfinder 介紹」網誌文章和「相機預覽」開發人員指南。

解決方案 3：手動導入 Camera2 

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

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

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

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

解決方案 4：使用意圖執行基本相機操作 

如果您不需要太多相機功能，簡單直接的解決方案是執行基本相機操作，例如使用裝置的預設相機應用程式拍攝相片或影片。在這種情況下，您只要使用 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 做好準備！