产品资讯

让您的应用为 Android 17 中的尺寸调整能力和屏幕方向变更做好准备

阅读用时:6 分钟
Miguel Montemayor
开发者关系工程师

随着 Android 16 在 2025 年发布,我们分享了对设备生态系统的愿景,即应用能够无缝适应任何屏幕,无论是手机、可折叠设备、平板电脑、桌面设备、车载显示屏还是 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:

注意: 如前文所述,对于小于 sw 600 dp 的屏幕或根据 android:appCategory 标志归类为游戏的应用,这些更改不适用。

清单属性/API忽略的值
screenOrientation竖屏、反向竖屏、传感器竖屏、用户竖屏、横屏、反向横屏、传感器横屏、用户横屏
setRequestedOrientation()竖屏、反向竖屏、传感器竖屏、用户竖屏、横屏、反向横屏、传感器横屏、用户横屏
resizeableActivity全部
minAspectRatio全部
maxAspectRatio全部

此外,用户可以保留控制权。在宽高比设置中,用户可以明确选择启用应用请求的行为。

准备应用

应用需要支持横屏和竖屏布局,以适应用户可以选择使用的各种宽高比的显示尺寸(包括可调整大小的窗口),因为将无法再将宽高比和屏幕方向限制为竖屏或横屏。

测试应用

第一步是使用这些变更测试您的应用,以确保应用在各种显示屏尺寸下都能正常运行。

在 Android Studio 中将 Android 17 Beta 1 与 Pixel Tablet 和 Pixel Fold 系列模拟器搭配使用,并设置 targetSdkPreview = “CinnamonBun”。或者,如果您的应用尚未以目标 API 级别 36 为目标平台,您也可以通过启用 UNIVERSAL_RESIZABLE_BY_DEFAULT 标志来使用应用兼容性框架

我们还提供了一些其他工具,可确保您的布局能够正确适应。您可以使用 Compose 界面检查自动审核界面并获取建议,使界面更具自适应性;还可以使用 DeviceConfigurationOverride 在测试中模拟特定的显示特征。

对于过去限制了屏幕方向和宽高比的应用,我们经常会看到以下问题:相机预览倾斜或方向错误、布局拉伸、按钮无法访问,或者在处理配置更改时丢失用户状态。

下面我们来看看解决这些常见问题的一些策略。

确保相机兼容性

在横屏可折叠设备上或在多窗口模式、窗口化模式或外接显示屏等场景中进行宽高比计算时,常见的问题是相机预览画面出现拉伸、旋转或剪裁。

camera_preview_issue.png

确保摄像头预览画面未被拉伸或旋转。

此问题通常发生在大屏设备和可折叠设备上,因为应用假定相机功能(例如宽高比和传感器方向)与设备功能(例如设备方向和自然方向)之间存在固定关系。

为确保相机预览能够正确适应任何窗口大小或屏幕方向,请考虑以下四种解决方案:

解决方案 1:Jetpack CameraX(首选) 

最简单且最可靠的解决方案是使用 Jetpack CameraX 库。其 PreviewView 界面元素旨在自动处理所有预览复杂性:

  • PreviewView 正确调整传感器方向、设备旋转和缩放
  • PreviewView 会保持相机图像的宽高比,通常通过居中和裁剪来实现 (FILL_CENTER)
  • 您可以将缩放类型设置为 FIT_CENTER,以便在需要时对预览进行信箱模式处理

如需了解详情,请参阅 CameraX 文档中的实现预览

解决方案 2:CameraViewfinder 

如果您使用的是现有的 Camera2 代码库,CameraViewfinder 库(向后兼容到 API 级别 21)是另一种现代解决方案。它通过使用 TextureViewSurfaceView 并为您应用所有必要的转换(宽高比、缩放和旋转),简化了摄像头画面的显示。

如需了解详情,请参阅相机取景器简介博文和相机预览开发者指南。

解决方案 3:手动实现 Camera2 

如果您无法使用 CameraX 或 CameraViewfinder,则必须手动计算屏幕方向和宽高比,并确保在每次配置变更时更新计算结果:

  • CameraCharacteristics 获取摄像头传感器方向(例如 0、90、180、270 度)
  • 获取设备的当前显示旋转角度(例如,0 度、90 度、180 度、270 度)
  • 使用摄像头传感器方向和显示旋转值来确定 SurfaceView 或 TextureView 所需的转换
  • 确保输出的宽高比 Surface 与相机预览的宽高比一致,以免出现画面变形

重要提示:请注意,相机应用可能在屏幕的一部分区域运行,无论是在多窗口模式、窗口化模式下还是在连接的显示屏上。因此,不应使用屏幕尺寸来确定相机取景器的尺寸,而应使用窗口指标。否则,相机预览可能会拉伸。

如需了解详情,请参阅相机预览开发者指南和不同设备类型上的相机应用视频。

解决方案 4:使用 Intent 执行基本相机操作 

如果您不需要太多相机功能,那么一个简单直接的解决方案是使用设备的默认相机应用执行拍照或录制视频等基本相机操作。在这种情况下,您可以直接使用 Intent,而无需与相机库集成,这样可以更轻松地进行维护和调整。

如需了解详情,请参阅相机 intent

避免界面拉伸或按钮无法访问

如果应用假定设备采用特定的屏幕方向或显示屏宽高比,那么当应用在各种屏幕方向或窗口尺寸下使用时,可能会遇到问题。

elementsLS.png

确保按钮、文本字段和其他元素在大屏幕上不会拉伸。

您可能已将按钮、文本字段和卡片设置为 fillMaxWidth 或 match_parent。在手机上,这看起来很棒。不过,在横屏模式下,平板电脑或可折叠设备的界面元素会拉伸到整个大屏幕。在 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)
)

通过将 max-width 限制与垂直滚动相结合,您可以确保应用无论窗口大小如何变化,都能保持正常运行和可用。

请参阅我们关于构建自适应布局的指南。

在配置变更后能够保留状态

移除屏幕方向和宽高比限制意味着应用窗口大小会更频繁地发生变化。用户可能会旋转设备、折叠/展开设备,或在分屏或桌面窗口模式下动态调整应用的大小。

默认情况下,这些配置更改会销毁并重新创建 activity。如果您的应用未正确管理此生命周期事件,用户将获得令人沮丧的体验:滚动位置重置为顶部、填写了一半的表单被清除,并且导航历史记录丢失。为确保提供顺畅的自适应体验,您的应用必须在这些配置更改期间保留状态。借助 Jetpack Compose,您可以选择不重新创建界面,而是允许窗口大小变化重组界面,以反映新的可用空间量。

请参阅我们关于保存界面状态的指南。

在 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 做准备吧!

作者:

继续阅读