Pith. sign in

REVIEW 3 major objections 5 minor 85 references

Revisiting Third-Party Library Detection: A Ground Truth Dataset and Its Implications Across Security Tasks

T0 review · 3 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A 6,055-app, version-level ground truth shows the best Android third-party library detector reaches only 60.15% F1, and the worst 2.26%.

desk verdict A serious and useful empirical study of TPL detection, but the version-level ground truth is not yet firmly established: the 50% exact-match rate on the validation sample is a load-bearing caveat that needs a breakdown and public artifacts. read the letter →

arxiv 2509.04091 v2 pith:6XEHGHIP submitted 2025-09-04 cs.CR

Jintao Gu , Haolang Lu , Guoshun Nan , Yihan Lin , Kun Wang , Yuchun Guo , Yigui Cao , Yang Liu This is my paper · ORCID
classification cs.CR
keywords third-partylibrarydetectionAndroidsecuritygroundtruthbenchmarksoftwarecompositionanalysisversion-levelR8obfuscationresiliencesupplychainvulnerabilitiessecretleakage
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that the field of Android third-party library (TPL) detection has been evaluating itself on small, unrepresentative datasets, and builds the largest open-source benchmark yet—6,055 real apps with version-level library labels—to test that premise. The central finding is that ten published detectors, run under a unified protocol, all fall far short of deployment quality: the best library-level F1 is 60.15%, the worst 2.26%, and version-level accuracy is weaker still. The paper traces the failures to R8-era code shrinking, namespace ambiguity between libraries sharing a root package, a systematic blind spot for Kotlin-only libraries, and feature sparsity in optimized code. It then shows why the gap matters: over a quarter of the apps carry at least one CVE-affected library, stripping libraries removes 60–80% of benign code without hurting malware detection accuracy, and 829,580 secrets leak across 19.2% of projects. If the benchmark is right, every downstream tool that assumes reliable library identification inherits an unmeasured margin of error.

What carries the argument

The load-bearing object is the version-level triplet <Group ID, Artifact ID, Version>, produced by the TPL-Extractor operator E(p) = ρ(∆(N(D, A, K))): N normalizes every dependency declaration in reachable modules into explicit triplets (resolving variables, TOML catalogs, BOM imports, and interpolated strings), ∆ removes exact duplicates, and ρ resolves version conflicts the way Gradle does. The same triplet serves as ground truth for scoring detectors and as the join key for mapping libraries to CVEs, apps to CVEs, and call-graph nodes to libraries. The benchmark's distributional coverage—R8-era builds, legacy DX, local .jar/.aar/.so imports, and a wide version spread—is what lets the pape

What would settle it

Compile a fresh, stratified sample of TPL-Benchmark projects spanning DX-era and R8 full-mode AGP versions and compare TPL-Extractor's triplets against Gradle's resolved release-runtime classpath: if exact-match falls materially below the reported 50%, or version mismatches concentrate in modern builds, the version-level trustworthiness claim that anchors every tool score is undermined. A second check: run a non-code-feature detector (resources plus build metadata) on the same 946-app evaluation; if it clears roughly 85% library-level F1, the paper's attribution of failure to code-level method

Watch

Extended reading notes

Core claim

The paper's claim is that TPL-Benchmark—6,055 APK/source pairs annotated with <Group ID, Artifact ID, Version> triplets, covering 5,756 unique libraries, 15,274 versions, and 62,218 app-library links—is a trustworthy ground truth at scale, and that under it the ten state-of-the-art TPL detectors it evaluates are far from practical usefulness. On 946 apps with 28,210 valid library links, the best library-level F1 was 60.15% (LibPecker) and the worst 2.26% (Orlis); version-level F1 topped out near 49% (LibID with candidate sets), and only one tool (LibHunter) kept recall above 76%. The labels themselves come from TPL-Extractor, which parses Gradle build files into normalized triplets, deduplic

Load-bearing premise

The labels extracted from Gradle build files correspond to what is actually packaged inside the paired APK, including the correct version; on the paper's own 200-app validation, only 50% of label sets matched Gradle's independently resolved dependency set exactly.

Editorial extensions

If this is right

  • A detector that reaches deployment quality on this benchmark cannot rely on code-structural signatures alone; the root-cause analysis points to compiler-aware matching and non-code artifacts such as resources and build metadata that survive R8 transformations.
  • Version-level accuracy is the binding constraint: with the best version F1 near 49%, any vulnerability report built on current detectors understates which apps run a vulnerable version of a library.
  • Library stripping is a cheap win for analysis pipelines: removing up to 70% of call-graph nodes held malware detection F1 at 86–88% while cutting storage from 238 GB to 71 GB and feature extraction time by 20%.
  • Software composition analysis should surface not just 'CVE present' but version lag and patch-availability-without-adoption, since nearly 40% of apps with 10+ CVEs target modern AGP versions.
  • The Kotlin blind spot—no detector identifies libraries that only contain kotlin_metadata—will widen as Kotlin Multiplatform distribution grows.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If adopted as a standard, the benchmark would likely compress the reported performance spread: the 2–60% F1 range is partly an artifact of each tool being tuned on its own dataset, and a common benchmark would re-anchor thresholds and candidate-selection heuristics across the board.
  • The 50% exact-match validation rate invites a decomposition the paper does not provide: version errors versus missing or extra libraries have different consequences, since version errors poison CVE-to-app mappings while missing libraries shrink recall baselines.
  • A natural next experiment the paper implies but does not run: a detector built on resource files plus build metadata, tested on this same benchmark, should beat every code-only tool—the root-cause analysis predicts this directly.
  • The secret-leakage channel analysis suggests build artifacts (.snapshot, .dill, .rsp) are an under-scanned vector; scanning CI caches and generated outputs rather than source files alone would be a concrete policy takeaway beyond the paper's stated recommendations.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper presents TPL-Benchmark, a dataset of 6,055 Android apps with version-level third-party library (TPL) annotations in <Group ID, Artifact ID, Version> form, built from APK–source pairs harvested from F-Droid and GitHub. The labels are produced by a new tool, TPL-Extractor, which parses Gradle build files, resolves variables, BOMs, and version conflicts, and aggregates dependencies from reachable modules. The authors report an internal reliability check on 200 apps against Gradle's releaseRuntimeClasspath resolution (r=0.99, MAE=0.75, exact-match rate 0.50), and then use the dataset to evaluate ten TPL detection tools, obtaining library-level F1 scores up to 60.15% and version-level F1 scores much lower. They also use the dataset for downstream analyses: CVE mapping, malware feature-dilution analysis, secret leakage scanning, and LLM-based code evaluation. The paper argues that current TPL detection tools are far from practical deployment quality and that TPL-Benchmark provides a more realistic and larger-scale evaluation foundation than prior datasets.

Significance. If the ground-truth labels are trustworthy, the dataset is a substantial contribution: it is far larger than existing open TPL benchmarks, contains version-level annotations, spans DX/D8/R8-era builds, and includes local and remote dependencies. The unified evaluation of ten tools under one protocol is also valuable, and the downstream analyses illustrate concrete uses of such a benchmark. The paper's open-science commitment is appropriate and necessary for the claims. However, the validity of every headline number—tool F1 scores, CVE mapping counts, and downstream statistics—depends on the correctness of the version-level labels. The current internal validation is not sufficient to establish that correctness, so the paper's central contribution is not yet fully supported.

major comments (3)
  1. [§3.4.1, Eq. (11)] The benchmark's central claim is trustworthy version-level labels, but the validation on n=200 reports only a 50% exact-match rate between Lp and Gradle's releaseRuntimeClasspath. MAE=0.75 and r=0.99 are count-based metrics and cannot detect version mismatches: replacing one version with another leaves the count unchanged. The paper attributes residual errors to build-configuration-induced and plugin-resolved dependencies but gives no breakdown and does not report version-only disagreement. Since Eq. (7) approximates Gradle's resolution rather than executing it, errors from BOM expansion, dynamic versions, and local imports may be shared by both Lp and Lgold. Appendix H concedes that the ground truth is 'a practical approximation rather than an absolute standard.' I request a version-level error breakdown, an independent validation against packaged binaries (e.g., comparing classes/resou
  2. [§4.1 and Appendix G] The evaluation protocol for candidate-set tools gives them a strong advantage that is not reflected in the abstract or Table 4. The candidate set includes the ground-truth libraries themselves, plus 100 random other versions and 100 random non-used libraries. In real deployment, a detection tool would not receive its target library as a candidate. This makes the reported F1=60.15% for LibPecker an upper-bound-like estimate under a favorable condition, not a realistic operating point. The full-database tools are evaluated under a different, more difficult setting. The paper should state this asymmetry prominently and analyze how results change when candidate sets are constructed without ground-truth knowledge.
  3. [§4.1] The data preparation step excludes 841 ground-truth jars 'with little or no code features' and selects 946 apps 'mostly with >20 TPLs.' The exact selection criterion and the distribution of excluded apps are not reported. If apps with few TPLs or small libraries are systematically excluded, the benchmark's difficulty is biased toward library-heavy apps, which may inflate or deflate tool scores in ways that change the generalizability of the conclusions. Please report the full selection rule, the number of apps excluded at each step, and the sensitivity of Table 4 to these exclusions.
minor comments (5)
  1. [Table 2] The column header 'Paris' in Table 2 appears to be a typo; presumably it should be 'Pairs.' Please correct and align the table formatting.
  2. [Figure 1] The figure contains the typo 'Retreval'; it should read 'Retrieval.' Also, the figure is dense and hard to read in monochrome; consider separating the pipeline stages.
  3. [§5.4] The LLM evaluation uses 'Qwen-Plus model [56]' but the cited reference is the Qwen2 technical report. Please clarify the exact model version and API access date, and report the prompt template or provide it in an appendix for reproducibility.
  4. [Appendix G] The '100 randomly selected' candidate libraries are not reproducible without a seed or a released list. Since candidate selection affects F1, please release the candidate sets and seeds.
  5. [§5.2] The malware analysis uses a 'curated TPL whitelist' that is not described in the paper. Please explain how this whitelist was derived from TPL-Benchmark and whether it includes version information.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the benchmark labels are extracted from build files and the evaluated tools are independent; the measured tool F1 scores are not forced by construction.

full rationale

The paper's derivation chain is: (1) collect APK/source pairs; (2) TPL-Extractor parses Gradle build files into <group, artifact, version> labels; (3) validate those labels against Gradle's own releaseRuntimeClasspath resolution; (4) evaluate ten third-party detection tools against those labels. None of these steps reduces to the tools' outputs or to fitted parameters. The labels come from build configuration, while tool detection operates on APK binaries, so the reported F1 scores are empirical measurements rather than consequences of the label definition. The ground-truth validation uses an external reference (Gradle's dependency resolution), not the tools under test; the 50% exact-match rate reported in Section 3.4.1 is a ground-truth validity caveat, and Appendix H explicitly calls the dataset 'a practical approximation rather than an absolute standard,' but this is a correctness/quality concern, not a circular reduction. Self-citations to prior work (e.g., ATVHunter, PanGuard, and the SCA study) are used as objects of evaluation or background context and are not load-bearing for the central claim. The candidate-set protocol includes ground-truth libraries in candidate pools, which can inflate tool scores, but it does not make the tool scores derived from the benchmark labels by construction; if anything, it makes the reported low F1 findings conservative. No equation in the paper equates a predicted quantity with an input, and no fitted parameter is renamed as a prediction. Therefore the paper is not circular.

Assumptions & free parameters 2 free parameters · 3 assumptions · 0 invented entities

The central contribution is empirical, so rather than invented entities it rests on dataset construction choices. The main unstated burden is the equivalence between build-file metadata and binary content, plus hand-set evaluation parameters (decoy counts, LLM weights) that shape the reported numbers.

free parameters (2)
  • LLM evaluation weights = security 45%, code quality 30%
    Section 5.4 assigns hand-chosen weights to aggregate LLM quality scores; these weights are arbitrary and affect reported LLM category rankings.
  • Candidate decoy counts in tool evaluation = 100 random versions + 100 random libraries
    Appendix G sets candidate set size for LibPecker/LibScan/LibID/LibHunter; results depend heavily on this small decoy pool, which includes ground truth by design.
assumptions (3)
  • domain assumption Gradle build files, once parsed by TPL-Extractor, faithfully reflect the libraries and versions actually packaged in the APK.
    Eq. (7) defines labels from build configuration; Section 3.4.1 validation against Gradle resolution itself shows only 50% exact match, so this assumption is partially untested.
  • domain assumption APK-source pairs are correctly aligned by repository, commit, and version.
    Section 3.1 selects pairs by release/tag/commit matching; any mis-pairing propagates directly into all 6,055 labels.
  • domain assumption NVD, VirusTotal, and Gitleaks annotations are accurate enough for the downstream counts.
    Sections 5.1-5.3 use these external sources without independent verification; known false positive rates in secret scanners and AV engines are not quantified here.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Revisiting Third-Party Library Detection: A Ground Truth Dataset and Its Implications Across Security Tasks." pith.science (2026). https://pith.science/paper/6XEHGHIP

@misc{pith2026250904091,
  author       = {Pith},
  title        = {Pith review of: Revisiting Third-Party Library Detection: A Ground Truth Dataset and Its Implications Across Security Tasks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6XEHGHIP}},
  note         = {Machine review of arXiv:2509.04091}
}
read the original abstract

Accurate detection of third-party libraries (TPLs) is fundamental to Android security, supporting vulnerability tracking, malware detection, and supply chain auditing. Despite many proposed tools, their real-world effectiveness remains unclear. We present the first large-scale empirical study of ten state-of-the-art TPL detection techniques across over 6,000 apps, enabled by a new ground truth dataset with precise version-level annotations for both remote and local dependencies. Our evaluation exposes tool fragility to R8-era transformations, weak version discrimination, inaccurate correspondence of candidate libraries, difficulty in generalizing similarity thresholds, and prohibitive runtime/memory overheads at scale. Beyond tool assessment, we further analyze how TPLs shape downstream tasks, including vulnerability analysis, malware detection, secret leakage assessment, and LLM-based evaluation. From this perspective, our study provides concrete insights into how TPL characteristics affect these tasks and informs future improvements in security analysis.

Figures

Figures reproduced from arXiv: 2509.04091 by the authors.

Figure 1
Figure 1. Overview architecture. Our pipeline integrates APK-source code pairs, processes them with [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Dataset composition and comparison. The left [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Distribution of Locally Imports and TPL Versions. [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Distribution and Severity of CVEs in TPLs and [PITH_FULL_IMAGE:figures/full_fig_p011_4.png]
Figure 6
Figure 6. Figure 6: Vulnerability and Secret Exposure Distribution with [PITH_FULL_IMAGE:figures/full_fig_p013_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

85 extracted references · 77 canonical work pages

  1. [1]

    https://www.mend.io/blog/ software-composition-analysis/

    What Is Software Composition Analysis (SCA)?, 2023. https://www.mend.io/blog/ software-composition-analysis/

    2023

  2. [2]

    Allatori Java Obfuscator - Professional Java Obfusca- tion, Accessed: 2025.https://allatori.com/

    2025

  3. [3]

    https://www.guardsquare.com/ dexguard

    Android App Security and Obfuscation | DexGuard, Accessed: 2025. https://www.guardsquare.com/ dexguard

    2025

  4. [4]

    https:// www.appbrain.com/stats/libraries

    Android library statistics, Accessed: 2025. https:// www.appbrain.com/stats/libraries

    2025

  5. [5]

    https://www.preemptive.com/ products/dasho/

    Android Obfuscation and Java Security with DashO, Accessed: 2025. https://www.preemptive.com/ products/dasho/

    2025

  6. [6]

    https://cordova

    Apache Cordova, Accessed: 2025. https://cordova. apache.org/

    work page 2025

  7. [7]

    https:// apkpure.com/cn/

    Download APK to Android using the free online APK downloader in APKPure, Accessed: 2025. https:// apkpure.com/cn/

    work page 2025

  8. [8]

    Enable app optimization | App quality, Accessed:

    work page

Show all 85 references
  1. [9]

    F-Droid - Free and Open Source Android App Reposi- tory, Accessed: 2025.https://f-droid.org/

    2025

  2. [10]

    https://flutter.dev/

    Flutter - Build apps for any screen, Accessed: 2025. https://flutter.dev/

    2025

  3. [11]

    https://gradle

    Gradle Build Tool, Accessed: 2025. https://gradle. org/

    2025

  4. [12]

    https://www.guardsquare.com/ proguard

    Java Obfuscator and Android App Optimizer | ProGuard, Accessed: 2025. https://www.guardsquare.com/ proguard

    2025

  5. [13]

    Maven Repository: Search/Browse/Explore, Accessed: 2025.https://mvnrepository.com/

    2025

  6. [14]

    https://nvd.nist

    Nvd - home, Accessed: 2025. https://nvd.nist. gov/

    2025

  7. [15]

    React Native, Accessed: 2025.https://reactnative. cn

    2025

  8. [16]

    https://m.app

    Xiaomi APP Store, Accessed: 2025. https://m.app. mi.com/

    2025

  9. [17]

    Droidapiminer: Mining api-level features for ro- bust malware detection in android

    Yousra Aafer, Wenliang Du, and Heng Yin. Droidapiminer: Mining api-level features for ro- bust malware detection in android. InInternational conference on security and privacy in communication systems, pages 86–103. Springer, 2013

    2013

  10. [18]

    Androzoo: A retrospective with a glimpse into the future

    Marco Alecci, Pedro Jesús Ruiz Jiménez, Kevin Allix, Tegawendé F Bissyandé, and Jacques Klein. Androzoo: A retrospective with a glimpse into the future. InPro- ceedings of the 21st International Conference on Mining Software Repositories, pages 389–393, 2024

    2024

  11. [19]

    Bissyandé, Jacques Klein, and Yves Le Traon

    Kevin Allix, Tegawendé F. Bissyandé, Jacques Klein, and Yves Le Traon. Androzoo: Collecting millions of android apps for the research community. InProceed- ings of the 13th International Conference on Mining Software Repositories, MSR ’16, pages 468–471, New York, NY , USA, 2016. ACM

    2016

  12. [20]

    Obfuscapk: An open-source black-box obfuscation tool for android apps.SoftwareX, 11:100403, 2020

    Simone Aonzo, Gabriel Claudiu Georgiu, Luca Verder- ame, and Alessio Merlo. Obfuscapk: An open-source black-box obfuscation tool for android apps.SoftwareX, 11:100403, 2020

    2020

  13. [21]

    Flow- droid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps.ACM sigplan notices, 49(6):259–269, 2014

    Steven Arzt, Siegfried Rasthofer, Christian Fritz, Eric Bodden, Alexandre Bartel, Jacques Klein, Yves Le Traon, Damien Octeau, and Patrick McDaniel. Flow- droid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps.ACM sigplan noti...

    2014

  14. [22]

    Mining apps for abnormal usage of sensitive data

    Vitalii Avdiienko, Konstantin Kuznetsov, Alessandra Gorla, Andreas Zeller, Steven Arzt, Siegfried Rasthofer, and Eric Bodden. Mining apps for abnormal usage of sensitive data. In2015 IEEE/ACM 37th IEEE interna- tional conference on software engineering, volume 1, pages 426–436...

    2015

  15. [23]

    Reliable Third-Party Library Detection in Android and its Se- curity Applications

    Michael Backes, Sven Bugiel, and Erik Derr. Reliable Third-Party Library Detection in Android and its Se- curity Applications. InProceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS ’16, pages 356–367, 2016

    2016

  16. [24]

    Brahmastra: Driving apps to test the security of third-party components

    Ravi Bhoraskar, Seungyeop Han, Jinseong Jeon, Tanzirul Azim, Shuo Chen, Jaeyeon Jung, Suman Nath, Rui Wang, and David Wetherall. Brahmastra: Driving apps to test the security of third-party components. In 23rd USENIX Security Symposium (USENIX Security 14), pages 1021–1036, 2014

    2014

  17. [25]

    Routledge, 2013

    Jacob Cohen, Patricia Cohen, Stephen G West, and Leona S Aiken.Applied multiple regression/correla- tion analysis for the behavioral sciences. Routledge, 2013

    2013

  18. [26]

    Keep me Updated: An Empirical Study of Third-Party Library Updatability on Android

    Erik Derr, Sven Bugiel, Sascha Fahl, Yasemin Acar, and Michael Backes. Keep me Updated: An Empirical Study of Third-Party Library Updatability on Android. InPro- ceedings of the 2017 ACM SIGSAC Conference on Com- puter and Communications Security, CCS ’17, pages 2187–2200, 2017

    2017

  19. [27]

    Same app, different behaviors: Uncovering device- specific behaviors in android apps

    Zikan Dong, Yanjie Zhao, Tianming Liu, Chao Wang, Guosheng Xu, Guoai Xu, Lin Zhang, and Haoyu Wang. Same app, different behaviors: Uncovering device- specific behaviors in android apps. InProceedings of the 39th IEEE/ACM International Conference on Auto- mated Software Enginee...

  20. [28]

    Identifying Open-Source License Violation and 1-day Security Risk at Large Scale

    Ruian Duan, Ashish Bijlani, Meng Xu, Taesoo Kim, and Wenke Lee. Identifying Open-Source License Violation and 1-day Security Risk at Large Scale. InProceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS ’17, pages 2169–2185, 2017

    2017

  21. [29]

    A study of android application security

    William Enck, Damien Octeau, Patrick D McDaniel, and Swarat Chaudhuri. A study of android application security. InUSENIX security symposium, volume 2, pages 1–38, 2011

    2011

  22. [30]

    A graph-based dataset of commit history of real-world Android apps

    Franz-Xaver Geiger, Ivano Malavolta, Luca Pascarella, Fabio Palomba, Dario Di Nucci, and Alberto Bacchelli. A graph-based dataset of commit history of real-world Android apps. InProceedings of the 15th International Conference on Mining Software Repositories, MSR ’18, pages 30...

    2018

  23. [31]

    CodeMatch: Obfuscation won’t conceal your repack- aged app

    Leonid Glanz, Sven Amann, Michael Eichberg, Michael Reif, Ben Hermann, Johannes Lerch, and Mira Mezini. CodeMatch: Obfuscation won’t conceal your repack- aged app. InProceedings of the 2017 11th Joint Meet- ing on Foundations of Software Engineering, ESEC/FSE 2017, pages 638–648, 2017

    2017

  24. [32]

    Information flow analysis of android applications in droidsafe

    Michael I Gordon, Deokhwan Kim, Jeff H Perkins, Limei Gilham, Nguyen Nguyen, and Martin C Rinard. Information flow analysis of android applications in droidsafe. InNDSS, volume 15, page 110, 2015

    2015

  25. [33]

    Identify and Inspect Libraries in Android Applications.Wireless Personal Communications, 103(1):491–503, 2018

    Hongmu Han, Ruixuan Li, and Junwei Tang. Identify and Inspect Libraries in Android Applications.Wireless Personal Communications, 103(1):491–503, 2018

    2018

  26. [34]

    Diversified Third-Party Library Predic- tion for Mobile App Development.IEEE Transactions on Software Engineering, 48(1):150–165, 2022

    Qiang He, Bo Li, Feifei Chen, John Grundy, Xin Xia, and Yun Yang. Diversified Third-Party Library Predic- tion for Mobile App Development.IEEE Transactions on Software Engineering, 48(1):150–165, 2022

    2022

  27. [35]

    Msdroid: Identifying malicious snippets for android malware detection.IEEE Transactions on Dependable and Secure Computing, 20(3):2025–2039, 2022

    Yiling He, Yiping Liu, Lei Wu, Ziqi Yang, Kui Ren, and Zhan Qin. Msdroid: Identifying malicious snippets for android malware detection.IEEE Transactions on Dependable and Secure Computing, 20(3):2025–2039, 2022

    2025

  28. [36]

    Scalably De- tecting Third-Party Android Libraries With Two-Stage Bloom Filtering.IEEE Transactions on Software Engi- neering, 49(4):2272–2284, 2023

    Jianjun Huang, Bo Xue, Jiasheng Jiang, Wei You, Bin Liang, Jingzheng Wu, and Yanjun Wu. Scalably De- tecting Third-Party Android Libraries With Two-Stage Bloom Filtering.IEEE Transactions on Software Engi- neering, 49(4):2272–2284, 2023

    2023

  29. [37]

    Lib- Seeker: A third-party library detection method for An- droid applications with parameter self-tuning.Journal of Chinese Mini-Micro Computer Systems, 40(2):332–340, 2019

    sirong huang, feifan tao, yuan zhang, and min yang. Lib- Seeker: A third-party library detection method for An- droid applications with parameter self-tuning.Journal of Chinese Mini-Micro Computer Systems, 40(2):332–340, 2019

    2019

  30. [38]

    Binaryai: Binary soft- ware composition analysis via intelligent binary source code matching

    Ling Jiang, Junwen An, Huihui Huang, Qiyi Tang, Sen Nie, Shi Wu, and Yuqun Zhang. Binaryai: Binary soft- ware composition analysis via intelligent binary source code matching. InProceedings of the IEEE/ACM 46th International Conference on Software Engineering, pages 1–13, 2024

    2024

  31. [39]

    Ui-ctx: Understanding ui behaviors with code contexts for mobile applications

    Jiawei Li, Jiahao Liu, Jian Mao, Jun Zeng, and Zhenkai Liang. Ui-ctx: Understanding ui behaviors with code contexts for mobile applications. InNDSS, 2025

    2025

  32. [40]

    Iccta: Detecting inter-component privacy leaks in android apps

    Li Li, Alexandre Bartel, Tegawendé F Bissyandé, Jacques Klein, Yves Le Traon, Steven Arzt, Siegfried Rasthofer, Eric Bodden, Damien Octeau, and Patrick McDaniel. Iccta: Detecting inter-component privacy leaks in android apps. In2015 IEEE/ACM 37th IEEE International Conference ...

    2015

  33. [41]

    Re- booting research on detecting repackaged android apps: Literature review and benchmark.IEEE Transactions on Software Engineering, 47(4):676–693, 2019

    Li Li, Tegawendé F Bissyandé, and Jacques Klein. Re- booting research on detecting repackaged android apps: Literature review and benchmark.IEEE Transactions on Software Engineering, 47(4):676–693, 2019

    2019

  34. [42]

    Bissyandé, Jacques Klein, and Yves Le Traon

    Li Li, Tegawendé F. Bissyandé, Jacques Klein, and Yves Le Traon. An Investigation into the Use of Common Libraries in Android Apps. In2016 IEEE 23rd Inter- national Conference on Software Analysis, Evolution, and Reengineering (SANER), volume 1, pages 403–414, 2016

    2016

  35. [43]

    On identifying and explaining similari- ties in android apps.Journal of Computer Science and Technology, 34(2):437–455, 2019

    Li Li, Tegawendé F Bissyandé, Hao-Yu Wang, and Jacques Klein. On identifying and explaining similari- ties in android apps.Journal of Computer Science and Technology, 34(2):437–455, 2019

    2019

  36. [44]

    Revisiting the impact of common libraries for android-related investi- gations.Journal of Systems and Software, 154:157–175, 2019

    Li Li, Timothée Riom, Tegawendé F Bissyandé, Haoyu Wang, Jacques Klein, and Le Traon Yves. Revisiting the impact of common libraries for android-related investi- gations.Journal of Systems and Software, 154:157–175, 2019

    2019

  37. [45]

    Large-scale third-party library detection in android mar- kets.IEEE Transactions on Software Engineering, 46(9):981–1003, 2018

    Menghao Li, Pei Wang, Wei Wang, Shuai Wang, Ding- hao Wu, Jian Liu, Rui Xue, Wei Huo, and Wei Zou. Large-scale third-party library detection in android mar- kets.IEEE Transactions on Software Engineering, 46(9):981–1003, 2018

    2018

  38. [46]

    LibD: Scal- able and Precise Third-Party Library Detection in An- droid Markets

    Menghao Li, Wei Wang, Pei Wang, Shuai Wang, Ding- hao Wu, Jian Liu, Rui Xue, and Wei Huo. LibD: Scal- able and Precise Third-Party Library Detection in An- droid Markets. In2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE), pages 335– 346, 2017

    2017

  39. [47]

    Malwukong: To- wards fast, accurate, and multilingual detection of ma- licious code poisoning in oss supply chains

    Ningke Li, Shenao Wang, Mingxi Feng, Kailong Wang, Meizhen Wang, and Haoyu Wang. Malwukong: To- wards fast, accurate, and multilingual detection of ma- licious code poisoning in oss supply chains. In2023 38th IEEE/ACM International Conference on Automated Software Engineering ...

    1993

  40. [48]

    LibRadar: Fast and accurate detection of third-party libraries in Android apps

    Ziang Ma, Haoyu Wang, Yao Guo, and Xiangqun Chen. LibRadar: Fast and accurate detection of third-party libraries in Android apps. InProceedings of the 38th International Conference on Software Engineering Com- panion, ICSE ’16, pages 653–656, 2016

    2016

  41. [49]

    AdDetect: Automated detection of Android ad libraries using semantic analysis

    Annamalai Narayanan, Lihui Chen, and Chee Keong Chan. AdDetect: Automated detection of Android ad libraries using semantic analysis. In2014 IEEE Ninth International Conference on Intelligent Sensors, Sensor Networks and Information Processing (ISSNIP), pages 1–6, 2014

    2014

  42. [50]

    Squad: 100,000+ questions for machine comprehension of text.arXiv preprint arXiv:1606.05250, 2016

    Pranav Rajpurkar, Jian Zhang, Konstantin Lopyrev, and Percy Liang. Squad: 100,000+ questions for machine comprehension of text.arXiv preprint arXiv:1606.05250, 2016

    2016 arXiv

  43. [51]

    Bissyandé, and Jacques Klein

    Jordan Samhi, Tegawendé F. Bissyandé, and Jacques Klein. AndroLibZoo: A Reliable Dataset of Libraries Based on Software Dependency Analysis. In2024 IEEE/ACM 21st International Conference on Mining Software Repositories (MSR), pages 32–36, 2024

    2024

  44. [52]

    Towards a scalable resource-driven approach for detecting repackaged android applications

    Yuru Shao, Xiapu Luo, Chenxiong Qian, Pengfei Zhu, and Lei Zhang. Towards a scalable resource-driven approach for detecting repackaged android applications. InProceedings of the 30th Annual Computer Security Applications Conference, pages 56–65, 2014

    2014

  45. [53]

    Lib- Sift: Automated Detection of Third-Party Libraries in Android Applications

    Charlie Soh, Hee Beng Kuan Tan, Yauhen Leanidavich Arnatovich, Annamalai Narayanan, and Lipo Wang. Lib- Sift: Automated Detection of Third-Party Libraries in Android Applications. In2016 23rd Asia-Pacific Soft- ware Engineering Conference (APSEC), pages 41–48, 2016

    2016

  46. [54]

    LibDX: A Cross-Platform and Accurate System to De- tect Third-Party Libraries in Binary Code

    Wei Tang, Ping Luo, Jialiang Fu, and Dan Zhang. LibDX: A Cross-Platform and Accurate System to De- tect Third-Party Libraries in Binary Code. In2020 IEEE 27th International Conference on Software Analy- sis, Evolution and Reengineering (SANER), pages 104– 115, 2020

    2020

  47. [55]

    Securing android applications via edge assistant third-party library detection.Computers & Security, 80:257–272, 2019

    Zhushou Tang, Minhui Xue, Guozhu Meng, Chengguo Ying, Yugeng Liu, Jianan He, Haojin Zhu, and Yang Liu. Securing android applications via edge assistant third-party library detection.Computers & Security, 80:257–272, 2019

    2019

  48. [56]

    Qwen2 technical report.arXiv preprint arXiv:2407.10671, 2024

    Qwen Team. Qwen2 technical report.arXiv preprint arXiv:2407.10671, 2024

    2024 arXiv

  49. [57]

    Comex: Deeply observing application behavior on real android devices

    Zeya Umayya, Dhruv Malik, Arpit Nandi, Akshat Ku- mar, Sareena Karapoola, and Sambuddho Chakravarty. Comex: Deeply observing application behavior on real android devices. InProceedings of the 17th Cyber Secu- rity Experimentation and Test Workshop, pages 100–109, 2024

    2024

  50. [58]

    WuKong: A scalable and accurate two-phase approach to Android app clone detection

    Haoyu Wang, Yao Guo, Ziang Ma, and Xiangqun Chen. WuKong: A scalable and accurate two-phase approach to Android app clone detection. InProceedings of the 2015 International Symposium on Software Testing and Analysis, ISSTA 2015, pages 71–82, 2015

    2015

  51. [59]

    Understanding the evolution of mobile app ecosystems: A longitudinal measurement study of google play

    Haoyu Wang, Hao Li, and Yao Guo. Understanding the evolution of mobile app ecosystems: A longitudinal measurement study of google play. InThe World Wide Web Conference, pages 1988–1999, 2019. 16

    1988

  52. [60]

    Beyond google play: A large-scale com- parative study of chinese android app markets

    Haoyu Wang, Zhe Liu, Jingyue Liang, Narseo Vallina- Rodriguez, Yao Guo, Li Li, Juan Tapiador, Jingcun Cao, and Guoai Xu. Beyond google play: A large-scale com- parative study of chinese android app markets. InPro- ceedings of the Internet Measurement Conference 2018, pages 293...

    2018

  53. [61]

    ORLIS: Obfuscation-resilient library detec- tion for Android

    Yan Wang, Haowei Wu, Hailong Zhang, and Atanas Rountev. ORLIS: Obfuscation-resilient library detec- tion for Android. InProceedings of the 5th International Conference on Mobile Software Engineering and Sys- tems, MOBILESoft ’18, pages 13–23, 2018

    2018

  54. [62]

    Fengguo Wei, Sankardas Roy, Xinming Ou, and Robby. Amandroid: A precise and general inter-component data flow analysis framework for security vetting of an- droid apps.ACM Transactions on Privacy and Security (TOPS), 21(3):1–32, 2018

    2018

  55. [63]

    Advantages of the mean absolute error (mae) over the root mean square error (rmse) in assessing average model performance

    Cort J Willmott and Kenji Matsuura. Advantages of the mean absolute error (mae) over the root mean square error (rmse) in assessing average model performance. Climate research, 30(1):79–82, 2005

    2005

  56. [64]

    Identifying affected libraries and their ecosystems for open source software vulnerabil- ities

    Susheng Wu, Wenyan Song, Kaifeng Huang, Bihuan Chen, and Xin Peng. Identifying affected libraries and their ecosystems for open source software vulnerabil- ities. InProceedings of the IEEE/ACM 46th Interna- tional Conference on Software Engineering, pages 1–12, 2024

    2024

  57. [65]

    Libscan: Towards more precise third-party library identification for android applications

    Yafei Wu, Cong Sun, Dongrui Zeng, Gang Tan, Siqi Ma, and Peicheng Wang. Libscan: Towards more precise third-party library identification for android applications. In32nd USENIX Security Symposium (USENIX Security 23), pages 3385–3402, 2023

    2023

  58. [66]

    Malscan: Fast market-wide mobile malware scanning by social-network centrality analysis

    Yueming Wu, Xiaodi Li, Deqing Zou, Wei Yang, Xin Zhang, and Hai Jin. Malscan: Fast market-wide mobile malware scanning by social-network centrality analysis. In2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE), pages 139–150. IEEE, 2019

    2019

  59. [67]

    Precise and Efficient Patch Presence Test for Android Applica- tions against Code Obfuscation

    Zifan Xie, Ming Wen, Haoxiang Jia, Xiaochen Guo, Xiaotong Huang, Deqing Zou, and Hai Jin. Precise and Efficient Patch Presence Test for Android Applica- tions against Code Obfuscation. InProceedings of the 32nd ACM SIGSOFT International Symposium on Soft- ware Testing and Anal...

    2023

  60. [68]

    Zifan Xie, Ming Wen, Tinghan Li, Yiding Zhu, Qin- sheng Hou, and Hai Jin. How Does Code Optimization Impact Third-party Library Detection for Android Appli- cations? InProceedings of the 39th IEEE/ACM Interna- tional Conference on Automated Software Engineering, ASE ’24, pages...

    1919

  61. [69]

    LibRoad: Rapid, Online, and Accurate Detection of TPLs on Android.IEEE Transactions on Mobile Computing, pages 1–1, 2020

    Jian Xu and Qianting Yuan. LibRoad: Rapid, Online, and Accurate Detection of TPLs on Android.IEEE Transactions on Mobile Computing, pages 1–1, 2020

    2020

  62. [70]

    LibPass: Third-party Library Detection Method Based on Package Structure and Signature.Journal of Software, 35(6):2880–2902, 2023

    Jian XU and QianTing YUAN. LibPass: Third-party Library Detection Method Based on Package Structure and Signature.Journal of Software, 35(6):2880–2902, 2023

    2023

  63. [71]

    Enhancing se- curity in third-party library reuse–comprehensive detec- tion of 1-day vulnerability through code patch analysis

    Shangzhi Xu, Jialiang Dong, Weiting Cai, Juanru Li, Arash Shaghaghi, Nan Sun, and Siqi Ma. Enhancing se- curity in third-party library reuse–comprehensive detec- tion of 1-day vulnerability through code patch analysis. arXiv preprint arXiv:2411.19648, 2024

    2024 arXiv

  64. [72]

    Neural network-based graph embed- ding for cross-platform binary code similarity detection

    Xiaojun Xu, Chang Liu, Qian Feng, Heng Yin, Le Song, and Dawn Song. Neural network-based graph embed- ding for cross-platform binary code similarity detection. InProceedings of the 2017 ACM SIGSAC conference on computer and communications security, pages 363–376, 2017

    2017

  65. [73]

    Order matters: Semantic-aware neural networks for binary code similarity detection

    Zeping Yu, Rui Cao, Qiyi Tang, Sen Nie, Junzhou Huang, and Shi Wu. Order matters: Semantic-aware neural networks for binary code similarity detection. In Proceedings of the AAAI conference on artificial intelli- gence, volume 34, pages 1145–1152, 2020

    2020

  66. [74]

    ATVHunter: Reliable Version Detection of Third-Party Libraries for Vulner- ability Identification in Android Applications

    Xian Zhan, Lingling Fan, Sen Chen, Feng We, Tianming Liu, Xiapu Luo, and Yang Liu. ATVHunter: Reliable Version Detection of Third-Party Libraries for Vulner- ability Identification in Android Applications. In2021 IEEE/ACM 43rd International Conference on Software Engineering (...

    2021

  67. [75]

    A comparative study of android repackaged apps detection techniques

    Xian Zhan, Tao Zhang, and Yutian Tang. A comparative study of android repackaged apps detection techniques. In2019 IEEE 26th International Conference on Soft- ware Analysis, Evolution and Reengineering (SANER), pages 321–331. IEEE, 2019

    2019

  68. [76]

    Re-checking app behavior against app description in the context of third-party libraries

    Chengpeng Zhang, Haoyu Wang, Ran Wang, Yao Guo, and Guoai Xu. Re-checking app behavior against app description in the context of third-party libraries. In SEKE, pages 665–664, 2018

    2018

  69. [77]

    Beresford, and Stephan A

    Jiexin Zhang, Alastair R. Beresford, and Stephan A. Kollmann. LibID: Reliable identification of obfuscated third-party Android libraries. InProceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA 2019, pages 55–65, 2019

    2019

  70. [78]

    Detecting third-party libraries in Android applications with high precision and recall

    Yuan Zhang, Jiarun Dai, Xiaohan Zhang, Sirong Huang, Zhemin Yang, Min Yang, and Hao Chen. Detecting third-party libraries in Android applications with high precision and recall. In2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengi- neering (SANE...

    2018

  71. [79]

    An empirical study of potentially malicious third-party libraries in Android apps

    Zicheng Zhang, Wenrui Diao, Chengyu Hu, Shanqing Guo, Chaoshun Zuo, and Li Li. An empirical study of potentially malicious third-party libraries in Android apps. InProceedings of the 13th ACM Conference on Security and Privacy in Wireless and Mobile Networks, WiSec ’20, pages ...

    2020

  72. [80]

    Software Composition Analysis for Vulnerability Detection: An Empirical Study on Java Projects

    Lida Zhao, Sen Chen, Zhengzi Xu, Chengwei Liu, Lyuye Zhang, Jiahui Wu, Jun Sun, and Yang Liu. Software Composition Analysis for Vulnerability Detection: An Empirical Study on Java Projects. InProceedings of the 31st ACM Joint European Software Engineering Con- ference and Symp...

    2023

  73. [81]

    Fsquadra: Fast detection of repackaged applications

    Yury Zhauniarovich, Olga Gadyatskaya, Bruno Crispo, Francesco La Spina, and Ermanno Moser. Fsquadra: Fast detection of repackaged applications. InIFIP An- nual Conference on Data and Applications Security and Privacy, pages 130–145. Springer, 2014

    2014

  74. [82]

    Towards robust detection of open source software supply chain poisoning attacks in industry envi- ronments

    Xinyi Zheng, Chen Wei, Shenao Wang, Yanjie Zhao, Peiming Gao, Yuanchao Zhang, Kailong Wang, and Haoyu Wang. Towards robust detection of open source software supply chain poisoning attacks in industry envi- ronments. InProceedings of the 39th IEEE/ACM inter- national conference...

    1990

  75. [83]

    Uncovering cross-context incon- sistent access control enforcement in android

    Hao Zhou, Haoyu Wang, Xiapu Luo, Ting Chen, Yajin Zhou, and Ting Wang. Uncovering cross-context incon- sistent access control enforcement in android. InThe 2022 Network and Distributed System Security Sympo- sium (NDSS’22), 2022

    2022

  76. [84]

    GMS” and “FOSS/Floss

    Jiawei Zhou, Zidong Zhang, Lingyun Ying, Huajun Chai, Jiuxin Cao, and Haixin Duan. Hey, your secrets leaked! detecting and characterizing secret leakage in the wild. In2025 IEEE Symposium on Security and Privacy (SP), pages 449–467. IEEE, 2025. A Reasons for Multiple APKs in a...

    2025

  77. [2025]

    cn/topic/performance/app-optimization/ enable-app-optimization

    https://developer.android.google. cn/topic/performance/app-optimization/ enable-app-optimization

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.