我們在 2025 年發布 Android 16 時,分享了裝置生態系統的願景,希望應用程式能順暢地配合任何螢幕調整大小,無論是手機、摺疊式裝置、平板電腦、桌機、車輛螢幕或 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 標記分類為遊戲的應用程式。
| 資訊清單屬性/API | 系統會忽略的值 |
| screenOrientation | portrait、reversePortrait、sensorPortrait、userPortrait、landscape、reverseLandscape、sensorLandscape、userLandscape |
| setRequestedOrientation() | portrait、reversePortrait、sensorPortrait、userPortrait、landscape、reverseLandscape、sensorLandscape、userLandscape |
| resizeableActivity | 全部 |
| minAspectRatio | 全部 |
| maxAspectRatio | 全部 |
此外,使用者仍可自行控管。在長寬比設定中,使用者可以明確選擇是否要使用應用程式要求的行為。
準備應用程式
應用程式必須支援橫向和直向版面配置,適用於使用者可選擇使用的所有顯示比例,包括可調整大小的視窗,因為系統不再允許將顯示比例和螢幕方向限制為直向或橫向。
測試應用程式
首先,請使用這些變更測試應用程式,確保應用程式在各種螢幕尺寸上都能正常運作。
在 Android Studio 中使用 Pixel Tablet 和 Pixel Fold 系列模擬器,並設定 targetSdkPreview = “CinnamonBun”,即可使用 Android 17 Beta 版 1。此外,如果您的應用程式尚未指定 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 做好準備!
繼續閱讀
-
產品新訊
隨著 Pixel 10 Pro Fold 等新板型規格加入 Android 生態系統,開發人員必須打造適應性應用程式,才能在手機、平板電腦和摺疊式裝置上提供優質使用者體驗。
Fahd Imtiaz, Miguel Montemayor • 3 分鐘可讀完
-
產品新訊
從擴增疊加層到完全沉浸式環境,Android XR 生態系統正在迅速擴展,Samsung Galaxy XR 也已於今天上市。
Stevan Silva, Vinny DaSilva • 3 分鐘可讀完
-
產品新訊
每年 Google I/O 大會都會發布生態系統和產品的最新消息與資源,包括 Android 開發。隨著開發工作轉向 AI 和代理程式輔助工具,我們也擴大產品陣容,無論您決定如何建構 Android 應用程式,都能獲得更完善的支援。
Simona Milanovic • 閱讀時間:2 分鐘
隨時掌握最新消息
每週透過電子郵件接收最新的 Android 開發洞察資訊。