When Google launched Pixel 5 in October, we were eager to get their hands on their new applications. (The phone itself is also very cool.) With the release of Pixel 5, new versions of the Google Camera and Google Recorder apps that we share with the community came. However, when many users of older Pixel devices tried to sideload the updates, they encountered an error (shown above). Strangely, not everyone had problems installing updates. Some managed to install them perfectly, while others had to reset the factory defaults just to be able to install the new versions. Because of the seemingly random nature of this problem, many have attributed it to a bug. We are quite confident now that this problem is not caused by a bug, but by Google’s use of a new API on Android 11 to block sideload updates.
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 that the scan was unsuccessful. Even if you try to sideload the APK using a shell command, you will not get a more specific reason for the installation failure. The installation return code that you will receive is “INSTALL_FAILED_VERIFICATION_FAILURE“, which unfortunately does not say why the verification was not successful. By examining the logcat, we can learn exactly why the verification 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, a Google Camera installation integrity check failed because “INSTALLER_NAME” did not match “com.android.vending”, the package name for the Google Play Store. (I was trying 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 AOSP code, the application’s integrity is designed to provide an additional layer of verification when verifying the signature of the existing package manager APK. The App Integrity API appears to use a set of rules to decide whether or not to allow installation. The rules are provided by a system application – which we believe to be Google Play Services – and are stored in a file.
In addition, App Integrity also calls another class called SourceStampVerifier if a “source stamp” is incorporated into the manifest’s metadata. For example, here’s what we believe to be the “seal of origin” of the Google Camera App Manifest:
As far as we can tell, the seal of origin is used to verify the signature of the package installer. So, for example, you cannot trick AppIntegrity to allow installation, even if you fake the Play Store as the installer.
In addition, it was not possible to find out exactly how Google is using AppIntegrity and related APIs to block sideload updates for the Google Camera and Google Recorder apps. A quick scan of the Google Play Services APK reveals that it is using these APIs, but the code is too obfuscated 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 contains only serialized data. We also haven’t found a way to disable the integrity check (it doesn’t seem to be as easy as just changing a setting), although we believe that the reason factory reset works for some is that Google Play Services doesn’t get a chance to initialize its suite of rules to block the installation. The logcat message and the introduction of these new APIs on Android 11 strongly suggest that this is all intentional and not a bug.
Google did not publicly comment on the use of these APIs (nor do we expect them to do so) and did not respond when contacted for comment. However, we do have some theories as to why they are blocking sideloaded updates. First, they may be protecting people from installing the wrong version of the app on their devices. Google offers specific versions of its applications for specific Pixel devices. For example, several versions of the Device Personalization Services application can be found online. Even though they are all installable on Pixel devices, it was possible at one point miss 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 applications in relation to unauthorized distribution”, as explained by Google in the SourceStampVerifier class.
So far, only some of the Google apps that use the app package format (like Google Camera and Google Recorder) are blocking non-Play Store installations, but we don’t know if the company will extend this behavior to its other apps after all of them switch to the AAB format. We also considered whether the move to app packages required implementing Application Integrity, but we found that Google already has a solution to deal with when users try to install an app that doesn’t have all the necessary divisions. Whatever the case, we don’t think Google intends to block all sideloading of its applications, although these tools certainly allow them to do so.
Thanks to the developers vvb2060, aviraxp and Quinny899 for their help in this article andthanks PNF Software for providing us with a license to use JEB Decompiler, a professional-grade reverse engineering tool for Android apps.