deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

F-Droid 2.0 Ships Days Before Google Begins Enforcing Sideloading Verification

F-Droid 2.0 landed six days before Google starts requiring identity-verified developers for sideloaded installs in four countries, and the store's build-from-source signing model sits awkwardly with the new rules.

F-Droid 2.0 Ships Days Before Google Begins Enforcing Sideloading Verification

A rewritten client, timed awkwardly

F-Droid released version 2.0 of its Android client on September 24, 2026, six days before Google begins enforcing developer verification for sideloaded installs on September 30. According to a write-up on dev.to that draws on F-Droid's official announcement and reporting from Pinggy and Android Authority, the release reached the top of Hacker News with more than 1,000 points — though the timing rather than the interface is what turned heads.

The 2.0 client is a ground-up rewrite. The old Java codebase has been replaced with Kotlin and Jetpack Compose, with a Material-aligned interface organised around three tabs — Discover, Search and My Apps — while Settings and Nearby Swap moved to the top bar. Search now indexes descriptions, categories and translations, adds support for CJK scripts and remembers recent queries, and filters for category, device compatibility and anti-features can be combined. Auto-updates are enabled by default through Android's pre-approval install API.

The client now requires Android 7 or newer, dropping Android 6. The Open Technology Fund's Security Lab carried out an independent audit, the culmination of 14 test releases and more than a year of work. Tor support was simplified to a proxy setting, and the panic-triggered app wiping feature was removed as too costly to maintain. The rollout is gradual over the coming weeks.

Not everything landed well. Commenters on Hacker News flagged that bulk updates now require per-app clicks, which they consider a regression. The post also notes that alternative clients such as Droid-ify and NeoStore still consume the older, SHA1-signed index-v1 format, while F-Droid's infrastructure has moved to index-v2.

What the verification rules require

Google's policy, as summarised in the dev.to post, is that on certified Android devices only apps registered to an identity-verified developer can be installed — and that includes sideloaded APKs. Enforcement begins September 30 in Brazil, Indonesia, Singapore and Thailand, with global expansion planned for 2027.

Three compliance paths reportedly exist. Full distribution requires verifying your identity and registering a package name against APKs signed with your key. A limited-distribution route is email-based and capped at 20 devices, aimed at hobbyists and students. A promised advanced flow would let experienced users sideload unregistered apps under additional safeguards, but its details remain vague. ADB installs are explicitly exempt, and custom ROMs and users outside the four launch countries are unaffected for now.

The signing-key mismatch

The reason F-Droid sits uncomfortably with these rules is structural. Most stores distribute an APK the developer signed; F-Droid builds most of its catalog from source and signs the output with its own key. Forum estimates cited in the post put that arrangement at roughly 85% of apps. Since verification binds a package name to a developer's signing key, F-Droid's key does not match, and making it match would require a coordination mechanism between thousands of independent maintainers and the store that does not currently exist.

Reproducible builds are the clean escape hatch — they would let F-Droid ship the developer-signed artifact directly — but coverage across the catalog is only partial today.

What developers shipping on F-Droid should do

The post's practical advice for maintainers is to check whether each app builds reproducibly and push toward it, since that is the only route where the developer's own key ends up on the artifact. Anyone distributing in an affected region should register their package name with Google even if they never use the Play Store. Maintainers should also watch how the advanced-flow specification develops, because it determines whether power users can still install unregistered apps. Finally, keep your applicationId and signing configuration stable rather than changing them mid-transition.

Why it matters

F-Droid 2.0 is a solid engineering milestone — audited, modern and easier to use — but a better client does not resolve a distribution-model problem. If Google's verification expands globally as planned in 2027, every app F-Droid builds and signs itself becomes harder to install on certified devices unless reproducible-build coverage grows or a new coordination mechanism emerges. The September 30 rollout across four countries is the first real test of whether open, build-from-source distribution can coexist with an operating system that increasingly ties every APK to a verified identity. Independent developers who rely on F-Droid to reach users outside Play should treat the coming months as a transition window, not a distant policy debate.

  • #f-droid
  • #android
  • #sideloading
  • #app-distribution
  • #open-source

Related posts