Avilability on F-Droid

[natrius]

I hope this app will be available in F-Droid, because updating manually is cumbersome.

https://f-droid.org/en/docs/Submitting_to_F-Droid_Quick_Start_Guide
Or set up your own repo. IzzySoft has its own repo for apps that need to change something to be accepted in the official repo, might be worth a look as well https://apt.izzysoft.de/fdroid/

[Zverik]

For now you can use apks from this repo. After the beta testing concludes, I'll expand on delivery options, and maybe include f-droid, if that's not too much work.

[matkoniecz]

Note that publishing on F-droid does not require action from app owner, as far as I know: it is enough that app is open source and someone else can setup F-droid publishing

[XandrexOSM]

Note that publishing on F-droid does not require action from app owner, as far as I know: it is enough that app is open source and someone else can setup F-droid publishing

yes, it is true that it is not mandatory to have the developer act to have the app in F-Droid.

Nevertheless :

• there are conditions as stated here : https://f-droid.org/en/docs/Inclusion_Policy/ someone needs to make sure that the conditions are met (again, this can be someone else than the dev team, but the dev team would be the most knowledgeable IMHO).
• someone has to open a "request for packaging". There are more than 200 open requests currently. https://f-droid.org/en/contribute/ How does the F-Droid team decide which they prioritise?
• the developer for any upcoming version must make sure they continue to comply with F-Droid's inclusing policy, otherwise the repo in F-Droid may stop being updated.

[matkoniecz]

Though F-droid drudgery can be also done by interested people - who are neither every_door developer nor F-Droid maintainers.

For example for StreetComplete F-droid things are not handled by app author (as far as I know), though some pull requests were accepted and changes requested in issues were done to keep F-droid happy.

How does the F-Droid team decide which they prioritise?

II bet that submitting PR implementing packaging request is a good way to speed it up.

[Zverik]

The only thing not compliant with their inclusion policy is the private.dart file with API keys. There are no ads, no tracking, and no binary libraries in there.

[l29ah]

The only thing not compliant with their inclusion policy is the private.dart file with API keys. There are no ads, no tracking, and no binary libraries in there.

So just add it to the repo. Pulling the keys from the apk is quite easy anyway, so it doesn't make much sense to hide them.

[mpeter50]

The app also contains Google Mobile Services (according to App Manager).

I think that too is a problem for F-droid, and also may be for privacy.
For what purpose is that library used?

By the way the app is very promising, I have missed an app that is lighter on resources than OsmAnd and can be used for creating new POIs. Thanks for your work!

[Georift]

Perhaps we could submit this to IzzyOnDroid's repo? I raised the point over at #358 before I found this issue.

There are lighter criteria for inclusion, and we can take the APK's that are already being built and released as a stop gap before F-Droid inclusion?

[IzzySoft]

The only thing not compliant with their inclusion policy is the private.dart file with API keys.

Unfortunately not, there's more:

Offending libs:
---------------
* Google Mobile Services (/com/google/android/gms): NonFreeDep

1 offenders.

I was asked to include your app with my repo, and I'd really like to. But your app is also beyond the per-app limit of 30M in my repo. Now I'd be willing to close an eye – but closing both eyes would make me blind 🙈 Does your app really depend on GMS (i.e. it would not run on AOSP devices which have no GSF installed)? What for is GMS needed here? If you could get rid of that dependency, I'd make an exception size-wise.

(I've also checked whether an ARM-only build – i.e. v7+v8 – would fit in, that'd be around 33M, and a single-arch build around 25M, while the current multi-arch APK is at around 42M. Just saying in case you'd consider one of those. Size is the curse of Flutter; here just the Flutter libs alone come at around 20M).

TL;DR: could you please get rid of the GMS dependency and ideally also get the size down a bit? Then I gladly accept your app into my repo, and you might even have a new user at the same time (I currently use StreetComplete, which is pretty nice – but does not let me check what objects already exist; so I'd never raise a note with "here's a bench now" because it might just be noise as the bench was already mapped 🙈). Thanks!

PS: Ah, found the culprit! You're using the geolocator plugin. That's known to drag in GMS. Find hints to possible solutions here.

[Zverik]

Thanks Izzy, I'll check this out. Next week there'll be the 1.0 release (the app is now in beta), so that's when it'll make sense to publish. Geolocation library is important, and I heard it doesn't work well with GMS disabled, so I will have to look into it. Possibly after the conferences, in three weeks.

I guess I could try compiling only for ARM, I'll see how one does that. A very large part of the APK is a presets database, which is 41 MB uncompressed, so there are limits there.

[IzzySoft]

Thanks @Zverik – and for the books: We had that issue with geolocator at F-Droid many times. The replacement seems to have worked out fine, at least I never heard any complaints. Also take into consideration that many F-Droid users run their devices Google-free – so they won't have GSF available. Which would mean that, if you rely on GMS it wouldn't work for them at all.

As one of the replacements is considered a drop-in, a possible path could be using different build flavors: one with geolocator, one with the replacement. If it's really drop-in, all that would need is declaring googleImplementation for the GMS variant and fossImplementation for the replacement flavor (speaking gradle here, no idea how that's done with Flutter).

Full ack to the release being the best point to introduce your app to (whichever) F-Droid repo 😄

As for the size: Yes, that database makes up a huge part. I just unzipped the APK and removed the arch-specific lib dirs, then zipped again – to get a size estimate. Values are above: just removing x86 brought the size down to around 33M, keeping only armv7 in 25M. Looks a bit different for the installed size maybe, but I'd say a build with both ARMs in might be a good compromise. And GMS gone, I'd make one of the rare exceptions allowing your app despite of its breaking the limits – it definitely looks worth it!

So TL;DR: please give me a ping when the new release/APK is there. I gladly run my scanner over it again and report back; your app might well be eligible for f-droid.org then (not sure about the API key part mentioned – but we can look into that one once the other point is solved).

[siiky]

For anyone currently manually downloading and updating ED from the GH releases: I guess not everyone knows about this feature. but you can set GH to notify you of new releases. No need to check every now and then.

At the top of the page, click the "Watch"/"Unwatch" button (left of "Fork"), click "Custom", and select "Releases".

[IzzySoft]

@siiky this would still mean manually downloading and then sideloading the APK. Having it in an F-Droid repo would mean either just pressing a button when notified, or even have it updated automatically (depending on the device's setup).

[siiky]

@IzzySoft Yeah, I know, I use F-Droid too! I just wanted to make life a little easier for those that don't use GPlay at all. :)

[Zverik]

This is definitely planned — I've even hardcoded tokens to comply with F-Droid policy. I'll have a go at it in September.

[Zverik]

(Or maybe somebody else wants to try making a pull request there?)

[IzzySoft]

@Zverik The Geolocator issue is taken care for? Its GMS dependency is a show-stopper for F-Droid. That I'd offer your app a place in my repo straight away if at least the size would go down a bit (over size limit and GMS is a bit much – one of the two solved and I'd take it in) I've already mentioned, right? Then it'd be available to F-Droid clients immediately, to shorten the time until it shows up at F-Droid.org…

[IzzySoft]

A pity today's release still comes with the Geolocator and thus with GMS 😢 You've seen the hints on replacing it with a GMS-free fork I've linked above on August 9th?

[SquishyBubble]

I think adding it to F-Droid could be beneficial since the open data/open source overlaps quite a bit. Great work on the app!

[Zverik]

So I spent a few hours today on this. Building an APK for Izzy would be easy: I updated the geolocator removing the dependency, and there are options for building. But — currently geolocation does not work without GMS, see #199. And until that issue is solved, there would be no point publishing the editor. I'll try solving that issue now.

[IzzySoft]

And until that issue is solved, there would be no point publishing the editor.

Until that's solved there might be a problem with the listing at F-Droid.org (though not necessarily as long as there are no non-free parts in the app itself; it would only raise NonFreeDep then). But if there is such an APK, it could be published to my repo; it might work on devices with microG at least.

[Zverik]

I have submitted the app to F-Droid: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11955

[IzzySoft]

@Zverik in case you've missed the ping: F-Droid asks for ABI splits. Which would also be good for the similar request at my repo – though once included by F-Droid, maybe it's not even needed in my repo anymore?

[deevroman]

🎉 https://f-droid.org/ru/packages/info.zverev.ilya.every_door

[IzzySoft]

🥳 https://floss.social/@IzzyOnDroid/109604200599761459 – congrats, @Zverik! I'd consider this issue solved then 😃

[natrius]

🥳 🎉

[mnalis]

The f-droid description should note why it got "This app promotes or depends entirely on a non-free network service" anti-feature (instead of letting user wonder)

[Zverik]

Thank you @IzzySoft for helping with the release!