Publish to F-Droid also?

xmflsct commented 3 years ago

Seems like people prefer GitHub and official website.

kr428 commented 2 years ago

Would be interesting to have this in fdroid not just for auto-updates but mainly also to give the proiect a bit more "visibility"; this seems one awesome client to the federated web but a lot of people I ran into hesitated installing apks from web pages; fdroid seems to have much more "reputation" here. Would it be possible to reconsider this?

IzzySoft commented 2 years ago

Yes, but there are 8 reasons why – at least in its current state – F-Droid wouldn't take it:

Offending libs:
---------------
* Play Install Referrer Library (/com/android/installreferrer): NonFreeNet,Tracking
* Firebase Data Transport (/com/google/android/datatransport): NonFreeNet
* Android Market (/com/google/android/finsky): NonFreeNet
* Google Mobile Services (/com/google/android/gms): NonFreeDep
* Google Play Core (/com/google/android/play/core): NonFreeNet,NonFreeDep
* Firebase (/com/google/firebase): NonFreeNet,NonFreeDep
* Firebase Analytics (/com/google/firebase/analytics): Tracking
* Sentry SDK for Java (/io/sentry): Tracking

8 offenders.

That'd be even too much for my repo (apart from the size limit of 30M).

xmflsct commented 2 years ago

I am pretty new to f-droid and seems like it is quite complicated to publish there. And thanks for mentioning the limitations which make it even more tricky to be on there. For now GitHub should be trustworthy enough to download apk. Hosting the apk on the website is to make sure users in mainland China can access it fast and freely when GitHub is blocked or not stable.

IzzySoft commented 2 years ago

seems like it is quite complicated to publish there.

Not that much. It's just the inclusion criteria which are quite strict. And just to set one thing straight: the 30M limit is just for my repo, no such limit at F-Droid.org. My repo has laxer rules in other places (if you e.g. could reduce the number of offending libs, I have up to two eyes I can close – while for F-Droid.org you'd need to get rid of all eight).

I don't know what for those libraries are needed here (they are often dragged in as dependencies of some libraries, at least GMS is), but let me see:

Sentry can be configured to be "acceptable" (it's provided under a FOSS license; so if you configure it to be opt-in, the Tracking label can be lifted)
Firebase Analytics often can be disabled (you wouldn't need 2 analytics frameworks, would you)
if you really need the Play Install Referrer for your publications on Play, you could use "build flavors" and just have it in the one for gplay. It doesn't make sense with other places anyway.
Now, as a side-effect some of the other culprits might even have disappeared automatically (like Firebase being needed by Firebase Analytics, Play Core by the install referrer and so on) – so we could check how much was cleaned up and, given that got the file size down as well (or you could provide per-ABI builds), it might already be eligible for my repo.

Some further usful hints you can find eg. in my F-Droid snippet (including some alternatives to some offenders).

xmflsct commented 2 years ago

Thanks @IzzySoft! When I meant by "complicated" was around extra building steps? As I don't quite understand how f-droid works still, it is not by simplying uploading an apk, right? My current build steps are based on Fastlane and on Mac since I am building both iOS and Android apps in one go through GitHub Actions.

Regarding the offending libs. Personally I don't need them except maybe Sentry, which I can live without for the tradeoff that I may be slower in responding to app crashes. I still need to figure out how to remove some of them as they are dependencies of other libs.

IzzySoft commented 2 years ago

As I don't quite understand how f-droid works still, it is not by simplying uploading an apk, right?

That's correct: we build apps from their source (it's just my repo that picks APKs from the developers# releases). Depending on your knowledge, you basically have 2 ways of tackling that: being an experienced contributor, you could open a merge request submitting the metadata .yml file so we'd just have to merge that (after a review of course) – or as one feeling that too complicated, just open a Request For Packaging providing the most essential metadata (or more, depending on what you have) and wait for someone else to prepare those metadata. The latter is often done by end-users who want their favourite apps added, and is fully acceptable (it just takes longer as someone needs to do all the work).

When I meant by "complicated" was around extra building steps

Of course we appreciate very much if you can provide the full build recipe. But we don't demand it.

Personally I don't need them except maybe Sentry, which I can live without for the tradeoff that I may be slower in responding to app crashes.

As pointed out, Sentry is FOSS and thus acceptable. You should just configure it to be clearly opt-in (you could e.g. ask at first start whether it may be enabled, and should the user change their mind have the appropriate toggle in the settings). If that's omitted, we'll need to point out Tracking – if it's opt-in, we don't. Just the other 7 are absolute no-gos and thus show-stoppers with F-Droid.org (in my repo, I can close eyes on two of them but not on 7).

I still need to figure out how to remove some of them as they are dependencies of other libs.

That is true. May I suggest you give that a try? When you thought you got rid of some, let me know and I run my library checker again. If their number was sufficiently reduced, I could see to take the app into my repo while you're working on the remaining offenders. Once all (except Sentry) are gone, you can approach F-Droid.

Disclosure, though you might have guessed already: I'm also one of the F-Droid maintainers.

xmflsct commented 2 years ago

@IzzySoft I managed to exclude some libraries that depends on those none free sources. Though I do not want to exclude Sentry for now since error reporting is useful, and I am fine tagging the app with Tracking.

Can you help run through this latest build again and see what is left? The best scenario is that only Sentry is left in there. https://github.com/tooot-app/app/releases/download/v3.5-0/tooot-v3.5-0.apk

Thanks!

IzzySoft commented 2 years ago

Offending libs:
---------------
* Firebase Data Transport (/com/google/android/datatransport): NonFreeNet
* Google Mobile Services (/com/google/android/gms): NonFreeDep
* Firebase (/com/google/firebase): NonFreeNet,NonFreeDep
* Firebase Analytics (/com/google/firebase/analytics): Tracking
* Sentry SDK for Java (/io/sentry): Tracking

5 offenders.

Those marked NonFreeDep are show-stoppers at F-Droid.org. So: 3 down (good start!), 3 more to go… Plus the first one will disappear automagically once the other 3 are gone :wink:

xmflsct commented 2 years ago

@IzzySoft Some quick searches reveal why there are still Google services existed. It is because tooot is a social media app and push notification is (probably) crucial. Currently I use expo-notifications which depends on FCM for Android messaging, https://github.com/expo/expo/blob/main/packages/expo-notifications/android/build.gradle#L81. Unless I remove push functionality from the app, I don't see how I can bypass those libraries.

Soon I will set up a feature voting site, and there I can gather how many users would like to sacrifice push for a full FOSS app build.

IzzySoft commented 2 years ago

You can switch to @UnifiedNLP – for your users at Google Play you could even integrate their FCM provider for seemless integration (using a build flavor, to keep FCM out of the FOSS build). See here for some more details.

Besides: I currently use Tusky on one and FediLab on another device. Both work fine without any Push framework. IMHO, that Push stuff is quite a bit overrated for things like this: do we really need to be available 24/7 and respond immediately? Delayed notifications keep the pace down a bit :wink: But yes, I understand some folks might want them. UnifiedPush will be a fine solution for both groups: if I want silence, I just don't specify a distributor – if I want push, I can pick from a selection of available candidates.

That way, no sacrifices needed :smiley:

IzzySoft commented 2 years ago

Urgs, Github is broken again – no preview, no edit :cry: I of course meant @UnifiedPush …

wakest commented 8 months ago

would also love to get this on F-Droid or @IzzySoft's repo, has any progress been made on this?

IzzySoft commented 8 months ago

has any progress been made on this?

I'd say rather regress:

Offending libs:
---------------
* Play Install Referrer Library (/com/android/installreferrer): NonFreeComp,NonFreeNet,Tracking
* Firebase Data Transport (/com/google/android/datatransport): NonFreeNet
* Android Market (/com/google/android/finsky): NonFreeNet
* Google Cloud Messaging (/com/google/android/gms/cloudmessaging): NonFreeComp,NonFreeNet
* Google Mobile Services (/com/google/android/gms): NonFreeComp
* Google Play Core (/com/google/android/play/core): NonFreeNet,NonFreeComp
* Google Play In-App Reviews API (/com/google/android/play/review): NonFreeComp
* Firebase (/com/google/firebase): NonFreeNet,NonFreeComp
* Firebase Analytics (/com/google/firebase/analytics): NonFreeComp,Tracking
* Firebase Installations (/com/google/firebase/installations): NonFreeNet
* ML Kit (/com/google/mlkit): NonFreeComp,Tracking
* Invertase RNFirebase (/io/invertase/firebase): Tracking,NonFreeNet
* Sentry SDK for Java (/io/sentry): Tracking

13 offenders.

That absolutely de-qualifies for F-Droid and for my repo (for the latter, the APK size of 42 MB is a second issue, but that might be possible to work around with per-ABI builds – while 13 offending libs, 8 of which are proprietary and 3 trackers, is an absolute no-go), sorry.

tooot-app / app

Publish to F-Droid also? #50