Field Notes

source

Understanding Build Reproducibility in the F-Droid Ecosystem

StatusStableUpdatedStands on3 sourcesSupportsnotes

This is a peer-reviewed empirical study of build reproducibility across F-Droid’s repository, presented at ACM REP ‘26 in Delft in July 2026 and released as an arXiv preprint on 2 July 2026. A saved copy is preserved here. The authors are Denise Nanni, Julien Malka, Stefano Zacchiroli, and Theo Zimmermann of Telecom Paris, with Gabriele D’Angelo of the University of Bologna. Zacchiroli and Malka work on reproducibility and software preservation across Debian, Nix, and Software Heritage, and the paper reads as an extension of that programme to the Android ecosystem.

What it studies

The paper separates two questions the word “reproducible” usually blurs:

  • Reproducibility over time — whether the share of reproducible apps rises as new app versions are published.
  • Reproducibility in time — whether a fixed app version that F-Droid once confirmed reproducible can still be rebuilt and still yields a bitwise-identical artifact today.

The second is what a reader who wants to audit an old binary depends on, and the paper claims to be the first study to measure it for a distribution’s own historical output.

The authors merged F-Droid’s catalog with its verification-server logs, crawled on 17 February 2026, reaching 80,139 package versions after deduplication. They then attempted to rebuild the 18,904 versions published between September 2018 and February 2026 that F-Droid had previously recorded as bitwise reproducible, using a modified build pipeline that selects the Debian base image matching each version’s publication date so that legacy APK builds get a period-appropriate JDK.

What it found

Rebuilding succeeded for 15,831 of 18,904 versions, an 83.7% rate. Failures were overwhelmingly environmental rather than internal: missing dependencies caused around 76% of them, and source code that could no longer be retrieved at all caused around 10%.

Among the versions that did rebuild, 94% were still bitwise reproducible. That split is the paper’s central result. Build non-determinism, the problem reproducible-builds work usually targets, is largely solved in F-Droid’s corpus; what decays is the ability to reconstruct a build at all. The authors put the consequence plainly:

Looking back five years, the number of “reproducible” apps that can still be tested has been halved.

Classifying apps by the stability of their reproducibility status, 66% never changed state, 18.5% had past problems but are currently reproducible, 3.5% regressed and are currently broken, and about 11% oscillated repeatedly. The trend across new versions is positive, which is the “over time” finding, and it coexists with the decay finding rather than contradicting it.

For contrast the authors cite Nix, where rebuildability stays above 99% even for packages several years old, and attribute the gap to Android’s dependency model rather than to anything peculiar to F-Droid’s diligence.

What it is evidence for

The study grounds a limitation on Source-to-binary correspondence that the vault previously stated only from F-Droid’s own commentary: correspondence is established at publication time and its re-checkability erodes afterwards.

It also bears directly on who can perform the check. The paper notes that post-publication verification yields strong additional guarantees only when the verification server is operated by an entity other than the one that built the app, records that independent instances are an official F-Droid goal that has not yet been deployed, and warns that environmental drift may undermine third-party verification servers when they do arrive.

Its recommendations follow from the failure causes: archive source code together with all transitive dependencies in a long-term repository such as Software Heritage, retrieve from that archive when the original host drops the artifact, and pin the exact dependencies and VM images a build used rather than inferring them later.

Limitations

The rebuild environment was reconstructed on a best-effort basis. The authors inferred each version’s Debian base image from its publication date rather than from a recorded build environment, because F-Droid does not systematically record one, and they acknowledge that better heuristics would raise both rates. That cuts in a specific direction: 83.7% is a floor for rebuildability, not a point estimate, and some failures are artifacts of the reconstruction. The finding it supports — that F-Droid’s build specification is too imprecise to prevent temporal degradation — survives the caveat, because the imprecision is what forced the heuristic.

Failure causes were classified with hand-built regular expressions over build logs, without inter-rater agreement or an audit of a random sample, so the 76% dependency figure carries classification error. The study covers one ecosystem and does not claim its specific rates generalize. The authors also note that repeating the experiment later would likely produce worse results, which makes the numbers a dated snapshot by their own argument. A replication package is archived on Zenodo.

Built on 3 sources (3 external).

Working out connections…