DEV Community

orange black
orange black

Posted on Originally published at dev.to

How to find out what SDKs, ad networks, and APIs a competitor's Android app uses

#android #showdev #mobile #monetization

How to find out what SDKs, ad networks, and APIs a competitor's Android app uses

You can install an app in ten seconds and still have no idea how it makes money. That's the gap this post is about.

Below is the whole workflow — from a Play Store URL to a list of SDKs, ad networks, and API endpoints — using only free tools, plus three findings from real teardowns to show what the output actually looks like. Everything here works on a Mac or Linux box; no rooted device required.

One honest prerequisite: you need the APK. Download it from a mirror you trust (APKMirror, APKPure, or bundletool from the developer's own bundle), and keep it local. Don't redistribute it — you're analyzing, not republishing.

Step 0 — Pull the manifest first (30 seconds, no decompiler)

An APK is a ZIP. Before you install anything, get the facts that are cheap:

unzip -l app.apk | head -50          # what's in the package
unzip -p app.apk AndroidManifest.xml > manifest.bin
Enter fullscreen mode Exit fullscreen mode

In the manifest (readable once you run it through aapt2 dump or apktool) you already get:

  • permissions — a surprising amount of monetization intent is visible here (AD_ID, ACCESS_FINE_LOCATION, POST_NOTIFICATIONS, BILLING, RECEIVE_BOOT_COMPLETED)
  • declared services and receivers — ad SDKs register background components with recognisable names
  • <meta-data> blocks — attribution SDKs (Adjust, AppsFlyer, Facebook) put their app IDs here in plain text
  • minSdk / targetSdk — a fast signal of how actively the app is maintained

Half the questions people ask ("does this app use X?") are answered at this step alone.

Step 1 — Decompile, don't reverse

You are not rebuilding the app. You want strings, class names, and dependencies:

apktool d app.apk -o out/            # resources, manifest, smali
jadx -d jadx-out app.apk             # Java-ish source, greppable
Enter fullscreen mode Exit fullscreen mode

jadx output is imperfect — obfuscated apps rename everything — but SDK integration code is almost never obfuscated, because the SDK vendors ship their own class names and those names are what the app has to call.

Then grep for the cohort:

grep -rIl "com.google.android.gms.ads" jadx-out/     # AdMob
grep -rIl "com.facebook.ads" jadx-out/                # Meta Audience Network
grep -rIl "com.applovin" jadx-out/                    # AppLovin / MAX
grep -rIl "com.unity3d.ads" jadx-out/                 # Unity Ads
grep -rIl "com.ironsource" jadx-out/                  # ironSource / LevelPlay
grep -rIl "com.vungle\|com.chartboost\|com.adcolony" jadx-out/
grep -rIl "com.adjust.sdk\|com.appsflyer\|com.kochava" jadx-out/   # attribution
grep -rIl "com.amplitude\|com.mixpanel\|app.cash.turbine\|io.sentry" jadx-out/  # analytics/crash
Enter fullscreen mode Exit fullscreen mode

Three details that separate a real answer from a grep hit:

  1. A class name is not a running network. Finding com.applovin proves the SDK is bundled. Whether it's initialized is a different question — look for the init call and for a mediation config (applovin_settings, MAX_Ad_Unit, or a remote config key).
  2. Check assets/. Some SDKs ship as a hidden DEX loaded at runtime, so they never appear in the main classes.dex grep.
  3. Count the adapters, not the SDKs. Mediation adapters (com.applovin.mediation.adapters.*, com.google.ads.mediation.*) are what tell you which networks actually compete for your impression.

Step 2 — Find the API surface

Two cheap passes:

# hardcoded hosts in resources and code
grep -rhoE "https?://[a-zA-Z0-9._-]+" out/res jadx-out --include=* 2>/dev/null \
  | sed 's|https\?://||' | cut -d/ -f1 | sort | uniq -c | sort -rn | head -40
Enter fullscreen mode Exit fullscreen mode

Then separate them into first-party (the vendor's own gateway) and third-party (SDK endpoints). The first-party list is where the interesting structure lives — and it's also where people accidentally leave things they shouldn't.

What this looks like in practice

Three findings from teardowns we've published, chosen because they're the kind of thing you can't see from the outside:

1. Six ad networks running simultaneously, with hybrid header bidding + waterfall. Not "the app has ads" — six mediation adapters, with a server-controlled configuration (ScannerRewardRatio.xml, a remote endpoint) that lets the vendor re-weight networks without shipping an update. If you're building a mediation stack, this is the reference architecture for the productivity category.

2. Facebook Audience Network shipped as a hidden DEX in assets/. audience_network.dex, ~5 MB, loaded at runtime rather than linked at build time. That's a deliberate cold-start trade: you pay a few hundred ms later to keep the base APK small. It also means a naive classes.dex grep misses it entirely.

3. Staging endpoints left in production. Six sandbox/staging hosts hardcoded alongside the live ones. Not a vulnerability by itself, but it tells you how the team ships — and it's a reminder to grep for -dev, -staging, -test before you ship.

Other things that fall out of the same workflow: which authentication providers an app supports (we found seven, including region-specific ones), whether API responses are encrypted at the transport layer or above it, and which privacy APIs (Topics, Attribution, Ad ID) are actually wired up versus merely declared in the manifest.

The workflow, condensed

Question Where the answer is
What does it monetize with? manifest permissions + mediation adapters in jadx output
Which ad networks? com.*mediation.adapters classes + remote config keys
Which attribution/analytics? <meta-data> in the manifest + SDK class names
What are its backends? hostname histogram from res/ and code
Is it native, hybrid, or Flutter? lib/*.so, flutter_assets/, classes.dex count
How actively maintained? targetSdk, SDK versions bundled, release cadence

Two caveats worth stating out loud

  • Version drift. Everything is a snapshot of one APK version. Record the version code and date next to every finding, or the analysis rots silently.
  • Bundled ≠ used. For anything that decides a business decision, confirm the SDK is initialized and reachable, not merely present.

If you want the worked examples

We publish full teardowns at appxray.blackorange.org — two are free and complete, no signup: CamScanner (306 MB XAPK, 27 split APKs, six-network mediation) and Duolingo (hybrid monetization, education category). Both include the SDK list, ad network breakdown, API endpoints, and architecture — the same output as the workflow above, minus the four hours.

If you'd rather not spend the evening in jadx, that's what we do: send a Play Store link, get the report in about two hours, $29 per app (or $19 each for three or more). No account needed — the pricing page explains what's in it.

Disclosure: this post is written by the team that sells that service. The methodology above is free and complete — you can run it yourself today, and the two sample reports are public so you can judge the output before paying anything.

More teardowns:

Top comments (0)