We should provide HABDroid on the F-Droid store (https://f-droid.org/)
I think this is an Android specific issue, maybe https://github.com/openhab/openhab/issues/394 needs to be moved here?
From your old issue:
I've been working on building HABDroid on the F-Droid platform and got it running. Unfortunately I
observe dependencies to closed source code, such as GoogleCloudMessaging and Crittercism. For
obvious reasons this is not allowed. Is it possible for HABDroid to provide a branch/Gradle flavour
where these closed dependencies are stripped?
I'm afraid unfortunately not, cause this will break the user experience - my.openHAB features will not work and we will not be able to track and resolve crashes/bugs from F-Droid users.
From what I understood from https://f-droid.org/wiki/page/Inclusion_How-To there are ways to use Google. openHAB is published under Eclipse Public License. So probably you should ask those guys how to do it?
The usual solution in this case is to split the app into two apps: One completely open source app and one that works as a plugin / connector to the proprietary stuff. Of course the second app needs to be optional.
However, I assume that most users would not install the second app, because it breaks the whole open source concept of the first app and opens a major security whole, since nobody knows what actually happens in closed source parts or proprietary services. The past has shown that one has to expect the worst.
If those closed source parts are just used for bug reports and for connecting to my.openHAB it should be possible to move this functionality into an optional app without breaking the user experience for users with privacy concern, because those users will anyway not use my.openHAB, because that would mean that they give a proprietary service access to their private data. The other users that don't care about privacy would just install the second app on demand. That way both groups should be satisfied.
Furthermore, there is another reason for splitting the app. There are millions of users with Custom ROMs (e.g. over 12 million CyanogenMod users) and a lot of them did not install the Google Apps for obvious reasons. Since those users are missing the Google Play Services they won't be able to use the GoogleCloudMessaging and thus cannot even install the openHAB app even if they get it from another source. That means that they have to install the closed source Google Play store in order to use the openHAB app. This is a pretty strong requirement for an "open source" app.
Hopeful to see openHAB for Android on the F-Droid store in the future. As I'm sure is the case for most others, a main attraction of openHAB was its status as free/libre software. It's unfortunate that the Android app currently includes proprietary dependencies.
As interim solution (until it gets listed with the official F-Droid repo, if ever), if the .apk would be available here at Github (preferably via the releases/ page), I could offer to place it into my F-Droid compatible repository. Updates would appear there usually within 24h from being "released" here. Just let me know if you want me to and have the .apk ready here, @belovictor
@xylo Wouldn't it be possible to make a "branch" without bug tracking? In this app https://github.com/physphil/UnitConverterUltimate/tree/develop/app/src there seems to be a different version for play store and fdroid.
my.openhab is now free, so this shouldn't be a problem
@mueller-ma Yeah, that's a very interesting solution and probably easier to manage than the plugin solution which I proposed.
The "Unit Converter Ultimate" app looks like a perfect example how different app versions can be comfortably handled within the same repository by using different source directories:
By default the gradle build script only uses the main source directory for building the open source app. If you want to build the version with google extensions, just create a file 'app/google-services.json' and run gradle.
Again, thanks for the example, @mueller-ma.
@digitaldan When someone makes a PR with different build flavors for foss and non-foss, is there a chance that it gets merged?
I have started working here: https://github.com/mueller-ma/openhab.android/commits/30-fdroid2
Currently it has two buildflavors, but the maintainence would be horrible because of some hugh clases like MainActivity. Some files like util/AsyncServiceResolver.java contain only a few lines non-foss code for tracking purposes. Can this be removed completly?
The PR could factor out the problematic parts into dedicated classes, so changing them in a different flavor would be easier. But this might make it less likely to be accepted by upstream.
It would be really great to see a free version of Openhab.Android available on f-droid! Thanks for all the effort you put in!
I have created a PR #409. Please review
PR to add openhab to fdroid: https://gitlab.com/fdroid/fdroiddata/merge_requests/2687
All issues for inclusion in fdroid has been fixed and I opened a new MR: https://gitlab.com/fdroid/fdroiddata/merge_requests/2982
TODO:
Finally :tada:
https://f-droid.org/packages/org.openhab.habdroid/
Most helpful comment
Finally :tada:
https://f-droid.org/packages/org.openhab.habdroid/