See important disclosures including my related financial interests.
Mobile adtech juggernaut AppLovin recently faced multiple allegations of misconduct. Allegations run the gamut—privacy, ad targeting, even national security and ties to China. I was among the researchers consulted by skeptical investors this spring, and I was quoted in one of their reports, explaining my concerns about AppLovin installing other games without user consent.
Today I argue that AppLovin places apps on users’ Android devices without their consent. As a maxim says, extraordinary claims require extraordinary evidence, but I embrace that high bar. First, I study AppLovin source code and find that it installs other apps without users being asked to consent. I use a decompiler to access Java source for AppLovin’s SDK and middleware, plus partners’ install helpers—following the execution path from an ad tap (just clicking an ad, potentially a misclick aiming for a tiny X button, with no Install button even visible on screen) through to an installation. AppLovin used an obfuscator to conceal most function names and variable names, so the Java code is no easy read. But with patience, suitable devs can follow the logic. Usefully, some key steps are in JavaScript—again obfuscated (minified), but readable thanks to a pretty-printer. I except the relevant parts and explain line by line.
Second, I gather 208 complaints that all say basically the same thing: users are receiving apps in situations where (at a minimum) they don’t think they agreed. The details of these complaints match what the code indicates: Install helpers (including from Samsung and T-Mobile) perform installs at AppLovin’s direction, causing most users to blame the install helpers (despite their generic names like Content Manager, Device Manager, and AppSelector). Meanwhile, most complaints report no notification or request for approval prior to install, but others say they got a screen which installed even when they pressed X to decline, and a few report a countdown timer followed by automatic installation. Beyond prose complaints, a handful of complaints include screenshots, and one has a video. Wording from the screenshots and video match strings in the code, and users’ reports of auto-installs, X’s, and countdowns similarly match three forks in AppLovin’s code. Overall, users are furious, finding these installations contrary to both Android security rules and widely-held expectations.
AppLovin CEO Adam Foroughi posted in February 2025 that “Every download results from an explicit user choice—whether via the App Store or our Direct Download experience.” AppLovin Array Privacy Policy similarly claims that AppLovin “facilitates the on-device installation of mobile apps that you choose to download.” But did users truly make an “explicit … choice” and “choose to download” these apps? Complaints indicate that users don’t think they chose to install. And however AppLovin defends its five-second countdowns, a user’s failure to reject a countdown certainly is not an “explicit” choice to install. Nor is “InstallOnClose” (a quote from AppLovin’s JavaScript) consistent with widely-held expectations that “X” means no. Perhaps Foroughi intends to argue that a user “consents” to install any time the user taps an ad, but even that is a tall order. One, AppLovin’s X’s are unusually tiny, so mis-taps are especially likely. Two, users expect an actual Install button (not to mention appropriate contract formalities) before an installation occurs; users know that on Android, an arbitrary tap cannot ordinarily install an app. Ultimately, “explicit user choice” is a high bar, and user complaints show AppLovin is nowhere close.
The role of manufacturers and carriers
Why would Samsung, T-Mobile, and others grant AppLovin the ability to install apps? Two possibilities:
- Financial incentives. AppLovin pays manufacturers and carriers for the permissions it seeks. These elevated permissions may be unusual, and the resulting installations are predictably annoying and unwanted for users. But at the right price, some partners may agree.
- Scope creep. Public statements indicate manufacturers and carriers authorized AppLovin to perform “out-of-box experience” (OOBE) installs—recommending and installing apps during initial device setup. Install helpers were designed to support this narrow context. But my review of install helper code shows no checks to limit installations to the OOBE window. A simple safeguard—such as rejecting installs more than two hours after first boot—would prevent ongoing installs. By omitting such safeguards, manufacturers and carriers effectively granted AppLovin open-ended install rights, whether or not that was their intent.
So far manufacturers and carriers haven’t said whether they approve what AppLovin is doing. Journalist Mike Shields asked Samsung, but they declined to comment. Perhaps my article will prompt them to take another look.
Sources of evidence
Five overlapping categories of evidence offer a mutually-reinforcing picture of nonconsensual installations:
- Execution path. Source code extracted from test devices shows how an ad tap leads all the way to an installation, without a user pressing “Install” or similar at a consent screen.
- Labels and strings. Code snippets reference installation without a user request or consent.
- Permissions. App manifests include nonstandard entries consistent with apps asking AppLovin middleware to install other apps.
- User complaints. 208 distinct complaints describe apps being installed while playing games or viewing ads. A few complaints include relevant screenshots and even video of nonconsensual installations. Complaints, screenshots, and videos match unusual details visible in the code.
- AppLovin statements. Public statements use euphemistic or contradictory language about user “choice” and “direct downloads,” suggesting attempts to obscure nonconsensual installs.
I also examine the legal and financial risks associated with nonconsensual installations.