Four signal types read straight from the APK, matched against a curated rule base — every detection traceable to evidence.
An SDK can hide its brand, but it can't hide its footprint. Every parsed APK yields four kinds of traces:
Java and Kotlin package prefixes inside the bytecode — com.umeng.analytics, com.appsflyer.*. The primary signal: most SDKs ship identifiable package trees.
.so filenames bundled in the APK — libBugly.so and friends. Deep parsing goes further, pulling JNI function names and embedded strings out of the binary.
Services, activities, receivers, providers, and metadata entries in AndroidManifest.xml — the components an SDK asks the app to wire up.
HTTP endpoints embedded in DEX strings. These reveal pure REST integrations and SaaS vendors that leave no package-name trace at all.
Signals become SDKs through the rule base: 1,900+ SDK rules and 57,000+ package-name patterns, seeded from the LibChecker community knowledge base and continuously extended by our own discovery pipeline. Matching follows LibChecker's logic — exact match, or prefix-plus-dot — so com.foo.bar matches rule com.foo, but com.foobar never does.
Every app–SDK pair carries a confidence level. Confirmed detections matched a curated rule; potential detections are unmatched signals still under review — many get promoted after an LLM-assisted judgment pass. Each result keeps its evidence chain: the raw signal, the rule that fired, the app version it was found in. What you see on a page, you can trace back to a binary.
The pipeline runs continuously: stores are crawled on a schedule, new versions queue for parsing, and statistics re-aggregate as results land. We always parse the latest version of each app — when a store ships an update, its SDK inventory refreshes with it. Directory and market-share numbers update daily; individual detections appear as soon as their APK finishes parsing.