F-Droid inclusion?

[TPS]

@tpcstld Would you support an RFP @ F-Droid? IfF so, I'd happily open 1 up.

[tpcstld]

I'm very unfamiliar with this. What's the maintaince burden of getting packaged? Is there something that I would need to do in every app update?

[TPS]

There's quite a lot of info @ @IzzySoft's writeup's linked above (https://android.izzysoft.de/articles/named/fdroid-intro-1) & specifically answers dev questions (including those you posed) in the "For Developers" sections.

[IzzySoft]

What's the maintaince burden of getting packaged?

Once it's set up, you will hardly notice any "burden".

Is there something that I would need to do in every app update?

Sure – and you will have to do that anyway: increasing versionCode, updating versionName, creating a tag so it's clear which commit marks the update/release.

Apart from that, as @TPS pointed out. The link given goes to part 1, which introduces F-Droid and mostly focuses on end-users. You should read it first, though (or at least "skim over" – it's not that long) as it gives you a general understanding. Then continue to part 2 (linked from there) for "advanced" topics and topics focusing on developers.

TL;DR: it won't be a burden. But you'll gain the audience of users valuing privacy highly and thus avoiding Play Store (and similar places). With a minimal effort to "get in" – which might be as minimal as just approving, let me take a look…

• license: fine! :heavy_check_mark:
• releases tagged: Yepp! :heavy_check_mark:
• tag name matching either versionName or versionCode: Yes :heavy_check_mark:
• versionName or versionCode being literals: yes, see link in previous bullet-point :heavy_check_mark:
• library check: oops, 1 offender (GMS) – we'd need a build flavor that comes without (if we know what you need it for, we might also be able to offer an alternative you could use "globally") :x:

A full scan by our bot might have additional details highlighted, but I doubt it will. Apart from the GMS dependency, this looks fine.