Permissions make it possible for AppLovin to do what the allegation claims

This post is part of AppLovin Nonconsensual Installs. See important disclosures.

Ordinarily, if app A wants to install app B, it must send the user to Google Play—where installation only proceeds if the user taps the prominent green Install button. At Google Play, accidental installs are rare, and nonconsensual installs are effectively unheard of.

If installations occur outside Google Play, the first question is technical feasibility. It is not enough that source code appears to support this behavior (as shown in my execution path analysis); the Android security model must also allow it. A close review of security settings in the relevant manifests shows that such installs are indeed possible—and in fact, the unusual settings documented on this page are difficult to explain any other way.

Save The Girl manifest indicates authorization to invoke AppHub

The Android game “Save The Girl” includes the following entry in its manifest:

<intent>
<action android:name="com.applovin.am.intent.action.APPHUB_SERVICE"/>
</intent>

Ordinarily, apps do not need this line to receive ads from AppLovin.  So why does this game—and dozens of others—request permission to invoke AppHub?  What legitimate purpose does this serve?

AppHub manifest indicates authorization to invoke T-Mobile packages with elevated permissions

The AppHub manifest includes permission to interact with a T-mobile installer helper:

<uses-permission android:name="com.tmobile.dm.cm.permission.UPDATES_INSTALL"/>
<uses-permission android:name="com.tmobile.dm.cm.permission.UPDATES_LOCAL_INSTALL"/>
<uses-permission android:name="com.sprint.permission.INSTALL_UPDATES"/>
<uses-permission android:name="com.sprint.permission.INSTALL_LOCAL_UPDATES"/>
<queries>
<package android:name="com.tmobile.pr.adapt"/>
<package android:name="com.sprint.ce.updater"/>
<package android:name="com.tmobile.dm.cm"/>
</queries>

One plausible explanation is that AppHub uses a T-Mobile install helper to complete out-of-box (OOBE) installations.  But that only raises a further question: Why would third-party games need to connect to the same privileged middleware?

Com.tmobile.dm.cm has elevated permissions including installing other apps

The com.tmobile.dm.cm package has the critical permission necessary to install other apps.

<uses-permission android:name="android.permission.INSTALL_PACKAGES"/>
<uses-permission android:name="com.android.permission.INSTALL_EXISTING_PACKAGES"/> ...

Reviewing code, I found that this is the package that ultimately installs promoted apps.  The combination of that code (which passes execution to the installer) and this permission (which grants the package the ability to do so) reinforce my conclusion.

Some AppLovin APKs seek permission to install apps themselves, without a manufacturer/carrier install helper

In some cases, AppHub does not rely on a manufacturer or carrier install helper.  Certain AppLovin APKs instead request install permissions directly. For example, the Adapt v3.40.2 manifest includes:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="3400299"
android:versionName="3.40.2"
android:compileSdkVersion="34"
android:compileSdkVersionCodename="14"
package="com.tmobile.pr.adapt"
platformBuildVersionCode="34"
platformBuildVersionName="14">
<uses-sdk
android:minSdkVersion="23"
android:targetSdkVersion="34"/>
<uses-permission android:name="android.permission.INSTALL_PACKAGES"/>...

AppLovin’s public statements are consistent with AppLovin sometimes receiving this permission. From AppLovin’s Array Terms:

To provide the Array Services to you, we may need access to the “INSTALL_PACKAGES” and “QUERY_ALL_PACKAGES” Android device permissions. We receive these permissions through your carrier or mobile phone original equipment manufacturer, and we use them to provide you with the Array Services, including presenting Direct Download screen to you and facilitating the on-device installation of mobile applications at your election (where Array acts as the technical installer, not your carrier).

This paragraph — including phone manufacturer or carrier preinstalling AppLovin code and presetting these permissions — matches what I observed. Of course the “at your election” claim is contrary to my analysis of the execution path, and my tabulation of user complaints, indicating nonconsensual installations.