Policy clarification: Can applications integrate pre-compiled AAR libraries?

Apps
1

Hi F-Droid team,

I’m trying to integrate Proofmode into the Save app (net.opendasharchive.openarchive.release) for cryptographic content authentication and archival purposes. However, the F-Droid build pipeline is rejecting the application due to several policy violations related to the Proofmode dependency.

Current blockers:

  1. Pre-compiled AAR library: Proofmode depends on c2pa-release.aar, which is a pre-compiled Android Archive library. This can’t be built from source in the current F-Droid pipeline.

  2. Binary test assets: Test assets in proofmode/android-libproofmode/src/androidTest/assets/ contain binary blobs.

  3. Rust components: Proofmode is moving toward Rust-based components (https://github.com/contentauth/c2pa-android) which adds another layer of complexity.

Pipeline errors: https://gitlab.com/prathieshna/fdroiddata/-/jobs/11508534167

Questions:

  • Does F-Droid have a policy for integrating libraries that are only distributed as pre-compiled AARs?

  • Does F-Droid support building Android libraries that include Rust components, and what are the requirements for Rust dependencies?

  • Is there a path forward for integrating authentication/verification libraries that have these constraints?

The Save app’s mission aligns with F-Droid’s values around privacy and transparency. Proofmode is critical for ensuring content authenticity in archival and documentation scenarios. We’d appreciate guidance on whether there’s a way to meet F-Droid’s requirements while maintaining this functionality.

Thank you for your time.

2

why not?

are they needed? we can delete them if not

we build a ton of Rust apps, reproducible too

Sure, read Maven Central is not as free as it looks | F-Droid - Free and Open Source Android App Repository and Inclusion Policy | F-Droid - Free and Open Source Android App Repository starting with “Though we tried to build everything from source…”

grep fdroiddata for rustup :wink:

1 Like
3

You can either build the AAR on F-Droid or vend it from either Maven Central (you’ll need to sign up for approval & gpg-sign all your artifacts) or Jitpack (it can build your AAR on-demand & host it immutable-y).

Here’s how a project I co-maintain (Firestack) does so:

(See this entry in the README on how these can be consumed by Gradle).

As @Licaon_Kter points out, even though Maven Central is allowlisted by F-Droid, it offers no guarantee that the artifact vend from there is built from OSS code.

What we do for Firestack is publish build (provenance) and SBOM (document) attestations (“witness attestations”). And so, folks can verify if the AAR they are downloading from any repository is the one GitHub built (and then verify if the corresponding GitHub workflow run built the artifact from source): Attestations · celzero/firestack · GitHub

1 Like
4

Some of aar files required close source software to compile I think, like Visual Studio?

5

Surely that ain’t true, right?

It needs vcpkg maybe? We can build that then the lib maybe…

6

I think the path forward might be to rebuild the library from source rather than relying on the pre‑compiled AAR. That way, you avoid licensing or binary‑blob issues that seem to trigger the policy rejection. If Proofmode’s source can compile with Rust dependencies under FLOSS build tools, that might satisfy the inclusion rules.

7

Hardware-Assisted Builds Environments (aka SLSA Build Level 3) seem much easier sell for maintainers who are on GitHub (which is the case for proofmode), as it provides similar integrity/verifiability guarantees.

How do RBs help avoid licensing issues?