All

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.

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

Flipping through AppLovin APKs, it is easy to find labels and strings that appear to indicate nonconsensual installations. Examples are below.

These labels must be interpreted with care. Ultimately these are labels, not directly indicating actual application functionality. Anyone could name a function FlyToMoon(), but that doesn’t mean he has a rocket or a launchpad.

Furthermore, there could be proper reasons for certain silent installs. Consider the out-of-box experience, when it is routine for manufacturers and carriers to place apps on a user’s device. Consider installations in which user consent is obtained in some earlier part of the process.

Overall, I consider the execution path a more reliable method of determining what AppLovin’s code does. On the other hand, the execution path is complicated—requiring parsing thousands of lines of code to follow the flow, and requiring substantial technical skills to understand the code. In contrast, reviewing strings can be as easy as Edit-Find and dictionary meaning.

Labels and strings in Java code

AppLovin’s code includes various labels that indicate or reference nonconsensual installations. A representative example: com.applovin.array.apphub.tmobile includes a class called TmobileSilentInstallManager. The literal meaning of a “silent install” is one without user consent.

Elsewhere in AppLovin code, there are hundreds of references to “Install”, “Installer”, “installing”, “startInstall”, and the like, including more precise labels such as “andr_app_installing_start”, “an.ui.ntfn.installing_progress.enabled”, and “package_installing_successfully_finished_notification_id”. AppLovin logging also includes status messages like “Failed to start install”, “Failed to start installing”. These labels and strings leave no doubt that AppLovin can install apps—but they do not prove that installations are silent, automatic, or nonconsensual. Other labels, like “DirectInstallOrDownload”, indicate a nonstandard installation (not via Google Play) and suggest the install has few steps (calling into question what disclosure is provided and what consent obtained), but again are less than complete proof.

Labels in JavaScript code

The AppHub APK embeds a resource file, index-BFfWBgBF.js, which contains labels indicating non-consensual “auto” installations. The file merits close examination (see my execution path analysis), but even its labels reveal its purpose. For example:

e.IsAutoInstallEnabled="ui.dd.mp.installation_countdown"
e.AutoInstallDelayMs="ui.dd.mp.install_countdown_ms"
const wt = {
...
autoInstallDelayMs: 5e3,
isAutoInstallEnabled: !0,
...

shouldStartAutoInstall
SetInstallationOnDismissEnabled
isAutoInstall
AppAutoInstallTimerEnd

Other labels indicate that installation may occur simply when a user closes an ad:

e.IsOneClickInstallOnCloseEnabled
...
const wt = {
...
isOneClickInstallOnCloseEnabled: !0
...
SetInstallationOnDismissEnabled

A JavaScript “Breadcrumb” message logger even records a possible event, “Installation on ‘X’ button click”. Yet clicking an X is ordinarily understood as rejection, not consent. Similarly, an error handler describes “Failed to set installation on dismiss enabled”—implying that, when working correctly, the code can indeed install on dismiss. But what user thinks “dismiss[ing]” an ad is basis for an installation? Code snippets below.

catch(a => {
    pe.reportError(new Error("Failed to set installation on dismiss enabled", {

pe.leaveBreadcrumb({
    message: 'Installation on "X" button click', ...

Taken together, these labels describe scenarios where installations proceed without a user being asked to install or without the user agreeing to install.

Possible settings screen entries consistent with automatic installations

The resource file index-BFfWBgBF.js also includes a potential settings screen with the following labels:

zu = "Enable Direct Download",
Gu = "Download apps with a single click", ...
Ra = { EnableDirectDownload: zu,
EnableDirectDownload_Description: Gu, ...

From the resource file alone, it is unclear whether this screen is ever presented to users, and if so, under what conditions or with what default setting. Yet users consistently report unexpected app installations, suggesting that the option may be enabled by default—or hidden in a screen users do not ordinarily open.

My personal experience reinforces doubt about such a screen being shown to users. In spring 2025, I purchased a new T-Mobile phone directly from the carrier. On first boot, the out-of-box setup prominently displayed AppLovin screens urging me to download apps. At no point did I see any option to “Enable Direct Download” or to “Download apps with a single click.”

User complaints confirm that no such screen is shown. In reviewing complaints, I found no screenshots of such a screen being proactively shown. One user noted:

I found an app called Content Manager on my Samsung S24 that I bought through T-Mobile. There was an option there that says “Allow Install of New Apps” and I turned it off, and the ad installs stopped. (Skybreak, April 6, 2024)

This complaint reinforces the problem: a user would have no reason to hunt through a Content Manager settings screen to disable unwanted installs. Nor does failing to disable a buried option constitute consent for arbitrary app installations.

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

A reliable way to understand what software does is to examine its source code and trace the execution path.  This is rarely possible for compiled code, but AppLovin is largely Java, which can be decompiled using tools such as JADX.  I reviewed decompiled source code alongside the full app manifests and relevant resource files embedded within APKs.  Together, these materials reveal both what the apps are permitted to do (via permissions), how execution proceeds from function to function, and, ultimately, what occurs.

Let me remark on three key challenges in interpreting the decompiled code.  First, length.  After decompilation using JADX, the AppHub APK totals a remarkable 626,053 lines of code.  Then there’s more in the AppLovin SDK, in install helpers, in manifests, and in JavaScript.  Of course most of the code is irrelevant to app installs.  In the excerpts linked below, I focus on what I found to be relevant.  But the execution path remains lengthy even after excerpting.

Second, both decompilation and deliberate obfuscation by AppLovin make parts of the code difficult to read.  Decompilation recovers some labels (function names and variable names), but others are lost and must be generated by JADX – yielding labels that are difficult to interpret (such as AbstractC1838d0) and not the labels actually used in AppLovin’s source code.  Meanwhile, AppLovin intentionally obfuscated (minified) its JavaScript—not unexpected, because they have no reason to help anyone read it, but still an impediment to understanding.

Third, Android’s architecture—including coroutine continuation functions for multithreading—adds further complexity.  This code is not the simple a() calls b() calls c() taught in introductory programming classes.

Nonetheless, with knowledge of Java syntax and Android architecture, and with determination and grit, the execution flow is apparent.  I worked on understanding this code on-and-off from February to September 2025, and I now feel I have a good understanding.  My remarks below are my best effort under important constraints, including both the size of the task and AppLovin’s intentional obfuscation.  I cannot guarantee perfection.  See my disclosures.

In the index below, I present code in the sequence in which it operates.  Where a function name is less than self-explanatory, I remark on its purpose.  In the linked pages, I introduce each block of code with a short narrative about key steps, and I use red text to mark the flow from one step to the next.  Occasional comments, marked with the prefix // , are added by me to explain selected areas.

In the AppLovin SDK

trackAndLaunchClick()

startDirectInstallOrDownloadProcess()

showDirectDownloadAppDetailsWithExtra()

AppHub mRemote.transact()

In AppHub wrapper

onTransact()

showDirectDownloadAppDetailsWithExtra() with service method AbstractC1838d0.m3826C(),delegate C2823r(), and Kotlin coroutine continuation with entry point mo410()

BinderC2829u.m4811d() creates intent DirectDownloadActivity

c3429t1.m5750a()

C3394o1 with continuation entry point mo410r()

In DirectDownloadActivity

onCreate()

onAppDetailsCreate()

setupAppDetailsFragment() and coroutine continuation class C3359j1 with continuation entry point mo410r()

DirectDownloadMainFragment C3374l2 and onViewCreated mo1147B() with coroutines C3339g2, C3332f2, and C3325e2, plus coroutine continuation orchestrator M5734P and URL builder m5748L

AbstractC3404p4.mo1147B() with C3334f4 and C3320d4 (WebView loader)

DirectDownloadMainFragment continuation entry point mo410r()

WebView loads JavaScript resources that implement auto-install

C4785e (WebView loader)

Variable wt (default configuration)

Wt() checks IsAutoInstall and installs if set

C() checks isOneClickInstallOnCloseEnabled and installs if set

Wt() checks if AutoInstallDelayMs is set, and if so uses av() to hook a timer’s onExpire event to the install function

c() install function

Ge.installApp() hooks /install-app endpoint

makeNativeXhrRequest()

makeHttpRequest() wraps browser-native XMLHttpRequest

Java URL interceptor prepares to run T-mobile InstallerHelper

DirectDownloadMainFragment C3374l2 creates C3298a3 which creates C5252f (WebView interception manager)

C5252f registers endpoint handler C5461u for /install-app

C5461u activates DirectDownloadPackageManager C2495r1 with coroutine resume function m4446F()

C0033f0 creates C0023a0 (installation executor) and coroutine resume function m431o() and continuation entry point mo410r()

mo410r() runs T-Mobile InstallerHelper startInstall()

In T-Mobile InstallerHelper

m14262a message dispatcher

sendEmptyMesage()

startInstall()

prepareInstall()

performInstallBundle()

m14247a (InstallParams method)

PackageInstaller (Android Package Manager from core Android)

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

My work follows six prior critiques in which others questioned AppLovin practices, both as to app installations and beyond.  I organize those critiques here, in chronological order, to assist those who wish to reread them. I emphasize those reports and sections that, like my post today, consider nonconsensual installations.

Culper 1 – pages 7-25 about installs

Fuzzy Panda – Part II discusses Direct Downloads and other methods of gaming installs (citing my work), among other subjects

Culper 2 – broader topics: misrepresentation of Chinese ties, national security concerns

Muddy Waters – focused on tracking and persistent identifiers

Mike Shields – on installs (citing me)

Olivia Solon (Bloomberg) – reporting an SEC probe of AppLovin’s data-collection practices

Compared with prior reports, I provide a more detailed technical analysis. For example Solon’s report of SEC inquiry does not provide any source code, screenshots, packet logs, or other direct evidence of data collection violations. I also provide greater proof relative to prior reports of nonconsensual installations. For example, the prior reports about nonconsensual installs present snippets of code, whereas I trace the full execution chain from ad delivery all the way to installation. Similarly, prior reports offer a few complaints about nonconsensual installations, but I offer hundreds, plus I explore patterns of complaints across devices and situations, and I cross-check complaints against details in decompiled AppLovin code.