Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New release #247

Closed
marek22k opened this issue Feb 16, 2023 · 13 comments
Closed

New release #247

marek22k opened this issue Feb 16, 2023 · 13 comments

Comments

@marek22k
Copy link

Hello,

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

@mar-v-in
Copy link
Member

mar-v-in commented Feb 16, 2023

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
Copy link
Author

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

@MayeulC
Copy link

MayeulC commented Mar 14, 2023

@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
Copy link
Member

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
Copy link

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
Copy link
Member

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
Copy link

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
Copy link

sbor23 commented May 30, 2023

@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.

@mar-v-in mar-v-in pinned this issue May 30, 2023
@LuccoJ
Copy link

LuccoJ commented Jun 10, 2023

@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
Copy link

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
Copy link

LuccoJ commented Jun 10, 2023

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

@IzzySoft
Copy link

Yes, didn't I even state that? I just wanted to make it clearer to those who might not 😉

@LuccoJ
Copy link

LuccoJ commented Jun 11, 2023

Okay, okay, let's agree to agree 🤣

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants