本文首发于公众号"Android技术圈"
Android 17 Beta 4 已经开始推送了，而且这是本轮发布周期最后一个"计划内 Beta"。
如果你还没开始"全面兼容性回归"，现在就是最合适的窗口：平台更稳定、API 更接近定稿、踩坑成本最低。
关键里程碑
官方把 Beta 4 定义为"关键里程碑"：它提供了一个接近最终形态的测试环境，适合做三件事：
-
• 把应用的核心路径（登录、支付、播放、上传、消息、搜索等）在 Android 17 上完整走一遍
-
• 把"看不见"的兼容性风险（权限、网络、动态加载、后台行为、证书链路）提前暴露出来
-
• 如果你是 SDK/库/工具/游戏引擎提供方，尽快把兼容性补丁发出去，避免下游被 target 17 卡住
最容易出问题的 4 个行为变更
很多团队在 Beta 阶段最常犯的错，是把注意力只放在"新 API"，却忽略了"旧逻辑在新系统上的默认规则变了"。
大屏可调整性：target 17 后更"强制"
如果你的应用在平板/折叠屏上还依赖某些"限制开关"，需要尽快调整预期：当你 target Android 17 后，大屏上的方向、可调整性、以及部分比例约束的"退出开关"不再生效。这对视频、阅读、游戏、工具类 App 的 UI/交互会有实际影响：同一个页面在不同尺寸下的布局稳定性，需要你用真实设备（或高分辨率模拟器）去验证。
动态代码加载：native 也进入更严格的安全门槛
如果你的项目存在插件化、热修复、脚本引擎、第三方 SDK 动态加载等场景，务必关注这一条：当应用 target 17+，Android 14 引入的"更安全的动态代码加载（DCL）"范围扩展到了 native 库。
简单说：通过 System.load() 加载的 native 文件必须是只读 ，否则系统可能直接抛 UnsatisfiedLinkError。这类问题一旦发生，往往是线上"必现崩溃"，而且和机型/安装路径/文件权限相关，越早在 Beta 里暴露越好。
本地网络：默认阻断，权限需要更明确
Android 17 对本地网络访问的保护进一步收紧：target 17+ 的应用默认无法访问本地网络 。官方建议是"能用隐私友好选择器就别自己扫网段"，如果确实需要"广泛、持续"的本地网络访问，再使用新的 ACCESS_LOCAL_NETWORK 权限。
你要做的不是"加不加权限"这么简单，而是把产品流程重新过一遍：哪些功能真的需要本地网络？有没有更少权限的替代路径？在用户授权前，是否还能提供可用但降级的体验？
后台音频：播放/焦点/音量交互更严格
从 Android 17 开始，音频框架对后台音频交互施加更严格限制，包含：
-
• 后台播放行为
-
• 音频焦点请求
-
• 音量调整相关 API
官方还提到：基于开发者反馈，Beta 2 之后已经对规则做过调整（例如某些场景的 targetSDK gating、闹钟音频豁免等）。这意味着你要用 Beta 4 做的测试，应当覆盖"真实用户会用到"的后台场景：锁屏、后台切前台、电话/导航打断、耳机插拔、蓝牙切换、闹钟/计时器等。
性能与安全
如果只做功能回归，很可能会在正式版之后才遇到"卡顿、耗电、被系统杀"的口碑问题。Beta 4提到了三类对体验影响很实在的新机制：内存上限、异常触发 Profiling、以及 Keystore 的后量子密码能力。
应用内存上限：更稳定，也更无情
Android 17 引入了基于设备总 RAM 的应用内存上限，目标是让系统环境更稳定、行为更可预期：优先打击极端内存泄漏与异常会话，避免它们把整个系统拖进掉帧、耗电、频繁杀进程的状态。
官方也强调：绝大多数会话影响预计不大，但建议建立内存基线 。特别是当你发现进程退出相关信息里出现 "MemoryLimiter"（通过 ApplicationExitInfo.getDescription()），这基本就是系统在提示你：别再拖了，赶紧抓泄漏。
异常触发 Profiling：系统帮你"提前留证据"
Android 17 引入了设备端异常检测服务，并与 ProfilingManager 集成。你可以用 TRIGGER_TYPE_ANOMALY 触发类型，在系统认为"异常"的时候拿到 profiling 产物，例如：
-
• 内存上限命中时的 heap dump
-
• binder 调用过量（binder spam）时的采样分析
更关键的一点是：官方明确说，这个回调发生在系统强制措施之前。换句话说，你有机会在"被杀之前"拿到证据，定位根因会比传统的线上日志/崩溃栈更直接。
Keystore 支持 PQC：ML-DSA 走进系统能力层
安全侧这次的亮点是：Android Keystore 增加了对 NIST 标准 ML-DSA 的支持。在支持的设备上，你可以在安全硬件里生成 ML-DSA 密钥，用它做量子安全签名，并通过标准 JCA API（如 KeyPairGenerator / Signature）使用。
这对短期"必须用"的业务未必立刻产生变化，但它是一个清晰信号：平台在逐步把"后量子时代的加密能力"下沉为系统默认能力，安全与合规团队会越来越关注它。
写在最后
你们团队现在对 Android 17 的适配进度到哪一步了？最难啃的坑是哪一类（大屏、网络、动态加载、后台行为、性能）？欢迎在评论区聊聊，我也会把大家反馈最多的问题整理成下一篇"避坑清单"。