SDKGPT 如何检测 SDK
从 APK 里直接读出四类信号，与人工维护的规则库匹配——每条检测都能回溯到证据。
四类信号
SDK 藏得住品牌，藏不住足迹。每个解析过的 APK 产出四类痕迹：
DEX 包名
字节码里的 Java/Kotlin 包名前缀——com.umeng.analytics、com.appsflyer.*。主力信号：大多数 SDK 都带着可识别的包名树。
原生库
APK 里打包的 .so 文件名——libBugly.so 之类。深度解析更进一步，从二进制里抽 JNI 函数名和内嵌字符串。
Manifest 声明
AndroidManifest.xml 里的 Service、Activity、Receiver、Provider 与 metadata 条目——SDK 要求应用接线的组件。
URL host
DEX 字符串里内嵌的 HTTP 端点。它揭示纯 REST 集成和完全不留包名痕迹的 SaaS 厂商。
规则库
信号通过规则库变成 SDK：1,900+ SDK 规则、57,000+ 包名模式，以 LibChecker 社区知识库为种子，再由我们自己的发现流水线持续扩充。匹配沿用 LibChecker 的逻辑——精确匹配，或前缀加点号——所以 com.foo.bar 命中规则 com.foo，而 com.foobar 永远不会误命中。
置信度与证据
每个「应用–SDK」对都带置信度。已确认检测命中了人工审核的规则；潜在检测是还没匹配上的信号，在评审队列里——其中很多会在 LLM 辅助终判后转正。每条结果保留完整证据链：原始信号、触发的规则、发现它的应用版本。页面上看到的，都能回溯到二进制。
数据新鲜度
流水线持续运行：商店按计划爬取，新版本进解析队列，统计随结果落库重新聚合。我们始终解析每个应用的最新版本——商店一上架更新，它的 SDK 清单就跟着刷新。目录与市场份额数字每日更新；单条检测在它所属的 APK 解析完成即出现。