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.