F-Droid

[TheEvilSkeleton]

Hello, can you request to include your app in the F-Droid repository? You can open an issue in their Request For Packaging (FRP) repository.

[Chainfire]

In the timely manner people have come to expect of me, I have looked at this today.

My conclusion is: not today.

I will count emoji responses to this reply as continued interest.

[IzzySoft]

Funny that I got a ping from this issue without having subscribed to it – and notification status is set to "All"… Maybe that should tell us something? 🤔 For example: if you'd provide the APKs here (e.g. attached to their corresponding releases, @Chainfire, my updater could fetch them and provide them via my repo, which in turn can be used with any of the F-Droid clients?

[Chainfire]

It is strange it should notify you without being subscribed. It wasn't me 🤷‍♂️ But since you're here and seem knowledgable about f-droid, do you have any input on the following?

My issue with core f-droid is that it wants to build everything completely from source, even jitpack-imported libraries (or do I not understand this correctly?).

LiveBoot uses some very old libraries - libsuperuser and librootjava - which are available on jitpack and import fine but require older version of Java, Gradle, and AGP to build. Then in turn, libcfsurface (which also depends on those libs) and the LiveBoot main app now require very recent recent versions of Java, Gradle, and AGP to build. There's currently no way to build them all together in one run in the same environment, the environments are incompatible.

To top that off, LiveBoot uses the Google Play Billing library which (again, as I understand, please correct me if I'm wrong) isn't allowed on f-droid because that library isn't foss. It should be noted that the app works fine without Google Play Services or otherwise completely de-Google'd Android, it'll just pretend you've purchased the Pro version and do its thing.

To fix that, I'd have to setup different flavor builds in Gradle, and introduce mocks for the billing code, something I've never done before because it simply wasn't a thing back when I did Android development, and it adds yet another way for Gradle to fail in the future, which it most definitely will. Only three things are certain in life: death, taxes, and Gradle/AGP introducing breaking changes every minor point release.

As for attaching APKs to every release so you can scrape them, I'd either have to consider manually doing it (which I'll forget next update, if any), or setting up automated Android builds here on GitHub, which as I understand is a workable solution but again not something I've done before.

All of this seems to be very contrary to my "I'm really not doing Android development anymore" attitude 😂

(The only reason I'm even here right now is because we just did an ultra-rare update to support Android 14, if you're wondering why this is suddenly active)