fdroid version

[Donkey-Doug]

Add the app to fdroid.

I assume that the app is currently in early stage and therefore not added, but ultimately the app should be added to fdroid.

[Raeitus]

This is the inclusion policy that must be met to be able to submit. More info about submitting can be found here.

Here is the issue tracker to request your package to be available on F-Droid. After submitting, they can assist on what is needed to be done (if anything) to get it on F-Droid.

[deckerst]

I took a look at their policy and process.

One blocker is that the app currently uses Firebase for analytics and crash reporting. The related anti-features are opt-in and Aves can run fine without them, but crash reporting has been essential for me to identify issues that I would never discover by myself. So, for now, Firebase is a must in the main flavour.

In principle I am not against creating another flavour specifically for F-Droid, stripped of Firebase. But there is currently a technical limitation: Flutter, the framework used by Aves, cannot handle flavours with different dependencies, so I can't define a flavour with Firebase and another without.

Until the Flutter issue above is resolved or F-Droid loosens their policy, I cannot submit Aves for inclusion.

[Lowxorx]

I took a look at their policy and process.

One blocker is that the app currently uses Firebase for analytics and crash reporting. The related anti-features are opt-in and Aves can run fine without them, but crash reporting has been essential for me to identify issues that I would never discover by myself. So, for now, Firebase is a must in the main flavour.

In principle I am not against creating another flavour specifically for F-Droid, stripped of Firebase. But there is currently a technical limitation: Flutter, the framework used by Aves, cannot handle flavours with different dependencies, so I can't define a flavour with Firebase and another without.

Until the Flutter issue above is resolved or F-Droid loosens their policy, I cannot submit Aves for inclusion.

I hope that F-Droid will not loosens its policy towards users' privacy, that would be a betrayal of their basic principles! That said, if you're also concerned about the questionable policies regarding the data collected on Firebase, you can always use a free crash analysis solution (I'm thinking of ACRA for example) Don't take this as a negative criticism, you are doing a great job!

[deckerst]

I intend to try ACRA. I just need to find some free hosting that can accommodate its backend.

[flexagoon]

@deckerst check out the catcher package on pub.dev (link). It doesnt need a server afaik, just an email adress (there actually are a lot of ways Catcher can handle crashes, like Discord or Slack crash reports. You definitely should check it out)

[flexagoon]

You can also use https://sentry.io. It can work as a standalone library, or you can configure Catcher (link in my previous comment) to send crash reports to Sentry

Using it with Catcher will be more private tho, because if you use it standalone, you can't make error reporting optional

[deckerst]

@flexagoon thanks for the link to catcher, I'll take a look!

Regarding F-Droid, I should probably give an update instead of letting this issue rot. Firebase is not actually what's blocking me now. I've discovered that F-Droid cannot handle API keys as a secret. To me that's a deal breaker, as I use an API key for Google Maps (which is a major part of the app), and I won't let this key be public.

So pure F-droid distribution seems out (unless there's a sensible solution to the API key conundrum) but, starting with the next release, Aves will likely be on IzzyOnDroid.

[Raeitus]

To me that's a deal breaker, as I use an API key for Google Maps (which is a major part of the app), and I won't let this key be public.

Can you instead move over to OpenStreetMaps and use their API?

[deckerst]

Let's distinguish the OSM editing API from their tiles. For Aves it's the tiles that I need, and the OSM tile usage policy is sensible: the tile servers are not free, so heavy use is forbidden. I don't want to rely on a service that cannot scale.

I added a few free alternative tile layers (the Stamen and Humanitarian OSM ones), but I certainly don't want the default (or worse, only) tile provider to be one of these. I will not abuse free services that depend on donations and good will.

[strider72]

How do all the FOSS map apps that use OSM do it? Are they basically just cheating?

[deckerst]

Maybe I'm wrong and OSM is happy with mobile apps using it, as they may not consider it heavy usage.

By principle though, I don't want to adopt a solution that will break if someone somewhere at OSM decides to block calls from this app.

[flexagoon]

How do all the FOSS map apps that use OSM do it? Are they basically just cheating?

What apps are you talking about? The most popular mobile OSM apps are Maps.Me/Organic Maps and OsmAnd, and they both use their own tile servers

[strider72]

It's entirely possible "they host their own copies" is the answer

[deckerst]

So pure F-droid distribution seems out (unless there's a sensible solution to the API key conundrum) but, starting with the next release, Aves will likely be on IzzyOnDroid.

IzzyOnDroid has in the end the same constraints as F-Droid: they dislike Crashlytics and Google Maps.

[flexagoon]

@deckerst do you know how much resources OSM tileservers consume? If it's not too resource heavy, then I can host a tileserver for you on my RasPi

[deckerst]

It's kind of you to suggest, but I'd rather not depend on an individual. Anyway, I've prepared a flavor of the app (for the next release, likely next week) that should satisfy Izzy's criteria.

[flexagoon]

It's kind of you to suggest, but I'd rather not depend on an individual. Anyway, I've prepared a flavor of the app (for the next release, likely next week) that should satisfy Izzy's criteria.

Yeah, I've seen that, that's great. Tho I dont know how good Izzy will be in the long run, since I saw that you plan to implement some ML stuff in the future, and that will increase the app size which is already almost too big for Izzy

[deckerst]

The APK size limit for Izzy is 30 MB. Actually, the universal APK of Aves is already too big, that's why the Izzy flavoured app is built as split APKs (one per ABI). The split APK for armeabi-v7 currently sits at 13.3 MB.

As for ML, it's likely to be via ML Kit (the on-devices API from Google) so that it does not cost me anything, and it's already available to many people. I believe the ML models are not necessarily bundled with the app, so the file size is probably not the issue here. Rather, it will increase the number of non-free dependencies! We'll see. I don't know when I'll get to these features anyway.

[flexagoon]

it will increase the number of non-free dependencies!

This and also it'll break those features on De-Googled devices. So yeah, I suggest agains MLKit but unfortunately I'm also not aware of any opensource face recognition libraries (I only know Tesseract for text recognition)

Edit: oh wait, there's OpenCV

[deckerst]

Could you expand on the "De-Googled devices"? Do you mean devices where Google services are not possibly available (because of diplomacy or industry issues), or devices where the device owner decided to boycott the company?

[flexagoon]

I mean both, but mainly the second case, because those (including me) are one of the main use cases for using opensource apps. Ppl who use custom ROMs like LineageOS, CalyxOS, GrapheneOS, etc.

[deckerst]

I'm afraid we'll have a fundamental divergence of opinion about the topic. I open-source my code because I have no reason to close-source it. If possible I also use open-source code, but the priority to me is the resulting app, not an ideology. In other words: I do not develop an "open-source app", but I develop an "app" and that app happens to be mostly open-source.

To get back to the Google services, I think the way multiple apps can all benefit from the same set of on-devices services is neat. No need for each app to be bloated with various versions of large libraries. As far as I know, other ecosystems (like Huawei) provide similar on-devices services and I'm willing to make alternate versions tailored to these ecosystems (if there's demand).

As for free/libre software, I'm only vaguely aware of microG (which seems a brilliant idea but probably doesn't cover this). Are there ML components on the custom ROMs you mentioned? Is there a way for apps to use them without shipping their own versions?

[flexagoon]

but the priority to me is the resulting app, not an ideology

Yeah, I already figured that out, that's fine, I'm not an extreme Stallman-like "closed-source-should-be-illegal" opensource ambassador either, although I like the ideology and prefer using FOSS software whenever possible. What I'm saying is that a lot of people who use opensource software have degoogled devices, so you probably shouldn't just completely ignore that part of the userbase.

Are there ML components on the custom ROMs you mentioned

Lineage and Calyx don't have any. Graphene optionally supports installing Google Services in a sandboxed environment, so it kinda does.

But afaik developers of the opensource apps usually use some opensource ML libraries, and instead of bundling models with the app itself, the model is downloaded when you launch the app (eg. on the first launch you see a message like "Do you want to optionally instal models to enable AI features of the app?", and if you click yes, the models are downloaded and installed.)

[strider72]

CalyxOS optionally runs microG, and Lineage can do so as well

[strider72]

it will increase the number of non-free dependencies!

This and also it'll break those features on De-Googled devices. So yeah, I suggest agains MLKit but unfortunately I'm also not aware of any opensource face recognition libraries (I only know Tesseract for text recognition)

Edit: oh wait, there's OpenCV

I'm confused. When did face recognition enter the conversation? Does this app use face recognition?

[flexagoon]

When did face recognition enter the conversation? Does this app use face recognition?

@strider72 it doesnt, but deckerst said that in the future Aves may have object and face recognition with Google ML Kit.

The discussion started here: https://github.com/deckerst/aves/issues/29#issuecomment-962454989

[deckerst]

The app is now on IzzyOnDroid! 🎉

Edit: I forgot to mention it, but the app distributed on IzzyOnDroid is functionally the same as the one on Play. The only difference is that it does not include Crashlytics.

@strider72 several features would be unlocked by using some ML:

• face detection
• image labeling
• text extraction
• selfie segmentation

All of these are important to some users, but some others will think they are useless or even scary (making these optional will be essential). I intend to tackle them in the (distant) future, but I'll need to find a performant library that does not increase the app size too much. Anyway, I don't need to decide now. Many other items have priority over this.

I'll close this issue. For distribution on F-Droid proper, I explained in the comments above the reasons why it's not happening. If you have ideas for workarounds that do not involve self-hosting or removing features, feel free to reach out.

[flexagoon]

By the way @deckerst, sorry for replying to a closed issue, but I've noticed that the Izzy flavour uses leaflet instead of Google Maps. Why does the Izzy version still have a dependency on Google Maps api then?

[deckerst]

sorry for replying to a closed issue

No worries, feel free to voice your opinion on any issue, open or closed.

Both flavours use the same set of maps : Google, Humanitarian OSM and the Stamen ones. Nothing has changed (unless I messed up in a surprising way!). And I already explained why having Google as the default is important, given that the others run on donation or good will.

Oh but maybe I know what's happening... If the Google services are not available on your device, Aves automatically hides the Google maps from the available layers, and picks another one randomly. But if you run the same APK on a device that has the Google services, the Google maps options should show up and be used as default. Were the Google Map layers available for you before with Aves v1.5.4 but not anymore with the Izzy flavour of Aves v1.5.5?

[alexanderadam]

I'll close this issue. For distribution on F-Droid proper, I explained in the comments above the reasons why it's not happening. If you have ideas for workarounds that do not involve self-hosting or removing features, feel free to reach out.

I'm not quite sure but if I understood this situation correctly, the only thing that's left would be this:

Firebase is not actually what's blocking me now. I've discovered that F-Droid cannot handle API keys as a secret.

Maybe a simple option to put an own API key in the settings could be the solution. Unless the key isn't available, the map button could be disabled.

Also I have the feeling that aves wouldn't cause too much traffic on OSM, would it?

I really love aves and it would seriously be great to have in on the official F-Droid repos.

[flexagoon]

@alexanderadam actually I wanted to create a fully FOSS fork of Aves and publish it to F-Droid (only if @deckerst is fine with that, of course). Though I can't tell you a specific time when I'll try to do it. Most likely not in the next few months.

[alexanderadam]

I wanted to create a fully FOSS fork of Aves and publish it to F-Droid

This sounds great but wouldn't it better if you'd rather provide PRs to the origin repo? This way users could profit from fixes in both apps and increases the likelihood of having contributors at one place.

[flexagoon]

@alexanderadam no, this repository does not accept PRs and deckerst doesnt plan to. I think it would make sense to create a separate Aves-FOSS project, like Telegram-FOSS is for Telegram.

[alexanderadam]

Oh, okay. I wasn't aware of that. :scream: In that case you're obviously right by creating an own fork. :+1:

Please ping me, once you created it.

[flexagoon]

@alexanderadam deckerst actually explained why PRs are not accepted: https://github.com/deckerst/aves/discussions/159

[deckerst]

Maybe a simple option to put an own API key in the settings could be the solution.

Let's think about regular users, who do not mind using the Google Maps services already on their device. Why would Aves force them to create their own API key to use them?

As for users who do not have the Google Maps services on their device, Aves already hides related features.

Anybody can use F-Droid to download and update the app, via the Izzy repo. I don't understand what the problem is.

create a fully FOSS fork of Aves and publish it to F-Droid (only if @deckerst is fine with that, of course)

If it's legal it's fine, you don't need my permission. That said, you won't get my blessing, as my opinion is the following: from a product perspective, the copycat culture is detrimental. Forking to provide a new product (with a new vision and active development) is great! But forking to provide the same product with tweaks is noisy: you get a dilution of product identity just to please a few vocal users. These few users do not represent users in general, so it's a shame that they have so much influence on what's visible on alternative stores like F-Droid.

As I said, this is my opinion, but you're free to fork and do whatever. Beauty of open-source.

[flexagoon]

@deckerst

As I said, this is my opinion, but you're free to fork and do whatever. Beauty of open-source

Obviously I am legally allowed to do this. But you are the creator of the app after all, so if you don't want me to do this, I won't.

These few users do not represent users in general, so it's a shame that they have so much influence on what's visible on alternative stores like F-Droid.

F-Droid is already the "foss app store" which (in the main repository) only allows 100% FOSS apps. So the userbase of F-Droid mostly consists of people who want FOSS apps as well. And I don't want to distribute the fork on anywhere else except F-Droid, your app will stay the only one on Google Play.

Also I think that creating a fork for that will save you some time, because you will no longer need to maintain a separate flavor that you don't personally need just for the few users who do.

[deckerst]

Maybe you're right. In any case, a FOSS believer will eventually do it so it might as well be you, being understanding and constructive as you are.

I like the concept of F-Droid repositories, like IzzyOnDroid, because it allows people to decide for themselves what kind of app they want, instead of being served on the main repository degraded "pure FOSS" versions of legitimate apps. I value freedom of choice and thinking in nuances, so this idea of purity is concerning to me.

[seniorm0ment]

Highly interested in a fully libre fork of Aves. Until then I will not use or suggest others to use. Sorry.

[IzzySoft]

With the app in my repo for a while now, I today wondered why I don't have it on one of my devices. Just installed it on a test device and found out why: Google Maps. Well, good thing is the app does not connect to GMaps directly but "just" to Mapbox. I'd really love to be "degraded to pure FOSS" please as you've put it, and have OSM instead :wink:

That said (without any malice in mind), I don't feel "degraded to pure FOSS", but rather "elevated" – as with "pure FOSS" I don't have to guess what's done with my data. I know, no guarantees – but chances are much lower that some "evil player" picks at them. No offense meant, and I'd trust you won't do such a thing willingly; but with proprietary things you cannot even tell for sure what it really does and so we all have to "trust blindly".

Having an Aves version "degraded to pure FOSS" would be the absolute icing on my cake; didn't take me longer than a minute to love the app…So maybe there's a chance?

[Ilithy]

Highly interested in a fully libre fork of Aves

Identically for me, I use a smartphone (Pixel) under grapheneos for this reason (exclude Google from my digital life), I would love Aves to be free of Google crap.

Thanks ❤️

[deckerst]

the app does not connect to GMaps directly but "just" to Mapbox. I'd really love to be "degraded to pure FOSS" please as you've put it, and have OSM instead

Aves does not use Mapbox, i wonder what makes you think so. Also, FOSS believers often present Google Maps and OSM as exclusive either-or offerings, but i do not think that way. Aves offers both Google Maps layers (if the device has the Google services installed) and some layers that use OSM tile data. If someone wants to use Aves without Google Maps they already can. They switch to another layer and move on.

[IzzySoft]

Aves does not use Mapbox, i wonder what makes you think so.

Thinking about it: That might be microG replacing GMaps in my case, so error in thinking on my end.

If someone wants to use Aves without Google Maps they already can.

Oh, nice – I wasn't aware of that (maybe we should point that out in the app description). Where can one perform that switch? I mean, make it the default before "something is called" (found it only in the info map itself, not in the global settings). And is it possible to use/define other OSM layers (e.g. Standard or ÖPNV – cycling & Co would be overdoing it I guess) as well? Still:

Offending libs:
---------------
* Google Maps API (/com/google/android/gms/maps): NonFreeDep,NonFreeNet
* Google Mobile Services (/com/google/android/gms): NonFreeDep
* Google Maps for Flutter (/io/flutter/plugins/googlemaps): NonFreeNet

3 offenders.

The first 2 are non-free (proprietary) libs included with the app :man_shrugging: (just stating the obvious, no offense meant of course)

And that said: the more I discover inside Aves, the more I like it :smiley:

[deckerst]

Where can one perform that switch? I mean, make it the default before "something is called" (found it only in the info map itself, not in the global settings).

At the moment, users can only change the map layer through the map overlay (the one in Info page, as well as the full map page), but not from the app settings, as you've correctly assessed. The setting is sticky, though, so you don't need to do it again. I may revisit the settings page, but I'm careful as there are already a lot of settings and i try to avoid superfluous and redundant ones.

And is it possible to use/define other OSM layers

I'd like to eventually allow users to add custom layers. It's geeky by nature (with URLs, API keys...) but it would unlock useful layers that i won't make built-in (e.g. for licensing reasons, as I explained above for original OSM tiles).

[IzzySoft]

but I'm careful as there are already a lot of settings

Yes, that's often the conflict. A possible alternative would be allowing to set a layer before the "first call" – i.e. when it would be used for the first time (eg using a popup, as if the user had triggered the layer selector manually).

add custom layers

That sounds cool, thanks! I personally mostly miss the "standard layer", but custom layers indeed would unlock a lot of potential.

I explained above for original OSM tiles

Scrolling up I couldn't find the reference (will try Ctrl-F next – ah, there; wasn't there something with many custom/self-hosted tile servers being added meanwhile? And wouldn't the danger to be locked-out apply to Google as well? I don't dare asking to make that an option to select from, we just had that question. But if each user could use their own API key, that'd be covered again, yeah), but noticed another remark: I hope you won't add ML Kit, as that'd be another proprietary dependency…

[seniorm0ment]

Not sure what I'm missing I skimmed the comments. However if the non-free dependencies and non-free network services non-features could be fixed (removed) for a completely libre experience I'd install the app in a heartbeat. Sounds like that is what is attempting to be done?

[deckerst]

Sounds like that is what is attempting to be done?

@seniorm0ment not by me. If people have the Google Mobile Services installed on their device, i don't see why Aves wouldn't connect to them.

[IzzySoft]

@deckerst I guess what @seniorm0ment was pointing at is that

Offending libs:
---------------
* Google Maps API (/com/google/android/gms/maps): NonFreeDep,NonFreeNet
* Google Mobile Services (/com/google/android/gms): NonFreeDep
* Google Maps for Flutter (/io/flutter/plugins/googlemaps): NonFreeNet

3 offenders.

will make an inclusion at F-Droid.org impossible. And as those libraries are proprietary, nobody but their developers can say for sure what they really do. Some of us have a "native mistrust" there – Google isn't exactly known as "the privacy respecters" but rather "the data collectors" :wink:

Which is also why I asked for that popup before showing a map for the first time:

A possible alternative would be allowing to set a layer before the "first call" – i.e. when it would be used for the first time (eg using a popup, as if the user had triggered the layer selector manually).

Would you consider that, maybe – so no data goes that way "by default" at least? Having GMaps selected as default would make it a single tap for those who don't care (or even prefer GMaps here), while us privacy folks would have a choice and then only need 2 taps (select OSM, confirm). A single time, on first call only. After that, the selection would be remembered as it is now. Should not be too hard I guess (in my naïvity I imagine that configuration field being NULL initially, thus prompting the described popup, and after the popup was confirmed it has a value).

Of course a "full floss flavor" would be even better – but that might also be a lot of work. Thinking aloud: if someone provided that flavor as PR, would you welcome it? Just to clarify: "extra flavor", so your current build would stay but you additionally could provide a FOSS build. If so, we could open an issue for that to be marked with an "help wanted" label – and I'd even make a "service call" on the Fediverse to hopefully attract potential supporting devs. If it works out, the FOSS build could be provided via F-Droid.org, while the current build could remain with my repo (to e.g. make switching from Play easy – which can be quite useful when some update gets stuck in their review, which I've heard is not exactly a rare case). To avoid confusion, the FOSS flavor could have a .foss or .fdroid appended to the applicationId even.

[deckerst]

Would you consider that, maybe – so no data goes that way "by default" at least?

Yes, for the izzy build only. I'll keep the map layer provided by local mobile services as default for play and huawei.

Of course a "full floss flavor" would be even better – but that might also be a lot of work.

Another flavour is actually trivial. I already set up all the infra for the play/huawei/izzy flavours. I explained reasons above why I kept GMaps so far.

If it works out, the FOSS build could be provided via F-Droid.org, while the current build could remain with my repo.

That's interesting. If both builds are available to F-Droid users (i mean, users who added your repo would still have access to the "full" build), then I'm willing to make and provide the "degraded" foss build alongside.

[IzzySoft]

That's interesting. If both builds are available to F-Droid users

That's the idea, yes. And as both are visible in the client, the "F/LOSS" one having a "suffix" to its applicationId (please make it an applicationId inside the flavor – I vaguely remember the F-Droid build system had issues with the applicationIdSuffix gradle feature, not sure if that's still the case) makes them show up in parallel if both repositories are enabled. If then the F-Droid one has a slightly different name as well (e.g. "Aves libre"), all confusion can be avoided. The full_description could even point out the differences plus where to get which version. I'd volunteer to provide the corresponding (suggested) phrasing then.

then I'm willing to make and provide the "degraded" foss build alongside.

Wonderful :star_struck: I'll then help getting it to F-Droid.org (disclosure: I'm one of the maintainers there).