Android 17 最新动态与适配指南：Beta 2 到底改了什么，应用现在该怎么跟？Android 17 当前 Be

Android 17 最新动态与适配指南：Beta 2 到底改了什么，应用现在该怎么跟？

基于 Android Developers 官方文档整理，时间点为 2026-03-23。
先说结论：Android 17 目前还不是正式版，而是 Beta 2 阶段。
Beta 1 发布时间是 2026-02-13，Beta 2 发布时间是 2026-02-26。如果你现在开始做适配，方向是对的；但策略应该是“先完成兼容性验证，再考虑全面 target Android 17（API 37）”。

今年 Android 17 的变化有一个很明显的特点：它不是单纯地加几个新 API，而是在“大屏适配、隐私权限、安全默认值、输入与音频行为”这些基础规则上继续收紧。

这意味着：

如果你是普通业务 App，最重要的不是先追新功能，而是先看行为变更会不会把你现有逻辑打穿。
如果你是音视频、局域网设备、输入法、游戏、远程桌面、平板应用，这一版需要重点测。
如果你的项目还有大量反射、私有 API、HTTP 明文访问、定制通知、老式横竖屏锁定思路，Android 17 会比前几版更容易暴露问题。

这篇文章我会分成 4 部分：

Android 17 当前到底进展到哪一步了。
这版最值得关注的新增能力和平台变化是什么。
哪些行为变更会直接影响现有 App。
一套可执行的适配与测试清单。

一、先看版本状态：Android 17 现在到哪了？

截至 2026-03-23，官方公开信息可以概括成下面这张表：

项目	当前状态
版本阶段	`Android 17 Beta 2`
API Level	`37`
Beta 1 发布时间	`2026-02-13`
Beta 2 发布时间	`2026-02-26`
适用场景	开发、测试、一般试用
官方定性	仍在积极开发中，系统和 App 可能存在不稳定行为

官方在 release notes 里明确写了两点：

Beta 1 已经适合开发、测试和一般使用。
Beta 2 同样适合开发、测试和一般使用，但 Android 17 仍处于活跃开发阶段，系统与应用行为仍可能继续变化。

如果你问“现在能不能开始适配”，答案是：

可以，而且应该开始了。

但如果你问“现在能不能把生产环境主分支直接全量切到 target 37”，我的建议是：

大多数团队现在先做兼容性适配和问题清单，不要急着全面切 target。

二、Android 17 最新动态：这版最值得关注的变化

1. 大屏适配正式从“建议”走向“强制”

这是 Android 17 最值得所有应用团队正视的一条。

从 Beta 1 开始，官方明确规定：

当应用 targetSdkVersion = 37
且运行在 sw >= 600dp 的大屏设备上

下面这些旧限制将被忽略：

screenOrientation
resizeableActivity
minAspectRatio
maxAspectRatio

也就是说，Android 17 不再允许普通应用继续靠“锁竖屏 / 锁比例 / 禁止拉伸”逃避大屏适配。

例外只有两类：

小于 600dp 的设备
android:appCategory="game" 的游戏应用

这意味着如果你的应用：

页面仍然强依赖手机竖屏布局
大量使用写死宽高
分栏、弹窗、播放器、详情页没有可拉伸和可重排能力

那 Android 17 很可能会直接把你的适配问题放大。

2. 配置变更策略变了，系统不再默认重启 Activity

Android 17 对一些配置项做了新的默认处理。

官方说明，从这一版开始，系统对以下配置变化不再默认重启 Activity：

CONFIG_KEYBOARD / CONFIG_KEYBOARD_HIDDEN
CONFIG_NAVIGATION
CONFIG_TOUCHSCREEN
CONFIG_COLOR_MODE
CONFIG_UI_MODE（仅部分桌面模式变化）

如果你的应用以前依赖“重启 Activity 重新加载资源”来兜底，那现在要格外小心。
官方给出的方向是：如果你确实依赖重启，需要显式使用新的 android:recreateOnConfigChanges 清单属性。

这条对谁影响最大？

表单页
编辑页
多窗口页面
依赖配置变化重建界面的老项目

3. 性能与调试链路更强了：ProfilingManager、JobDebugInfo、新 MessageQueue

Android 17 在性能排查这块给的东西很实用。

新增能力包括：

ProfilingManager 新增 3 个触发器
- 冷启动 COLD_START
- OOM OOM
- 异常高 CPU 被系统杀掉 KILL_EXCESSIVE_CPU_USAGE
JobDebugInfo 增强
- 可以更容易看出 Job 为什么一直 pending
- 例如因为没充电、没联网、约束不满足而延迟多久
MessageQueue 改成无锁实现
- 官方说它能减少丢帧、提升性能
- 但如果你反射了 MessageQueue 私有字段或私有方法，可能直接出问题

这对业务团队的价值很直接：

启动慢的问题更容易拿到系统级线索
JobScheduler 不执行的锅更容易定位
某些底层 Hook、热修复、监控 SDK 如果碰私有 MessageQueue 结构，风险会上升

4. 联系人和局域网都更“细粒度授权”了

Android 17 在隐私这块的思路非常清楚：能不给全量权限，就不给。

先看联系人：

系统提供了新的 Android Contacts Picker
它是系统级、可浏览、可搜索、可多选的联系人选择器
可以只授权电话号码、邮箱等指定字段
从而替代大量 READ_CONTACTS 的粗权限场景

再看局域网：

Android 17 为面向 17 的应用引入了新的运行时权限 ACCESS_LOCAL_NETWORK
它属于现有的 NEARBY_DEVICES 权限组
官方目标很明确：限制未经授权的 LAN 扫描、设备发现、用户指纹跟踪

如果你的应用涉及这些场景，就要重点适配：

智能家居发现
投屏 / Cast
NAS / 局域网文件访问
同网段设备发现
自研 IoT 配网

5. 音频后台行为继续收紧

这是音视频和播客类应用必须认真测的一条。

Android 17 对后台音频交互加了新的限制：

音频播放
音频焦点请求
音量变更 API

如果不是在有效的生命周期状态中发起，这些调用会失败：

播放和音量变化会“静默失败”
音频焦点会返回 AUDIOFOCUS_REQUEST_FAILED

这意味着如果你的应用还在以下位置偷偷操作音频：

后台 Receiver
不可见页面
生命周期不明确的 Service / Worker

那 Android 17 很可能把这些灰色行为直接打掉。

6. 安全默认值继续提高：明文流量、静态常量、Keystore、BAL 都更严格

Android 17 在安全层面有几条非常值得提前处理的变化：

static final 字段对面向 Android 17 的应用变成不可修改
- 反射改 static final 会抛 IllegalAccessException
- JNI 改这类字段甚至会直接 crash
跨应用 / 跨 profile 的 localhost 通信新增 USE_LOOPBACK_INTERFACE 安装时权限
- 如果你的 App 依赖 127.0.0.1 或 ::1 做跨应用通信，要单独检查
Android Keystore 开始对每个应用持有的 key 数量设上限
- 非系统应用且 target 17+：50,000
- 其他应用：200,000
usesCleartextTraffic 已经进入弃用路线
- 官方建议迁移到 Network Security Configuration
target 17+ 默认启用 Certificate Transparency（CT）
Native Dynamic Code Loading 继续收紧
- 通过 System.load() 加载的 native 文件必须是只读，否则会抛 UnsatisfiedLinkError
Background Activity Launch（BAL）约束继续增强
- 对 IntentSender 的后台启动也更谨慎

如果你的项目还有以下做法，建议尽快清理：

通过反射魔改系统常量
Keystore 里无上限堆 key
还在靠 android:usesCleartextTraffic 兜 HTTP
后台直接拉起页面

7. 新能力上，Android 17 也不只是“更严格”，它也确实给了新东西

除了行为收紧，Android 17 也有一些值得关注的新能力：

Handoff
- 支持跨 Android 设备续接任务，例如手机切到平板继续
EyeDropper API
- 无需屏幕录制权限即可读取屏幕像素颜色
AAPM
- Android Advanced Protection Mode，可通过 AdvancedProtectionManager 感知用户是否开启强化保护
JobDebugInfo
- 对后台任务排障很实用
UWB 下行 TDoA、Wi-Fi 邻近能力、流媒体下行/上行速率查询
- 对设备互联、室内定位、可穿戴、IoT 场景很有价值
视频能力增强
- MediaRecorder.setVideoEncodingQuality() 支持常量质量模式
- 平台支持 VVC / H.266

所以 Android 17 的整体气质可以概括成一句话：

一边继续收紧系统边界，一边把跨设备、隐私友好和性能调试能力补齐。

三、哪些变化最可能直接影响现有 App？

如果你没有时间把所有文档都看一遍，优先盯这 10 条：

场景	风险点	建议动作
大屏 / 平板	横竖屏、比例、不可拉伸限制会被忽略	尽快检查 `sw >= 600dp` 布局与多窗口表现
表单 / 编辑器	旋转后键盘不会自动恢复可见	在 `onCreate()` 或配置变化后显式拉起 IME
局域网设备	target 37 后 LAN 通信需要 `ACCESS_LOCAL_NETWORK`	改为运行时申请，或改用系统设备选择器
音视频 App	后台播放、音量、焦点请求可能静默失败	只在有效生命周期和合法前台状态下操作音频
联系人相关功能	再要全量 `READ_CONTACTS` 会显得更重	尽量迁到 Contact Picker
本地代理 / 同机通信	跨应用 `localhost` 不再默认可用	检查是否需要 `USE_LOOPBACK_INTERFACE`
反射 / Hook	反射 `MessageQueue`、修改 `static final` 风险升高	清理私有 API 和反射改常量逻辑
游戏 / 远控 / 绘图	pointer capture 下触控板默认变成相对事件	评估是否需要改为 `POINTER_CAPTURE_MODE_ABSOLUTE`
安全与网络	`usesCleartextTraffic` 进入弃用路线	迁到 `Network Security Configuration`
密钥系统	Keystore key 数量被限制	检查是否存在“按会话 / 用户无限建 key”的逻辑

四、适配指南：建议按官方节奏分两步走

官方 migration 文档给出的节奏非常明确：迁移通常分成两个阶段，而且可以并行推进。

阶段一：先做兼容性适配，不急着 target 37

这一步的目标是：

不改 targetSdkVersion
先把应用放到 Android 17 Beta 2 上跑起来
把“所有应用都会受到影响”的问题先清掉

优先动作如下。

1. 先在真机或模拟器上跑当前线上版本

官方建议：

先拿 Android 17 设备或模拟器安装你当前发布版本
跑完整主流程
重点关注 crash、输入、音频、权限、后台任务、第三方 SDK

这一步非常重要，因为很多兼容性问题不需要 target 37 就会暴露。

2. 先看 All apps 行为变更

Android 17 对所有应用的重点影响包括：

usesCleartextTraffic 弃用路线
未来 Android 18 将收紧隐式 URI grant，建议现在就显式授权
每应用 Keystore key 数量上限
跨应用 localhost 通信限制
配置变化后 IME 默认可见性不恢复
pointer capture 下触控板默认相对事件
后台音频更严格

这一步处理完，你的“基础兼容性”就稳很多了。

3. 排查 restricted non-SDK interfaces

官方迁移文档专门提醒要排查 restricted non-SDK interface。

建议你：

看 logcat 警告
用 StrictMode.detectNonSdkApiUsage() 抓程序化访问
升级三方 SDK 到最新版本

如果你的埋点、热修复、加固、监控 SDK 很老，这一步要重点测。

阶段二：再切 target 37，处理 target-only 行为变更

当你准备完整支持 Android 17 时，再进入第二阶段：

升 compileSdkVersion
升 targetSdkVersion = 37
针对 target-only 行为逐项修

重点关注这些 target-only 变化：

大屏强制自适应
ACCESS_LOCAL_NETWORK
MessageQueue 无锁实现可能影响反射
static final 不可修改
本地网络、安全与 BAL 相关收紧

官方还建议使用 Android 17 的 compatibility toggles 来做定点验证：

不必一次性处理全部 target 行为
可以只打开某个 change 做回归
可以通过 adb 管理，适合集成到自动化测试

这条非常适合大项目，因为它能把“升级 targetSdk”的风险切碎。

五、几个高频适配点，怎么落地更实际

1. 局域网设备类应用：优先补 `ACCESS_LOCAL_NETWORK`

如果你的应用需要访问局域网设备，先把权限链路补上。

<uses-permission android:name="android.permission.ACCESS_LOCAL_NETWORK" />

然后走标准运行时权限申请。
如果你的场景可以切换到系统提供的设备选择器，就尽量优先选择系统 picker，这样用户心智更清晰，也更符合 Android 17 的隐私方向。

如果你的应用还依赖跨应用 127.0.0.1 / ::1 通信，例如：

本地代理
调试桥
同机协同 App
内嵌本地 Web 服务

那还要额外检查 USE_LOOPBACK_INTERFACE，因为它和 ACCESS_LOCAL_NETWORK 不是同一件事。

2. 还在走 HTTP 明文的项目：尽快迁到 Network Security Config

不要再把希望压在 usesCleartextTraffic 上。

更稳妥的方式是把确实需要明文访问的域名单独写进配置文件：

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">example.internal</domain>
    </domain-config>
</network-security-config>

这样你的可控性会比一个全局布尔值高得多，也更符合官方的迁移方向。

3. 大屏适配：别再把“锁竖屏”当方案

如果你准备 target 37，建议立刻检查这些地方：

首页、详情页、播放器、编辑页在平板横屏下是否还能用
弹窗、BottomSheet、悬浮层是否写死尺寸
Compose / View 布局是否基于窗口尺寸分级
分栏和导航是否能在更宽窗口下重排

Android 17 的信号已经很明确：
大屏适配从加分项，正在变成基础项。

4. 音频类 App：把所有“后台偷偷调用”找出来

重点搜索这些触发点：

requestAudioFocus
adjustVolume
setStreamVolume
进入后台后触发播放
广播 / Worker / 定时器里触发播放

如果这些操作不是由用户可感知的前台交互触发，就要尽快重构。

5. 输入与编辑类 App：测试旋转、外接键盘、中文输入法

Android 17 对输入相关改动不少，尤其要测：

旋转后键盘是否还能自动弹出
自定义 InputConnection 是否正确分发文本变更
外接键盘和 CJK 输入法组合下的无障碍反馈

对普通 TextView 来说，Android 17 已经帮你兜了一部分；
但如果你是富文本编辑器、代码编辑器、自定义输入框，就不能只靠默认行为。

六、我建议团队现在就执行的 Android 17 适配清单

如果你只想拿一份待办清单，可以直接照这个顺序推进：

用 Android 17 Beta 2 真机 / 模拟器跑当前线上版本。
按官方文档过一遍 all apps 行为变更。
全局搜索私有 API、反射改常量、MessageQueue Hook。
检查是否存在 HTTP 明文访问，迁到 Network Security Configuration。
检查 LAN、Cast、IoT、NAS 场景，评估 ACCESS_LOCAL_NETWORK。
检查后台音频、音频焦点、音量控制链路。
检查表单页、旋转、IME、外接键盘、大屏窗口。
检查自定义通知、第三方 SDK、JobScheduler、WorkManager 相关行为。
升级三方 SDK，并用 StrictMode.detectNonSdkApiUsage() 做一次排查。
再开分支升级 compileSdkVersion / targetSdkVersion = 37，用 compatibility toggles 定点回归。

七、结论

Android 17 现在最值得关注的，不是“又多了几个新 API”，而是它把 Android 这几年的几个长期方向继续往前推了一步：

大屏适配更硬性
隐私授权更细粒度
安全默认值更严格
音频和输入行为更规范
调试与性能排查链路更完整

如果你是 Android 团队负责人，我的建议很直接：

从现在开始做 Android 17 兼容性验证，但把“全面 target 37”放到问题清单收敛之后。

这样做的好处是：

不会把 Beta 期的不确定性直接带进主线
能尽早发现大屏、音频、局域网、输入法这些隐藏问题
等 Android 17 接近正式版时，你的适配工作量会小很多

Android 17 最新动态与适配指南：Beta 2 到底改了什么，应用现在该怎么跟？