Android 应用程序更新后BuildConfig.VERSION_代码与PackageManager.getPackageInfo（）之间不匹配

我发现我的应用程序用户经常遇到一种奇怪的情况（通过Crashlytics/Google Analytics reporting…），我无法重现这种情况：

更新我的包后-PackageManager类返回的版本代码与

BuildConfig.version\u code

返回的版本代码不同：

int packageManagerVersionCode = context.getPackageManager()
                                .getPackageInfo(context.getPackageName(), 0).versionCode;

boolean versionMismatch = packageManagerVersionCode != BuildConfig.VERSION_CODE;

为了简单起见，我省去了大部分日志记录、官僚作风和封装，但结果是：

• packageManagerVersionCode

  等于正确的更新版本

• BuildConfig.VERSION\u code

  等于更新前应用程序的版本

需要提及的要点：

• 我的应用程序在设备固件上作为系统应用程序预加载
• 我的应用程序正在自我更新（它具有所需的权限..）

我目前的假设是，由于原始APK安装在system/priv应用程序分区中，并且更新不在系统分区上，因此在更新后的某个时间点，原始预加载应用程序的进程在某些方面仍然有效。我没有任何方法来证实这个假设，也没有找到任何官方的参考资料来证明这种行为是否会发生

您可能想知道为什么我会关心这个版本代码不匹配，以及我最初是如何想到做这个验证的：在我们在一个新版本中更改了清单中注册的

BroadcastReceiver

的名称（出于重构目的…）之后，这一切都是从一个面向生产用户的验证开始的

当重新将接收器重命名为原始预加载版本中调用的原始名称时，我们停止了崩溃，因此我们怀疑这与版本代码不匹配有关

我的问题是：

• 为什么会出现这种版本不匹配

---

• 我能做些什么来防止它发生吗？或者至少确保原始预加载应用程序中的组件不会处于活动状态

• 我关于它为什么会发生的假设是正确的吗

---

“至少要确保原始预加载应用程序中的组件不会处于活动状态？”--您可以尝试侦听，如果发现版本代码不匹配，请终止进程。这只是一个想法，因为我从未亲自处理过预装应用程序，所以我不知道与普通SDK应用程序相比，“游戏规则”有什么不同。@commonware:谢谢你的建议。实际上，我确实会听操作“我的包”替换，因为我需要在替换包后运行特定的代码，所以终止进程不是一个选项