【CSDN 编者按】 这篇文章描述了作者维护一款旧版安卓应用的经历。由于谷歌要求应用更新到更高级的 API 级别，导致更新后的版本在最新安卓系统上崩溃。作者修复问题后，因为谷歌审核耗时长，作者在文章最后呼吁回归开源标准，在开发应用程序中减少对巨头公司的依赖。

(相关资料图)

原文链接： https://solutional.ee/blog/2023-08-26-Prisoners-of-Google-Android-Development.html

未经允许，禁止转载！

作者 | Jarmo Pertman 译者｜Ric Guan 责编 | 屠敏 出品 | CSDN（ID：CSDNnews）

过去，我们一直负责为客户维护一款旧版的 Android App，这款 App 已经投入使用了很多年，而且很长时间才会更新一次。如果由我们来决定，我们可能不会对这个 App 做任何其他的事情，只会让它快乐地活下去。

开端

然而，一切到了 2023 年 8 月 18 日这一天发生了巨大的改变。那一天，我们收到了谷歌一封看似纯洁的电子邮件：

邮件提示让作者将他两款 app 在8 月 31 日之前更新到最新目标 API 等级规定

为了找到更多有关这一要求的信息，我在谷歌网站上找到了以下内容：

其中下面这句话引起了我们的注意：“现有应用程序必须达到或超过 API 31 级（Android 12），才能在比应用程序目标 API 级更高的 Android 操作系统的设备上供用户使用”。

读到这句话，我们很难理解那些目标 API 等级比较低的程序应用安装在新版本 Android 设备上会发生什么。

于是我采取了 “宁可信其有，不可信其无” 的做法，优先完成了这项任务，尽管它不会带来任何商业价值，纯粹因为谷歌要求必须完成。而谷歌规定的截止日期距离收到电子邮件的时间不到 3 周。在此之前，谷歌没有就这个问题发送过其他电子邮件。

实施改变

我从 8 月 23 日开始执行这项任务。我将 targetSdkVersion 从 API 级别 30 更新到 33，并尝试在 Android 模拟器中编译/运行应用程序。由于依赖关系不兼容，第一次运行失败。幸运的是，我可以直接移除该依赖关系，因为它与分析有关，与业务逻辑本身并不紧密相关，所以并不那么重要。

我成功运行了应用程序，并试用了核心功能，其工作方式似乎与之前一样，没有任何问题。是时候把它放到 GooglePlay 商店了。

Play 商店

将应用程序放入 Play 商店的过程基本上没有遇到任何问题。当然，由于这是一款不经常发布的旧版应用程序，所以我需要填写一些由谷歌制作的问卷，但这在应用程序每年最多更新一到两次的情况下是很正常的。

填写完这些问卷后，应用程序就被送去审核了。

不到一个小时的时间，应用程序就通过了审核、验收并投入生产。当时我还不知道接下来会发生什么，这一切都发生在晚上下班后。

前方的问题

21：30 左右，我的手机收到客户发来的信息，称使用最新版本的应用程序登录账户时遇到了问题。起初我并不太担心，因为这似乎与应用程序更新没有任何关系。

不过，我第一次用最新的安卓系统设备（之前没有使用过）进行了仔细检查，看看能否成功登录。登录后，应用程序立即崩溃并关闭。

那一刻，我的脊背开始发凉，于是我开始更详细地调查所遇到的问题。

经过一番排查，很明显，最新的安卓系统（当时是 13）存在问题，登录后应用程序会立即崩溃。使用旧版本的安卓系统则没有问题。

我们的问题之一是我在测试时没有在模拟器中使用最新的安卓版本，因此这些问题就没有被发现。更新时出现问题并不是没有发生过，但这次谷歌设定了时间压力，而且改动很小，所以就不那么令人期待了。我本可以通过使用不同版本的安卓系统模拟器做得更好，但为时已晚。

解决问题

我的第一个想法是回滚到谷歌应用商店中的旧版本，这样只有运行最新安卓系统并拥有最新版本应用程序的用户才会受到影响，然后在第二天以适当的方式处理这个问题。但出乎意料的是，我发现这是不可能的 -- 安卓生态系统无法撤回或取消最新版本。

第二个想法是将 targetSdkVersion 恢复到 API 级别 30，提升应用程序版本并在 Play 商店上创建一个新版本。这也是不可能的，因为谷歌显示了关于 API 33 级是强制性的错误信息（还记得谷歌关于 33 级以下的应用程序更新在 9 月 1 日之前是可能的声明吗？） 此时我还意识到，我可以向谷歌申请延期，以便在 11 月 1 日前使用 31 级 API - 我照做了，但不幸的是，错误信息依然如故。这意味着我们无法返回到旧版本，唯一的办法就是修复最新安卓版本的崩溃问题，然后创建一个新版本。

我需要立即开始修复，而不是撤回到之前的版本并在第二天修复崩溃问题，因为用户正在慢慢地自动将最新版本的应用程序更新到他们的手机上。

幸运的是，这些崩溃也发生在最新的安卓模拟器上，而且不需要修改太多代码就能修复。但是，在晚上工作时间紧迫的情况下，错误还是有可能发生，而且在把修复版本放到 Play 商店之前，也没有那么多时间进行彻底测试。既然应用程序在登录后会立即崩溃，那么无论如何我都要尽快将更新版本放到 Play 商店中，这样会比目前的状态更好。

简而言之，我们的计划是修复所有已知的崩溃问题，发布一个新版本，然后经过更彻底的测试，再发布一个包含可能修复问题的新版本。至少这是我们的想法。在 Play 商店上创建新版本后，我焦急地等待着谷歌完成审核。

审查已经进行了两个小时，我决定在夜里一点左右睡觉，希望早上醒来时应用程序已经发布。

第二天

起床后，应用程序仍处于 \"审核中 \"状态。

这一天的大部分时间我都用来刷新 Play 商店页面，查看应用程序是否可以在 Android 13 上发布和测试。发现了一些小问题，并进行了修复，但都不是关键问题。

一天结束时，应用程序仍处于 “审核中” 状态。

后续

我读过多篇关于移动应用开发中发生类似情况的文章，谷歌（或苹果）阻止修复生产中的问题，甚至更糟糕的是，应用会无缘无故从相应的应用商店中下架。

作为开发者，我们无法加快审核过程，也无法以任何方式联系谷歌支持。没有任何可能的变通办法，我们只能等待。直到我们有被批准将修复程序投入生产。

我个人多年来一直反对开发移动应用程序，原因与本文及其他类似文章所述完全相同 -- 一旦你决定开发移动应用程序，你就把产品/服务的控制权交给了第三方，一旦出现问题，你就无法更换。它被匿名的大公司谷歌/苹果所控制，只要不出问题，大家都很高兴。但一旦出现问题，你就只能靠自己了，无论你的技术有多好，都无法解决问题。通常情况下，你甚至没有任何临时变通的办法。你只能一个人与价值数十亿美元的公司对抗。

如今，我甚至不知道作为开发者的我们为什么会允许这种情况发生--开发移动应用程序通常已经没有任何充分的理由了。是时候回归开源（网络）标准，将控制权重新掌握在我们自己手中了！技术已经准备就绪。在此之前，我们只能不断刷新 “Google Play 控制台” 网页，希望更新能从 “审核中” 状态转入生产状态。

已经过去了大约 72 小时，更新仍在 “审核中”。我只能等待，希望谷歌的某个人按下正确的按钮，允许应用程序更新进入商店。这是我第一次看到谷歌如此漫长的审核过程（苹果通常是这样）。墨菲定律--当然会在最关键的时刻发生。

希望是我现在唯一的选择。我不知道你怎么想，但这显然听起来并不是解决问题的专业方法。