Pith. sign in

REVIEW 2 major objections 6 minor 8 references

A public dataset of 99,722 Android apps linked to 246 tracking SDKs and their providers, built by static signature matching of APKs.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · grok-4.5

2026-07-12 08:23 UTC pith:SQ37RGCQ

load-bearing objection Solid, usable Data Descriptor: large open app–SDK–provider graph with a real pipeline; static-detection limits are real but already flagged and do not sink the claim. the 2 major comments →

arxiv 2607.02627 v1 pith:SQ37RGCQ submitted 2026-07-02 cs.SE cs.SI

A large-scale dataset of Android applications and their SDK dependencies

Aurora Gori Savellini , Tiziano Squartini , Massimo Riccaboni This is my paper
classification cs.SE cs.SI
keywords Android appsthird-party SDKstracking librariesstatic analysisapp-SDK bipartite networkprovider concentrationprivacy infrastructureopen dataset
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

Most Android apps do not build every feature themselves. They embed third-party software kits for ads, analytics, login, crash reports, and location. Those kits sit inside the app binary, inherit its permissions, and can feed data back to a small set of upstream companies. This paper releases a large open resource that makes those hidden links visible at scale. It pairs hundreds of thousands of app packages with detection rules for tracking SDKs, matches namespaces inside the compiled code, and then maps each SDK to the firm that controls it. The result is both a ready-to-use table of app-version observations and the scripts needed to rebuild bipartite app-SDK networks and firm-level projections. A sympathetic reader cares because the mobile economy’s data and software dependencies have been hard to measure without proprietary scanners; this release turns that layer into a public, reproducible research object.

Core claim

A fully scripted static-analysis pipeline that samples Google Play APKs, extracts Dalvik namespaces, matches them against open tracker rules, and maps detected SDKs to companies yields a released corpus of 334,719 unique app-version observations (99,722 packages), 246 observed tracking SDKs, 197 providers, and more than 845,000 app-SDK relationships, complete with app and SDK metadata that support bipartite and projected network analysis of technological concentration.

What carries the argument

The bipartite app-SDK edge list (and its provider-mapped counterpart) obtained by namespace-prefix and regular-expression matching of APK bytecode against a public tracker rule base, then aggregated into one-mode projections on apps, SDKs, and firms.

Load-bearing premise

That matching namespace prefixes and regexes inside APK bytecode against a fixed public tracker list is complete enough for ecosystem statistics, even when code is obfuscated, loaded at runtime, or present but inactive.

What would settle it

A large, independently labeled sample of the same APKs in which dynamic or de-obfuscated inspection finds systematically different presence or co-occurrence rates for the top trackers and providers than the static pipeline reports.

Watch this falsifier — get emailed when new claim-graph text bears on it.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

2 major / 6 minor

Summary. This Data Descriptor presents a large-scale open dataset linking Google Play Android apps to embedded third-party tracking SDKs. The authors combine AndroZoo APKs/metadata with Exodus Privacy detection rules in a fully scripted static-analysis pipeline (namespace-prefix and regex matching on DEX bytecode), then map SDKs to operating companies. The released resource covers 334,719 unique app-version observations (99,722 packages), 246 empirically observed SDKs, 197 provider entities, and hundreds of thousands of app–SDK relationships, plus app- and SDK-level metadata. The data support bipartite app–SDK and app–provider networks and their one-mode projections, with public code (GitHub) and frozen data (Zenodo).

Significance. Open, large-scale app–SDK–provider linkage remains scarce relative to proprietary mobile-intelligence products. The contribution is a reusable research infrastructure rather than a novel theoretical result: a reproducible pipeline, a frozen multi-version sample, a carefully documented canonical provider mapping, and ready-to-use network edge lists. Strengths that raise the value of the resource include near-complete processing success (99.998%), 100% metadata merge and provider-mapping coverage after validation, zero internal SDK-count inconsistencies, external prevalence checks against Exodus (Pearson 0.874, substantial top-20 overlap), and full public release of scripts and data (subject to AndroZoo APK redistribution limits). If the static-detection caveats are kept in view, the dataset can support concentration, co-occurrence, privacy-infrastructure, and longitudinal dependency studies that are otherwise hard to reproduce.

major comments (2)
  1. Methods, “SDK detection rules” / “Limitations of static SDK detection”: the central usability claim for prevalence, co-occurrence, and concentration analyses rests on static namespace/regex matching against Exodus without de-obfuscation, dynamic loading analysis, or runtime confirmation. The manuscript already flags false negatives (obfuscation/dynamic load) and false positives (inactive code). For a Data Descriptor this is acceptable only if the abstract, Data Records, and network-statistics sections more explicitly frame all reported degrees, densities, and provider concentration figures as upper/lower bounds on observable code presence rather than realized tracking. A short quantitative sensitivity note (e.g., the LiteRadar provider-level overlap already mentioned in a footnote, or a stratified check on heavily obfuscated packages) would make the load-bearing assumption falsifiable ra
  2. Data Records / Table 6–7 and network construction: package-level aggregation (union of SDKs across versions of the same app) is used for the headline bipartite and projection statistics, while the raw resource preserves multi-version observations. The manuscript should state more clearly which analyses use the union, which use latest-version only, and how multi-version edges are collapsed when computing the 214,421 app–SDK relationships versus the 845,010 app-version–SDK edges. Without that, users can easily mis-specify longitudinal versus cross-sectional concentration measures.
minor comments (6)
  1. Abstract vs. body: abstract reports 334,719 unique app-version observations; Background & Technical Validation also cite 334,711 successfully processed APKs and occasional 334,711/99,722 figures. Align the headline counts and define “observation” vs. “successfully processed APK” once in Data Records.
  2. Table 1 / dex_date: placeholder 1980/1981 dates are correctly flagged; a one-line recommendation on how users should filter temporal snapshots would reduce misuse of Figure 2.
  3. Table 7: assortativity and clustering for bipartite vs. one-mode projections are reported without stating whether they are computed on weighted or unweighted graphs; a short note would help reproducibility.
  4. Provider mapping (Table 3–4): ownership is frozen at October 2025. Explicitly label company_canonical as time-stamped and point users to the audit CSV for re-mapping after future acquisitions.
  5. Sample representativeness (Tables 9–11): free-app over-representation is well explained by the tracking focus; still, state in the abstract or Data Records that the resource is not a monetization-stratified sample of Google Play.
  6. Minor consistency: “334,719” vs. earlier “334,711” and “845,000” vs. “845,010” appear in different sections; pick one rounding convention for the abstract.

Circularity Check

0 steps flagged

No circularity: empirical data-descriptor construction and external validation, not a derivation that reduces to its inputs.

full rationale

The paper is a Data Descriptor whose central claims are the existence, scale, and usability of a released app–SDK–provider resource (334k app-version observations, 246 SDKs, provider mapping, bipartite/projected networks) produced by a scripted static-analysis pipeline. There is no theoretical derivation, uniqueness theorem, fitted parameter renamed as prediction, or self-definitional loop. Reported counts and coverage figures are direct outputs of APK processing against the independent Exodus Privacy rule base plus AndroZoo metadata; technical validation compares prevalence and category distributions to external sources (Exodus reports, 42matters) rather than re-deriving the same quantities from the same sample. Standard network definitions (biadjacency matrix, projections U=BBᵀ, V=BᵀB) are applied after the data exist and do not force the empirical results. Minor self-references to the authors’ own pipeline scripts are ordinary reproducibility infrastructure, not load-bearing premises. The weakest assumption (static namespace matching) is an acknowledged measurement limitation, not circularity. The work is therefore self-contained against its external benchmarks.

Axiom & Free-Parameter Ledger

2 free parameters · 4 axioms · 2 invented entities

As a data-release paper the load-bearing commitments are methodological rather than theoretical: reliance on AndroZoo’s Google Play slice, Exodus static signatures, random sampling without stratification, package-level aggregation for networks, and a hybrid automated/manual ownership map frozen at October 2025. No free parameters are fitted to produce a scientific constant; the invented entities are the released dataset and the canonical provider labels themselves.

free parameters (2)
  • target sample size (~100k apps) = ~100000 packages
    Pipeline designed to target approximately 100,000 packages while retaining all available versions; the exact target is a design choice that determines final scale.
  • fixed random seed for APK sampling = fixed (unspecified numeric value)
    Seed chosen for reproducibility of the random draw from AndroZoo Google Play APKs; different seeds would yield different samples.
axioms (4)
  • domain assumption Static namespace-prefix and regex matching against Exodus Privacy rules is a valid proxy for the presence of tracking SDKs in an APK.
    Stated in Methods (SDK detection) and Limitations; no runtime confirmation is performed.
  • domain assumption Restricting to AndroZoo packages whose markets field contains play.google.com yields a sufficiently representative slice of the Android ecosystem for the intended analyses.
    Methods, Sampling Google Play apps; alternative marketplaces are excluded by design.
  • ad hoc to paper Provider ownership can be canonicalized to a single company label at the time of mapping (Oct 2025), collapsing acquisitions and aliases.
    SDK-provider mapping section; ownership is frozen at mapping time and may lag future corporate changes.
  • ad hoc to paper Package-level aggregation (union of SDKs across versions of the same app) is an appropriate default for the reported network statistics.
    Construction of the app-SDK networks; version-level graphs are possible but not the default reported tables.
invented entities (2)
  • Canonical SDK–provider mapping table (company_canonical) independent evidence
    purpose: Collapse raw Exodus tracker labels and aliases into firm-level nodes for concentration and provider-provider network analysis.
    Hybrid scrape + manual validation produces 338 canonical providers from 431 raw labels; independent of any single prior public table at this coverage.
  • Released app-version / app-SDK / app-provider edge lists and projected networks independent evidence
    purpose: Provide ready-to-use bipartite and one-mode graphs for downstream ecosystem studies.
    Primary data product of the paper; existence is verified by Zenodo DOI and GitHub pipeline.

pith-pipeline@v1.1.0-grok45 · 24731 in / 3115 out tokens · 27920 ms · 2026-07-12T08:23:49.172091+00:00 · methodology

0 comments
read the original abstract

Mobile applications (apps) increasingly rely on third-party Software Development Kits (SDKs) to provide services such as advertising, analytics, authentication, crash reporting, and location services. These components form an important, but often hidden, layer of the mobile ecosystem. Here, we present a large-scale dataset linking Android apps to the third-party SDKs they integrate. The dataset was constructed by combining app package files (APKs) and metadata from AndroZoo with SDK detection rules provided by Exodus Privacy. We implemented a reproducible, static-analysis pipeline that downloads APKs, inspects their compiled code, and detects SDKs through code-level signature matching: the released dataset contains 334,719 unique app-version observations (associated with 99,722 Android apps) and 246 third-party SDKs - including app-level metadata such as categories, comments, file size, download counts, ratings and SDK-level metadata such as categories, code roots, code versions, names. The dataset supports the construction of a large-scale app-SDK dependency network and its projection onto both layers; in addition, SDKs are mapped to their corresponding operating companies, enabling provider-level analysis of technological concentration and upstream control in the mobile ecosystem. To support reproducible research, the pipeline and dataset are publicly released on GitHub and Zenodo; more broadly, the project provides a reusable research infrastructure for studying third-party technological dependencies, data-collection capabilities, and privacy infrastructures across Android apps.

Figures

Figures reproduced from arXiv: 2607.02627 by Aurora Gori Savellini, Massimo Riccaboni, Tiziano Squartini.

Figure 1
Figure 1. Figure 1: Overview of the dataset construction pipeline. Starting from the AndroZoo catalog, we retain Android apps observed on Google Play and construct a reproducible sample of APKs and associated versions. APK files are downloaded via the AndroZoo API and processed with static analysis, including DEX extraction, namespace parsing, and matching against Exodus Privacy detection rules. Detected SDKs are normalized, … view at source ↗
Figure 2
Figure 2. Figure 2: Temporal distribution of APK observations. The yearly distribution of APK observations reflects the temporal composition of the underlying AndroZoo repository, from which APKs were randomly sampled: as a consequence, the peak around 2020 should be interpreted as a characteristic of the available APK on Androzoo rather than as a direct indication of Android ecosystem dynamics. In the present work, the Andro… view at source ↗
Figure 3
Figure 3. Figure 3: Overview of the tracker SDK detection workflow used to construct the app-SDK dataset. Android APKs are processed through static analysis of DEX bytecode, from which Dalvik/Java namespaces are extracted. Extracted namespaces are matched against publicly available Exodus Privacy detection rules based on namespace prefixes and regular-expression patterns. Matched signatures are mapped to SDK identifiers and a… view at source ↗
Figure 4
Figure 4. Figure 4: Illustrative tripartite provider-SDK-app dependency structure. Technology providers (left) develop and maintain SDKs (center), which are embedded into mobile apps (right). The app-SDK and app-provider networks released in this dataset can be interpreted as subsets of this underlying tripartite structure. The entities shown are illustrative examples and do not represent the complete dataset. biα = ( 1, if a… view at source ↗
Figure 5
Figure 5. Figure 5: Overview of the released data resources and their relationships. The SDK extraction outputs, metadata integration pipeline, and network construction procedures are generated through reproducible scripts made publicly available in the GitHub repository. These components are integrated to create the final app-level dataset, which is archived on Zenodo. Starting from the merged dataset, researchers can constr… view at source ↗
Figure 6
Figure 6. Figure 6: Community structure of the SDK-SDK (top) and provider-provider (bottom) projection network. Block-ordered adjacency matrices obtained using Louvain modularity maximization, Leiden modularity maximization, the Stochastic Block Model (SBM), and the degree-corrected Stochastic Block Model (dcSBM). Nodes are reordered according to the detected partition and red lines indicate community or block boundaries: the… view at source ↗
Figure 7
Figure 7. Figure 7: Distribution of the number of detected SDKs per APK. Left: histogram of the number of tracking SDKs detected within each APK. Most applications embed a relatively small number of third-party tracking SDKs, while a smaller subset contains substantially larger SDK stacks. Vertical dashed lines indicate the sample mean and median. Right: complementary cumulative distribution function (CCDF) of the same distri… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

8 extracted references · 2 canonical work pages · 1 internal anchor

  1. [1]

    Proceedings of the 21st International Conference on Mining Software Repositories , pages=

    AndroZoo: A Retrospective with a Glimpse into the Future , author=. Proceedings of the 21st International Conference on Mining Software Repositories , pages=

  2. [2]

    AndroZoo: Collecting Millions of Android Apps for the Research Community , booktitle =

    Allix, Kevin and Bissyand. AndroZoo: Collecting Millions of Android Apps for the Research Community , booktitle =. 2016 , isbn =. doi:10.1145/2901739.2903508 , acmid =

    doi:10.1145/2901739.2903508 2016

  3. [3]

    Don’t Accept Candies from Strangers: An Analysis of Third-Party SDKs , institution =

    Feal,. Don’t Accept Candies from Strangers: An Analysis of Third-Party SDKs , institution =

  4. [4]

    Super SDKs: Tracking Personal Data and Platform Monopolies in the Mobile Ecosystem , journal =

    Pybus, Jennifer and C. Super SDKs: Tracking Personal Data and Platform Monopolies in the Mobile Ecosystem , journal =. 2024 , doi =

    2024

  5. [5]

    2017 , eprint=

    AndroZoo++: Collecting Millions of Android Apps and Their Metadata for the Research Community , author=. 2017 , eprint=

    2017

  6. [6]

    2025 , month = dec, date =

    Marzi, Mattia , title =. 2025 , month = dec, date =

    2025

  7. [7]

    arXiv preprint arXiv:2601.10224 , year =

    Emer, Lorenzo and Gallo, Anna and Marzi, Mattia and Mina, Andrea and Squartini, Tiziano and Vandin, Andrea , title =. arXiv preprint arXiv:2601.10224 , year =. doi:10.48550/arXiv.2601.10224 , url =

    work page internal anchor Pith review doi:10.48550/arxiv.2601.10224

  8. [8]

    New Journal of Physics , abstract =

    Saracco, Fabio and Straka, Mika J and Clemente, Riccardo Di and Gabrielli, Andrea and Caldarelli, Guido and Squartini, Tiziano , title =. New Journal of Physics , abstract =. 2017 , month =. doi:10.1088/1367-2630/aa6b38 , url =

    work page doi:10.1088/1367-2630/aa6b38 2017