F-Droid build servers can't build modern Android apps due to outdated CPUs

Hacker News Discussion ↗

Root cause & impact on apps

  • Google’s newer Android Gradle Plugin (AGP 8.12.0) ships an aapt2 binary compiled for SSE4.1/SSSE3 (x86_64-v2).
  • F-Droid’s build farm CPUs (older AMD Opterons) lack these instructions, so builds for many apps now fail.
  • Devs are forced to pin older AGP versions, ship multiple “maintenance” releases, or disable baseline profiles, which breaks F-Droid’s reproducibility rules and confuses users.
  • A similar SSSE3 issue existed in 2021 and was fixed upstream; some commenters initially misread that old fix as applying here, but this new problem is not resolved.

F-Droid infrastructure, culture, and governance

  • Multiple comments describe a long‑running pattern: understaffed, ambitious goals (full reproducible builds), and a resistant core maintainer leading to burnout and slow change.
  • F-Droid is said to be slow to publish updates and inflexible about any deviation from their strict build model.
  • Some see this as a typical “bus-factor-1 FOSS project” dynamic, not unique to F-Droid.

Why are the servers so old?

  • Servers appear to be ~2007–2011 era Opterons lacking full SSE4; age alone surprises many.
  • Some speculate they were chosen for open firmware (coreboot/libreboot, no Intel ME/AMD PSP) and physical trust, not performance.
  • Others argue that at this age, power consumption and fragility likely outweigh benefits; cheap used hardware or even laptops would be faster and cheaper to run.
  • F-Droid reportedly has budget for new hardware but lacks a trusted hoster/sysadmin to install and maintain a high‑security, physically trusted build box.

Who is at fault: Google or F-Droid?

  • One camp blames Google/Gradle for silently raising CPU requirements in a minor version, violating expectations of semantic versioning and broad compatibility.
  • Another camp argues it’s reasonable in 2025 to target SSE4.1, and that keeping 15–20‑year‑old hardware in production is effectively “unmaintained infrastructure.”
  • Some see no malicious intent, just defaults in compilers/toolchains drifting to newer baselines.

Alternatives and technical workarounds

  • Suggested mitigations:
    • Rebuild aapt2 and related tools from source with older CPU targets (not trivial in the Android ecosystem).
    • Use QEMU or VM profiles that expose newer instruction sets.
    • Add runtime CPU feature detection and multi‑versioned binaries (as Debian/glibc do) rather than hard baselines.
  • IzzyOnDroid is cited as an alternative repo that distributes upstream APKs and decouples publishing from reproducible verification, so it’s unaffected.

Broader concerns about FOSS and app stores

  • Commenters worry that crucial counterweights to Big Tech (like F-Droid) depend on tiny, underfunded volunteer teams.
  • Some call for public/EU funding and more institutional support; others emphasize that donations alone are fragile and should be invested for long‑term resilience.