F-Droid 2.0 Teardown: Jetpack Compose, Session APIs, and the Sideloading Crisis

On September 24, 2026, the F-Droid project released version 2.0—the client’s first foundational architectural rewrite in over a decade. Powered by Kotlin and Jetpack Compose, the update drops legacy Android 6 support, deprecates the decade-old F-Droid Privileged Extension (FPE), and migrates all unattended app updates to the AOSP PackageInstaller Session API. Yet this technical milestone arrives under an existential shadow: Google’s aggressive rollout of mandatory Android Developer Verification, designed to choke off third-party sideloading through cryptographic gatekeeping.

While everyday users celebrated modern Material Design parity and seamless background updates, systems architects and security researchers immediately focused on critical structural trade-offs: the loss of root-level installation automation with the deprecation of FPE, the unresolved friction between source-verified builds and rapid direct-from-GitHub updaters like Obtainium, and the precarious survival of open-source software on certified Android hardware.

The Legacy Burden: Why F-Droid 1.x Collapsed Under Technical Debt

To appreciate the scale of F-Droid 2.0, one must understand the architectural decay that plagued the 1.x branch. F-Droid’s original client architecture was conceived in the Android 2.3 (Gingerbread) and Android 4.0 (Ice Cream Sandwich) eras. The codebase was heavily encumbered by imperative Java, custom XML layout hierarchies, manual SQLite database queries running raw cursors on the main thread, and fragmented concurrency models spanning AsyncTask, IntentService, and manual thread dispatchers.

Every repository synchronization required fetching a monolithic index file, unpacking it via CPU-intensive Java streams, and locking local database tables. When users swiped pull-to-refresh across multiple large community repositories (such as the Guardian Project or IzzyOnDroid), intermediate database thrashing caused frequent socket timeouts, 502 gateway errors, and full interface freezes.

Beyond UI freezes, the legacy client suffered from three crippling structural deficits:

1. Repository Sync Thrashing: The pull-to-refresh gesture forced full client-server synchronizations regardless of whether package metadata had actually changed. Users conditioned by standard mobile UX routinely triggered redundant index downloads, generating massive egress bandwidth bills for volunteer-operated mirrors.
2. Fragmented Client Variants: The maintainers were forced to support two bifurcated codebases—the standard F-Droid client and “F-Droid Basic” (a stripped-down variant targeting modern background updates without privileged installation hooks). This doubled the testing matrix and slowed release velocity.
3. Obsolete OS Compatibility Shims: Preserving backward compatibility down to Android 6 (API 23) forced the team to carry legacy networking stacks, unmaintained TLS shims, and outdated permission check fallbacks that modern Android toolchains actively penalized.

F-Droid 2.0 eliminates this accumulation of legacy technical debt. Funded by NLnet through the Mobifree fund, the Open Technology Fund’s UXD and Sustainability Funds, and the Calyx Institute, the application was re-engineered from the ground up using Kotlin Coroutines, Flow, Jetpack Compose Material 3, and Room ORM. Support for Android 6 was permanently retired, setting the minimum operational baseline to Android 7.0 (API 24).

Architectural Mechanics: The AOSP PackageInstaller Session Engine

The defining engineering shift in F-Droid 2.0 is the complete transition from custom elevated installer daemons to the native Android Open Source Project (AOSP) Session Installer API.

For nearly a decade, achieving silent, unattended app installations on Android required one of two invasive mechanisms: either rooting the device and running shell commands through su, or flashing the F-Droid Privileged Extension (FPE) directly into the /system/priv-app/ partition. FPE allowed the client to invoke the hidden INSTALL_PACKAGES permission over an AIDL IPC interface. Both methods introduced severe friction, broke over-the-air system updates on locked bootloaders, and created elevated system attack surfaces.

Beginning in Android 12 (API 31) and further refined in Android 14 (API 34) under regulatory pressure from the European Union’s Digital Markets Act (DMA), Google introduced native APIs allowing alternative app stores to perform unattended updates without interactive confirmation prompts on every single package.

F-Droid 2.0 unifies all installation logic onto this standardized OS-level pipeline through a four-stage execution lifecycle:

1. Session Parameter Initialization: The client creates an install session using PackageInstaller.SessionParams.MODE_FULL_INSTALL, declaring the targeted package name and marking the install reason as user-initiated. Critically, it sets setRequireUserAction(USER_ACTION_NOT_REQUIRED), instructing the framework to bypass interactive installation modals.
2. Update Ownership Assertion: On Android 14 and newer, the client invokes setRequestUpdateOwnership(true). This locks the application’s update channel to F-Droid, preventing malicious secondary app markets or unauthorized sideloaders from silently replacing installed packages.
3. Sandboxed Byte Streaming: The client streams the verified APK bytes directly into the OS framework’s package buffer using an unbuffered file descriptor, synchronizing data integrity with an explicit fsync() call before closing the stream.
4. Asynchronous Broadcast Commit: The session is committed alongside a mutable PendingIntent status receiver. The framework validates package signatures, ensures no dangerous runtime permissions were added, installs the update silently in the background, and dispatches a broadcast confirming completion.

The Steiner Conundrum: Is FPE Truly Dead?

The removal of FPE sparked immediate debate across the Android modding and privacy community. Several maintainers and power users on custom ROMs (such as LineageOS and older CalyxOS builds) raised concerns over the loss of root-level background installation for newly added packages.

Hans-Christoph Steiner, lead maintainer of F-Droid, addressed the architectural trade-off directly during community technical reviews: “When Google added the ‘session’ installer to AOSP, we thought it would replace F-Droid Privileged Extension (FPE). So we stopped development on it. The answer now is that the ‘session’ installer mostly replaces FPE, but not fully. So we’re exploring reviving development.”

The gap lies in initial installation bootstrapping. While the AOSP Session API allows silent updates of existing packages, installing a brand-new application for the very first time still mandates an explicit user confirmation dialog on non-rooted systems. For custom ROM developers who ship F-Droid as their primary system store and desire zero-click automated provisioning out of the box, standard session APIs impose unavoidable user friction. As a result, discussions to revive FPE as an optional bridge for specialized ROM builds remain active under GitLab issue #100.

Cryptographic Integrity: Index-v2 vs. The Obtainium Direct-Fetch Model

A recurring debate surrounding F-Droid 2.0 is the rise of Obtainium—a lightweight client that bypasses centralized repositories altogether by scraping and downloading APK binaries directly from developer GitHub and GitLab release pages.

While Obtainium delivers zero-day updates the minute a developer tags a release, it completely inverts the security model that F-Droid has championed for 15 years. Grabbing binaries directly from developer repository releases links client integrity directly to developer credential security and unverified CI/CD release scripts. If a developer’s personal access token is compromised or their automated GitHub Actions runner is poisoned, users receive an immediate, Trojanized binary without any secondary verification layer. In contrast, F-Droid enforces clean-room source builds verified via independent reproducible build attestation.

Index-v2: Modernizing Repository Cryptography

F-Droid 2.0 fully consolidates operations onto Index-v2. Legacy Index-v1 relied on a monolithic JAR file containing an XML manifest signed with SHA-1 or legacy RSA digests. In contrast, Index-v2 decomposes repository metadata into modular JSON and CBOR streams:

• Canonical Entry Points: Signed using modern Ed25519 elliptic-curve cryptography via entry.jar.
• Differential Streaming: Clients fetch only compact JSON diffs for updated packages rather than redownloading multi-megabyte XML indices.
• Metadata Privacy: Third-party frontends frequently leaked package request patterns to upstream servers. The official F-Droid 2.0 core libraries use differential index chunking that prevents remote mirrors from correlating which specific applications a user searches or installs.

Source-Verified Cleanroom Builds vs. Precompiled Binaries

When an app is published to the official F-Droid repository, F-Droid does not accept an APK compiled on a developer’s laptop or an automated commercial CI runner. Instead, F-Droid’s build infrastructure enforces a four-tier cleanroom build cycle:

1. Upstream Commit Clones: The build server clones the upstream Git repository at the tagged release commit.
2. Anti-Feature Excision: The source tree is audited to ensure all proprietary SDKs, tracking libraries, and binary blobs are excised (flagging Anti-Features like tracking or non-free network dependencies).
3. Air-Gapped Container Compilation: The APK is compiled inside an isolated, air-gapped Docker container running a verified, auditable build recipe.
4. Reproducible Attestation: The output binary is signed with F-Droid’s master release key, or verified using diffoscope to confirm byte-for-byte identity with the upstream developer’s signed release.

Comparative Systems Evaluation

The following matrix contrasts the architectural, operational, and security parameters across Android application distribution systems:

Privacy Architecture: Tor Modernization and the Panic Mechanism

F-Droid has historically catered to high-risk threat models: journalists, political dissidents, and whistleblowers operating in hostile jurisdictions where possessing specific communication or encryption tools can result in physical detention. Version 2.0 significantly alters two foundational privacy components to align with modern threat environments.

In legacy versions, F-Droid included a dedicated “Use Tor” toggle with an automated detector that sought out local Orbot instances. Over the past five years, the Android network stack fundamentally changed. The rise of modern VPN-mode daemons (such as TorVPN, Orbot in full-device routing mode, and ProtonVPN) rendered app-level proxy bindings brittle and error-prone. In F-Droid 2.0, the toggle has been migrated into a standardized, generic Proxy Configuration engine supporting HTTP and SOCKS5 endpoints. The development team now officially recommends running Tor at the operating system layer via TorVPN or Orbot’s system-level VPN slot, while preserving manual proxy controls for advanced air-gapped network tunnels.

Similarly, the historical “panic” disguise system—which masked the client as a functional calculator app—has been restricted exclusively to cosmetic icon and label aliasing. The rationale represents a cold, realistic security assessment: modern digital forensics tools (such as Cellebrite and GrayKey) used by border guards and law enforcement inspect the device’s internal package database directly. A cosmetic calculator façade provides zero defense against forensic physical extraction. By stripping the interactive calculator illusion, F-Droid prevents users from developing a false sense of operational security.

The Existential Siege: Google’s Android Developer Verification Gatekeeping

While F-Droid 2.0 delivers the most robust client in the project’s history, the timing of its launch is marked by an urgent warning banner spanning the top of the official website: “F-Droid is under threat. Google is changing the way you install apps on your device. We need your help.”

Under the banner of fraud prevention, Google’s Android Developer Verification mandate requires all developers who distribute Android software to register government-issued identification documents and submit payment to Google—even if their applications are distributed entirely outside the Google Play Store via sideloading or independent repositories.

Google’s strategy to curtail sideloading does not rely on an outright binary ban (which would trigger immediate antitrust penalties under the EU DMA and US courts following Epic v. Google). Instead, Google is executing an incremental friction choke-point:

1. Psychological Gatekeeping via Play Protect: Unverified APKs trigger full-screen crimson warning banners declaring the application “high risk,” requiring users to navigate multi-step sub-menus and enter lock-screen credentials to proceed.
2. Artificial 24-Hour Cool-Down Timers: Under updated Google Play Protect security profiles, installing sideloaded packages that lack centralized Google developer attestation introduces artificial latency periods, conditioning mainstream users to believe alternative software is fundamentally hazardous.
3. The Play Integrity API Lockout: Banking institutions, media providers, and enterprise apps are increasingly enforcing hardware-backed Play Integrity checks. Devices running uncertified ROMs or relying exclusively on FOSS ecosystems are automatically locked out of essential financial and civic infrastructure.

For the F-Droid ecosystem, this policy destroys pseudonymous open-source development. Security tools (such as censorship-circumvention proxies and whistleblowing platforms) are frequently authored by contributors in authoritarian regimes who cannot safely disclose government identification to a centralized corporation in California. Imposing financial and administrative hurdles also penalizes volunteer hobbyists who maintain utility packages with zero commercial monetization.

The Keep Android Open coalition—led by F-Droid, privacy organizations, and digital rights foundations—is actively organizing developers to file antitrust complaints with the European Commission and competition regulators globally. They contend that Google is transforming the open Android commons into a notarized walled garden identical to Apple’s iOS.

The Sovereign Computing Horizon

F-Droid 2.0 demonstrates that decentralized, privacy-first software distribution can deliver the same refined user experience, automated background updates, and Material 3 aesthetic expected of commercial app stores. By moving to Kotlin and Jetpack Compose while standardizing on AOSP session mechanics, the project has established a modern technical foundation capable of sustaining the ecosystem for the next decade.

Yet the ultimate battle for Android freedom will not be decided solely in application code. As Google accelerates its developer verification gatekeeping, the survival of sovereign computing hinges on regulatory enforcement of open standards and the community’s resolve to defend sideloading. F-Droid 2.0 provides the software infrastructure; keeping the platform open is now the defining challenge for the entire mobile ecosystem.