今天，我们发布了 Android 17，并使其可在大多数受支持的 Pixel 设备上使用。未来几个月内，敬请期待搭载 Android 17 的新设备。
Android 17 标志着我们开始向智能系统过渡，将您的应用置于中心位置。Android 正在转向自适应优先的开发标准，引入强制性的大屏可调整尺寸功能，同时提供新一代隐私保护、安全、媒体、相机和性能。本文将介绍所有这些内容，以及我们如何将新一代工具、库和智能体技能整合在一起，帮助您的应用把握这一机遇。
在过去的一年中，从 Canary 渠道到 Beta 版发布，我们与开发者社区中的许多人合作，共同打造了一个您和您的用户可以信赖的平台。为此，我们在此宣布，Android 开源项目 (AOSP) 中现已提供源代码。这样一来，您就可以检查源代码，从而更深入地了解 Android 的运作方式。
我们来深入了解一下 Android 17。
情报系统
通过将硬件、软件和 AI 深度集成，我们将 Android 从操作系统转变为智能系统。它旨在提供可预测用户需求的新实用体验，并为用户与您的应用互动带来更多机会。为此，Android 17 扩展了 AppFunctions（一个具有相应 Jetpack 库的平台 API）的功能。借助该功能，您可以将应用的独特功能作为可编排的“工具”贡献给 Android MCP，后者是设备端等效的 Model Context Protocol。AI 代理和助理（例如 Google Gemini）可以发现并执行 AppFunctions，以代表用户执行工作流，并直接访问应用的本地状态。
Jetpack 库目前处于 Alpha 版阶段，可让您轻松添加 AppFunctions，只需为类添加注释和 KDoc 注释即可。
/** * A note app's [AppFunction]s. */ class NoteFunctions( private val noteRepository: NoteRepository ) { /** * Adds a new note to the app. * * @param appFunctionContext The execution context. * @param title The title of the note. * @param content The note's content. */ @AppFunction(isDescribedByKDoc = true) suspend fun createNote( appFunctionContext: AppFunctionContext, title: String, content: String ): Note { return noteRepository.createNote(title, content) } }
我们还推出了 AppFunctions 智能体技能，该技能可分析应用的关键工作流，自动生成所需的 Kotlin 代码，针对 LLM 工具调用优化 KDoc，并提供用于测试和调试的 ADB 命令。
Gemini 集成目前正面向可信测试人员开放私测预览，但您现在就可以着手为您的应用做好准备。除了使用 ADB 命令来执行 AppFunctions 之外，我们还提供了一个测试代理应用，其中包含用于发现和执行 AppFunctions 以及模拟 AI 智能体集成的界面。请访问 goo.gle/eap-af 加入我们的集成抢先体验计划，有机会成为首批将 AppFunctions 部署到正式版环境的应用之一。
自适应优先
您的用户不再依赖单一的设备形态，而是在手机、可折叠设备、平板电脑、笔记本电脑、车载显示屏和沉浸式 XR 环境之间切换。现在，用户手中的大屏设备已超过 5.8 亿台，并且即将推出 Googlebook，这是基于 Android 堆栈构建的新一代 ChromeOS，因此自适应不再只是一个技术目标。这是一个覆盖高度互动的用户的绝佳机会，这也是我们改用自适应优先开发标准的原因之一。
大屏设备上没有尺寸调整/屏幕方向限制
为确保应用在所有设备规格（包括在连接的显示屏上以桌面模式运行的移动设备）上都能提供优质体验，Android 17（API 级别 37）移除了针对以 API 级别 37 为目标平台的应用在大屏设备 (sw > 600 dp) 上设置的屏幕方向和尺寸调整限制的开发者选择停用选项。系统将忽略旧版清单属性和运行时 API，包括 screenOrientation、setRequestedOrientation()、resizeableActivity=false 和宽高比限制 (minAspectRatio/maxAspectRatio)。游戏（根据 Google Play 中的应用类别）仍可免除此要求。您的应用必须能够适应任何窗口大小，尊重用户偏好的设备姿态，并原生支持自由窗口模式。
新一代多任务处理：应用气泡、气泡栏和桌面互动式画中画
Android 17 引入了强大的全新窗口功能，重新定义了用户执行多任务的方式，对应用的布局灵活性提出了更高的要求：
- 应用气泡： 除了即时通讯气泡 API 之外，用户现在还可以通过在启动器上长按任何应用的图标，将其转换为浮动气泡。此功能适用于手机、可折叠设备和平板电脑，可让您轻松执行多项任务，满足各种工作流程的需求。
- 气泡栏：在大屏设备（平板电脑和可折叠设备）上，系统任务栏现在包含一个专用气泡栏，用于整理、切换和停靠这些浮动应用气泡。
- 桌面互动式 PiP：在桌面环境中，Android 17 引入了互动式画中画 (PiP)。与只读的传统画中画窗口不同，这些固定窗口始终显示在其他应用窗口之上，同时保持完全互动。
activity 重新创建更新
为防止出现破坏性状态丢失和卡顿，Android 17 更新了 activity 重新创建的默认行为。对于不需要完全重绘界面的典型配置更改（包括 CONFIG_KEYBOARD、CONFIG_KEYBOARD_HIDDEN、CONFIG_NAVIGATION、CONFIG_TOUCHSCREEN 和 CONFIG_COLOR_MODE），系统将不再默认重启 activity。
相反，正在运行的 activity 将通过 onConfigurationChanged() 接收这些更新，从而实现平稳过渡。如果您的应用明确依赖于完全重启来重新加载资源以实现这些更改，您现在必须使用新的 android:recreateOnConfigChanges 清单属性明确选择启用此行为。
接续操作
Android 17 新增了“继续处理”功能，可帮助用户在 Android 设备之间无缝切换任务。用户会在平板电脑的任务栏中看到移动设备上最近打开的应用的建议，只需点按一下即可启动该应用并深层链接到上次停下的位置。“继续”功能可以支持应用到网站的过渡，包括在应用未安装的情况下回退到使用网站。
class MyHandoffActivity : Activity() {
...
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// Do stuff
...
// Enable handoff
setHandoffEnabled(true, null)
}
// Override and implement onHandoffActivityDataRequested
override fun onHandoffActivityDataRequested(handoffRequestInfo: HandoffActivityDataRequestInfo) : HandoffActivityData {
// Create and return handoff data
}
}使用 Jetpack Compose 优先打造自适应应用
为了帮助您调整应用以满足新的 Android 17 要求，我们推出了 Jetpack Compose 自适应技能。此 AI 赋能的开发者工作流可帮助您实现最佳自适应实践：
- 自适应导航：使用 Material 3 自适应库中的
NavigationSuiteScaffold，在移动设备上的底部导航栏和大屏设备上锚定到边缘的导航栏之间自动转换。 - 多窗格布局：使用 Navigation 3 场景（
ListDetailSceneStrategy和SupportingPaneSceneStrategy）以原生方式实现列表-详情和辅助窗格布局，而不是使用脆弱的 fragment 事务。 - FlexBox 和 Grid API：利用 Compose 1.11 的动态布局组件，轻松实时调整行跨度和列跨度，确保内容始终完美填充空间。
- 高级非触控输入：利用 Compose 1.11 增强的触控板和鼠标支持，包括原生焦点环和新 API（例如
TrackpadInjectionScope和performTrackpadInput），轻松在 Googlebook 和桌面模式下测试并提供真正的“笔记本电脑级”体验。 - 动态窗口状态：利用 Compose 的响应式状态模型，在应用从全屏过渡到浮动应用气泡或交互式桌面 PiP 窗口时，无缝调整界面，即使在最小尺寸下也能确保优质体验。
Android 优先采用 Compose
Compose 提供了一种最简单的方式来构建自适应应用，而这只是我们认为所有 Android 界面都应使用 Compose 构建的众多原因之一。为此，Android 开发现已全面转向 Compose 优先。所有新的 Android API、库、工具和开发者指南都将专门为 Jetpack Compose 构建。旧版 View 组件（位于 android.widget 软件包中）和基于 View 的 Jetpack 库（例如 Fragments、RecyclerView 和 ViewPager）现已进入维护模式。它们只会收到关键问题修复，而不会收到新功能。
提示：准备好迁移了吗？使用我们由 AI 驱动的 XML 到 Compose 迁移技能，自动分析旧版 View 布局并将其转换为高度自适应的 Compose 代码。
性能和效率
应用性能意味着流畅的界面、快速的应用启动时间和高效的多任务处理；Android 17 在所有这些方面都有显著改进。
应用内存限制
内存用量是影响整体性能的潜在因素之一。当某个前台应用或服务不受控制地增长时，内存管理会使 CPU 和电池利用率飙升，最终导致其他行为良好的缓存应用和后台作业终止，从而迫使冷启动变慢并影响多任务处理。
从 Android 17 开始，系统将根据设备的 RAM 总容量强制执行严格的应用内存限制，并突然终止违规进程。以下新功能可帮助您应对这些更严格的要求：
- R8 优化器：R8 优化器通过将类、方法和字段缩减为更短的名称，并剥离未使用的代码和资源，显著减少应用的字节码内存占用。 使用完整模式的 R8 以及新的 R8 配置分析器，确保您的应用充分利用 R8 的优势。
- Android Studio Panda 中的 LeakCanary： 分析器现在具有原生 LeakCanary 集成功能，可作为专用任务与您的 IDE 和源代码完全集成。
- ApplicationExitInfo：如果您的应用因这些限制而被终止，ApplicationExitInfo 中的 getDescription() 将返回“MemoryLimiter:AnonSwap”。
- 设备端异常值检测：作为 ProfilingManager 的一部分，您可以利用基于触发器的分析功能（使用
TRIGGER_TYPE_ANOMALY）在达到内存限制时自动捕获堆转储。
val profilingManager = applicationContext .getSystemService(ProfilingManager::class.java) val triggers = ArrayList<ProfilingTrigger>().apply { add(ProfilingTrigger.Builder( ProfilingTrigger.TRIGGER_TYPE_ANOMALY).build()) } profilingManager.addProfilingTriggers(triggers)
此外，我们还致力于在 Google Play 管理中心内向您显示更多实地内存指标。
分代垃圾回收
Android 17 为 ART 的并发标记压缩式垃圾回收器 (GC) 引入了频率更高、资源消耗更低的新生代回收。通过将存留期较短的对象与稳定且存留期较长的对象分开，系统可以频繁运行轻量级的“年轻代”扫描，而不是耗费资源的全堆扫描，从而大幅减少 CPU 使用率、耗电量和界面卡顿。我们的测试表明，GC 对应用线程的干扰显著减少，最大内存常驻集大小 (RSS) 也随之减少。通过 Google Play 系统更新，搭载 Android 12（API 级别 31）及更高版本的 10 亿多台设备也可使用 ART 改进。
无锁 MessageQueue
对于以 SDK 37 或更高版本为目标平台的应用，核心 android.os.MessageQueue 现在实现了无锁架构，可显著减少丢帧、缩短应用启动时间，并大幅提升多线程场景中繁忙队列的性能。注意：这可能会破坏在私有 MessageQueue 字段和方法上使用反射的应用。向 TestLooperManager 添加了 peekWhen 和 poll API，以便在不依赖 MessageQueue 内部实现的情况下进行插桩测试。
静态 final 字段现在真正是 final 字段
从 Android 17 开始，以 SDK 37 或更高版本为目标平台的应用将无法修改“static final”字段，从而使运行时能够更积极地应用性能优化。如果尝试通过反射（或深度反射）来执行此操作，系统会抛出 IllegalAccessException。
通过 JNI 的 SetStatic<Type>Field 方法系列修改它们会立即导致应用崩溃。
自定义通知视图限制
为了减少内存用量，我们进一步限制了 自定义通知视图的大小。此更新填补了一个漏洞，该漏洞允许应用使用 URI 绕过现有限制。此行为受目标 SDK 版本限制，并对以 API 37 及更高版本为目标平台的应用生效。
隐私权和安全
维护用户信任是 Android 生态系统的核心。Android 17 引入了强大的功能，可在简化用户体验的同时保护敏感数据。
可保护隐私的选择
过去，应用需要获得广泛的永久性权限才能访问通讯录、精确位置信息和媒体文件等信息。Android 17 继续朝着隐私保护型选择转变，仅授予对用户明确选择的数据的临时会话访问权限：
- 系统级联系人选择工具：利用
ACTION_PICK_CONTACTS，应用可以仅请求临时访问用户选择的特定字段（例如，电子邮件地址或电话号码），从而无需广泛的READ_CONTACTS权限。它还完全支持工作/个人资料分隔。 - 可自定义的照片选择器宽高比：使用 PhotoPickerUiCustomizationParams，您可以自定义系统照片选择器，以纵向模式显示缩略图。这非常适合始终以竖屏模式显示照片和视频的应用，例如基于视频的社交媒体应用。
- 系统渲染的位置信息按钮：您可以将新的系统渲染的位置信息按钮嵌入到应用中，以便仅在当前会话期间授予精确位置信息访问权限。
- EyeDropper API：借助新的系统级 API
ACTION_OPEN_EYE_DROPPER，您的应用可以创建由系统提供支持的取色器，让用户能够从显示屏上的任意像素中选择颜色。这提供了一种安全且可保护隐私的颜色选择体验，无需广泛的敏感屏幕截取或媒体投屏权限。
val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result -> if (result.resultCode == Activity.RESULT_OK) { val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK) // Use the picked color in your app } } fun launchColorPicker() { val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER) eyeDropperLauncher.launch(intent) }
本地网络访问权限
以 Android 17 为目标平台的应用现在需要 ACCESS_LOCAL_NETWORK 运行时权限，或者使用系统介导的、可保护隐私的设备选择器进行本地网络通信，例如与智能家居设备或投屏接收器通信。由于 ACCESS_LOCAL_NETWORK 属于现有的 NEARBY_DEVICES 权限组，因此已授予其他 NEARBY_DEVICES 权限的用户不会再次收到提示。
动态短信密码保护
Android 17 扩展了短信动态密码 (OTP) 保护功能，将对短信消息的访问延迟了 3 小时：
- WebOTP 格式： 对于所有不是预期接收者的应用（网域不匹配），延迟发送。
- 标准短信动态密码： 对于以 SDK 37 及更高版本为目标平台的所有应用，均会延迟。
例外情况：默认短信应用、助理应用和关联的配套应用不受此限制。强烈建议应用迁移到 SMS Retriever 或 SMS User Consent API。
后量子加密 (PQC)
Android 17 已为新一代加密安全性做好准备：
- Keystore 集成：受支持的设备可以在安全硬件中生成 ML-DSA（基于模块网格的数字签名算法）密钥，以生成抗量子安全签名，并通过标准 JCA API 公开。
- 混合 APK 签名：推出 v3.2 APK 签名方案，该方案将经典签名与 ML-DSA 签名相结合，以确保应用交付安全。
更安全的原生动态代码加载
如果您的应用以 SDK 37 或更高版本为目标平台，则在 Android 14 中针对 DEX 和 JAR 文件引入的更安全的动态代码加载 (DCL) 保护功能现在也适用于原生库。使用 System.load 加载的所有原生文件都必须标记为只读。否则，系统会抛出 UnsatisfiedLinkError。
针对实体输入的更智能的密码保护
在 Android 17 中，我们默认不再显示最近输入的字符，从而让用户在使用实体键盘时更安全地输入密码、PIN 码和其他机密信息。
用户仍然可以轻松自定义这些显示设置，以符合自己的偏好设置（可用性可能因设备制造商而异）。
Android 的内置 SDK 组件会自动支持这些增强型隐私保护功能，并且 Compose 1.12 将支持 SecureTextFields。
可赋能创作者并让用户满意的媒体和相机功能
Android 17 引入了新的创作者功能，可让用户使用专业级相机和媒体，同时还能提升消费者体验。
- Eclipsa Video：基于 SMPTE ST 2094-50 规范构建的 HDR 视频标准，引入了新的元数据，可帮助设备根据显示余量和环境光条件调整内容，并改进标准内容和 HDR 内容的同时显示。
- RAW14 图片格式：新增对 RAW14 图片格式的支持，让专业相机应用能够从兼容的相机传感器中捕捉到最高级别的细节和色彩深度。
- 供应商定义的相机扩展：借助供应商定义的扩展，硬件合作伙伴可以定义和实现自定义相机扩展模式，从而提供对最新最佳相机功能的访问权限。
- 扩展型 HE-AAC 软件编码器：一种新的系统提供的扩展型 HE-AAC 软件编码器，使用统一的语音和音频编码，支持低比特率和高比特率，可在低带宽条件下显著提升语音消息的音质，包括支持响度元数据。
- 多功能视频编码 (H.266)：使 OEM 能够通过在 MediaFormat 中定义 video/vvc MIME 类型、在 MediaCodecInfo 中添加新的 VVC 配置以及将支持集成到 MediaExtractor 中来添加编解码器支持。
- 摄像头设备类型：用于查询底层设备类型的新 API，可用于识别摄像头是内置硬件、外置 USB 摄像头还是虚拟摄像头。
- 视频录制恒定质量：MediaRecorder 中的 setVideoEncodingQuality 为视频编码器配置恒定质量 (CQ) 模式，以确保整个视频的视觉保真度保持一致。
更好地支持助听器
- 蓝牙 LE 音频助听器支持：Android 现在包含一个用于蓝牙低功耗 (BLE) 音频助听器的特定设备类别，并提供新的 AudioDeviceInfo.TYPE_BLE_HEARING_AID 常量，因此您的应用可以区分助听器和常规耳机，从而为使用辅助听力设备的用户提供量身定制的体验。
- 精细的助听器音频路由：Android 17 允许用户单独管理特定系统声音的播放位置。他们可以选择将通知、铃声和闹钟声音发送到已连接的助听器或设备的内置扬声器，从而避免不必要的入耳中断，同时保持蓝牙连接以供助听器管理应用使用。
CameraX 和 Media3
CameraX 和 Media3 已针对 Android 17 进行更新。它们可以帮助您完成繁重的工作，消除媒体开发中的粗糙之处，并简化可靠的相机拍摄、流畅的媒体播放以及富有创意且复杂的编辑体验的构建。
我们发布了一项代理技能，可将旧版 Android 相机实现（Camera1 或原始 Camera2 API）迁移到 CameraX。
注意：您需要将 CameraX 版本更新为 1.5.2 或 1.6.0 及更高版本，以避免与 Android 17 设备上新增的动态范围模式相关的崩溃。
准备好您的应用、库、工具和游戏引擎！
如果您开发 Android SDK、库、工具或游戏引擎，那么现在就准备好所有必要的更新至关重要，这样才能防止下游应用和游戏开发者因兼容性问题而受阻，并允许他们以最新的 SDK 功能为目标。如果需要更新才能完全支持 Android 17，请告知您的下游开发者。
测试包括使用 Google Play 或其他方式将您的正式版应用或使用您的库或引擎的测试应用安装到运行 Android 17 Beta 4 的设备或模拟器上。完成应用的所有流程，并查找功能或界面问题。每个 Android 版本都包含一些平台变更，旨在提升隐私保护、安全性和总体用户体验；请查看对在和以 Android 17 为目标平台的应用有影响的行为变更，以便确定测试重点，包括以下内容：
- 大屏上的尺寸调整： 一旦您以 Android 17 (SDK 37) 为目标平台，就无法再选择停用大屏上的屏幕方向、尺寸调整和宽高比限制。
- 动态代码加载：如果您的应用以 SDK 37 或更高版本为目标平台，则在 Android 14 中针对 DEX 和 JAR 文件引入的更安全的动态代码加载 (DCL) 保护机制现在也适用于原生库。使用 System.load() 加载的所有原生文件都必须标记为只读。否则，系统会抛出 UnsatisfiedLinkError。
- 默认启用 CT： 证书透明度 (CT) 默认处于启用状态。（在 Android 16 上，CT 可用，但应用必须选择启用。）
- 本地网络保护： 以 SDK 37 或更高版本为目标平台的应用默认会被阻止访问本地网络。尽可能切换为使用可保护隐私的选择器，并使用新的
ACCESS_LOCAL_NETWORK权限来实现广泛的持久访问。 - 后台音频安全加固：从 Android 17 开始，音频框架会强制执行后台音频交互限制，包括音频播放、音频焦点请求和音量更改 API。根据您的反馈，自 Beta 2 以来，我们进行了一些更改，包括在应用使用期间强制执行 FGS 的 targetSDK 门控，以及免除闹钟音频。如需了解详情，请参阅更新后的指南。
- NPU 访问权限声明：如果应用以 Android 17 为目标平台，并且需要直接访问 NPU，则必须在其清单中声明
FEATURE_NEURAL_PROCESSING_UNIT，以免被阻止访问 NPU。这包括使用 LiteRT NPU 委托、特定于供应商的 SDK 以及已废弃的 NNAPI 的应用。
Android 17 使用入门
如果您的 Pixel 设备尚未加入 Android Beta 版计划，应该很快就会收到 Android 17 更新。如果您没有 Pixel 设备，可以在 Android Studio 中使用 Android 模拟器搭配 64 位系统映像。如果您目前使用的是 Android 17 Beta 版 4.1，但尚未采用 Android 17 QPR1 Beta 版，则可以退出该计划，然后系统会通过无线下载方式向您提供 Android 17 的正式版。
在合作伙伴设备上获取 Android 17 Beta 版
Android 17 Beta 版已在合作伙伴（包括 Honor、iQOO、Lenovo、OnePlus、OPPO、Realme、Sharp、vivo 和 Xiaomi）的手机、平板电脑和可折叠设备上推出。
为了获得 Android 17 的最佳开发体验，我们建议您使用最新 Canary 版的 Android Studio Quail。设置完成后，您应执行以下操作：
- 测试当前应用的兼容性，了解您的应用是否受到 Android 17 中的变更影响，并将应用安装到运行 Android 17 的设备或 Android 模拟器上，然后进行广泛测试。
再次感谢所有参与 Android 开发者预览版和 Beta 版计划的社区成员。我们期待看到您的应用如何利用 Android 17 中的更新，并计划在未来以快节奏的发布周期为您带来更新。
如需详细了解 Android 17，请访问 Android 17 开发者网站。
-
产品新闻Android 17 今天正式通过 Beta 3 达成“平台稳定性”里程碑。这意味着 API 表面已锁定；您可以执行最终的兼容性测试，并将以 Android 17 为目标平台的应用推送到 Play 商店。
Matthew McCullough • 阅读用时：5 分钟 -
产品新闻今天，我们发布了第一组长周期任务 (LHT)，这些任务非常复杂，需要工程师花费数天甚至一周的时间才能完成。我们还推出了代理式评估，首先从相应模型提供商的代理开始。
Matthew McCullough • 阅读用时：3 分钟 -
产品新闻提供出色的用户体验是 Android 的核心使命，而要实现这一目标，就必须确保设备快速、灵敏且可靠。
Blair Harmon • 阅读用时：2 分钟
每周通过电子邮件接收最新的 Android 开发洞见。
