When Google launched the Pixel 5 back in October, we were excited to get the new apps. (The phone itself is also pretty cool.) With the launch of the Pixel 5 came new versions of Google Camera and the Google Recorder apps that we shared with the community. However, when many users of older Pixel devices tried to sideload the updates, they were encountered an error (shown above). Strangely, not everyone had trouble installing the updates. Some managed to install them just fine, while others had to reset the factory just so they could install the new versions. Due to the seemingly random nature of this problem, many people called it a mistake. We’m pretty sure this issue is not caused by an error, but rather Google̵
If you try to sideload 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 saying that the confirmation could not be successful. Even if you try to load the APK on the page using a shell command, you will not get a more specific reason for the installation error. The installation code you receive is “INSTALL_FAILED_VERIFICATION_FAILURE”, which unfortunately does not tell you why the verification failed. By examining the log cat, we can learn exactly why the confirmation fails:
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 “INSTALLER_NAME” did 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 message was added to the system log 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 extra check layer on top of the package manager’s existing APK signature verification. The App Integrity API appears to use a set of rules to determine whether the installation should be allowed or denied. Rules are provided by a system app – which we believe are Google Play services – and stored in a file.
In addition, App Integrity also calls another class called SourceStampVerifier if a “source stamp” is embedded in the manifest’s metadata. For example, here’s what we think is the “source stamp” from the Google Camera App Manifesto:
From what we can tell, the source stamp is used to verify the signature of the package installer. So for example, you can not trick AppIntegrity to allow installation, even if you forged the Play Store as the installer.
Beyond that, we were unable to find out exactly how Google uses AppIntegrity and related APIs to block side-loading updates to Google Camera and the Google Recorder apps. A quick examination of the Google Play Services APK reveals that it uses these APIs, but the code is too veiled to really make sense of everything. We even found the directory where the integrity rules are stored – / data / system / integrity rules – but it was of little use because it only contains serial data. We also have not found a way to disable privacy verification (it does not seem to be as simple as just changing a setting), although we believe that the reason factory reset works for some is that Google Play Services does not get a chance to initialize the rule set to block the installation. The logcat message and the introduction of these new APIs in Android 11 strongly suggest that this is designed and not a bug.
Google has not commented on public use of these APIs (nor do we expect them to do so), and they did not respond when reached for comment. However, we have some theories as to why they block side-loaded updates. First, they can protect people from installing the wrong version of the app for their device. Google delivers specific versions of its apps to specific Pixel devices. For example, you can find several versions of the Personalization Services app online. Although they can all be installed on Pixel devices, at one point it was possible to lose the Live Captions feature on Pixel 4 by downloading a version built for an older Pixel device. Another reason could be to “improve the traceability of apps with respect to unauthorized distribution”, as explained by Google in the SourceStampVerifier class.
So far, only a few of Google’s apps that use the app bundle format (like Google Camera and Google Recorder) block non-Play Store installations, but we do not know if the company will extend this behavior to its other apps when everyone switches to AAB. format. We also considered whether the switch to appbunter necessitated 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 necessary shares. Whatever the case, we do not believe Google intends to block all page loading of its apps, although these tools certainly allow them to do so.
Thanks to the developers vvb2060, aviraxp and Quinny899 for their help in this article, and tcontact PNF Software to provide us with a license to use JEB Decompiler, a professional reverse engineer tool for Android applications.