就在今天，紫光展锐宣布完成 Android 17 同步升级，旗下 T8300、T7300 等平台完成适配验证。知乎两天前，谷歌也面向 Pixel 10 等 19 款机型推送了 Android 17 QPR2 Beta 3。知乎ROM 这边，基于 Android 17 的 ColorOS 17 也已开启首批升级招募。知乎
Android 17 的设备盘子正在快速变大，但对不少 App 开发团队来说，“适配"可能还躺在待办清单的末尾。Android 17 稳定版已于 2026 年 6 月 17 日正式发布，国内主流厂商小米、vivo、OPPO、荣耀预计 7-8 月开始推送。知乎这一版被官方称为"Android 系统上第一个 AI 升级”，不过对真正写 App 的人来说，更该盯紧的不是 AI 故事，而是一批关乎应用生死的行为变更。这篇把多方信源捋了一遍，聊聊哪些坑最疼、窗口期还剩多久。
最疼的一条：被杀进程，但没有崩溃堆栈
过去系统内存紧张时，靠 Low Memory Killer 按优先级杀后台，前台应用基本安全。Android 17 换了逻辑：系统会按设备物理内存总量为每个 App 设定明确的内存使用上限，一旦超限，进程直接被终止，而且不会留下常规的崩溃信息。知乎也就是说，用户侧的表现只是"App 突然没了"，你的崩溃平台却一片安静。
官方给的判断方法不复杂：下次启动时读取 ApplicationExitInfo，如果退出原因是 REASON_OTHER、description 字符串里带 MemoryLimiter:AnonSwap，就是被内存限制器"静默处理"了。知乎这也意味着，把 ApplicationExitInfo 加进启动诊断链，在 Android 17 上几乎是必修课，不然这类死亡会一直是笔糊涂账。
官方开的药方很具体。一是把 R8 优化全开、换用新的 proguard-android-optimize.txt——官方明确说旧的 proguard-android.txt 会阻止优化，AGP 9 里也不再支持。知乎二是 onTrimMemory 里主动释放缓存，重点处理 TRIM_MEMORY_UI_HIDDEN 和 TRIM_MEMORY_BACKGROUND 两个回调。三是用 ProfilingManager 新增的 TRIGGER_TYPE_OOM 和 TRIGGER_TYPE_ANOMALY 两个触发器，在接近被杀前抓到 heap dump，看清到底是谁在占内存。信源文章引用的 R8 优化案例图显示：Monzo 银行在优化全开后，冷启动改善约 30%、ANR 率下降约 35%、包体积缩小约 9%——R8 这次是真值得动。
这个改动也有争议。做性能优化的开发者普遍认可：以前一个内存泄漏的 App 能拖着系统杀一堆正常缓存应用，用户切回去全是冷启动。也有声音担心，内存受限后应用驻留时间变短，链式启动这类场景会受到影响。知乎站在用户一边，系统清理"内存大户"是好事；但站在开发者一边，内存问题从"优化项"变成了"生存项"。
行为变更分两层：不是不动 targetSdk 就能躲
Android 17 的行为变更分两层。这个区分很重要，因为"我还没升 targetSdk，所以与我无关"这个想法只对了一半。
第一层，影响所有应用，不管 targetSdk 多少。
内存上限（即上条）。图片编辑、视频处理、直播、地图、IM、电商长列表等重内存场景首当其冲；
后台音频收紧：应用不处于有效生命周期状态时，播放、焦点请求、音量调节可能静默失败；
部分配置变化不再重启 Activity：键盘、导航、触摸屏、颜色模式等变化改走 onConfigurationChanged()，以前靠重建 Activity 偷懒刷新资源的，会出现主题不更新、状态错乱，必要时要用 android:recreateOnConfigChanges 显式声明；
自定义通知视图的尺寸限制更严，URI 绕过的口子也被堵上。
以上这些行为变更影响所有应用，与 targetSdk 无关。知乎
第二层，targetSdk 升到 37 才会撞上。
大屏设备（sw>600dp）上，锁竖屏、禁止缩放这类限制会被系统无视，只有部分游戏类目能按 Google Play 分类豁免。知乎官方统计目前已有超过 5.8 亿台大屏 Android 设备，"只锁竖屏"的 App 迟早要补这一课；
MessageQueue 换成 lock-free 架构，反射访问私有字段会出异常；
static final 字段不能再靠反射或 JNI 修改，轻则 IllegalAccessException，重则直接 crash；
访问局域网设备要申请新的 ACCESS_LOCAL_NETWORK 权限，或走系统中介的设备选择器——投屏、打印、NAS、智能家居、局域网联机全要重新梳理。知乎短信验证码的读取也可能被延迟 3 小时，建议尽早切到 SMS Retriever 这类合规方式。
一句话：不升 targetSdk，前四条照样随系统更新找上门；升到 37，后四条一次补齐。两头都躲不掉，只能排优先级。
两个值得长线关注的信号
一个是 Compose-first 被官方正式"官宣"：新的 API、库和工具都优先围绕 Jetpack Compose 构建，Fragment、RecyclerView、ViewPager 这些 View 系库进入维护模式，不再有新功能。知乎新项目基本没有理由再从 XML 起步，老项目也该把迁移排上日程了。
另一个是 AppFunctions。App 可以把"创建笔记"“搜索内容"这类能力暴露成结构化工具，让系统级 AI Agent 发现和调用，函数名、参数、返回值、说明都会被系统索引——可以理解成 Android 版的官方"MCP”。知乎目前 Jetpack AppFunctions 库还在预览阶段，用 Kotlin 注解加 KDoc 描述函数能力，谷歌还配了辅助生成代码的 agent skill。方向已经很明确：后面的 App 不只要设计页面，还要设计能被系统理解的能力接口。
开发者社区也已经在跟进这波变化，GDG 开发者社区的分享主题覆盖了 Android 17 核心变更、应用内存限制与 MessageQueue 无锁化重构、ProfilingManager 实践、大屏适配和后台音频。哔哩哔哩
现在该做什么：窗口期和优先级
时间上有两个节点值得盯。一个是国产厂商基于 Android 17 的新系统 7-8 月起陆续推送，小米、OPPO、vivo、荣耀都已公布测试版适配机型，包括小米 17、OPPO Find X9 Pro、vivo X300 Pro、荣耀 Magic8 Pro 等旗舰，测试版就是给开发者做适配调试用的。知乎另一个是 QPR2 预计 2026 年 12 月推送稳定版，届时系统侧的变化就齐了。知乎
按优先级，我的建议是：
所有 App：先用现有 targetSdk 在 Android 17 真机回归一轮，重点盯后台音频、配置变化页面、通知、内存四条链路。模拟器测不出厂商 ROM 差异，真机必须上；
重内存应用（音视频、图片、直播、IM、长列表）：优先做内存自查，ApplicationExitInfo 打点安排上，R8 full mode 排期评估；
IoT、投屏、智能家居、局域网联机类：现在就梳理本地网络权限链路，这是 target 37 的硬变更；
计划升 target 37 的：先做大屏适配，再排查反射和 static final 用法，最后验证短信验证码链路；
长线：Compose 迁移分阶段规划，AppFunctions 保持关注，从预览跟到稳定。
最后留个话题：你的 App 在 Android 17 设备上遇到过"无堆栈死亡"吗？是怎么定位的？评论区聊聊，互相避坑。
