When Google re-launched the Pixel 5 in October, we were excited to get its hands on its new apps. (The phone itself is also pretty cool.) With the introduction of Pixel 5 came new versions of the Google Camera and Google Recorder apps that we shared with the community. However, when many users of older Pixel devices tried to sideload the updates, they encountered an error (shown above). Oddly enough, not everyone had trouble installing the updates. Some were able to install it well, while others had to reset the factory settings so that they could install the new versions. Because of the seemingly random nature of this issue, many have spray-painted it a mistake. We are now fairly confident that this issue is not the result of an error, but rather Google’s use of a new API in Android 11 to block sideloading updates.
If you try to load Google Camera 8.0 or later or Google Recorder 2.0 or later on a Pixel device running Android 11, you will see an error message stating that the authentication could not succeed. Even if you try to sideload the APK with a shell command, you will not get a more specific reason for the installation failure. The installation return code you receive is “INSTALL_FAILED_VERIFICATION_FAILURE”, which unfortunately does not tell you why the authentication failed. By examining the logcat, we can learn exactly why the verification failed:
AppIntegrityManagerServiceImpl: Integrity check of com.google.android.GoogleCamera result: DENY due to [Rule: (PACKAGE_NAME EQ com.google.android.GoogleCamera) AND (VERSION_CODE GTE 32045130) AND (APP_CERTIFICATE EQ F0FD6C5B410F25CB25C3B53346C8972FAE30F8EE7411DF910480AD6B2D60DB83) AND NOT (INSTALLER_NAME EQ com.android.vending), DENY]According to this message, an integrity check of the Google Camera installation failed because the “INSTALLER_NAME” does not match “com.android.vending”, the package name for the Google Play Store. (I tried to install Google Camera 8.0 using the APKMirror Installer app, for what it’s worth.) This post was added by AppIntegrityManagerServiceImpl, which is part of Android’s new “App Integrity” feature. According to the code in AOSP, App Integrity is designed to provide an additional layer of checks on top of the package manager’s existing APK signature verification. The App Integrity API apparently uses a set of rules to decide whether the installation is allowed or not. Rules are provided by a system app – which according to our Google Play services – and are stored in a file.
Furthermore, App Integrity also mentions another class called SourceStampVerifier if a “source stamp” is embedded in the Manifest’s metadata. For example, here’s the ‘source stamp’ of the Google Camera app’s Manifesto:
From what we can see, the source stamp is used to verify the signature of the package installer. For example, you can not mislead AppIntegrity into allowing the installation, even if you cheated on the Play Store as the installer.
In addition, we were unable to detect exactly how Google uses AppIntegrity and related APIs to block updates from the Google Camera and Google Recorder apps. A quick examination of Google Play Services APK reveals that it uses these APIs, but the code is obscure to really make sense of everything. We even found the directory where the integrity rules are stored – / data / system / integrity_rules – but it’s of little use because it contains only serial data. We also did not find a way to disable integrity verification (it does not seem as easy as just changing a setting), but we believe that the reason the factory setting works for some is that Google Play Services does not a chance to initialize its rule set to block the installation. The logcat message and the launch of these new APIs in Android 11 strongly suggest that it is all designed and not a bug.
Google has not publicly commented on their use of these APIs (nor do we expect them to), and they did not respond when reached for comment. However, we have some theories as to why they block page load updates. First, they can protect people from the wrong version of the app for their device. Google delivers specific versions of its applications to specific Pixel devices. For example, several versions of the App Personalization Services app can be found online. Although it can all be installed on Pixel devices, at some point it was possible to lose the Live Captions feature on the Pixel 4 by downloading a version built for an older Pixel device. Another reason could be to ‘improve the unauthorized distribution traceability of programs’, as explained by Google in the SourceStampVerifier class.
So far, only some of the Google apps that use the app bundle format (like Google Camera and Google Recorder) are blocking non-Play Store installations, but we do not know if the company will extend this behavior to its other apps. AAB format. We also looked at whether switching to app bundles necessitates the implementation of App Integrity, but we found that Google already has a solution to deal with when users try to install an app that does not have all the required parts. Either way, we do not think Google intends to block all its loading of its apps, although these tools certainly allow it.
Thanks to developers vvb2060, aviraxp and Quinny899 for their help in this article, and tdirect PNF software to give us a license to use JEB Decompiler, a reverse engineering tool for professional quality professional applications.