Orgzly-android: F-Droid package

[fengshaun]

Would be nice to have Orgzly on F-Droid.

[relan]

I've been just investigating this. There are some issues that prevent Orgzly from being on F-Droid.

1. Orgzly cannot be built without org-java project, which is not checked out automatically. Solution: make org-java a git submodule of orgzly.

2. Jars. F-Droid does not allow code in binary form. Solution: use juniversalchardet from JCenter and remove the other two that are unused.

3. API keys for Dropbox. F-Droid does not treat "secrets" in any special way because anyone should be able to build an app exactly as F-Droid does. Solution:
   a) move Dropbox integration into a separate plugin or
   b) provide a Dropbox-free flavor.

When those issues are addressed, it'll be easy to push Orgzly into F-Droid.

[nevenz]

1. This should be just a matter of replacing: compile project(':org-java') with compile 'com.orgzly:org-java:1.0'. org-java is in JCenter. ../org-java currently used was just left there for faster development.

2. No idea why I used jar in the first place.

3. Yeah, this is a tricky one. Although another option is to create a separate account and Dropbox app and simply include the the api key in the source. It not an access token or such and is only used to identify the app. In fact, I'm finding the one used in Orgzly now by grepping the APK. 😄

I'd do this last one, unless someone sees opportunity for abuse.

[fengshaun]

It's great that you're taking the initiative to "fix" this issue. With an API key, there are potential for abuses and it's best not to have the api key linked to your personal account. I can't think of a secure way to distribute the API key, though. I do know of many projects that distribute api keys with their source (I do that myself too) and it's been fine, but the potential is there for someone to take the api key and abuse the service, leading to the account being suspended.

[relan]

@nevenz,

1. That's even better.
2. OK.
3. Providing a dedicated Dropbox API key in the source code sounds good. Some developers treat them as a treasure, while they serve mostly statistical purpuse for service owners.

Let me know in this issue when you make those changes, I'll help with inclusion into F-Droid.

[gdt]

Also, if there is dropbox support in what's built for f-droid, it's going to get the antifeature tag of "promotes non-free network services". So from the purist POV (which is the f-droid viewpoint), it seems better to just omit dropbox support or have it be a plugin. But as long as one can ignore it and the app doesn't try to talk to dropbox, it seems harmless enough.
(I'm assuming the code to accesss dropbox that you are using is open source.)

[nevenz]

All 3 issues should have been resolved.

There's a new fdroid flavor which should be used. It removes "Dropbox" as an option when creating a new repo in the app. Seemed like the easiest solution for now.

[relan]

Everything looks good, thanks.

One question: does Dropbox SDK connect to Dropbox servers in _fdroid_ flavor? Since it's still built into the app it can collect statistics or something like that.

[nevenz]

No, nothing is going on without explicit user action. That can be:

• Linking to Dropbox
• Collecting files from Dropbox directory
• Uploading a file to Dropbox
• Downloading a file from Dropbox

They all require Dropbox repository to be created, which can't be done in fdroid flavor.

Still, code too can be removed in the future, if only to make APK smaller.

[relan]

Almost done: https://gitlab.com/relan/fdroiddata/blob/orgzly/metadata/com.orgzly.txt

Please drop a comment here when you tag a new stable release, I'll make a merge request to F-Droid.

[nevenz]

I've pushed v1.4.11-beta.1 now, v1.4.11 is coming in a day or two, if nothing breaks.

[relan]

Awesome! I'm on holiday till the end of the week (away from PC), will post merge request to F-Droid as soon as I can (after v1.4.11 is ready).

[nevenz]

v1.4.11 is now pushed. Thanks!

[relan]

Orgzly will become available on F-Droid the next day after this MR is reviewed and merged: https://gitlab.com/fdroid/fdroiddata/merge_requests/2065

[relan]

Here it is: https://f-droid.org/app/com.orgzly

You can add a proud badge. :)

[nevenz]

Great. 😃

What about the Auto Update issue that was mentioned? Will it work?

[relan]

What about the Auto Update issue that was mentioned? Will it work?

No, versionNameSuffix breaks autoupdates because with it F-Droid cannot calculate version string from a Git tag.

Is versionNameSuffix really needed?

[nevenz]

No, I was just thinking it would be useful to be able to quickly tell which flavor is installed.

Instead of removing it, I think I'd prefer naming the version v.1.4.11+fdroid and start tagging releases with that one too. Any thoughts on that?

[relan]

I think double tagging is tiring and excessive.

Maybe just append flavor name to the the version string in Settings (under "What's new", where it is now)? It's an easy enough place to check quickly.

[nevenz]

Yeah, that's the place that was using BuildConfig.VERSION_NAME. I've changed it to use a new custom variable instead and removed versionNameSuffix.

[relan]

Thanks! MR that enables automatic updates: https://gitlab.com/fdroid/fdroiddata/merge_requests/2076

[nevenz]

I'll push v1.4.12 soon, just released v1.4.12-beta.1.

There's no fdroid anywhere now, except displayed in the app. I see Build:1.4.11 (fdroid),58 still in here, is that OK?

BTW, would adding archivesBaseName break something? It would help me when testing install/replace using APKs.

[relan]

I see Build:1.4.11 (fdroid),58 still in here, is that OK?

Yes, Git tags filter is set to exclude tags with letters. F-Droid usually does not provide only alfa/beta builds.

would adding archivesBaseName break something?

No idea. I didn't understand what archivesBaseName is from Gradle documentation.

[nevenz]

No idea. I didn't understand what archivesBaseName is from Gradle documentation.

It changes the filename of generated APK.

If not set, app/app-fdroid-release.apk is generated. If set to orgzly-$versionName, app/orgzly-1.4.12-fdroid-release.apk is generated instead.

It would probably require additional Build parameter(s) to be specified (output it seems?), probably not worth it.

[relan]

I never looked at how F-Droid finds output APKs. Anyway, output parameter should do the trick.

[nevenz]

I've pushed v1.4.12, let me know if there's anything else needed.

[relan]

Should be there in about two days. Let's wait.

[Matrixcoffee]

The home page needs a badge linking to the f-droid app. Also maybe link to the f-droid app under http://www.orgzly.com/help#orgdb73ae6

[relan]

How to add an F-Droid badge: https://gitlab.com/fdroid/artwork/blob/master/badge/README.md

BTW, F-Droid bot updated metadata automatically to version 1.4.12. The bad news is that build has failed. This is F-Droid problem, it's being worked on. Failing builds will be retried, no need to worry.

[licaon-kter]

There is a badge already, what do you mean?

[Matrixcoffee]

@licaon-kter I mean the orgzly home page at http://www.orgzly.com

I don't see any F-Droid badge in the following screenshot:

[relan]

JFYI, F-Droid issues are solved, Orgzly 1.4.12 has arrived: https://f-droid.org/app/com.orgzly

[nevenz]

JFYI, F-Droid issues are solved, Orgzly 1.4.12 has arrived: https://f-droid.org/app/com.orgzly

Great, thanks.

I've added the badge to the site and updated FAQ.