移动开发界囚徒现身说法，审查困境与控制权探讨
作者 | Jarmo Pertman
译者 | 核子可乐
策划 | 李冬梅
用现实生活中的真实案例，聊聊 Android（也包括 iOS）应用开发的变革节奏有多么迅猛。
我们一直在负责为客户维护一款有点年头的 Android 应用。这款软件是面向最终客户在生产环境下使用的，目前已经不再做任何主动开发了，多年来只要能稳定起效就万事大吉。如果能让我们说了算，那我们绝对不会动这应用一分一毫，让它那样恬淡运转、岁月静好就是最佳安排。
事情的开端
一切麻烦的开端，源自谷歌 2023 年 8 月 18 日发出来的这封看似无害的通知邮件。
为了了解关于内容的更多信息，我在谷歌官网上发现了以下提示：
下面这句话引起了我们的注意：现有应用必须指向 level 31 或者更高级别的 API，以确保正在运行高于应用目标 API 级别的 Android 操作系统 / 设备用户仍可正常使用。光从内容上看，我很难想象这款应用在不同 API 级别的设备上会搞出哪些问题。为了不对客户造成实际影响，我决定主动出击、优先将其解决。我知道这事不会增加任何商业价值，但人家谷歌都友情提示了，应该是说明影响比较严重吧。而且谷歌还专门给出了截止日期，距离收到邮件之日起已经不足 3 周。最后我向大家保证，谷歌在此之前从未没发送过关于这个问题的任何邮件。
着手升级
时间来到 8 月 23 日，我开始将 targetSdkVersion 从 API level 30 更新到 33，并尝试在 Android 模拟器中编译 / 运行这款应用。但因为依赖项不兼容，首次运行失败了。幸运的是我可以删掉这个依赖项，因为它主要是跟分析相关的，而且与业务逻辑本体也没有紧密耦合，所以影响不算太大。
在成功运行应用并尝试了一番核心功能之后，我发现新版本的使用效果基本跟原先相同，也没出什么问题。准备就绪，是时候把它放进 Google Play Store 了。
Play Store
应用在 Play Store 的上架流程也基本没有问题。当然，因为这是个遗留应用的版本更新，发布间隔比较长，所以我得按谷歌的指示填写一些调查问卷。相信每年都要更新一、两次应用的朋友早就习惯这个流程了，我承认是我自己不太适应。完成之后，应用开始进入审核流程，而且整个审核、接收和发布至生产环境的过程只用了不到 1 个小时。我寻思着这也太顺利了，却无论如何没有想到大麻烦会在下班之后等着我。
麻烦来了
大概是晚上 21：30 左右，手机上亮起客户发来的消息，说使用最新的应用版本会在登录账户时遇到问题。开始我并没有惊慌，因为问题看起来跟应用更新没啥关系。但在第一次使用 Android 实机（我之前只在模拟器上测试过）检查了登录流程后，发现应用会崩溃并关闭。那一刻起，我的脊背开始发凉，于是慌忙调查究竟是哪里出了问题。
经过一系列故障排查之后，明显就是最新的 Android 版本（当时是版本 13）有毛病。这个问题会导致应用在登录后立即崩溃，而使用较旧 Android 版本则不受影响。我们的最大疏忽，就是没有在模拟测试时使用最新的 Android 版本，所以没能及时问题隐患。更新时引发问题其实并不少见，但这次谷歌设定了明确的截止日期，再加上需要更新的东西并不多，所以让人放松了警惕。我本来可以在模拟器里多测试几种 Android 版本的，但谁想得到呢……
解决问题
我想到的第一件事，当然就是先回滚到 Google Play Store 中的较旧版本，确保把受影响的范围控制在运行最新 Android 系统版本的用户之内。然后等第二天上了班，我再具体解决这个问题。但令人意外的是，我发现 Google Play Store 根本不支持这项功能——Android 生态不允许撤回或撤销最新版本。
第二个想法则是把 targetSdkVersion 恢复到 API level 30、做个新的应用版本并发布到 Play Store 上。但这同样不行，因为谷歌会弹出强制要求使用 API level 33 的错误信息（这就是谷歌在声明中提出的，所谓 9 月 1 日之前必须对低于 level 33 的应用做更新）。这时候我想到，可以把谷歌扩展的 API level 30 使用时间延长到 11 月 1 日——我做了尝试，但错误提示仍然存在。也就是说，我根本没法回归旧版本，唯一的办法只有修复最新 Android 版本的崩溃问题、继续保留更新后的应用。
而且我得马上就开始修复。毕竟 Google Play Store 不支持版本回滚，如果不立即着手解决，用户会逐渐把这个最新版本的应用安装到手机上，然后把我们公司彻底逼疯。
我还算幸运，因为同样的崩溃状况在最新 Android 模拟器上成功复现，而且修复起来并不需要做太多代码变更。但熬夜加班还是很容易出错误，在把修复版本摆上 Play Store 前也实在没有多少时间能做全面测试。但毕竟之前的问题是应用在登录后立即崩溃，所以我觉得这次更新再怎么差也比之前要好。简单来讲，我想达成的效果就是修复所有已知的崩溃问题、发布新版本，然后在逐步完成全面测试后再更新一个包含后续修复的新版本。所以在向 Play Store 提交了新版本后，我就在焦急地等待谷歌完成审核。
在苦等了两个小时无果之后，我决定在凌晨一点左右去睡觉，希望早上醒来时就能看到应用顺利上架。
时间来到第二天
我从床上爬起来，发现申请仍处于“审核中”。
这一天里，我随时都会跑到 Google Play Store 页面上点几次刷新，想看看应用发没发布、在 Android 13 上到底能不能成功运行。其实我还是有点信心的，毕竟修复过程只发现了一些小问题、也都顺利解决了，应该不会卡审核才对。
但直到第二天结束，申请状态仍然显示为“审核中”。
后来，我总算了解了谷歌
我查阅了不少移动应用开发方面的文章，其中都提到了类似的情况。有时候谷歌（或者苹果）会阻止开发者修复生产应用中的问题，甚至可能无缘无故就把应用从软件商店中下架。
作为开发者，我们没有任何办法来加快审核过程，也不能以任何方式联系谷歌支持人员。唯一能做的就只有等待，等待巨头们能施下神明般的怜悯、让我们挽回自己的那一点无心之失。
多年来，我个人一直很反感移动应用开发，理由也跟这类文章中的说法相同——一旦决定开发移动应用，我们实际上就是把产品 / 服务的控制权交给了第三方，即使出了问题也无法修复。这种控制权落在了谷歌 / 苹果等科技大厂手中。如果不出问题当然是皆大欢喜，而一旦出了问题，你就只能求上天保佑了。而且残酷的现实是，无论你的技术水平有多高超，都不可能彻底回避问题。这时候，你不仅没有任何补救的手段，甚至可能第一次感受到跟技术 / 财务巨头对抗的致命压迫感。
如今，我甚至不确定整个开发者社区为什么要允许这种情况发生——毕竟在大多数情况下，真有必要专门搞个移动应用吗？是时候回归开放网络标准，把控制权重新掌握在自己手中了！各项技术已经准备就绪，我们何不反攻谷歌、夺其鸟位？毕竟之前那种随时刷新 Google Play 控制台页面、绝望地等待“审订中”状态发生变化的日子就不应该存在。
到现在时间已经过去了约 72 个小时，更新的状态仍处于“审核中”。我能做的就是等着，等待谷歌那边有某位员工按下正确的按钮、把应用更新发布到商店中。这是我这辈子见过的最漫长的谷歌审核流程（苹果倒是一直就这么慢）。墨菲定律说的就是这码事吧——最差的情况总是在最要命的时刻发生。
所以，你敢相信一名程序员现在唯一能做的就是求神拜佛吗？不知道大家怎么样，但我觉得这样的问题解决方式实在是太不专业了。
原文链接：
https://solutional.ee/blog/2023-08-26-Prisoners-of-Google-Android-Development.html
相关阅读：
移动应用高级语言开发——并发探索 (https://xie.infoq.cn/article/470a83d4c9516e01690eec296)
Docker 等容器技术如何与移动开发相结合 (https://xie.infoq.cn/article/ad6a4d3bd176fd3d1b23b9d42)
移动应用程序开发新趋势 (https://xie.infoq.cn/article/444b7c4090093ce159d19a3ac)
推荐几款实用的移动开发平台 (https://xie.infoq.cn/article/266bee1c50151f75bddbaa88d)
声明：本文由 InfoQ 翻译，未经许可禁止转载。
点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！
今日好文推荐
上云还是下云：章文嵩博士解读真正的云原生 Kafka 十倍降本方案！
互联网大厂“组团”宕机，都怪降本增“笑”？
软件开发“食物链”：运维竟高于开发，最顶端该是用户还是管理层？
滴滴 P0 事故，K8s 背锅？拼多多正式登顶中国电商巨头，马云阿里内网罕见发言；学霸女儿创业AI项目火了，老爸公司涨停｜Q资讯