All

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 mo410(r)

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 mo410(r)

mo410(r) 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.