Upload the application to F-Droid

[marmistrz]

No description provided.

[borisyankov]

Thanks for the suggestion, Marcin. I am not familiar with F-Droid.
Do we need to register or can anyone submit it?

We are providing APK files with each release here:
https://github.com/zulip/zulip-mobile/releases

[Be-ing]

I have opened a request for this on F-Droid's tracker.

[Be-ing]

The Android app is quite laggy for me on LineageOS without GApps on an HTC One M9. I don't know if this is an issue with the app in general or if the lack of GCM push notifications is slowing it down.

[marmistrz]

You need to make a merge request to the following repository: https://gitlab.com/fdroid/fdroiddata
The application must not used closed-source dependencies. You may want to ask the F-Droid people at the IRC channel #fdroid on Freenode or on the F-Droid forum for more details on the process.

Basically, inclusion requests tend to be untouched for a long time. The best way is to contribute metadata.

[Be-ing]

F-Droid has an FAQ for app developers and a guide for contributing.

[borisyankov]

@vishwesh3 do you want to have a look at the perf issues on LineageOS? I am curious what is going on.

[Be-ing]

Until this happens, it would be nice if https://zulipchat.com/apps/android mentioned that the APK files can be downloaded from https://github.com/zulip/zulip-mobile/releases

[anirudhjain75]

I use lineageOS on Nexus 6 works for me perfectly 🤔

[anirudhjain75]

@zulipbot claim

[pulkonet]

@anirudhjain75 any success in uploading the app to fdroid?

[Serkan-devel]

Any updates on this?

[ghost]

Until this happens, it would be nice if https://zulipchat.com/apps/android mentioned that the APK files can be downloaded from https://github.com/zulip/zulip-mobile/releases

+1 ... it's not obvious that folks don't have to use Google services in order to download and use Zulip. 😄

[Serkan-devel]

but it's easier to update that way

[gnprice]

@downeym Thanks for the suggestion/bump! I agree.

I took a quick look at the relevant server code, and it isn't a trivial matter of adding a <p><a>... to an HTML template. So I'll file an issue there to see about getting someone to make that change.

[gnprice]

Just a quick note that we heard from a user who mentioned they were using the app "from F-Droid", and they explained that they were getting it from the IzzyOnDroid app repository:
https://apt.izzysoft.de/fdroid/index/apk/com.zulipmobile
https://apt.izzysoft.de/fdroid/index/info
But AFAICT the work of getting Zulip into the F-Droid repo itself is still open for someone to pick up and do.

(FTR there seem to be some inferences on that page that aren't true: we do not use Firebase Analytics, in fact we go out of our way not to; and we don't require any non-free dependencies.)

[mdimjasevic]

As someone interested in seeing this happening, I'm just sending a gentle reminder. I am not sure if this has been resolved in the meantime, but there was a build dependency problem where some React libraries required Play Services: https://gitlab.com/fdroid/rfp/issues/386#note_134825356

Zulip is free software so it would be great to have it available in a free software repository for Android-based devices!

[timabbott]

One thing worth mentioning is that we do distribute the app via a direct download link to the Android APK on zulipchat.com/apps. Obviously, this isn't the same as froid, but does mean it can be installed without going through the Play store.

[mdimjasevic]

One thing worth mentioning is that we do distribute the app via a direct download link to the Android APK on zulipchat.com/apps. Obviously, this isn't the same as froid, but does mean it can be installed without going through the Play store.

Thank you for your reply, @timabbott! I am aware of the direct link option. Still, it would be great to see Zulip in the official F-Droid repository.

[gnprice]

I am not sure if this has been resolved in the meantime, but there was a build dependency problem where some React libraries required Play Services: https://gitlab.com/fdroid/rfp/issues/386#note_134825356

Interesting, thanks for highlighting that.

One of those, react-native-notifications, is no longer part of our Android build since 01b33ad. (Rather, I think its JS still gets included because we use it on iOS; but its Gradle project is gone from our build.)

The other, react-native-device-info, does a few small things for us and I don't think any of them actually involve Play Services, so this is really just an issue with its build metadata.

---

The next step for this remains for someone who uses F-Droid and is excited about seeing Zulip in that repo to try preparing an F-Droid package for it. You'll want to consult F-Droid's documentation about how to do that; I think it ultimately turns into a merge request on their repo.

If you run into problems where Zulip won't build there, due to those Play Services mentions or another issue, either this thread or the #mobile stream on chat.zulip.org is a good place to ask; we'll be happy to answer questions.

[varac]

Any progress on this ?

[dioraman]

Any progress on this ?

Hi all! I second the question. :)

[IzzySoft]

PS, for the subject of this issue: you might consider switching to UnifiedPush for cloud messaging. That would leave the user the choice of the backend. While your PlayStore build could even default to the FCM backend, F-Droid users could pick the Gotify backend (Gotify-UP is available at F-Droid), which in my tests worked fine. The UP project is still young, but there are already apps using it (out of my head I remember two of them: Fedilab in its latest version, and the Matrix client FluffyChat).

[gnprice]

Thanks, those details are helpful. Nothing to apologize for. I've filed #5087 as an issue specifically for getting that code out of the build.

I'll reiterate, though, that we do not use Firebase Analytics -- it's not configured, and it's not reporting anything. (Details in that issue #5087, which is also the best place to discuss further.) But it would be nice to remove the code too, so that a scanner like yours can more easily be confident of that.

PS, for the subject of this issue: you might consider switching to UnifiedPush for cloud messaging.

Yeah, this is #3838. I'll copy the other details in your comment there.

[IzzySoft]

we do not use Firebase Analytics

I cannot tell that without running some tests, so I'm far from accusing you of this 😉 My library scanner can only tell what is present, not whether it's used (or if it's only a stub). So ideally indeed, removing the code brings confidence: what's not present cannot be used. Above config should take care that the build doesn't include the analytics parts (so my scanner wouldn't report it as it's no longer found) while keeping FCM intact.

Great to read UP was already brought up and you are open to it (side-note: OpenPush seems not too active anymore, long time not heard of). The more apps making use of it, the more useful it becomes – for the obvious reasons (a single network session being kept alive for all apps to use). Wishing you easy progress with all 3 topics (size, getting rid of the analytics code, and bringing in UP) 😃

[dm17]

I would consider Zulip if it was up-to-date on F-DROID.

[IzzySoft]

So what happended to this? The latest release still is beyond 120M. I'll have to consider removing it from my repo then, as that's more than 4 times the limit. What about the split APKs we've talked about last year? Any chance?

[gnprice]

@IzzySoft Thanks for the ping -- sorry I let this hang.

We did some further debugging on this back in October, which I've just written up at #5086 (comment) . Let's continue discussion of the APK size on that thread.

I'm going to go see about splitting the APKs up as you suggested: #5295 .

[IzzySoft]

Thanks @gnprice – I've already joined the discussion there 😃

[dm17]

We are providing APK files with each release here:
https://github.com/zulip/zulip-mobile/releases

The cool thing about F-DROID we can freely download stuff and have a certain level of privacy because they screen for such things. Then there is an easy question of "what's the difference between the GitHub and F-DROID release" - and if there is no difference, then we can just use GitHub to have a quicker release cycle. So, existing on F-DROID is kind of a third party review process.

[IzzySoft]

Hehe… that's the reason why some apps are on F-Droid and in my repo as well (e.g. FairEmail) – quicker release cycle 😉

[gnprice]

@dm17 Thanks for that feedback about your use case!

[IzzySoft]

Just stumbled about this RFP at F-Droid during the triage runs, which was opened by @Be-ing. There were some packaging tries, but they got stuck with build errors (see e.g. here). Any chance one of you could have a look at that to get things rolling there as well?

[IzzySoft]

@gnprice @chrisbobbe any chance? The due-date popped up again, so the RFP at F-Droid now enters the candidate-to-close state: if we see no chance to process the request, we have to close it in 4 weeks.

[IzzySoft]

Well… We can reopen the RFP again once you're ready, or start a new one. But as there was no reply at all, it will now be closed due to inactivity, sorry. Looking forward to a revival then…

[gnprice]

Ah, just looking at this now. From those build errors:

/home/vagrant/build/com.zulipmobile/android/app/src/main/java/com/zulipmobile/notifications/FcmListenerService.java:6: error: package com.google.firebase.messaging does not exist
import com.google.firebase.messaging.FirebaseMessagingService;
                                    ^

It looks like they're all saying that the Firebase messaging libraries (aka FCM), which we use for push notifications, weren't found.

That in turn is presumably because of this line in the quoted build script:

    prebuild:
      - sed -i … -e '/firebase/d' build.gradle

which deletes the line in our build config that pulls in that dependency.

I think the way forward on that would be for someone to send a PR here that makes the use of FCM a build-time option. I don't think we'll find time on the core team to write such an option, but I'd be happy to review and merge a PR to add one. Then that will make for a more sustainable way to support that variation than trying to sed out lines from the build config.

For how to implement such an option, probably the easiest way is with a Gradle "project property". For an example, see our use of a sentry property: it's consumed at the if (hasProperty('sentry')) in android/app/build.gradle, and it's set by passing -Psentry on the Gradle command line in tools/android. Here, we might call it nofcm, so -Pnofcm on the Gradle command line.

I believe it would also be possible to set up the no-FCM build as a different flavor or version in our Android build config. That might even be cleaner, but I haven't really used that mechanism so can't offer suggestions on how to do it that way.

[IzzySoft]

A different build flavor is what most projects use for that case. Another option might be using @UnifiedPush and then have their simple FCM distributor included with the non-free version (so e.g. PlayStore users won't notice a difference, while others have the option to use the distributor of their choice). That way, push messages would be possible in both variants. If that sounds interesting to you, you can find some pointers here in my snippet.

Note however that I am no dev, so I cannot provide you a corresponding PR – I can only share my findings 😉

[licaon-kter]

The recipe is ready to be merged: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11516

F-Droid awaits for this to be in: #5462

[chrisbobbe]

Thanks, @licaon-kter! Does this mean the build errors Greg discussed in #1270 (comment) were resolved? I'm curious about that because I don't remember a PR going by that matches this description:

I think the way forward on that would be for someone to send a PR here that makes the use of FCM a build-time option.

[licaon-kter]

This issue has been open for the last 5 years? The way forward might sound nice, hope someone can make such a nice PR. In the mean time, if @linsui can add screenshots this is ready to be merged. Is this ok?

[gnprice]

Sure, if you have a build that works and that meets F-Droid's requirements for merging, then it's not a problem for us how you make it work.

The suggestion I made above was because the previous attempt was hitting build errors, and I offered a suggestion for how to handle them. Those build errors are all that @chrisbobbe was asking about. Based on the CI results on that thread https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11516 , I gather that the build errors have been dealt with one way or another.

Just to make sure we have a shared set of expectations: there's a lot of stuff in that prebuild recipe that we can't guarantee will keep working. It's entirely likely that some of that recipe will break in the future. That's what I was saying here, above:

that will make for a more sustainable way to support that variation than trying to sed out lines from the build config.

But if you're OK with that, and F-Droid in general is OK with that, then we don't have any intention of standing in the way.

[gnprice]

And I see https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11516 has been merged! Thanks to @linsui and everyone else who contributed.

Are there any other steps remaining which this issue can help track, or should it be closed?

[gnprice]

Are there any other steps remaining which this issue can help track, or should it be closed?

Hearing none, I've let the issue be closed by @Poussinou's #5481 just now, which added a link in our README to the F-Droid page for the app. Thanks again, everyone 🙂

If further issues come up which would be good to address or track in this repo, please don't hesitate to file a new issue or PR as usual.

[Be-ing]

https://zulip.com/apps/android could be updated to link to F-Droid as well

[IzzySoft]

Congrats to your listing at F-Droid! As the link in the Readme already points there, I'll now remove the armeabi build from my repo to avoid confusion (see here for some background). Should you want it back for some reason, just drop me a note to restore it.