Android 17 正式版发布，全新 AI 和各种破坏性更新

说了这么久的 Android 17 终于来正式版了，这也是 Android 系统上第一个 AI 升级，同时也是隐私又进一步收紧，需要各种适配的版本。

对开发者来说这次主要变化应该有：

• App 支持被 AI Agent 调用
• 要适配任意窗口和大屏
• 要控制内存
• 要处理更严格的本地网络
• 动态代码加载
• 后台音频
• OTP
• 证书透明度
• NPU 声明等行为变化

这次 Android 17 正式发布后，目前 Pixel 已经开放更新，同时 AOSP 也同步开放。

AI

这次更新最重要的就是 An intelligence system ，基本 Android 未来也是往这方面转变，就像前段时间的 WWDC 里苹果也是，这一次 Android 17 是 Android 从传统操作系统转向"智能系统"的开端，官方强调的是硬件、软件和 AI 的深度整合，让系统可以主动理解用户需求，把 App 放在 AI 工作流中心。

说人话就是，现在支持了 AppFunctions ，这个我们已经聊过好多次了， 简单来说，以前 App 只是一个界面，AI 最多打开你的 App 进行操作，而现在 App 可以把自己的能力暴露成"工具"，让系统级 AI Agent 能发现和执行：

这个在之前的 《Android 官方正式官宣 AI 支持 AppFunctions ，Android 官方 MCP 和系统级 OpenClaw 雏形》 我们就详细聊过，比如：

一个笔记 App，可以把"创建笔记""搜索笔记""整理待办"等能力做成 AppFunction，未来 AI 助手就可以直接调用这些能力，而不是只跳转 App 页面。

AppFunctions 就是 Android MCP 的可编排工具，AI Agent 可以发现并执行这些 AppFunctions，并且能访问 App 的本地状态。

目前 Jetpack AppFunctions 库目前是 alpha，开发方式是通过 Kotlin 注解 @AppFunction 和 KDoc 注释描述函数，让 LLM 更好理解这个工具怎么调用：

/**
 * 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)
    }
}

Google 还发布了一个 AppFunctions agent skill，可以分析 App 的关键流程、自动生成 Kotlin 代码、优化 KDoc、并提供 ADB 命令做测试和调试。

Adaptive-first

Android 17 官方也宣布明确 adaptive-first development standard， 其实在此之前，官方也官宣了 Compose First ，也就是 XML 模式已经成为历史，不再更新，所以 "自适应优先" 也是 Compose 这种响应式框架的基础。

目前用户已经不只在手机上用 App，而是在手机、折叠屏、平板、笔记本形态、车机、XR 等设备之间切换，官方统计目前已有超过 5.8 亿大屏 Android 设备，而且未来还有基于 Android stack 的下一代 ChromeOS "Googlebooks"。

说这么多，核心就是想告诉大家：

当 App target Android 17 / API 37 后，在大屏设备上不能再拒绝横竖屏、缩放、自由窗口和比例变化。

具体说就是 Android 17 对 sw > 600dp 的大屏设备，会移除开发者对方向和尺寸限制的 opt-out，系统会忽略旧的 manifest 属性和运行时 API，包括：

• screenOrientation
• setRequestedOrientation()
• resizeableActivity=false
• minAspectRatio / maxAspectRatio

也就是说你以前可以强行锁竖屏、禁止 resize、限制窗口比例，但是到了 targetSdk 37，在大屏上这些限制会被系统无视。

游戏按 Google Play app category 还可以豁免。

实际上这个之前我们也聊过了，核心就是让你尽早做好适配，目前还是有大量还在锁竖屏、强依赖单 Activity 固定尺寸布局的 App。

新多任务形态

在 Android 17 目前加了几类新窗口能力，其实也是进一步强化"App 适配动态尺寸"的能力：

• 第一是 App Bubbles，它不再只是聊天气泡 API，用户可以长按 launcher 图标，把任意 App 转成浮动气泡，这个能力覆盖手机、折叠屏和平板

• 第二是 Bubble Bar，在平板和折叠屏等大屏上，系统任务栏会有专门的 Bubble Bar，用来组织、切换和停靠这些浮动 App 气泡

• 第三是 Desktop interactive PiP，传统 PiP 通常只是只读小窗，比如视频播放，而 Android 17 的桌面交互式 PiP 是可交互的，而且可以置顶在其他窗口上

Activity 变化

从 Android 17 开始，官方修改了 Activity 对部分配置变化的默认处理。

为了减少状态丢失和卡顿，系统对一些"不需要完整 UI 重绘"的配置变化，不再默认重启 Activity，而是通过 onConfigurationChanged() 通知正在运行的 Activity，涉及的配置包括键盘、键盘隐藏、导航、触摸屏、颜色模式等。

如果你的 App 明确依赖 Activity 重启来重新加载资源，那么现在需要用新的 manifest 属性 android:recreateOnConfigChanges 显式声明

这个变化的实际影响的其实有点抽象：

以前很多 App 靠 Activity recreate 偷懒刷新资源，现在需要检查配置变化后的 UI 状态、资源切换、输入法/键盘场景、外设状态等场景是否正确适配。

Continue On：

Android 17 新增的 Continue On 这个之前我们也详细聊过，主要就是用来让用户在 Android 设备之间继续任务。

比如用户刚在手机上打开某个 App，到了平板上，平板任务栏可以出现一个接续建议，用户点一下就能打开同一个 App，并通过 deep link 回到上次停留的位置。

这个目前一些场景也有类似的了。

不过 Continue On 还支持 App-to-Web ，也就是如果平板上没装 App，可以 fallback 到网页继续，官方示例里，Activity 需要调用 setHandoffEnabled(true, null) 开启 handoff，并实现 onHandoffActivityDataRequested() 返回接续数据。

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
  }
}

也就是现在官方觉得 Android 生态要做跨设备连续体验，类似"手机到平板/桌面"的任务迁移，而对于 App 来说，业务页面需要有可靠 deep link、状态恢复、账号同步和跨端 fallback。

Compose-first

官方再一次官宣 Android development is now Compose-first ， Google 表示，新的 Android API、库、工具和开发者指导都会优先围绕 Jetpack Compose 构建。

传统 View 组件和 View-based Jetpack 库，比如 Fragment、RecyclerView、ViewPager，进入 maintenance mode ，不再获得新功能支持。

另外谷歌也发布了 Jetpack Compose adaptive skill，这个 AI workflow 可以辅助实现自适应导航、多面板布局、FlexBox/Grid、非触控输入、动态窗口状态等。

性能

Android 17 在性能侧有不少"会影响 App 生死"的变化，这个之前我们在 《Android 17 内存管理将严格管控，App 要注意适配》 也聊过。

首先是 App memory limits ， Android 17 开始会根据设备总 RAM 执行更严格的 App 内存限制，如果前台 App 或前台服务内存没管理好，系统可以直接终止违规进程，而且你还不会收到 crash 信号。

谷歌建议可以使用几个新的工具来辅助：

• R8 full mode 和新的 R8 configuration analyzer，用来减少字节码内存占用
• 如果 App 因内存限制被杀，ApplicationExitInfo.getDescription() 会返回 `"MemoryLimiter:AnonSwap"``

• ```ProfilingManager`` 支持 TRIGGER_TYPE_ANOMALY，可以在触发内存限制时自动抓 heap dump

val profilingManager = applicationContext
   .getSystemService(ProfilingManager::class.java)
​
val triggers = ArrayList<ProfilingTrigger>().apply {
  add(ProfilingTrigger.Builder(
    ProfilingTrigger.TRIGGER_TYPE_ANOMALY).build())
}
profilingManager.addProfilingTriggers(triggers)

• Android Studio Panda Profiler 集成 LeakCanary，作为 IDE 内置任务。

其次是 Generational GC，Android 17 给 ART 的 Concurrent Mark-Compact GC 引入更频繁、更轻量的 young-generation collections，把短生命周期对象和长期稳定对象分开处理，减少全堆扫描，从而降低 CPU、功耗和 UI 卡顿。

这些 ART 改进会通过 Google Play System updates 支持到老设备。

然后是 Lock-Free MessageQueue ，这个我们也聊过，对于 target SDK 37 及以上的 App，核心 android.os.MessageQueue 改为 lock-free 架构，目标是减少掉帧、改善启动时间，并提升多线程高负载队列性能。

但如果 App 通过反射访问 MessageQueue 私有字段和方法，那就会异常了。

接着 static final 字段 truly final ，从 Android 17 开始，target SDK 37 及以上 App 不能再修改 static final 字段，通过反射或 deep reflection 修改会抛 IllegalAccessException，通过 JNI 的 SetStatic<Type>Field 修改会直接 crash。

最后是自定义通知视图限制更严格，为了降低内存占用，Android 17 进一步限制 custom notification views 的尺寸，并关闭通过 URI 绕过现有限制的漏洞。

隐私安全

隐私的其实之前我们也聊过，Android 17 的隐私方向很明确：

减少长期、宽泛的权限，改成系统选择器、临时授权、会话级授权。

第一是系统级联系人选择器 ，通过 ACTION_PICK_CONTACTS，App 可以只请求用户选择的具体字段，比如 email 或电话号码，不再需要宽泛的 READ_CONTACTS 权限，同时支持 work/personal profile 隔离。

第二是 Photo Picker 可自定义缩略图比例 ，通过 PhotoPickerUiCustomizationParams，App 可以让系统照片选择器以竖屏缩略图展示，适合短视频、竖屏内容社交类应用。

第三是系统渲染 Location Button，App 可以嵌入一个系统渲染的位置按钮，用户点击后只给当前 session 的精确位置访问，而不是长期位置权限。

第四是 EyeDropper API ，通过 ACTION_OPEN_EYE_DROPPER，App 可以调用系统级取色器，从屏幕任意像素取色，不再需要申请屏幕录制、MediaProjection 或宽泛截图权限。

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 对本地网络访问加了新限制 ，target Android 17 的 App，如果要访问局域网设备，比如智能家居设备、投屏接收器等，要么申请新的 ACCESS_LOCAL_NETWORK runtime permission，要么使用系统中介的隐私保护设备选择器。

ACCESS_LOCAL_NETWORK 属于现有的 NEARBY_DEVICES 权限组,如果用户已经授予了其他 NEARBY_DEVICES 权限，系统不会再次弹窗。

这对物联网场景的 App 影响比较大，例如：

• 智能家居
• 投屏/局域网投放
• 打印机/扫描仪
• NAS/SMB/DLNA
• IoT 配网
• 局域网调试工具
• 局域网发现服务

以前 App 都默认觉得可以扫局域网，现在 target 37 后要重新梳理权限和系统 picker了。

SMS OTP 保护

这个也是比较蛋疼的，我们之前也聊过，Android 17 扩大了 SMS OTP 保护，会延迟 App 对短信验证码的访问，延迟时间为 3 小时。

WebOTP 格式下，如果 App 不是目标接收方，也就是 domain mismatch，会被延迟

标准 SMS OTP 对 target SDK 37+ 的 App 延迟，默认短信 App、assistant、connected companion apps 豁免，Google 建议迁移到 SMS Retriever 或 SMS User Consent APIs 。

这个变化主要是为了防止恶意 App 读取验证码，对开发者来说，重点是不要再依赖直接读短信做验证码自动填充，要抓紧迁移到官方 API。

Post-Quantum Cryptography

Android 17 加入 Post-Quantum Cryptography (PQC) 相关能力，支持的设备可以在安全硬件中生成 ML-DSA 密钥，并通过标准 JCA API 生成抗量子签名。

APK 签名侧，Android 17 引入 v3.2 APK Signature Scheme，结合传统签名和 ML-DSA 签名，用于提升 App 分发安全。

说人话就是又多了一种签名方式。

Native 动态代码

这个以前也聊过了，Android 14 已经对 DEX/JAR 的 safer dynamic code loading 做了保护，Android 17 把这个保护扩展到 native libraries。

对于 target SDK 37 或更高的 App，所有通过 System.load() 加载的 native 文件都必须标记为 read-only，否则系统会抛 UnsatisfiedLinkError。

这会主要影响热更新、插件化、下载 so、解压 so、动态加载 native 模块的方案，特别是一些自研插件框架、游戏引擎、跨平台运行时、加固壳、动态算法包，可能要重点检查文件权限。

物理键盘密码输入更安全

Android 17 在使用物理键盘输入密码、PIN 等敏感内容时，默认不再显示最后输入的字符。

用户还是可以根据设备厂商支持情况自行调整显示设置，而 Android 内置 SDK 组件会自动支持这些增强保护，Compose 1.12 的 SecureTextFields 也会支持。

媒体和相机

这个主要就是一些零散更新了：

• Eclipsa Video：基于 SMPTE ST 2094-50 的 HDR 视频标准，使用新元数据帮助设备根据显示器亮度能力和环境光适配内容，也改善 SDR/HDR 同屏显示

• RAW14 image format：支持 RAW14，让专业相机 App 可以从兼容传感器捕获更高细节和色深。

• Vendor-defined camera extensions：允许硬件厂商定义和实现自定义相机扩展模式，让 App 能访问更具体的新相机特性。

• Extended HE-AAC software encoder：系统提供 Extended HE-AAC 软件编码器，支持低/高比特率和 loudness metadata，改善低带宽语音消息质量。

• VVC/H.266 ：OEM 可以通过 video/vvc MIME type、VVC profiles、MediaExtractor 等集成 VVC 支持。

• Camera device type：新 API 可以查询摄像头是内置硬件、外接 USB 摄像头，还是虚拟摄像头。

• Constant Quality for Video Recording ：MediaRecorder 的 setVideoEncodingQuality 可以配置视频编码 CQ 模式，让整段视频视觉质量更稳定。

不过 CameraX 和 Media3 也针对 Android 17 进行了更新适配，Google 还发布了一个 agent skill，可辅助把旧 Camera1 或裸 Camera2 实现迁移到 CameraX。

这里有一个非常具体的坑：需要把 CameraX 更新到 1.5.2 或 1.6.0+，否则可能因为 Android 17 新增 dynamic range mode 导致崩溃。

助听器支持

Android 17 增加了 BLE Audio hearing aid 的设备类型常量 AudioDeviceInfo.TYPE_BLE_HEARING_AID，App 可以区分助听器和普通耳机.

系统支持用户更细粒度管理系统声音路由，比如通知、铃声、闹钟是走助听器还是走设备扬声器

尽快适配

官方这次还专门强调现在就要准备更新，这次 Android 17 变化还是挺大的，不适配容易有问题，例如：

• 大屏 resizability：target 37 后不能再在大屏上 opt out 方向、resize、比例限制
• 动态代码加载：target 37 后，通过 System.load() 加载的 native 文件必须 read-only，否则 UnsatisfiedLinkError
• 证书透明度 CT：Android 17 默认启用 Certificate Transparency，Android 16 中 CT 可用但需要 App opt in
• 本地网络保护：target 37 后，本地网络访问默认阻止，需要优先使用隐私保护 picker，确实需要长期广泛访问再申请 ACCESS_LOCAL_NETWORK
• 后台音频加固：Android 17 对后台音频交互加强限制，包括音频播放、audio focus 请求、音量修改 API
• NPU 访问声明：target Android 17 后，如果 App 需要直接访问 NPU，必须在 manifest 声明 FEATURE_NEURAL_PROCESSING_UNIT，否则可能被阻止访问 NPU
• 有没有依赖修改 static final 字段、是否反射访问 MessageQueue 私有实现
• 有没有直接读 SMS OTP、是否使用过大的 custom notification view
• 内存有没管理好，不然会被静默杀死

更多可见： Android 17 新适配要求，各大权限进一步收紧，适配难度提升

链接

android-developers.googleblog.com/2026/06/And...