Android: F-Droid inclusion

[shuvashish76]

Hello, would you consider publishing at F-Droid please?
see https://f-droid.org/en/about/

• https://f-droid.org/en/docs/Submitting_to_F-Droid_Quick_Start_Guide/
• https://gitlab.com/fdroid/fdroiddata/blob/master/CONTRIBUTING.md#merge-requests

[BenHenning]

Hi @shuvashish76. Thanks for asking this!

I spent some time digging into F-Droid since, admittedly, I wasn't very familiar with it before. I find the overall concept quite interesting, and it does seem quite straightforward for us to integrate with F-Droid's method of building apps directly from source code (since it seems we can still leverage our Bazel build integration). This also well complements our other ongoing work with build automation (since that ultimately boils down to getting the app build to be completely done via CI workflows).

However, there are some pretty significant gaps that I see which would make this sort of integration challenging and unlikely to do right now:

1. Feasibility: The restriction on closed third-party libraries would cause substantial, immediate pain. We need to be able to continue to collect telemetry for users as part of app development. While I have no issue with moving this functionality to being opt-in (as that's something we've discussed doing, anyway), the main problem here is our significant usage of Firebase and Play APIs. It wouldn't be too much work to create a flavor of the build which exempts these, but it would be a massive undertaking to completely replace them with fully OSS alternatives (which we are definitely open to doing as there are many aspects of Firebase and Google Analytics we don't like, but the work here is immense). The alternative is shipping a version of the app without analytics and I really don't think we want to do that at this time.
2. Priority: Our primary target demographic are young learners in hard-to-reach locations around the world, and oftentimes they are using a device at school or the single shared family device at home. The child's parents often don't know how to manage the phone themselves and instead rely on technical support from wherever they purchased the phone. In these cases and others, I suspect it's very unlikely that F-Droid would be a blocker for them to gain access to Oppia's educational materials. Taking this one step further, I'm not sure F-Droid would actually expand access to any of our demographic.

While I think the premise behind the store is good, it doesn't feel like the right time for us to commit any of our limited resources toward such a massive, cross-team effort if it doesn't actually help us expand our offering to more learners. If the environment changes (e.g. major phones in low connectivity regions are sold with F-Droid as the default app store) then we would be happy to revisit this. It's possible some of these blockers will have had progress made on them or would be completely solved by then.

[PaulMayero]

Hi @BenHenning .

Thanks for all your work on Oppia! It is an impressive open-source project that is making high quality education very accessible.

To address some of the challenges you mentioned, here are my thoughts.

Feasibility: The restriction on closed third-party libraries would cause substantial, immediate pain. We need to be able to continue to collect telemetry for users as part of app development. While I have no issue with moving this functionality to being opt-in (as that's something we've discussed doing, anyway), the main problem here is our significant usage of Firebase and Play APIs. It wouldn't be too much work to create a flavor of the build which exempts these, but it would be a massive undertaking to completely replace them with fully OSS alternatives (which we are definitely open to doing as there are many aspects of Firebase and Google Analytics we don't like, but the work here is immense). The alternative is shipping a version of the app without analytics and I really don't think we want to do that at this time.

We do understand that the work of replacing Firebase and Google Analytics with OSS alternatives is a lot. You mentioned that Oppia still relies on the telemetry collected for app development. This is very understandable. F-Droid offers tooling that can be used to ship the Oppia app without necessarily having to remove proprietary libraries you rely on. You can create your own custom repository with the current version of Oppia and still download it using the F-Droid app.

Only apps on https://f-droid.org are required to be use no proprietary libraries.

Below are possible tools you can use.

• The quickest way to set up a repo is by using Repomaker - a web app that allows users to set up their own custom F-Droid repositories. The demo repomaker instance allows you to upload the Oppia APK. With the resulting repo that is created, scan it with the F-Droid app to add it as a repo on your client. Test it out and tell us what you think! We are looking for ways to improve Repomaker and your feedback will be highly appreciated. Here is a tutorial that will be of help.

• If you use fastlane in your development process, you can check out the custom fastlane fdroid plugin . The action of interest to you would be the fdroid_set_up_nightly_repo_on_github .The entire plugin documentation can be found on Gitlab . With the nightly repo, one can use F-Droid as they develop their own app.

• Another option is to use fdroidserver to set up a custom repo of your app. A quick tutorial can be found here . All the aforementioned tooling are built on fdroidserver.

A number of people and organizations have set up their own F-Droid repositories. The list can be found on F-Droid's Discourse and there is another list on this Github gist I hope this gives you the courage to set up your own repository. In case you need any help, do reach out!

Another option is that you can request Oppia to be distributed through IzzyOnDroid . It is a F-Droid compartible repository that allows apps with proprietory libraries. Once Oppia is included, F-Droid users can install Oppia from the IzzyonDroid repository. Details on how to include an app on IzzyOnDroid can be found here.

Priority: Our primary target demographic are young learners in hard-to-reach locations around the world, and oftentimes they are using a device at school or the single shared family device at home. The child's parents often don't know how to manage the phone themselves and instead rely on technical support from wherever they purchased the phone. In these cases and others, I suspect it's very unlikely that F-Droid would be a blocker for them to gain access to Oppia's educational materials. Taking this one step further, I'm not sure F-Droid would actually expand access to any of our demographic

I agree with this. There are chances that wherever they receive technical support from might not be familiar with F-Droid. When they install F-Droid for the first time, they might be scared off by the error that normally pops up. This is an Android issue that is sadly not in our control.

However, in the same vein, F-Droid repositories can be set up as mirrors in places where access is difficult. Such mirrors can run on Raspberry Pis and can be used to distribute Oppia too!

[BenHenning]

Thanks for the follow-up @PaulMayero. I wasn't aware of the repository modality aspect of F-Droid (I suppose I missed that in my research since I had assumed it operated more like Google's and Apple's app stores). I would be curious about the user experience in selecting a repository since that presumably introduces another barrier to entry (which could very well be prohibitive given Oppia's target demographic).

The mirroring concept is an interesting side benefit of the repository approach and could actually be useful for us to consider. I'll make a note of this with our Programs lead in case we come across any findings that such a solution would make things easier. If it would then we would absolutely look deeper into this as a distribution method.