Google Play has a Data Safety section. Developers fill it out themselves. Nobody verifies it.

A Mozilla study from 2023 found that over 80% of privacy labels on the Play Store are inaccurate or incomplete. The same conclusion came from Oxford in 2018 and MIT researchers since. There is no penalty for a developer who lies about data collection. The label is a checkbox exercise.
That is the problem AppXpose was built to solve.

The Technical Problem

Most privacy tools work at the network level. They monitor traffic, block domains, or analyze behavior at runtime. That approach has real value but it also has a fundamental limitation: it only catches what an app does while you are watching.
Static APK analysis takes a different approach. Instead of watching what an app does, it reads what an app contains.
An APK is a ZIP archive. Inside it are DEX files — Dalvik Executable format, the compiled bytecode that Android runs. DEX files contain all the class names from the app's Java and Kotlin source code.
Here is the insight: you do not need to decompile or reverse-engineer anything to identify third-party SDKs. Class names follow predictable package naming conventions. com.google.firebase.analytics is Firebase Analytics. com.appsflyer.internal is AppsFlyer. com.facebook.ads is Meta Audience Network.
You can identify embedded SDKs just by reading class name prefixes. No decompilation. No dynamic analysis. Just string matching against a signature database.

Building the Signature Database

AppXpose currently has 174 tracker SDK signatures from two sources.
About 80 signatures come from Exodus Privacy, an open-source tracker database licensed under ODbL. These are the well-known ones: Google Analytics, Firebase, AdMob, Crashlytics, AppsFlyer, Adjust.
The remaining signatures come from original research and a community discovery pipeline.
The community discovery pipeline works like this: when AppXpose scans an app and finds class prefixes that do not match any known signature, those prefixes are reported anonymously to a server. When the same unknown prefix appears in three or more distinct apps, it gets flagged for investigation. Confirmed signatures are pushed to all devices via a daily sync without requiring an app update.
This means the detection engine improves passively with every scan in the corpus. No crowdsourced effort required. It just accumulates.
The 13 tracker categories are: Analytics, Ads, Attribution, Crash Reporting, Social, Push, Payment, Location, Support, Authentication, Experimentation, Deep Linking, and Unknown.
Unknown is the most interesting category. More on that below.

The Matching Engine

The core matching logic is simpler than it sounds.
For each installed app, AppXpose extracts all DEX class names using PackageManager and a custom DEX parser. It applies a 30MB cap to avoid OOM on large apps. Multi-DEX is handled natively.
Class names are then matched against the signature database using prefix matching. com.google.firebase.analytics.FirebaseAnalytics matches the prefix com.google.firebase.analytics.
Two deduplication layers prevent inflation:
First, sub-package deduplication collapses child packages into the parent SDK. If you have both com.google.firebase.analytics and com.google.firebase.analytics.connector detected, only one SDK is counted.
Second, an SDK subsumption map handles transitive dependencies. Firebase is bundled automatically when you add AdMob. Counting both would be misleading. The subsumption map knows which SDKs are typically bundled together and collapses them.
Per-batch sizing handles large APKs: apps over 100MB scan in batches of 2, smaller apps in batches of 4. This prevents ANR on constrained devices.

APK Integrity Checks

Beyond tracker detection, AppXpose runs five deterministic integrity checks against each APK.
DEX header fingerprint: checks for non-standard header sizes, endianness anomalies, and checksum mismatches. Legitimate Play Store apps have clean DEX headers. Repackaged or tampered APKs often do not.
Suspicious file entries: searches for known hooking framework artifacts — Frida server binaries, Xposed framework files, Cydia Substrate signatures, LSPosed/Whale hooking libraries, root binaries like su and busybox, debugging tools like gdbserver. Also checks for repackaging indicators like classes_patched.dex.
Signing block shape: analyzes the APK signature block structure. APKs stripped of their v2/v3 signatures and re-signed with a different key show characteristic anomalies here.
Native library presence: flags native libraries associated with hooking or surveillance tools.
Multiple DEX detection: counts DEX files. Unusual counts relative to app size can indicate modification.
A real example from our corpus: com.mmaa.narasarangapp flagged HIGH for AppGuard Packer. The scan found assets/appguard/sign.crt and assets/appguard/sign.mf inside the APK. AppGuard is a Korean code obfuscation tool used to hide what the app does from static analysis. A legitimate app has no reason to use it.

What the Data Shows After 3,745 Scans

The corpus has accumulated some clear patterns.
Finance apps average 13.5 tracker SDKs per app. The category handling your most sensitive data is the most aggressive tracker category in the corpus.
1 in 7 apps scores HIGH or CRITICAL risk.
The Unknown SDK category averages 6.6 trackers per app. That is three times higher than the Ads category. These are unrecognized packages being actively investigated through the community discovery pipeline. The fact that unrecognized SDKs show up so frequently across so many apps suggests there is a long tail of tracking infrastructure that has not been catalogued yet.
Some specific findings: Match Masters contains 41 embedded tracker SDKs. An app called "AI Browser - Safe & Fast" contains 30 trackers and scores HIGH risk.
The full dataset is available at appxpose.app/research.

What I Would Do Differently

Starting with static analysis was the right call. I considered dynamic analysis early on but the complexity of instrumenting a runtime, handling obfuscation, and dealing with apps that behave differently under observation made static analysis a much more tractable starting point.
The community discovery pipeline was the best architectural decision. Passive improvement without user effort is hard to replicate with any other approach.
The AI risk analysis using Claude Haiku for the summary and score blending works better than I expected. The prompt engineering to get consistent, calibrated scores took iteration but the results are genuinely useful.
What I underestimated: the gap between what permissions an app declares and what it actively uses at runtime. Declared permissions inflate some findings. This is a known limitation of static analysis and worth being explicit about.

Open Questions

How do you handle aggressive class name obfuscation? Some apps rename everything to single characters. Prefix matching breaks entirely on these.
How do you distinguish a permission declared because an SDK requires it versus one the app actually uses? This requires dynamic analysis to answer properly.
How do you scale the signature database beyond 174 entries while keeping false positive rates acceptable? More signatures mean more potential for incorrect matches on classes that happen to share a prefix.
If you are working on similar problems or have thoughts on any of these, I am happy to talk through it in the comments.
The full methodology is at appxpose.app/how-it-works.

AppXpose is free on Google Play. The research corpus data is public at appxpose.app