8 月中旬那件事刷屏时我没写，一是让子弹飞一会儿，二是自己也还在思考；这两天开始发表公众号，觉得值得记一笔——它表面是座位纠纷，实际暴露的是「规则边界清楚了，执行细则没跟上」。

做安卓开发这些年，博客基本就是写某个技术点的踩坑记录：某个 API 的行为变了、某个库的版本兼容问题、某个奇怪的崩溃栈。但现在 AI 问两句就能把来龙去脉讲清楚，甚至还顺带给出代码片段，这种”点对点”的技术笔记确实越来越没必要写了。

前阵子回头看自己学 Flutter 那段经历，突然有点感慨。当年为了上手，老老实实把 StatefulWidget、setState、路由、MethodChannel 这些啃了一遍，还专门记了笔记，生怕哪天忘了某个 widget 的参数。现在再让我徒手写 Flutter，我八成写不出来，但让我“用 Flutter 做个需求、改个 bug”，我一点都不虚——鼠标点开 WorkBuddy，把需求甩给它就行。

适用对象：计划将应用升级 / 适配到 Android 17（API 37）的 Android 开发团队
文档目标：明确 所有应用 与 以 Android 17 为目标平台（targetSdk = 37）的应用 各自需要完成的适配项。每个适配点按「背景 / 适用范围 / 变更内容 / 适配步骤」展开，说明为什么要改以及具体怎么改。

0. 文档导读

Android 17 的适配变更可分为两类，团队需按自身升级目标分别处理：

建议升级路径：先确保应用能在 Android 17 设备上正常安装运行（全局变更），再将 compileSdkVersion / targetSdkVersion 提升到 37 并验证目标平台变更。可利用系统提供的兼容性切换开关（通过 adb 管理）分阶段验证。

注：部分全局变更当前由 Aconfig Flag 控制、或属于「弃用预告 / 限制预告」，在 Android 17 中可能尚未完全强制生效，但建议现在即着手迁移，避免 Android 18 正式生效时被动改动。

适用对象：计划将应用升级 / 适配到 Android 16（API 36）的 Android 开发团队
文档目标：明确 所有应用 与 以 Android 16 为目标平台（targetSdk = 36）的应用 各自需要完成的适配项。每个适配点按「背景 / 适用范围 / 变更内容 / 适配步骤」展开，说明为什么要改以及具体怎么改。

0. 文档导读

Android 16 的适配变更可分为两类，团队需按自身升级目标分别处理：

建议升级路径：先确保应用能在 Android 16 设备上正常安装运行（全局变更），再将 compileSdkVersion / targetSdkVersion 提升到 36 并验证目标平台变更。可利用系统提供的兼容性切换开关（通过 adb 管理）分阶段验证。

适用对象：计划将应用升级 / 适配到 Android 15（API 35）的 Android 开发团队
文档目标：明确 所有应用 与 以 Android 15 为目标平台（targetSdk = 35）的应用 各自需要完成的适配项。每个适配点按「背景 / 适用范围 / 变更内容 / 适配步骤」展开，说明为什么要改以及具体怎么改。

0. 文档导读

Android 15 的适配变更可分为两类，团队需按自身升级目标分别处理：

建议升级路径：先确保应用能在 Android 15 设备上正常安装运行（全局变更），再逐步将 targetSdkVersion 提升到 35 并验证目标平台变更。

之前负责的 Android 项目都是原生开发，公司有基于 Flutter 开发的项目，最近分了个问题单给我来改，准备基于实际问题一边修改问题，一边学习 Flutter 相关的知识。此文便记录下学习 Flutter 的过程。

背景

Claude Code 是 Anthropic 官方推出的命令行 AI 编程助手，支持在终端中直接进行代码生成、重构、调试等操作。但 Anthropic 官方 API 在国内无法直接访问，需要借助第三方兼容端点。

DeepSeek 提供了兼容 Anthropic Messages API 格式的端点，国内可直接访问，使得我们可以在无需代理的环境下使用 Claude Code。

最近了解到一个比较重要的 Android 兼容性变化，需要在项目里提前关注一下：Android 15 开始原生支持 16KB 内存页面大小，未适配的应用将直接无法在新设备上安装运行，直接闪退。刚好团队有新项目在规划中，就花时间研究了一下，在此记录。

在多人协作开发（尤其是参与开源项目或团队公共项目）时，直接向官方仓库推送代码是不太现实的——普通开发者通常没有上游仓库的写权限，就算有，每个人往上一通推，代码冲突和稳定性问题也够呛。还有一个常被忽略的原因：分支管理。上游仓库需要保持分支整洁，只保留主分支、开发分支等核心分支，如果每个开发者的个人分支都往上堆，很快就会乱成一锅粥。

所以日常开发用的是 Fork 工作流：先把官方仓库 Fork 到自己名下当「个人开发中转站」，在自己的仓库里随便建分支、搞开发，完事后通过 MR/PR 提交审核。这样既不影响上游仓库的分支整洁性，也有独立的开发空间。这个流程大家都很熟悉，但有个细节容易踩坑——本地 git push 时，代码到底推送到哪？