New release

[marek22k]

Hello,

the last release on GitHub and F-Droid is from 2017, is it possible to create a new release?

[mar-v-in]

Unfortunately due to changes to AOSP, it's no longer possible to run UnifiedNlp reliable in latest Android the way things worked before (i.e. external packages bound from the network location provider can be paused, resulting in the location provider to lock until next restart). The updates/commits you're seeing were attempts to improve this, but field tests show it still does not work reliably.

As such, the plan is to drop support for UnifiedNlp, its module system and the standalone app and build a new variant as part of GmsCore that doesn't suffer from this issues.

[marek22k]

That's sad to hear. Thanks for the answer!

[MayeulC]

@mar-v-in Thank you a lot for linking me to this issue; I read multiple threads before posting the above message, yet this is the most technical explanation I've encountered.

1. Do you have a link, open issues, or Android changelogs describing the issue in more detail? I won't have the time to do Android development work soon, but I may come back to it later.
2. Is this also the case for system-priv apps?

external packages bound from the network location provider can be paused, resulting in the location provider to lock until next restart

I guess you meant "packets" as in network packets, or Android intents? Are you describing a lock similar to a mutex issue, due to the current software architecture, or is this a more fundamental issue, and UnifiedNlp is not feasible anymore?

[mar-v-in]

As you probably know, UnifiedNlp uses a module concept where location providing modules are installed as independent APKs and bound using an Android service (using the Binder RPC system). Previously, such a bind relationship would keep the bound package process running and fully operational if and as long as the binding package process remains running. This is no longer the case in latest Android versions and Android would under certain conditions pause the bound process, resulting in the binder interface being stuck until the process is unpaused or terminated. UnifiedNlp itself is exempted from any such pausing while being registered as a system location provider.

It probably would work if we had UnifiedNlp and the modules as a privileged system app. However that would defeat the whole purpose of using a module system (as users can't easily install or uninstall the modules). So what makes most sense is to get rid of the module system entirely, allowing for even better performance and reduced energy consumption for the location logic.

Even though the plan is to build that directly into microG GmsCore, that doesn't mean it won't be possible to build that part of microG GmsCore into a standalone app without any of the remainders, if there is a lot of interest to do that (I wouldn't know why it's so important to have that, but that's a topic for discussion at a later point).

[IzzySoft]

Just for understanding, @mar-v-in – would that mean "backends" could no longer be maintained/installed separately, but would need to be integrated into core directly (and thus microG Core would need to ship with all of them built-in)? So if one backend (say, Nominatim or MLS) needed an update, or a new backend became available, it would require an update of Core? I see the performance advantage, but also a huge maintenance disadvantage then.

No complaints, I just want to make sure I understood correctly. (And I'm not entirely sure about other implications either)

[mar-v-in]

Yes. That's how it's going to be.

Given that the set of "backends" we currently have is rather small and some have overlap in features, I think this is very much reasonable. In fact it probably is going to decrease total maintenance work: caches are only to be implemented once, backends could be more synchronized to new wifi/cell information being available and so on. It also makes it just much clearer to everyone where to change code (moving from ~5 repository to a single one).

[IzzySoft]

I currently count 12 Location Provider; not sure if all of them are still maintained. Looking at the list I see some issues arising with some of them (e.g. Baidu, AMap, Apple would raise NonFreeNet; but then that could be avoided with having them all turned off by default).

But that's an entirely different issue (sorry for hijacking this one here) – and yes, that's probably how it has to be then. Looking forward to how that will be implemented – that will be quite a move. 🤞 for a smooth move!

[sbor23]

@mar-v-in Thanks for given a summary of what's going on, even for someone who is not familiar with Androids inner workings. Could you please sticky this issue so it's easier to find?

As a happy user of plain LineageOS without GApps or MicroG: A standalone app would still be highly appreciated, even if it needs to be moved manually to system-priv after every update.

[LuccoJ]

@IzzySoft then again, microG itself raises NonFreeNet the moment you turn device registration or push notifications on, which is one of the most used feature by many people. It's not used by everyone, of course, but like you said, just as it can be and is disabled by default, so could the "problematic" backends.

I personally am not at all thrilled by a prospect where the only available online location provider is Mozilla. Not everyone likes and trusts the same companies.

[IzzySoft]

microG itself raises NonFreeNet the moment you turn device registration or push notifications on

That's up to you to turn it on, and off by default. microG works without it, hence it's not a strict requirement and thus nor raised unless you raise it yourself – that AntiFeature is to make you aware of things enabled without you're enabling it yourself, but you know that of course.

I personally am not at all thrilled by a prospect where the only available online location provider is Mozilla.

Nor am I. Ideally someone provides a different one. Not sure if OpenCellID could be used that way. The RadioCells.org backend unfortunately has not seen any update for 5 years now, no idea if that's still working. Do other potential (and trustable) sources exist? Not that I myself could write a backend, not being an Android dev at all…

[LuccoJ]

You do realize that's exactly what I said about the NonFreeNet part, right?