Support F-Droid

[alterechtschreibung]

@konklone discusses publishing to F-Droid in this discussion thread:

In order to support F-Droid, I will need to:

* make it so if analytics is disabled through a configuration flag, this also activates graceful handling of the Google Analytics JAR being missing entirely.
* also, if analytics is disabled, do not include a menu option that goes to the Settings activity in the main screen.
* write a build script that does this work as part of the fdroid build process - and in general, automate as much of [the manual](https://f-droid.org/manual/) as possible.

I haven't yet firmly decided to do this - it is a non-trivial amount of work. However, if it is done, it'll be done in a manner that doesn't require maintaining a separate branch.

Other requirements:

• Deal with an API key that I don't want to commit to source control
• Other values in keys.xml, like our contact email, debug flags, etc.

[alterechtschreibung]

In response to your answer on f-droid, one of the maintainers replied: "The issue is not analytics: it’s that the jar is proprietary."

[alterechtschreibung]

Alternative open source analytics:

http://bangoandroidsdk.codeplex.com/wikipage?title=Sample%20Implementation

And F-Droid is fine with it.

[alterechtschreibung]

One of the f-droid editors replied: "Apps in the F-Droid repo are built from source, so we can compile it with this flag easily. You wouldn’t have to do anything at all. However, will the app still compile if that flag is enabled AND the proprietary jar file is deleted? We simply can’t and won’t ship proprietary software, even if it’s not used.

The other alternative is for us to replace the jar with something that provides the appropriate interface to allow the app to compile, but is open source. Obviously it would be non-functional, as far as analytics is concerned, but at least it would allow the app to be included.

I think either of these solutions is preferable to a separate branch, which would make unnecessary work for everybody.

I do note that your policies say that you don’t allow apps in the store that track users unless users explicitly allow >the catalog to show them apps that do tracking. This seriously hampers the utility of analytics collection, and >makes the catalog less attractive for me to spend time bringing my app into compliance. For analytics to be >statistically useful, it has to be opt-out, not opt-in, with appropriate transparency. I think F-Droid is overly >aggressive about privacy.

To be more specific, this only applies if the app does so without their knowledge. For example, assume you replaced libGoogleAnalytics.jar with something open source, and asked users FIRST for consent before collecting information – that would be fine and would NOT give it the Tracking anti-feature. On the other hand, if you did it unless they found and activated an option to turn it off, that would give it the Tracking anti-feature. Opt-in, versus opt-out. I don’t think this is overly agressive, I think it’s what any reasonable person would expect. Perhaps the documentation you read doesn’t make the policy clear enough, in which case we should update it."

[dalb8]

The issue isn't really Google Analytics — that can be removed easily, with the current tools we have. The issue is the API keys: a key is missing from the source code and F-Droid won't sign some agreement to obtain one, since divulging the key would likely go against the agreement.

[alterechtschreibung]

So if I get you right, all we need would be either a random key in the source (if it still works) or a way, that the user can also enter an own key.

[dalb8]

Well, if the terms required for obtaining a key aren't too stupid, somebody could register for one and we could obtain it that way. e.g. somebody just got a key for the NPR app which says that any non-commercial organization can use it and said nothing about disclosure — close enough to freedom for me! Dummy keys are out of the question and entering own keys is too.

[konklone]

This article by The Guardian Project on setting up your own F-Droid server is interesting, and at least gives me the ability to use the same key between markets.

[konklone]

To anyone still subscribed: if I set up a Simple Binary Repository, with the app as it is (in other words, still containing proprietary Google Analytics code), and hosted this repository ourselves via S3 and a custom domain -- would this be useful? What would it take for it to appear in someone's F-Droid app, if that user accepted the fact that the app is not fully free software?

[dalb8]

It would be useful for a small number of people: those who know the repo exists, dont mind entering a URL into F-Droid client repo screen and are OK with Google Analytics. Of course the apks can be downloaded via a browser too, so if you are already serving apks, it's worth doing. The guardian project are customizing the fdroid client to allow peer to peer repos but this isnt ready yet.

[konklone]

I got a proof of concept repository working on my laptop, and was able to install the app through F-Droid on my phone after adding the URL. It's a real simple model, I hadn't realized an F-Droid repository could be a bunch of flat files -- that makes deployment concerns vastly easier (syncing to S3 and forgetting about it).

We're not yet serving direct APKs. I would like to diminish our Google dependency (I'm currently in the midst of replacing our Google maps with Mapbox ones, for example). Yet, we also can't drop Google Analytics, as we have deep institutional investment in the product (and, at various times, GA-based metrics with money on the line). I'm also loathe as an engineer to complicate our release workflow and code by making the GA JAR optional.

So, a simple repo, hosted statically, with a URL advertised on our app's landing page, is the most appealing option. It's a small enough burden to our release workflow that I'm personally comfortable with it, but I'll need to talk about it internally.

[alterechtschreibung]

Sounds good. Also the idea of peer to peer repos sound interesting. @konklone: you can now easily replace GA with NoAnalytics. It can be used as drop in replacement. You don't need to change your app.

[alterechtschreibung]

To make it fully open source.

[konklone]

Very nice, I had no idea that existed - that makes that decision a lot easier. I'll bring this up as we figure out our publishing strategy. I'm going to ship a couple of releases first with other things (including our Mapbox switch), but I'll update this thread in a couple weeks. Anyone should of course feel free to ring in with any other suggestions.

[konklone]

Updating this thread with an email I just sent an inquiring F-Droid user:

---

This is something I've discussed with the F-Droid community quite a bit.

There's this original discussion thread on the F-Droid forums: https://f-droid.org/forums/topic/congress/

And then this ticket on our issue tracker for our app: https://github.com/sunlightlabs/congress-android/issues/545

The main issues are our use of Google Analytics, our unwillingness to put other API keys the app uses into version control, and our insistence on using our current signing key on any version of the app we publish.

Some of this has been mitigated with recent changes: we've deleted all JARs and are now using gradle to manage dependencies, and we've killed our Google News integration. Nonetheless, it's non-trivial engineering to make our app work with F-Droid's all-files-are-versioned build process.

Where we last left it, the plan I found most workable was to update the app to make the presence of Google Analytics optional, and to then host our own F-Droid repository.

But I have cooled on this plan since it was last discussed, because hosting our own F-Droid repository is extra maintenance work on our part, for the small subset of users who a) use F-Droid, b) can't/won't use an open source app distributed through Google Play, and c) are willing to manually type in Sunlight's repo URL into the app.

To put our attitude into perspective, we've been in another prominent alternative app marketplace, the Amazon Appstore, for 2 years, and it has turned up so few downloads that it may not have been worth the effort.

Our position on this certainly could change over time, and I'm not the sole arbiter of whether this happens or not. It's also possible F-Droid has updated its processes since the last time I looked into it, I haven't kept close tabs.

But publishing to F-Droid becomes an easier thing to do if F-Droid's processes allow for publishing on the central F-Droid repository while allowing for the inclusion of non-versioned files that may contain secret keys (an extremely common and necessary practice) and retaining the use of one's own signing key (the same one that may be used to distribute the app on other marketplaces).

I hope that's helpful in explaining our position so far -- if you'd like to discuss it further, I'd encourage you to bring the discussion over to the Github ticket I referenced above (https://github.com/sunlightlabs/congress-android/issues/545).

[dalb8]

The Guardian Project have added a lot of features to F-Droid, including possibility to use developer's signing keys (f-droid.org just verifies the APK), easier repo bootstrapping (e.g qrcodes) and easier pushing of APKs to repos via libcloud (if you want to use your own repo).

There's no documentation for any of these new features; probably best visit dev.guardianproject.info if you can't figure out the intentions of the code.

F-droid.org generates a fair number of downloads and publicity, but sure: if you're distributing via your own repo expect numbers to be low.

[pizzamaker]

+1

[strugee]

@konklone why did this get closed?

[konklone]

@strugee The app is being transferred from the Sunlight Foundation to me personally, to manage updates in my (very limited) spare time.

So, I went and closed most of the issues in the repository, and am going to be focused on slimming the app down to something that can a) withstand the forced migration from the sunsetting Sunlight Congress API to the Pro Publica API, and b) I stand a chance of being able to personally maintain.

That means focusing on as few channels as possible, so I'm limiting this to Google Play. This includes removing code and support for other already established non-Google channels of publication, such as Amazon, which I'm tracking in #654.