
全球范围内有超过 30 亿台 Android 设备正在使用中,这使得 Android 生态系统比以往任何时候都更加活跃。Android 移动应用能够在手机、可折叠设备、平板电脑、Chromebook、汽车以及最新的 XR 设备等多种设备上运行。用户选择的是一个完整的设备生态系统,并期望他们的应用能够在所有设备上运行。您的应用需要无缝地适应不同的屏幕大小和设备形态,以在这个多设备环境中蓬勃发展。
许多 Android 应用依赖于在单一屏幕方向和/或限制了大小调整的情况下工作的界面方法。然而,用户希望应用能够充分利用大屏优势,因此 Android 设备制造商引入了备受好评的功能,以突破这些应用的限制。
鉴于此,Android 16 将在平台层面取消应用限制屏幕方向和大小调整的能力,转而采用一种统一的自适应应用模式,使应用能无缝适应不同的屏幕大小和方向。通过这一变更,应用的行为将更好地满足用户的期望,从而减少碎片化现象。同时,通过尊重用户对屏幕方向的偏好设置,提升应用的无障碍性。我们正在构建相关工具、库和平台 API,以帮助您实现这一点,从而在整个 Android 生态系统中提供始终如一的卓越用户体验。
有哪些变更?
从 Android 16 开始,我们将逐步淘汰用于限制应用屏幕方向和大小调整的清单属性及运行时 API,从而在各种设备上为众多应用带来更好的用户体验。
这些变更最初将适用于应用在大屏设备上运行时,其中 "大屏" 指的是显示区域的最小宽度大于或等于 600dp 的情况。这包括:
大屏可折叠设备的内屏平板电脑,包括桌面窗口模式桌面环境,包括 Chromebook以下清单属性和 API 将在以 Android 16 (SDK 36) 为目标的大屏设备应用中被忽略:
清单属性/API
忽略的值
screenOrientation
portrait、reversePortrait、sensorPortrait、userPortrait、landscape、reverseLandscape、sensorLandscape、userLandscape
setRequestedOrientation()
portrait、reversePortrait、sensorPortrait、userPortrait、landscape、reverseLandscape、sensorLandscape、userLandscape
resizeableActivity
所有
minAspectRatio
所有
maxAspectRatio
所有
在屏幕方向控制、宽高比和大小调整方面,这些变更有一些例外情况:
如前所述,这些变更不适用于最小宽度小于 600dp 的屏幕 (例如大多数手机、"翻盖" 式设备和大屏可折叠设备的外屏)基于 android:appCategory 标志,游戏将不受这些变更的影响此外,用户拥有控制权。他们可以在宽高比设置中明确选择使用应用的默认行为。

以 API 级别 36 为目标的应用,此前在大屏设备上呈信箱模式显示,现于 Android 16 上以横向模式铺满整个显示屏。
让应用具备自适应性,为即将到来的变更做好准备
应用需要支持横向和纵向布局,以适应用户可以选择的各种宽高比的窗口大小。因为将没有办法限制宽高比和屏幕方向仅为纵向或横向。
要测试您的应用是否会受这些变更影响,可以在 Android Studio 中使用搭载 Pixel Tablet 和 Pixel Fold 系列模拟器的 Android 16 Beta 1 开发者预览版,并设置 targetSdkPreview = "Baklava" 或通过启用 UNIVERSAL_RESIZABLE_BY_DEFAULT 标志来使用应用兼容性框架。
对于那些限制屏幕方向和宽高比的现有应用,这些变更可能导致布局重叠等问题。为了解决这些问题并满足用户期望,我们的愿景是使应用具备自适应性,以确保无论用户是在手机、可折叠设备、平板电脑、Chromebook、XR 设备还是在车内使用应用时,都能获得最佳体验。
解决常见问题
避免界面组件拉伸:如果布局是在假设为手机屏幕的情况下设计和构建的,那么应用功能可能会在其他宽高比下出现问题。例如,如果布局是在假设纵向宽高比的情况下构建的,那么填充窗口最大宽度的界面元素在横向窗口中会被拉伸。如果布局没有构建滚动功能,用户可能无法点击屏幕外的按钮或其他界面元素,从而导致功能混淆或失效。为避免拉伸,需要为组件添加最大宽度,并添加滚动功能以确保所有内容都可访问。确保相机在两种屏幕方向上的兼容性:相机取景器预览可能假设相对于相机传感器的特定宽高比和屏幕方向,一旦这些假设不成立,就可能导致预览画面拉伸或翻转。请确保取景器能够正确旋转,并考虑到界面的宽高比与传感器的宽高比不同。在窗口大小变化时保持状态:取消屏幕方向和宽高比限制也意味着,应用的窗口大小将更频繁地根据用户使用应用的偏好发生变化,例如旋转、折叠设备,或在多窗口/自由窗口模式下调整应用大小。默认情况下,屏幕方向变化和调整大小会导致 Activity 重建。为了确保良好的用户体验,在这些配置变更的过程中保留应用状态至关重要,以免用户在更改设备状态或更改窗口模式时丢失之前的操作进度。为了适应不同的窗口大小和宽高比,应使用窗口大小类来驱动布局行为,这种方式不需要针对特定设备进行自定义。在构建应用时,还应假设窗口大小会频繁变化。没有必要为不同的屏幕方向构建重复的特定布局,而是应确保现有界面在任何窗口大小下都能顺利地重新布局。如果您有专门针对横向或纵向设计的布局,那么这些布局仍然会被使用。
通过构建自适应性来优化窗口大小
如果您已经在构建自适应布局并支持所有屏幕方向,那么您就已经为成功做好了准备,因为您的应用将能够适应用户希望使用的各种设备类型和窗口模式。这些变更对您应用的影响会很小。
我们还提供了一系列测试资源,帮助您保证应用的可靠性。您可以使用 Espresso 测试框架和 Jetpack Compose 测试 API 等工具进行自动化测试。
时间表
我们理解,这些变更对于长期以来只支持纵向显示的应用来说意义重大。此类应用可能需要调整界面问题,例如按钮超出屏幕、内容重叠或屏幕带有相机取景器等。
为了帮助您提前规划并做出必要的调整,以下是这些变更的生效时间表:
Android 16 (2025):上述变更将成为以 API 级别 36 为目标的应用在大屏设备 (最小屏幕宽度大于 600dp) 上的基本体验,开发者可以选择暂不更改调整。2026 年的 Android 版本:上述变更将成为以 API 级别 37 为目标的应用在大屏设备 (最小屏幕宽度大于 600dp) 上的基本体验,开发者必须选择接受。目标 API 级别
适用设备
开发者是否能选择不接受
36(Android 16)
大屏设备 (最小屏幕宽度 > 600dp)
是
37
(预计)
大屏设备 (最小屏幕宽度 > 600dp)
否
针对特定 API 级别的截止日期取决于具体的应用商店。对于 Google Play,我们计划在 2026 年 8 月前应用需以 API 级别 36 为目标,在 2027 年 8 月前应用需以 API 级别 37 为目标。