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:

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

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.