AppLovin Execution Path

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)

Prior Critiques of AppLovin

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.

AppLovin – My disclosures

This post is part of AppLovin Nonconsensual Installs.

In January 2025, I was engaged by an investment firm that was skeptical of AppLovin.  They asked me to investigate a range of concerns, including installation practices.  That engagement continued until June 2025.  My agreement with that firm disallows me from revealing its name, but allows me to share all information I figured out from public sources.  Since then, I have had no paid relationship with that firm—or any other investment firm—regarding AppLovin.

As part of my research for this post, I spoke with a range of experts concerned about AppLovin’s practices, including security researchers, journalists, industry analysts, attorneys, and competing adtech firms.  No money changed hands in any of these discussions.  As my post indicates, my primary methodology was forensic: I reviewed AppLovin source code and tested the product first-hand, plus examined user complaints.

From my extended analysis, I became convinced that AppLovin engaged in serious misconduct.  The accompanying report details the methods and evidence supporting this conclusion.

Consistent with my practice whenever contractually permitted, I am releasing this report publicly for anyone to use.  To the best of my knowledge, the information herein is accurate and based on sources and methods I consider reliable.  Nonetheless, all content is provided strictly “as is,” without any warranty—express or implied.  I make no representations as to the accuracy, timeliness, completeness, or likely results of using this information.  My research necessarily contains inferences, estimates, and opinions which may prove inaccurate and are subject to risks and uncertainties beyond my control.

This report is not investment advice.  I make no representation or warranty regarding its completeness or the future performance of AppLovin’s securities.  Readers must conduct their own research and due diligence, including consulting with financial advisors, before making investment decisions.

I hold a financial interest in which I profit if AppLovin’s stock price declines.  I opened this financial interest after completing research, based on my serious concern at what I found.  I may change, reduce, or close this position at any time, without notice.  I do not undertake to update this report to reflect changes in my views or positions.  However, if I conclude that I am mistaken about AppLovin’s technology, I will correct the record publicly.

***

Update, October 16, 2025: I no longer have a financial interest relating to AppLovin.

Cookie-Stuffing and Low-Intention Traffic

In an article originally posted to VPT’s blog, I explain how web pages open popups and new tabs to claim commission on sales a merchant would have made on its own — and how VPT automation can catch, process, and even tabulate these violations. Details: Cookie-Stuffing and Low-Intention Traffic.

***

Updated text adapted from the archive:

Many affiliate marketers have heard of “cookie-stuffing” – a broad term that can cover almost any scenario in which affiliate tracking links are invoked, and cookies are placed on a user’s computer, without the user so requesting. Historically, this was often done via invisible windows such as 0x0 IFRAMEs and even IMG tags. But with changing browser rules about third-party cookies, these days I more often see cookie-stuffing via low-intention traffic — sites that invoke affiliate links even though a user did nothing to invoke links or request those destinations.

For untargeted low-intention traffic, a merchant is more vulnerable if it sells something almost everyone needs. The larger an advertiser’s advertising spend and customer footprint, the more vulnerable it is to this type of abuse, because a broader reach creates correspondingly more preexisting transactions that a rogue affiliate would hope to get credit for. Some people call this affiliate tactic “spray and pray”: Claim to have referred a large number of users to a given site, in hopes that some users respond to the ad or, in any event, buy from that site within the return-days period the advertiser set. When Uber was in hyper-growth mode, they spent heavily on marketing to attract new passengers and driver signups – and I observed Uber’s marketing partners invoking Uber links without users requesting them. These days, Uber is much more careful. But new advertisers with broad advertising and customer reach are similarly vulnerable to this tactic.

Automation can catch low-intention traffic by scouring the web sites known to originate this traffic — often sites for filesharing, torrents, piracy, and pornography. Automation browses these sites just as normal users do. The broad strategy is to receive low-intention traffic, and chronicle what occurs.

In recent testing, VPT crawlers repeatedly observed video piracy sites promoting Aliexpress (discount merchandise of all types) and Bitpanda (Bitcoin trading and investment). Here’s a representative example from a recent observation: Automation requested Qatarstreams.me, a site that distributes live sports streaming without authorization from rights-holders. While automation browsed, Qatarstreams and its partner ad networks (using highly encoded JavaScript from madurird.com and a redirect through paizeestawumee.net) opened a new tab that loaded Aliexpress (inbound link /e/_ooXP3cN?af=8024617&dp=941157966432965158). Strings and other evidence in the decoded JavaScript suggest the ad network responsible for this placement is Popads.net.

About 30 seconds later, as automation continued browsing, Qatarstreams and its partner ad network Youradexchange opened a new tab that redirected to an Impact affiliate link to Bitpanda (inbound link /c/4484296/1755018/15871).

As usual, automation can retain full-motion screen-capture video as well as a packet log showing all HTML, JavaScript, and other network communications causing these new tabs. Because a video captures many frames per second, it’s usually even possible to examine steps midway through a redirect, as in the second and third screenshots above (showing steps between Qatarstreams and the Aliexpress landing page).

Astute readers will notice that the Bitpanda landing page is a /de/ page written in German. Indeed, this test occurred from a computer in Germany. VPT uses equipment around the world in order to find problems that geotarget or geofence specific areas.

It is unlikely that Aliexpress and Bitpanda intended to advertise on a site offering unlicensed videos, nor to advertise in pop-up ads or auto-opening new tabs. They probably just wanted a broad reach and didn’t do much to supervise their affiliates and other traffic sources. Alas, unsupervised traffic-buying too often leads to traffic from piracy sites, popups, and auto-opening new tabs, and similar unwanted traffic.

Anyone with a site of broad interest, buying broadly-targeted traffic, is potentially vulnerable. Beyond marketplaces and financial services, low-intent traffic brokers also often target brands in the travel sector.

How Adware Manipulates Attribution to Monetize a Merchant’s Own Traffic

In an article originally posted to VPT’s blog, I explain how adware claims commission on sales a merchant would have made on its own — and how automation can catch, process, and even tabulate these violations.  Details: How Adware Manipulates Attribution to Monetize a Merchant’s Own Traffic.

***

Updated text adapted from the archive:

When adware programs and their partners want to drain advertisers’ budgets, they have an oddly well-established path to do so: Wait for the user to browse an advertiser’s site, then invoke an advertiser’s own affiliate link. Users will typically not notice anything amiss; at most they get a second window showing the advertiser’s web site, but that is easily ignored as a small glitch. Meanwhile, the advertiser will see genuine purchases and quite logically assume the affiliate must have added value – must have done something to get the user to buy. So the advertiser will pay a commission according to its standard fee schedule. These commissions can be sizable – often, 10% or more of the user’s purchase price. Meanwhile all the affiliate had to do was get adware (or a browser plugin) onto a user’s computer, or buy clicks from some other adware already installed.

Automation can catch this problem. When I think affiliate, I often jump straight to Amazon – the advertiser that took affiliate marketing mainstream when countless publisher sites began promoting Amazon for books, later music, and now almost anything. So I searched automation records for adware targeting Amazon. A representative example is below.  Quoting verbatim from the automated report summarizing what our automation did and what it found:

We tested on a computer with the adware 3D Earth Maps. When the user navigated to https://www.amazon.com/, the adware invoked an affiliate link with parameters as shown below.
…
tag=namespacebran37-20

The report provides two screenshots of what was observed.

  1. First automation loaded Amazon.com, just as a user would. This is shown in the left screenshot below.
  2. 83 seconds later, the adware opened a second tab that loaded an affiliate link for Amazon. This second request sets the affiliate’s cookie, positioning the affiliate to claim commissions on subsequent sales. See the right screenshot below, showing both tabs visible.

Automation also made a video showing exactly what occurred. But if there’s any doubt, the packet log shows all communications between the browser, the adware, and Amazon’s site. (Automation can even decode HTTPS encryption.) Sure enough the adware told its controlling server, v2i8b.com (yellow highlighting below), that the user was at amazon.com (blue), to which the server instructed opening the new tab loading Amazon with the specified affiliate ID (green). Here’s the relevant HTTP transaction from the packet log:

GET https://r.v2i8b.com/api/v1/bid/redirect?campaign_id=...&url=https%3A%2F%2Fwww.amazon.com&source=...&cid=...&ec=...&ecr=...&t=24570&vc=... HTTP/1.1
Host: r.v2i8b.com
Connection: keep-alive
sec-ch-ua: "Not)A;Brand";v="8", "Chromium";v="138", "Google Chrome";v="138"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9

HTTP/1.1 302 Found
Date: Wed, 16 Jul 2025 19:18:23 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 203
Connection: keep-alive
cache-control: no-store, no-cache, must-revalidate, proxy-revalidate
expires: 0
location: https://www.amazon.com?asc_campaign=f34153f85476486748b59b061a7daf98&asc_source=01GEF8XYFYR5K9W7K9EJD4XTW2&tag=namespacebran37-20
pragma: no-cache
referrer-policy: no-referrer
server: Cowboy
surrogate-control: no-store
vary: accept-encoding
x-request-id: 01K0AARX0E20SA8N6YYRWZSTJS
<html><body>You are being <a href="https://www.amazon.com?asc_campaign=f34153f85476486748b59b061a7daf98&amp;asc_source=01GEF8XYFYR5K9W7K9EJD4XTW2&amp;tag=namespacebran37-20">redirected</a>.</body></html>

Nothing in the packet log reveals how much Amazon paid this affiliate. I think highly of Amazon’s sophistication, so I expect that Amazon catches many such affiliates before they paid any of the wrongfully-claimed commissions. Furthermore, Amazon’s Associates program policies are well-written and appropriately prohibit this type of abuse. But in just six days of testing, automation saw this affiliate’s links appear 37 times. The affiliate probably had to pay the adware for each (fake) click, suggesting that the affiliate expects to get paid.

Virgin Atlantic cancelling ticketed and confirmed award travel

I represented Chaim Zeev Rozen in a portion of his formal DOT complaint against Virgin Atlantic.  Mr. Rozen had transferred points from a credit card to Virgin’s frequent flyer program in order to redeem travel for relatives who shared his last name.  Inexplicably, Virgin cancelled the tickets — without telling him or the passengers.

I filed a Reply on Mr. Rozen’s behalf.  I pointed out that, contrary to Virgin’s repeated claim and even its Answer, nothing about his conduct was “fraudulent.” I criticized Virgin’s “fraud detection tools” which supposedly “flagged the booking”. I pointed out that Virgin’s Answer was oddly silent on whether any human even attempted to check whether those tools were correct.  I argued that Virgin did not act reasonably in the penalty it imposed and its handling of Mr. Rozen’s complaint and correspondence alleging error. I identified a DOT regulation and Virgin contract provision that were implicated.

The parties subsequently filed a Notice of Withdrawal of Complaint and Joint Motion to Dismiss, indicating that they reached an amicable resolution of the matter.  A footnote in that filing explains specific improvements Virgin made: new tools to better identify actual fraud, a new process for customer complaints and appeals, and new communications to passengers indicating that bookings have been canceled.  Kudos to Mr. Rozen for his role in bringing about these benefits for the traveling public.

Google Discovery Violations in In re Google Digital Advertising Antitrust Litigation

This post is part of Revisiting Litigation Alleging Google Discovery Violations.

In re: Google Digital Advertising Antitrust Litigation.  1:21-md-03010-PKC. (S.D.NY.)

MDL docket originated August 12, 2021.  First filing as to spoliation May 30, 2025.

May 30, 2025 letter presents MDL Plaintiffs’ request to file motions seeking an adverse inference against Google based on its spoliation — grounded in its scheme to encourage employees to use Google Chat set to automatically delete messages for employees subject to litigation hold; its failure to ensure that employees complied with litigation holds; and its policy to mislabel sensitive information as “privileged and confidential” to attempt to avoid discovery.

Explains the evidence of Google’s intent to spoliate evidence, including employees discussing what information they should discuss where and how.

Summarizes critical remarks from other courts that examined Google’s spoliation.  Donato: “a permissive adverse inference instruction is a reasonable and proportionate remedy to Google’s intentional failure to preserve relevant evidence.”  Mehta: “Google’s failure to preserve chat messages might” “warrant” sanctions. Brinkema: “systematic disregard of the evidentiary rules regarding spoliation of evidence … may well be sanctionable.”

Criticizes’s Google’s “systematic abuse of privilege” including by CEO Sundar Pichai personally, noting his admission that he “marked e-mails privileged, not because [he was] seeking legal advice, but just to indicate that they were confidential.”  Notes criticism from other courts: Donato: “frankly astonishing abuse of the attorney-client privilege designation to suppress discovery.”  Mehta: “the court is taken aback by the lengths to which Google goes to avoid creating a paper trail for regulators and litigants.”  Brinkema: “misuse of the attorney-client privilege may well be sanctionable.”  Notes that other courts only withheld an adverse instruction because it would have been superfluous given the liability findings already made.

Public comment on passenger complaint about airline overcharge

Aviation enthusiast Mike Borsetti last month alerted the US Department of Transportation to Qatar Airways adding bogus fees contrary to prior representations: Their online check-in allowed him to select a seat free of charge, but at the airport, both check-in staff and a manager said he’d have to pay to keep that seat.  In response, Qatar tried to trivialize Borsetti’s problem — as if this overcharge doesn’t matter or isn’t important enough for DOT to investigate.  In a public comment filed today, I explained why Borsetti is absolutely right:

First, having already complained to both line staff and a manager at the airport, Borsetti had put Qatar amply on notice of the dispute.  Qatar says he should have complained again, after travel, so they could refund him then.  But two unsuccessful discussions with airline staff is more than enough to justify Borsetti’s decision to bring this matter to a regulator.

Second, by all indications the problem stretches well beyond Borsetti alone, and is bigger than Qatar admits.  Online comments already revealed four other customers with substantially the same problem — online check-in seating dishonored unless customers pay more at the airport.  Of customers affected, only a tiny fraction would both realize they were overcharged and then happen to see the one blog discussing Borsetti’s complaint.  So the problem must be substantial.  And that’s as you’d expect: If there’s a defect in Qatar’s software or process, such as airport systems mistakenly saying a seat fee is due even though online check-in already authorized a seat without charge, that problem would occur for a broad swath of passengers since software ordinarily operates predictably and consistently.

On some level Borsetti’s complaint is unusually simple.  He was overcharged, he wants a refund, and he wants Qatar Airways to stop charging passengers for seats it had said would be free.  Will DOT act to make sure all the other affected passengers — who didn’t realize they were overcharged, or didn’t take the time to complain — are also fully refunded?  And will DOT act to make sure that Qatar Airways finally fixes its systems so this problem doesn’t recur?

Turkish Airlines Mishandled Baggage Reimbursements

Congratulations to Mirel Baumgarten, who in 2020 used my formal DOT complaint template to report Turkish Airlines delivering bags 31 hours late and arbitrarily withholding compensation in violation of US law and international treaty.  DOT today cited Mirel in a Consent Order with Turkish, which had to admit its wrongful acts and pay a total of $1.3m (both for delaying refunds after COVID-19 schedule changes and cancellations, and for arbitrarily limiting mishandled bag reimbursements).

DOT summarizes the violation: Turkish Airlines “arbitrarily limited reimbursement for delayed or lost baggage to a maximum amount of $50 USD payment per day for a maximum of six days regardless of the content consumers submitted in their claims.” But, DOT explains, under the Montreal Convention, an airline may not limit its liability for expenses related to delayed baggage to any amount lower than 1,288 SDRs (currently about $1,670).  See Consent Order page 5.

If you enjoy this sort of thing, Mirel’s complaint shows the kind of nonsense airlines all too often inflict on passengers.  Mirel reported bags delivered 31 hours late (complaint page 12) and provides proof with timestamps, yet Turkish oddly categorized the baggage delay as less than 24 hours (not that that would eliminate or even reduce reimbursement under governing treaty and law).  Mirel was traveling for a wedding, had to buy expensive replacement clothes to attend, and had receipts documenting the expenditure.   (See complaint page 11.) Turkish refused to consider Mirel’s evidence, saying the only relevant factor was “the framework of the rules” which purportedly say the Turkish rep “cannot re-evaluate your case” (page 10).  When Mirel cited the specific treaty that required reimbursement of all reasonable expenses subject to the treaty’s cap, disallowing the limitation Turkish proposed, the Turkish rep remarked that no further discussion was possible, “we do not have phone service”, and the specified amount was “our final offer.”  Most consumers would give up.  Kudos to Mirel for sticking with it, telling the DOT, and thereby causing DOT to include this matter in its broader investigation of Turkish.

The DOT’s $1.3m settlement with Turkish is substantial, but that entire amount goes to the US Treasury.  Not a penny flows to the passengers who received arbitrarily reduced reimbursements from Turkish.  Both DOT and Turkish know the names and contact information of affected passengers.  I’d like to see Turkish affirmatively provide every affected passenger with the full amount shown in receipts previously submitted, plus interest.

Other affected Turkish customers should be emboldened by this consent order to demand their full documented loss, no matter any prior protestation by Turkish that its policies called for paying less. I don’t know if Turkish customer service representatives are trained to honor and pay those claims. If not, Turkish customers could contact the attorneys who represented Turkish in this matter, David Endersbee and Barbara Marrin of KMA Zuckert, who should be in a position to press Turkish staff to pay claims consistent with the consent order.