Click Injection and SDK Spoofing Explained

What are click injection and SDK spoofing?

Click injection is Android ad fraud where an app already on the phone notices that another app is being installed and fires a fake ad click at the last moment, so the fraudster gets credit for an install they did not cause. SDK spoofing skips the device entirely: a fraudster sends fake install and in-app event calls straight to a measurement server, made to look like they came from the app’s SDK. Click spamming (also called click flooding) is the blunt version of click injection, sending huge numbers of fake clicks so that one of them happens to be the last click before an organic install.

All three attack attribution, the step that decides which source gets paid for an install (see What is attribution? and What is an MMP?). For fake clicks and fake leads in any channel, see Ad fraud and bot traffic.

Click spamming and click flooding

Most mobile attribution is last click: the install goes to the source of the last recorded click inside the attribution window. Click spamming exploits that rule with volume: the fraudster reports clicks for users who never saw an ad, for example clicks fired in the background of an app, ad views counted as clicks, or clicks sent from a server with collected device IDs. When some of those users later install the app on their own, the spammed click is the last one on record and the fraudster is paid for an organic install.

Adjust’s help page on its Distribution Modeling filter describes click spam as illegitimate click activity used to take credit for organic installs, in forms that range from views counted as clicks to servers sending artificial clicks. It names two patterns it filters:

• Hyper engagement: repeated clicks sent on a user’s behalf at regular intervals. Adjust removes high-volume click patterns from attribution, and the install goes to the next legitimate click or to organic.
• Distribution outliers: Adjust says over 85% of installs from legitimate traffic happen within the first hour after the ad click. Spammed clicks have no real link to the install, so their click-to-install times spread across the whole window. When most of a source’s conversions arrive 60 minutes or more after the click, Adjust rejects attribution to those clicks.

Two more signs: millions of clicks with a tiny conversion rate, and installs that behave exactly like your organic users, because they are.

Click injection: how it exploits the install broadcast

Click injection is the precise version. Android announces device changes, such as a new app being installed, through system broadcasts. Adjust’s Click Injection filtering page explains the attack: a fraudster’s app listens for those broadcasts and sends an ad click after the install of the target app has started but before the user opens it for the first time. That click is the newest one on record, so it is very hard for an honest source to beat. Adjust says click injection only affects Android, because it depends on these broadcasts. Some vendors call the same pattern install hijacking.

How the Install Referrer API exposes it

The Play Install Referrer library lets an app read, on first launch, the referrer URL plus two timestamps listed in the ReferrerDetails reference: getReferrerClickTimestampSeconds(), when the referrer click happened, and getInstallBeginTimestampSeconds(), when installation began. Google says these details stay available for 90 days.

The logic that follows is simple: a click recorded after the install began cannot have caused the install. Adjust compares each engagement with the install begin time from the Google Play and Huawei referrer APIs and treats engagements delivered after it as likely injection. For installs from other stores, where no referrer API supplies that time, it falls back to the install finish time its SDK records.

What Android itself changed

Android has narrowed what a background app can see. Android’s implicit broadcast exceptions page says that since Android 8.0 (API level 26), apps targeting that level cannot register manifest receivers for implicit broadcasts unless the broadcast is sent specifically to them, and it notes that package broadcasts such as ACTION_PACKAGE_REPLACED are not exempt. Since Android 11 (API level 30), package visibility filtering also hides most other installed apps by default, and the QUERY_ALL_PACKAGES permission is subject to Google Play approval. That makes the classic trick harder, but MMPs still document click injection filters, so rely on the timestamp check. Checked on October 20, 2026.

SDK spoofing: fake installs that never touched a phone

An MMP SDK inside an app reports installs and events to the MMP’s servers. In SDK spoofing, a fraudster studies that traffic, for example by intercepting it on a device they control, then sends the same calls from their own servers with invented device data. The MMP sees a normal-looking install or purchase and credits the fraudster’s source, though no real device or user was involved.

It is the mobile cousin of a forged postback. In server-to-server tracking, anyone who knows the endpoint and the request format can send a call, so a call arriving proves nothing on its own. Encryption does not help here: Adjust’s SDK Signature page says TLS encrypts the traffic but does not stop another party from sending fraudulent install or event data to your app’s endpoint.

Defenses against SDK spoofing

• Signed SDK payloads. Adjust’s SDK Signature signs requests from its SDK, and its servers reject requests that are unsigned or carry an invalid signature. Adjust does not enforce it automatically: you switch on rejection of suspicious installs, and it suggests waiting about two attribution windows after releasing the signed app version (for example 14 days with a 7-day window) so older app versions do not get rejected.
• Know its limits. Adjust says the signature is not an anti-cheating engine and does not stop user-level fraud, such as exploiting bugs in your app. It proves where a request came from, not that a real person made it.
• Device and app attestation for your own server. Google’s Play Integrity API helps you check that requests come from your genuine app, installed by Google Play, on a genuine certified Android device, with verdicts for tampered binaries, emulated environments, and unusually high activity. Google says it works best alongside other signals, not as your only anti-abuse measure.
• Pay on events that are hard to fake. A spoofed purchase that never reached your payment system does not survive your own records.

Device farms, emulators, and bots

These fake the user rather than the attribution.

• Device farms are racks of real phones, run by people or scripts, that install and open apps over and over, often resetting the advertising ID so each pass looks like a new device. GAID and IDFA explains those IDs.
• Emulators run Android in software on a server or PC, which makes thousands of “devices” cheap. The Play Integrity device verdict exists for exactly this.
• Bots are scripts that click and fill forms. Simple ones come from data center addresses; better ones imitate real browsers.

The industry reference is the Media Rating Council’s Invalid Traffic Detection and Filtration Standards Addendum (June 2020). It splits invalid traffic into General Invalid Traffic (GIVT), caught with lists and routine checks such as known data center traffic and declared bots, and Sophisticated Invalid Traffic (SIVT), which needs advanced analysis. Its SIVT examples include emulators, hijacked devices, click farms, and falsified measurement events such as clicks, referrers, and conversions, along with attribution spoofing. Its footnote on click farms excludes disclosed reward programs that do not aim to manipulate measurement, though it says such traffic should be reported separately. That is the line between honest incentivized traffic and fraud.

Mobile ad fraud types at a glance

How detection works

Fraud tools combine three kinds of evidence. None is proof on its own; the MRC addendum describes sophisticated cases as needing multi-point corroboration.

Click-to-install time distribution

Click-to-install time (CTIT) is the gap between the attributed click and the first app open. Honest traffic bunches early: Adjust’s figure is over 85% of legitimate installs within the first hour. Injection piles up in the first few seconds, faster than a person can download and open an app. Spam spreads out flat over days. The MRC addendum asks measurement companies to apply logic to the time between impressions, clicks, and installs, saying short, illogical durations may signal invalid activity.

Impossible timings

Some timings cannot happen: a click after install begin, a level 10 event a minute after the first open, or one device “installing” the same app every few minutes. No honest explanation fits, so these are the easiest rejections to defend.

IP, device, and behavior anomalies

Many installs from one IP range or data center, device models that do not fit the country, the same few devices with fresh ad IDs, and users who never return. The MRC addendum names post-install activity too: non-use or uninstalling may signal invalid activity. App retention benchmarks help you judge what “never returns” means for your category.

What advertisers can do

1. Pay on deeper confirmed events. An install is the cheapest thing to fake. Pay for a registration your backend confirmed, a tutorial completed, or a first purchase, or split the payout across several steps. Multi-event offers covers how to design them, and Pay only for confirmed results explains why it shifts risk off your budget.
2. Turn on your MMP’s fraud tools, including click injection, click spam, and SDK signature checks, and roll out signed SDK versions before you enforce rejection.
3. Do not report rejected installs as conversions. If your MMP rejects an install, make sure no postback fires to the source, and agree in writing before launch that conversions reversed for fraud are not paid.
4. Reconcile with your own data. Compare MMP installs and events with your backend sign-ups and payments by source and sub ID. Spoofed events are missing on your side.
5. Watch CTIT and retention by source, and cap spend per source per day, so one bad source cannot hide in the average or drain the budget.

What publishers can do

Publishers lose from fraud too, through reversals and lower payouts. The fraud you control is on your side of the integration.

• Sign your offerwall links on your server. The hash proves the user ID in the link is the one your server chose, so nobody can open the wall as someone else. Never put the salt in an app bundle or browser code, where it can be pulled out, which is the same weakness SDK spoofing exploits. How to rotate your keys and link salt covers what to do if it leaks.
• Verify the hash on every postback. A forged postback is SDK spoofing aimed at you: a fake server call that credits a user for nothing. Postback security walks through the check, constant-time comparison, and one credit per transaction.
• Rate-limit what users can do, such as sign-ups per IP, wall opens per account, and credits per user per hour, and review anything above your normal range before a cashout.
• Stop emulators and farms at the door. If you run an app, the Play Integrity API can tell your server about emulated environments and modified builds. On any property, device fingerprinting and VPN checks catch one person running many accounts; Stop multi-accounting and VPN abuse covers the layers and how to avoid punishing honest users.
• Hold new earnings before cashout, so a fraud reversal lands first.

Frequently asked questions