• 原文: Android 17 is here
    来源:Android Developers Blog,发布于 2026 年 6 月 16 日。
    说明:本文为中文改写版,保留原文主要信息和结构,便于中文读者快速理解 Android 17 的关键变化。

    Google 已正式发布 Android 17,并开始面向大多数受支持的 Pixel 设备推送。未来几个月,也会有更多搭载 Android 17 的新设备上市。

    Android 17 的重点不只是一次系统版本更新。Google 将它描述为 Android 从“操作系统”向“智能系统”演进的开始:通过硬件、软件和 AI 的深度结合,让应用可以更自然地参与用户任务,并在大屏、多设备、隐私安全、媒体能力和性能方面带来一系列新变化。

    从操作系统走向智能系统

    Android 17 强化了 AppFunctions。开发者可以把应用中的核心能力暴露为可编排的“工具”,让设备端的 Android MCP 发现和调用这些能力。AI 助手或智能代理可以在用户授权和系统约束下,基于应用本地状态完成任务流。

    配套的 Jetpack 库目前处于 alpha 阶段。开发者可以通过注解类和编写 KDoc 的方式定义 AppFunction,从而让应用能力更容易被 AI 工具理解和调用。

    Google 还发布了 AppFunctions agent skill,用于分析应用关键流程、生成 Kotlin 代码、优化适合 LLM 工具调用的 KDoc,并提供用于测试和调试的 ADB 命令。Gemini 集成目前处于面向受信任测试者的私有预览阶段,但开发者已经可以提前准备应用。

    自适应优先成为新标准

    Android 17 的另一个核心方向是 adaptive-first,也就是“自适应优先”。用户已经不只在手机上使用应用,他们会在折叠屏、平板、笔记本、车载屏幕和 XR 环境之间切换。Google 表示,目前大屏 Android 设备数量已经超过 5.8 亿台,因此自适应不再只是技术优化,而是触达高活跃用户的重要机会。

    大屏不再允许随意限制方向和尺寸

    对于面向 Android 17,也就是 API level 37 的应用,在大屏设备上,系统将不再允许开发者通过旧方式规避横竖屏、尺寸调整和宽高比适配。

    系统会忽略一批旧的 manifest 属性和运行时 API,包括:

    • screenOrientation
    • setRequestedOrientation()
    • resizeableActivity=false
    • minAspectRatiomaxAspectRatio 等宽高比限制

    这个变化适用于 sw > 600 dp 的大屏设备。游戏根据 Google Play 中的应用类别仍然豁免。对普通应用来说,开发者需要确保界面能适配任意窗口大小,尊重用户选择的设备姿态,并原生支持自由窗口模式。

    新一代多任务能力

    Android 17 引入了更多窗口化和多任务能力,对应用布局弹性提出了更高要求:

    • App Bubbles:用户可以长按启动器图标,把任意应用变成浮动气泡,不再局限于消息气泡场景。
    • Bubble Bar:在平板和折叠屏等大屏设备上,系统任务栏会提供专门的气泡栏,用于组织、切换和停靠这些浮动应用气泡。
    • 桌面交互式画中画:在桌面环境中,Android 17 支持可交互的 PiP 窗口。它不再只是只读的小窗,而是可以保持置顶并继续响应用户操作。

    Activity 重建行为调整

    为了减少状态丢失和卡顿,Android 17 改变了部分配置变化下 Activity 的默认重建行为。对于一些不需要完整重绘 UI 的典型配置变化,系统默认不再重启 Activity,而是通过 onConfigurationChanged() 通知运行中的 Activity。

    如果应用明确依赖重建流程来重新加载资源,需要通过新的 android:recreateOnConfigChanges manifest 属性显式选择重建行为。

    Continue On:跨设备继续任务

    Android 17 新增 Continue On 能力,帮助用户在 Android 设备之间无缝继续任务。例如,用户在手机上最近打开的应用,可以出现在平板任务栏中,并通过一次点击跳转到之前停下的位置。

    这个能力还可以支持从应用到网页的连续体验。如果目标设备未安装应用,系统可以回退到网页继续相关任务。

    Jetpack Compose 的自适应开发方向

    为了帮助开发者满足 Android 17 的自适应要求,Google 推出了 Jetpack Compose adaptive skill。它可以辅助开发者落地自适应最佳实践,包括:

    • 在手机底部导航和大屏侧边导航栏之间自动切换
    • 使用 Navigation 3 Scenes 构建列表详情页和辅助窗格布局
    • 使用 Compose 1.11 的 FlexBox 与 Grid API 动态调整行列跨度
    • 通过增强的触控板和鼠标支持,打造更接近笔记本体验的交互
    • 在全屏、App Bubble 和交互式桌面 PiP 等窗口状态之间保持 UI 自适应

    Google 也明确表示,Android 开发现在进入 Compose-first 阶段。新的 Android API、库、工具和开发者指南会优先围绕 Jetpack Compose 构建。

    传统 View 组件以及基于 View 的 Jetpack 库,例如 Fragment、RecyclerView 和 ViewPager,将进入维护模式,只接收关键 bug 修复,不再新增功能。

    性能与效率改进

    Android 17 在应用启动、流畅度、内存和多任务效率方面带来多项变化。

    应用内存限制

    从 Android 17 开始,系统会根据设备总内存对应用施加更严格的内存限制。如果前台应用或服务的内存使用失控,系统可能会直接终止相关进程。

    开发者可以借助以下工具应对新限制:

    • R8 Optimizer:通过缩减字节码、移除未使用代码和资源来降低内存占用。
    • R8 configuration analyzer:帮助确认 R8 配置是否充分发挥作用。
    • Android Studio Panda 中的 LeakCanary 集成:让内存泄漏分析更贴近 IDE 和源码。
    • ApplicationExitInfo:如果应用因内存限制被终止,getDescription() 会返回相关描述。
    • ProfilingManager:支持基于异常触发的分析,在达到内存限制时自动采集 heap dump。

    Google 也计划在 Google Play Console 中提供更多真实环境下的内存指标。

    分代垃圾回收

    Android 17 为 ART 的 Concurrent Mark-Compact GC 引入更频繁、成本更低的年轻代回收。系统会区分短生命周期对象和长期存活对象,用轻量的年轻代扫描减少全堆扫描,从而降低 CPU 使用、耗电和 UI 卡顿。

    这些 ART 改进也会通过 Google Play 系统更新覆盖到大量运行 Android 12 及以上版本的设备。

    无锁 MessageQueue

    对于目标 SDK 37 及以上的应用,android.os.MessageQueue 采用无锁架构。这有助于减少掉帧、改善启动时间,并提升多线程繁忙队列场景下的性能。

    需要注意的是,如果应用通过反射访问 MessageQueue 的私有字段或方法,可能会受到影响。测试场景下应改用新增的 TestLooperManager API。

    static final 字段真正不可变

    从 Android 17 开始,目标 SDK 37 及以上的应用不能再修改 static final 字段。通过反射修改会抛出 IllegalAccessException,通过 JNI 修改会导致应用崩溃。这一变化让运行时可以更积极地做性能优化。

    自定义通知视图限制

    Android 17 进一步收紧自定义通知视图的大小限制,关闭了通过 URI 绕过既有限制的方式。该行为受目标 SDK 控制,适用于目标 API 37 及以上的应用。

    隐私与安全

    Android 17 延续了近年来 Android 的隐私方向:减少长期、宽泛权限,转向按会话、按选择授权。

    更隐私友好的选择机制

    Android 17 提供了多项系统级能力,让应用只访问用户明确选择的数据:

    • 系统级联系人选择器:应用可通过 ACTION_PICK_CONTACTS 临时访问用户选择的具体字段,例如邮箱或电话号码,而不必申请完整的 READ_CONTACTS 权限。
    • 可自定义宽高比的照片选择器:通过 PhotoPickerUiCustomizationParams,应用可以让系统照片选择器以竖屏缩略图方式展示内容。
    • 系统渲染的位置按钮:应用可嵌入系统渲染的位置按钮,只为当前会话获取精确位置。
    • EyeDropper API:应用可通过系统级取色器从屏幕任意像素取色,避免申请敏感的屏幕捕获或媒体投影权限。

    本地网络访问

    面向 Android 17 的应用,如果需要访问本地网络,需要申请 ACCESS_LOCAL_NETWORK 运行时权限,或者使用由系统中介的隐私保护型设备选择器。例如智能家居设备通信、投屏接收器发现等场景,都需要关注这一变化。

    由于 ACCESS_LOCAL_NETWORK 属于 NEARBY_DEVICES 权限组,已经授予相关附近设备权限的用户通常不会再次看到授权提示。

    短信验证码保护

    Android 17 扩展了短信一次性验证码保护。部分应用对短信内容的访问会延迟三小时:

    • WebOTP 格式短信:如果应用不是预期接收方,将被延迟访问。
    • 标准短信验证码:面向 SDK 37 及以上的应用会受到延迟限制。
    • 默认短信应用、助手应用和已连接的配套设备应用可豁免。

    Google 建议开发者迁移到 SMS Retriever 或 SMS User Consent API。

    后量子密码能力

    Android 17 为下一代加密安全做准备。支持的设备可以在安全硬件中生成 ML-DSA 密钥,用于量子安全签名,并通过标准 JCA API 暴露给应用。

    同时,Android 17 引入 v3.2 APK 签名方案,把传统签名和 ML-DSA 签名结合起来,用于增强应用分发安全。

    更安全的原生动态代码加载

    对于目标 SDK 37 及以上的应用,Android 14 引入的 Safer Dynamic Code Loading 保护扩展到原生库。通过 System.load() 加载的原生文件必须标记为只读,否则系统会抛出 UnsatisfiedLinkError

    物理键盘输入密码更安全

    Android 17 在使用物理键盘输入密码、PIN 和其他敏感内容时,默认不再显示最后输入的字符。用户仍可根据偏好调整显示设置,具体可用性可能因设备厂商而异。

    媒体与相机能力

    Android 17 为创作者和媒体应用带来了多项新能力:

    • Eclipsa Video:基于 SMPTE ST 2094-50 的 HDR 视频标准,引入新的元数据,让设备根据显示能力和环境光优化内容呈现。
    • RAW14 图像格式:为专业相机应用提供更高细节和色彩深度的采集能力。
    • 厂商定义的相机扩展:硬件合作伙伴可以定义和实现自定义相机扩展模式。
    • Extended HE-AAC 软件编码器:在低带宽语音消息等场景中提供更好的音频质量,并支持响度元数据。
    • Versatile Video Coding,也就是 H.266:允许 OEM 增加 VVC 编解码支持。
    • 相机设备类型 API:应用可以识别摄像头是内置硬件、外接 USB 摄像头还是虚拟摄像头。
    • 视频录制恒定质量模式:通过 MediaRecorder 配置视频编码器的恒定质量模式,让视频视觉质量更稳定。

    更好的助听器支持

    Android 17 增强了对助听器的支持:

    • 新增 BLE Audio 助听器设备类别,应用可以区分助听器和普通耳机。
    • 用户可以更细粒度地控制系统声音路由,例如通知、铃声和闹钟可以选择播放到助听器或设备扬声器。

    这些能力有助于减少不必要的入耳打扰,同时保持助听器管理应用的蓝牙连接。

    CameraX 与 Media3 更新

    CameraX 和 Media3 已针对 Android 17 更新,用于简化相机拍摄、媒体播放、创意编辑和复杂媒体体验的开发。

    Google 还发布了一个 agent skill,可以帮助把旧的 Android 相机实现迁移到 CameraX。需要注意的是,开发者应将 CameraX 更新到 1.5.2 或 1.6.0 及以上版本,以避免 Android 17 设备上与新增动态范围模式相关的崩溃。

    开发者需要尽快准备什么

    如果你开发 Android SDK、库、工具或游戏引擎,需要尽快测试和更新,避免下游应用和游戏开发者在适配 Android 17 时被阻塞。

    重点检查以下变化:

    • 大屏可调整尺寸:目标 Android 17 后,不能再在大屏上规避方向、尺寸和宽高比适配。
    • 动态代码加载:目标 SDK 37 及以上时,原生库动态加载也必须满足只读要求。
    • 证书透明度:Android 17 默认启用 Certificate Transparency。
    • 本地网络保护:目标 SDK 37 及以上时,本地网络访问默认受限。
    • 后台音频加固:Android 17 对后台音频播放、音频焦点和音量相关 API 做了更多限制。
    • NPU 访问声明:需要直接访问 NPU 的应用,必须在 manifest 中声明 FEATURE_NEURAL_PROCESSING_UNIT

    如何开始使用 Android 17

    受支持的 Pixel 设备会陆续收到 Android 17 正式版推送。如果没有 Pixel 设备,可以使用 Android Studio 中的 64 位 Android Emulator 系统镜像进行测试。

    Google 建议开发者使用最新 Canary 版本的 Android Studio Quail,并完成以下工作:

    • 在 Android 17 设备或模拟器上安装并测试现有应用。
    • 检查应用是否受到 Android 17 行为变更影响。
    • 针对核心流程做完整兼容性测试。
    • 对库、SDK、工具和游戏引擎提前发布适配说明或更新版本。

    总结

    Android 17 的关键词可以概括为:智能系统、自适应优先、Compose-first、性能效率、隐私安全和创作者能力。

    对开发者来说,最需要立即关注的是目标 SDK 37 后的大屏适配要求、本地网络权限变化、动态代码加载限制、内存限制、后台音频行为变化,以及 Compose-first 带来的长期技术方向变化。

    如果你的应用仍然依赖固定方向、固定窗口尺寸、旧 View 体系或对系统私有实现的反射访问,那么 Android 17 是一个明确的信号:现在是时候开始适配更弹性、更隐私友好、更面向多设备场景的 Android 应用了。

    上一篇:
    Android Bench:Google 如何评测大模型的 Android 开发能力
    下一篇:
    使用 LM Studio 在 macOS 上本地部署 Gemma 4
    本文目录
    本文目录