Google于10月推出Pixel 5时，我们很高兴能够使用其新应用程序。(手机本身也很酷。)Pixel 5的发布带来了新版本的Google Camera和Google Recorder我们与社区共享的应用程序。但是，当许多旧版Pixel设备的用户尝试侧加载更新时，他们遇到了错误(如上所示)。奇怪的是，并非每个人都在安装更新时遇到问题。有些能够很好地安装它们，而其他一些则必须恢复出厂设置，以便可以安装新版本。由于此问题看似随机，许多人将其归咎于错误。现在我们非常有信心，这个问题不是由错误引起的，而是由Google在Android 11中使用新的API来阻止侧载更新。

如果您尝试在运行Android 11的Pixel设备上加载Google Camera 8.0或更高版本或Google Recorder 2.0或更高版本，则会看到一条错误消息，提示验证无法成功。即使您尝试使用shell命令来旁载APK，也无法获得安装失败的更具体原因。您将得到的安装返回码是“ INSTALL_FAILED_VERIFICATION_FAILURE ”，不幸的是，它不会告诉您验证失败的原因。通过检查logcat，我们可以确切了解验证失败的原因：

根据此消息，由于“ INSTALLER_NAME”与Google Play商店的软件包名称“ com.android.vending”不匹配，因此无法对Google Camera安装进行完整性检查。(我正尝试使用APKMirror Installer应用安装Google Camera 8.0，以了解其价值。)此消息已由“ AppIntegrityManagerServiceImpl ”添加到系统日志中，该消息是Android新的“ App Integrity”功能的一部分。根据AOSP中的代码，App Integrity旨在在包管理器现有的APK签名验证的基础上提供附加的检查层。App Integrity API似乎使用了一组规则决定是否允许或拒绝安装。规则由系统应用程序(我们认为是Google Play服务)提供，并存储在文件中。

此外，如果在清单的元数据中嵌入了“源标记” ，则App Integrity还将调用另一个称为SourceStampVerifier的类。例如，以下是我们认为是Google Camera应用的清单中的“源印章”：

据我们所知，源戳用于验证软件包安装程序的签名。因此，例如，即使您将Play商店欺骗为安装程序，也无法欺骗AppIntegrity允​​许安装。

除此之外，我们无法确切地了解Google如何使用AppIntegrity和相关API来阻止侧面加载对Google Camera和Google Recorder应用程序的更新。快速检查一下Google Play服务APK后发现它正在使用这些API，但是代码过于模糊，无法真正理解所有内容。我们甚至找到了存储完整性规则的目录-/ data / system / integrity_rules-但它用处不大，因为它仅包含序列化数据。我们还没有找到禁用完整性验证的方法(这似乎不像更改设置那样简单)，尽管我们认为某些情况下可以进行工厂重置，原因是Google Play服务没有机会初始化其规则集以阻止安装。logcat消息和Android 11中这些新API的引入强烈表明，这完全是设计使然，而不是错误。

Google尚未公开评论其对这些API的使用(我们也不希望它们使用)，并且在收到评论时它们没有回应。但是，我们有一些理论为什么它们阻止侧面加载的更新。首先，他们可以保护人们避免为其设备安装错误版本的应用程序。Google将特定版本的应用程序提供给特定的Pixel设备。例如，可以在线找到多个版本的Device Personalization Services应用程序。即使它们都可以安装在Pixel设备上，也有可能一时失去Live Captions功能在Pixel 4上下载适用于较旧的Pixel设备的版本。正如Google在SourceStampVerifier类中所解释的那样，另一个原因可能是“针对未经授权的分发提高了应用程序的可跟踪性”。

到目前为止，只有少数使用应用捆绑包格式的Google应用(例如Google Camera和Google Recorder)阻止了非Play商店的安装，但我们不知道该公司是否会在所有其他应用上都将这种行为扩展到其他应用切换到AAB格式。我们还考虑了是否需要切换到应用程序捆绑软件来实现App Integrity，但我们发现Google在用户尝试安装未包含所有必需拆分内容的应用程序时已经提供了一种解决方案。不管是什么情况，我们都不认为Google打算阻止其应用程序的所有侧面加载，尽管这些工具当然可以阻止它们这样做。