DEV Community: orange black

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

orange black — Thu, 17 Sep 2026 11:55:14 +0000

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

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

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

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

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).
Check assets/. Some SDKs ship as a hidden DEX loaded at runtime, so they never appear in the main classes.dex grep.
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

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:

How Does Duolingo Monetize? I Decompiled the Android App (v6.79.5)

orange black — Tue, 26 May 2026 07:05:46 +0000

I wanted to know how Duolingo makes money on Android -- ads vs Super subscription, which SDKs they use, and how aggressive the free tier is. So I decompiled Duolingo 6.79.5 (164 MB APK, 11 DEX files, 242 activities).

TL;DR

IronSource mediation sits at the center -- Unity Ads, Vungle, Moloco, AdMob, Facebook, and Pangle all plug in around it
Facebook Audience Network ships as a 5 MB hidden DEX in assets (same trick as CamScanner)
7+ ad networks for free users; Google Play Billing for Super/Plus (no RevenueCat found)
Kotlin + Jetpack Compose for the main app; Unity for some game modules (chess, etc.)
Staging APIs (android-api-stage, goals-api-stage-*) are hardcoded in the production build
Adjust + Sentry (+ Firebase) for attribution and crashes

How Duolingo Makes Money

Subscriptions (Super / Plus)

Duolingo uses Google Play Billing directly -- ProxyBillingActivity, PlusPurchaseFlowActivity, strings for gems and family plans. Deep links hit duolingo.com/settings/super.

I did not find RevenueCat or Superwall in the DEX. Subscription logic appears first-party on top of Google's billing library.

Ads (free tier)

Free users hit a mediation-heavy stack:

Network	Role
IronSource	Mediation hub (most SDK surface area)
Unity Ads	Mediated demand + game ad units
Google AdMob	Google demand, MRAID native templates
Facebook AN	Hidden `audience_network.dex`
Pangle (TikTok)	Rewarded, interstitial, app open
Vungle	Video
Moloco	Programmatic / MRAID / VAST

Duolingo-owned ad screens include CustomNativeAdActivity, FullscreenNetworkNativeAdActivity, and PlusPromoVideoActivity -- ads show up at session end and league flows, not random webviews.

The hidden Facebook DEX (again)

assets/audience_network.dex  ~5 MB

Meta's SDK is not fully embedded in the main multidex load. It is loaded from assets when needed -- a common pattern to protect cold start on huge apps.

Tech Stack (what they built with)

Layer	Choice
UI	Kotlin + Jetpack Compose (thousands of references)
Games	Unity (`UnityActivity`, chess promo assets)
Network	OkHttp, Retrofit
Media	ExoPlayer, Lottie, Rive
Attribution	Adjust
Crashes	Sentry (`duolingo-sentry.sentry.io`) + Firebase
Support	Zendesk

Min SDK 29 -- they have dropped pre-Android 10 devices.

Staging servers in production

Same class of mistake as other big apps:

android-api-stage.duolingo.com
goals-api-stage.duolingo.com (+ stage-2, stage-3)
infra-edge-gateway-stage-cf.duolingo.com

Useful if you are researching API behavior; risky if those hosts expose looser auth.

Duolingo vs CamScanner (quick compare)

I decompiled CamScanner earlier:

	CamScanner	Duolingo
Mediation lead	AdMob + PubMatic bidding	IronSource + Unity
UI	Native + Flutter	Compose + Unity games
Ad networks	6	7+
Hidden Meta DEX	Yes	Yes

Education apps and utility apps converge on the same playbook: many networks, one mediator, lazy-load Meta.

What I left out of this post

The full report includes 60+ first-party API hosts, complete permission breakdown, schools/DET endpoints, and module-level Activity mapping. This post is the highlights.

I run AppXray -- send any Google Play link, get a full reverse-engineering report (PDF + Markdown) in ~2 hours. $29 for one app, $19/app for batches.

Free samples: CamScanner teardown

Questions about Duolingo's stack? Comment below.

More teardowns:

What Ad Networks Does CamScanner Use? I Decompiled the APK to Find Out

orange black — Thu, 14 May 2026 12:47:03 +0000

Android App Reverse Engineering Report | APK Teardown — AppXray

Send a Google Play link. Get a full APK teardown — architecture, APIs, SDKs, ad networks, permissions. Delivered in 2 hours.

appxray.blackorange.org

I wanted to know what ad networks CamScanner uses and how they monetize a 100M+ download scanning app. So I reverse-engineered the APK.

Here's what I found inside CamScanner v7.16.5 (306 MB, 12 DEX files, 369 activities).

TL;DR

6 ad networks running at the same time
Header bidding + waterfall hybrid — not just AdMob
Facebook Audience Network loaded as a hidden DEX file at runtime
6 staging/test servers exposed in the production build
Hybrid Flutter + Native architecture using Alibaba's FlutterBoost
34 third-party SDKs total

The Ad Stack: 6 Networks Running Simultaneously

Most indie apps use AdMob alone. CamScanner runs six ad networks in parallel:

Network	Role
Google AdMob	Primary SDK, all ad formats
Pangle (ByteDance/TikTok)	Secondary — 14 Activity classes registered, big in Asia
Facebook Audience Network	Loaded dynamically as a separate DEX at runtime
PubMatic OpenBid	Header bidding via OpenRTB 2.5
Vungle	Video ads (rewarded + interstitial)
Google Ad Manager	DoubleClick — for premium/direct-sold inventory

The interesting part isn't the list — it's how they combine them.

Header Bidding + Waterfall Hybrid

PubMatic runs real-time auctions (OpenRTB 2.5) in parallel with AdMob's waterfall. This means:

AdMob waterfall handles most impressions
PubMatic bids in real-time, winning when its CPM beats the waterfall floor
Result: higher effective eCPM than either method alone

If you're only running AdMob, you're leaving 30-50% of ad revenue on the table.

Hidden DEX Loading for Facebook Ads

This one surprised me. Facebook Audience Network isn't bundled in the main APK. Instead, there's a file called audience_network.dex (5 MB) sitting in the assets/ folder, loaded at runtime via DexClassLoader.

Why? Cold start optimization. CamScanner avoids loading 5 MB of Facebook ad code on every app launch — it only loads when a Facebook ad placement is triggered.

Server-Controlled Ad Config

Two remote config sources control ad behavior:

cs8.intsig.net/ad — likely controls placement logic and frequency
ScannerRewardRatio.xml hosted remotely — controls rewarded ad payout ratios

This means they can A/B test ad strategies, change placements, and adjust frequency caps without shipping an app update.

What's CamScanner Built With?

The tech stack is a hybrid:

Core app: Native Android (Java/Kotlin) — scanning, document management
New features: Flutter via Alibaba's FlutterBoost — AI chat, document processing
OCR: Google ML Kit (on-device)
Crash monitoring: Sentry + ByteDance APMPlus (dual monitoring for global + China)
Attribution: AppsFlyer (they're running paid user acquisition)
Analytics: Firebase Analytics

The Flutter + Native hybrid with FlutterBoost is worth noting — it's Alibaba's framework that lets you mix Flutter screens with native Activities seamlessly. If you're considering adding Flutter to an existing native app, this is a proven pattern at scale.

The Security Mistake: Staging Servers in Production

I found 6 staging/sandbox API endpoints hardcoded in the release build:

api-cs-sandbox.intsig.net
api-center-sandbox.intsig.net
api-algo-sandbox.camscanner.com
ai-cn-sandbox.camscanner.com
cs1-sandbox.intsig.net
b103-sandbox.camscanner.com

These are internal test servers that should have been stripped from the production build. They could potentially expose debug interfaces or less-secured services. Don't make this mistake in your own app.

Key Numbers

Metric	Value
Total size	306 MB (27 split APKs)
DEX files	12 (85.5 MB bytecode)
Activities	369
Third-party SDKs	34
Ad networks	6
Auth providers	7+
Permissions	35
Supported languages	27

What I Didn't Include Here

The full report goes deeper: complete API endpoint list (18 first-party + 14 third-party), full SDK breakdown by category, permission-by-permission analysis with risk levels, build configuration details, and technical implementation specifics like the dynamic DEX loading mechanism.

I do this as a service. Send me any Google Play link and I'll send you a full reverse-engineering report (PDF + Markdown) within 2 hours. $29 for one app, $19/each for 3-10 apps.

Free sample report (CamScanner full version): appxray.blackorange.org

Have questions about what I found? Drop a comment — happy to discuss.

More teardowns: