outline-apps
outline-apps copied to clipboard
Jigsaw-Code
Support F-Droid as an official deployment location
Hi,
Is it possible to add this app to F-Droid. It's a very safe way to get this app, for example for folks who can't access Google Play in their country. They will build your app from source, if there is no proprietary dependencies.
Otherwise, could you please provide a signed "release" apk in the release section?
Thanks for your feedback, @Poussinou. Users who cannot access the Play Store can download the signed Android app here.
The best way to attach binaries is to do it via the release section of the source code repo, I think (see here for more information). It's easier to see if we have the up to date version of the app, and you can keep the older versions available for everyone... But it's ok, thanks!
One nice feature offered by F-Droid not addressed by Github releases is the ability to share the app directly between devices.
We also host them in the releases section, for instance: android-v1.0.1.
But you forgot them there for the stable releases – only pre-releases have APK files attached. As @Poussinou pointed out, that would make updates easier – also for the auto-updater of my F-Droid compatible repo, where I've just added your app on request by @Poussinou :wink:
The arguments for F-Droid makes sense, but wouldn't F-Droid be blocked if the Play store was also blocked?
@fortuna Blocked by what exactly? Do you think about a blocked access?
In fact even if Google Play AND F-Droid were blocked by something, the fact that F-Droid allows to share the app directly between devices is an advantage... Once you have the app and F-Droid installed, you can give the app to everyone very easily. It could be effective in a country where F-Droid and Google Play were blocked: if one person has Jigsaw and F-Droid, everybody can have it...
What @Poussinou describes is practiced in Cuba, due to "flaky Internet". There's an article on that somewhere on the F-Droid site.
Another example for "blocked access" are firewalls and filters. For example, try using Google in China (behind the "big Firewall"). Not sure if F-Droid is blocked there as well, though – but you get the point.
In China, GooglePlay is blocked by Great Firewall (GFW, '墙'), but F-Droid works now. We usually share VPN application through QQ, WeChat, SD card, Flashdisk, or directly download from github (but slow and unstable).
Izzy [email protected] 于 2018年6月17日周日 07:11写道：
What @Poussinou https://github.com/Poussinou describes is practiced in Cuba, due to "flaky Internet". There's an article on that somewhere on the F-Droid site.
Another example for "blocked access" are firewalls and filters. For example, try using Google in China (behind the "big Firewall"). Not sure if F-Droid is blocked there as well, though – but you get the point.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Jigsaw-Code/outline-client/issues/50#issuecomment-397843885, or mute the thread https://github.com/notifications/unsubscribe-auth/AQVHEkG-SJtjRm_uDanJ5B64gei7s3bCks5t9ZCTgaJpZM4TBeta .
Here you can find the article @IzzySoft is talking about 👍
So yes having Jigsaw in the official F-Droid repo would be a good idea...
Also don't forget the "prestige". Other than apps from Playstore, those on F-Droid are checked and then build from source – no trackers or other "unexpected stuff". There are folks for whom this is important (you've just met some here at this issue). And it's not that rarely I hear things like "this app is kosher, it's on F-Droid".
So get yourself the Hechsher! Ⓤ :rofl:
Can we please re-open this issue? This is important for privacy-conscious, at-risk people, so exactly the Outline target audience. Offering them a way to install and seamlessly upgrade their Outline client via F-Droid would be a boon. And since the signed APK is already available, it does not seem like a lot of additional work would be needed...
@rysiekpl you can already, if you add my repo to the client – see here. Though I definitely admit having it in the main repo would be a jump upwards!
@rysiekpl, I think your request is fair. I'm not very familiar with F-Droid. Is there a way for us to include only signed APKs in the main repo, or do we have to import the source?
Releasing the clients for five platforms is already challenging for our small team, so we need to evaluate whether we can absorb the maintenance cost of supporting F-Droid.
@IzzySoft, can the repo you set up be included in the main F-Droid repo? Or would we have to set it up as maintainers?
@alalamav my repo is fed by the APKs you provide here. If you tag a new release and attach an APK to it, that should show up in my repo within 24h. Users cann simply add the repo URL to the F-Droid client installed on their devices, use that to install your app, and they'd be notified about updates automatically.
For details you're welcome to check with my 3-part blog series on F-Droid (soon-to-be 4-part):
- F-Droid: The privacy-friendly alternative to Google Play Store
- F-Droid for advanced users and developers (includes instructions for 3rd party repos like mine)
- Your own F-Droid Repository with Repomaker
There's also an article on my repo (IzzyOnDroid’s F-Droid Repo with additional functionality), a list of Unofficial (and incomplete) list of F-Droid repositories, and more.
Thank you @alalamav and @IzzySoft! This is good news indeed. If there could be some mention of that in the documentation (Outline is available on this-and-that repo on F-Droid), that would be swell.
Version 1.3.0 added a bunch of trackers (e.g. Crashlytics, Firebase Analytics). I hope this was an accident, and not something intended – because your app is supposed to be dealing with sensitive data, and you cannot really control what data goes to 3rd parties when using such proprietary trackers.
Could you please remove them again, @alalamav? Meanwhile I disabled auto-updates for your app in my repo, and removed v1.3.0 manually again – as that combination is a show-stopper here. Apart from that, all the 4 of them are show-stoppers for including the app with the official repo, where proprietary components (including GMS and Firebase) are not accepted at all.
@IzzySoft , we hear your concern. There's a trade-off here.
We are migrating our network stack to Go, so we can share network code across platforms (our team is small, that's a lot of overhead). Unfortunately the migration is taking a while because we are getting a significantly higher number of crash reports, and those reports don't have all the details of the stack when it crosses languages. Furthermore, we were unable to reproduce the errors on our development environment and devices.
After struggling with it for some time, we decided to try Crashlytics, since it can give us the full stack. It's only being used for the crash reports, not analytics. Notice that the PR hasn't been submitted yet. The code is only for the beta version of the Android app. The production version won't have any of the Firebase code (it's added at build time). AFAIK the plan is to have a notice alerting the user of the library in the beta version. The user can always switch to the production version.
Does it make sense? Do you have any other ideas on how we can find out what's going on with those crash reports?
@alalamav to sanity check what I said :-)
What @fortuna said is correct; Firebase is only integrated into the client when we explicitly build for beta. @IzzySoft, I would only add that we are happy to mark beta releases as non-production ready, so they are not consumed by your F-Droid repo.
@fortuna thanks a lot! I'm not a dev and thus don't have the "deep insights" – but if you just need crash reporting, maybe taking a look at ACRA, which is fully FOSS, might give you an acceptable option for that? ACRA is even "white-listed" in the official F-Droid repo, so it should be fine. There are 2 or 3 others – but not being a dev I didn't keep track. Let me look what my library scanner has in terms of "crash reporting without the Tracking AntiFeature:
- CrashReporter: "a handy tool to capture app crashes and save them in a file. This library captures all unhandled crashes and saves them locally on device, not on some remote server." (uses Apache 2.0 license)
- BugClipper: "lets users report issues directly from your app, with screenshots, screen recordings and crash videos" (not sure if this is FOSS; if not, it would again be a show-stopper for the official repo)
@alalamav thanks to you as well – and yes, I'd welcome that option. You could make the beta-build releases "pre-releases" (which you already do) – and I let my updater know to skip those, which is easy and the default anyway and was even set for Outline. If you later decide to bring your app into the official repo, you could even have that one skip beta-builds (which there can be controlled via tag name patterns, which you already use: e.g. replacing the android- prefix by an fdroid- prefix for those F-Droid should pick up, so we'd set AutoUpdateMode to Version fdroid-%v and it would ignore all others).
Just wondering, as I couldn't find any non pre-release "android*" tag: have you already "turned that switch"? As my configuration says to skip pre-releases for Outline. So shall I then try switching auto-update on again? That should then walk back to the latest non-pre release, for now find no APK there, and then wait for the next.
Crash reports are very important to create a stable products.
Another solution could be store the crash logs in app and request the user to send it when app is opened again using email or some other means this way user also will know what he is sending and no 3rd party dependencies.
Refer this https://github.com/RohitSurwase/UCE-Handler
Again I'm not recommending this particular library, we can implement something similar on our own
Thanks for the pointers. One challenge is the fact that we are cross-platform.
What are people's opinion of Instabug? It seems to be quite well developed.
According to my library scanner, it seems to have earned the Tracking AntiFeature as well (i.e. at least with the default config, doesn't ask the users' consent before uploading things). Exodus thinks the same. Moreover, it seems to be "free" as "free beer", but not "libre" (no link to the sources – at least not on a quick glance). So it'd be a show-stopper for F-Droid again.
According to my library scanner, it seems to have earned the
TrackingAntiFeature as well (i.e. at least with the default config, doesn't ask the users' consent before uploading things). Exodus thinks the same. Moreover, it seems to be "free" as "free beer", but not "libre" (no link to the sources – at least not on a quick glance). So it'd be a show-stopper for F-Droid again.
That's very disappointing.
As I pointed out in https://github.com/Jigsaw-Code/outline-client/issues/50#issuecomment-507235307, we only have Crashlytics in the beta build. Users not comfortable with that can use the stable version instead. We are very grateful to the users that help us test the beta version! It helps us make the product better.
@fortuna thanks for the pointer! Then F-Droid could stick to the stable builds. I see no build.gradle, so I cannot verify :wink:
PS: it's also pretty hard to find the stable builds on your releases tab, with all those daily development builds published by the bot. Maybe you could link to the latest build releases (per OS) from somewhere, e.g. from the Readme?
Thanks to the new tag names, picking only stable ones (android-v%v) is now easy. I just re-enabled auto-updates for my repo after verifying the last version (1.2.13), which my scanner confirmed to be "clean".
Closing because we're a small team and don't have the bandwidth to maintain another release. We do have APK releases available here on GitHub for folks who can't or don't want to use the Play Store.
