Android: "Network-based location" vs "Network location provider" and other location functionality

[alohapersona]

There is two entries that are somewhat related, but not exactly the same. I think there's been some mixing of them.

• "Network-based location" should be about the functionality to locate based on Wi-Fi, Bluetooth and/or mobile networks. In other terms, it's a feature to provide geolocation in scenarios where GNSS typically do not work (well), e.g. indoors, or where one wants to avoid it's battery consumption (which is typically significantly higher than network-based). GrapheneOS Emulated network location provider does not provide this functionality. DivestOS can provide it when installing microG and LineageOS can provide it when installing microG or Play Services.
• "Network location provider" should be about the OS providing a "network" location provider to installed apps. Which means that if an app requests a location from the network provider from the OS (and not the GPS provider that uses GNSS), there will be replies. This is probably what GrapheneOS Emulated network location provider can do, but I'm not sure it will be redirected to Google when using Sandboxed Play Services (should be easy to confirm with the SatStat app, that allows to display the GPS and network provider on a map for comparison). LineageOS should be able to provide this with both microG and Play Services and also Qualcomm NLP on some devices, I am not sure if DivestOS can.
• There could be two additional location related functionality that could be considered in the comparison:
  • "fused" location provider support: It's supported by Play Services, but not microG, but also requires the OS to support it. Some OS ship with a broken fused location provider (see https://github.com/organicmaps/organicmaps/issues/4158#issuecomment-1519019882).
  • Google Fused Location Provider API support: This can be provided through Play Services, microG and also there is a feature in GrapheneOS to emulate it when Sandboxed Play Services is installed (but only then, as apps would not try to use this API if they don't detect Play Services installed).

[eylenburg]

Hi, thank you for the issue.

On the row "network-based location" in "features", I think it's correct as it. DivestOS doesn't support it even with microG ("Enabling the location provider in microG/UnifiedNlp will not do anything as it does not have permission to be a system location provider."). You're right about Graphene's GNSS redirect not really offering a network-based location (e.g. when indoors) but it's still possible with the optional Play Services. So I think the green colour can stay, to be consistent with the other ROMs that have (optional) network-based location via microG. But I think it's worthwhile elaborating a bit more on the limits of the GNSS redirect.

I might just rename the other row to "provider for network-based location" because this in the "Degoogling" sub-table. But you actually made me think about the appropriate colour for GrapheneOS. "Emulated/GNSS,or Google" is basically the same as "None, or Google", which I've marked light green in other cells (e.g. SUPL for /e/OS). So perhaps it should be light green for GrapheneOS as well - it is fully degoogled by default but a bit more limited in functionality (e.g. as you mentioned, GNSS wouldn't work when you're indoors).

Is Fused Location something combining the data from GNSS and a network-based location to get the best mix of accuracy and battery use? It might be worth adding, at least in a single row, with support for Stock Android and GrapheneOS with Play Services.

[alohapersona]

Regarding DivestOS FAQ: Enabling location in microG will not allow using the "network" location provider, however it will provide network-based locations when accessed through the Google Fused Location Provider API implementation in microG. For example, if you used Google Maps (which uses Google Fused Location API) on DivestOS with microG it could get network-based indoor location. So the the FAQ in DivestOS is not wrong, but also not completely true when taking all possible ways to get network location into the picture.

Regarding Emulated network location provider in GrapheneOS: The solution of GrapheneOS helps with a lot of apps, because most apps that request network location are not particularly interested in ensuring that they get indoor locations, but rather care about not consuming additional battery, as GNSS is typically battery intensive. A traditional example is weather apps, which fetch your approximate location in the background every hour so they can warn you of rain at your location. As they request in the background every hour, it would be bad if they consumed a lot of energy for doing so, so restricting to network location is a good idea, but they typically don't fallback to GPS when network location is not available, so GrapheneOS doing it for them, fixes the issue at the cost of additional battery use.

Fused location is essentially mixing, yes. On traditional Play Services systems, Play Services provides both APIs (just like they also provide network location). I don't have a full picture of which ROMs support which of the two APIs and to what capacity (i.e. if they require a network location provider present or they can just fallback to GNSS). I know that GrapheneOS has a compatibility feature for the Google API, not sure what's their status on AOSP fused API.

[thestinger]

"Network-based location" should be about the functionality to locate based on Wi-Fi, Bluetooth and/or mobile networks. In other terms, it's a feature to provide geolocation in scenarios where GNSS typically do not work (well), e.g. indoors, or where one wants to avoid it's battery consumption (which is typically significantly higher than network-based). GrapheneOS Emulated network location provider does not provide this functionality. DivestOS can provide it when installing microG and LineageOS can provide it when installing microG or Play Services.

GrapheneOS emulated network location uses GNSS + A-GNSS which does download data on cell towers as part of SUPL. The way SUPL is used depends on the SUPL configuration. Using it to detect location without GNSS availability requires sending more data so that's not what's normally done.

"Network location provider" should be about the OS providing a "network" location provider to installed apps. Which means that if an app requests a location from the network provider from the OS (and not the GPS provider that uses GNSS), there will be replies. This is probably what GrapheneOS Emulated network location provider can do, but I'm not sure it will be redirected to Google when using Sandboxed Play Services (should be easy to confirm with the SatStat app, that allows to display the GPS and network provider on a map for comparison). LineageOS should be able to provide this with both microG and Play Services and also Qualcomm NLP on some devices, I am not sure if DivestOS can.

OS location requests are never redirected to sandboxed Google Play, and location requests made to sandboxed Google Play are redirected to the OS by default. Sandboxed Google Play is not part of GrapheneOS. The option to disable rerouting location requests allows using sandboxed Google Play for network location in apps choosing to use Google Play network location explicitly, not apps using the OS network location provider. Nearly all apps from the Play Store use the Google Play network location API because that's recommended and provides better backwards compatibility with old Android versions.

not sure what's their status on AOSP fused API

It's the standard implementation. There aren't currently network location providers bundled with the OS beyond the emulated one due to privacy, security and other issues with existing implementations including microG. We can't use code which leaks location when it's not supposed to or allows arbitrary apps to provide location providers trusted by the OS.

[thestinger]

Google Play has their own location providers including a fused provider. This is mixing a lot of things up. I suggest leaving things as they are instead of changing them in a confusing way which is going to result in accuracy issues. There is no good reason to document the fused provider that's the same across each OS.

[thestinger]

Sending real-time location data to a network service is very privacy invasive. That's why the default on GrapheneOS is emulating it and redirecting location requests to Google Play to the OS where network location is emulated. Using network location by default is a privacy issue. Google requires consenting to using it as part of the initial setup wizard, where if you disagree it provides the option to opt in later.

[alohapersona]

OS location requests are never redirected to sandboxed Google Play

Thanks for confirming, so the table is incorrect, as it currently states that "Network location provider" can be Emulated/GNSS or Google, when in fact it can't be Google in GrapheneOS. Network-based location from Google can only be used when Google Fused Location Provider is used, so we likely want that as an independent row (as @eylenburg already suggested).

Sending real-time location data to a network service is very privacy invasive.

Agree 100%, maybe this should be added as a comment to the table.

---

For clarification, the idea would then to have three rows (instead of current two) that would be more accurate. Currently there is:

1. Network-based location
2. Network location provider

With the scope of both very unclear.

The idea is to change to

1. Network-based location (referring to the ability to locate based on wifi and cell towers)
2. Network location provider (referring to providing an implementation for AOSP "network" location provider)
3. Fused location provider (referring to providing an implementation of Google Play Services' Fused Location Provider interface)

As far as I understand, GrapheneOS has support for all of them, no? 1. can be provided through Play Services if installed, 2. is emulated via GNSS, 3. is either GrapheneOS own implementation (using GNSS) or Play Services (supporting both GNSS and network-based location).

[eylenburg]

At the moment the two rows have these intentions:

1. In "Features": can the OS find the (approximate) location without GNSS? For example when you're indoors and can't find the satellite. Sounds like this would still be possible on GrapheneOS but through the fused location provider - just the name of the row needs to be changed to something more fitting.
2. In "Degoogling": will the phone connect to Google servers when the (non-GNSS) location is requested by an app (e.g. the example for a weather apps requesting a rough location every hour)? Here, it would be "no" for GrapheneOS, although right now I'm a bit confused whether it should say "no, because the location is always retrieved through GNSS" or "no, unless you decide to install Play Services which can then get the location from Google"

[thestinger]

Thanks for confirming, so the table is incorrect, as it currently states that "Network location provider" can be Emulated/GNSS or Google, when in fact it can't be Google in GrapheneOS. Network-based location from Google can only be used when Google Fused Location Provider is used, so we likely want that as an independent row (as @eylenburg already suggested).

The table is accurate for what it shows. Network-based location is supported in 2 ways: emulated via GNSS + A-GNSS including via SUPL or via sandboxed Google Play for apps using the Google Play location API. I don't see any reason it should be split into an additional row and your proposal for what it should say about GrapheneOS is not correct. SUPL is not an Android network location provider but it is network-based location, and it is supported by GrapheneOS. If you want to change the table to add another row, it should still show GrapheneOS as supporting it.

Network-based location (referring to the ability to locate based on wifi and cell towers)

GrapheneOS has location via cell towers enabled by default (SUPL) including for the network location API.

Network location provider (referring to providing an implementation for AOSP "network" location provider)

This is provided by GrapheneOS via GNSS + A-GNSS including SUPL. It is not provided via Google Play. Google Play network location provider is a separate thing, which is redirected to the OS by our compatibility layer by default but the real thing can be used too as can another network-based location provider similar to how it works.

Fused location provider (referring to providing an implementation of Google Play Services' Fused Location Provider interface)

AOSP has a fused location provider and should not be a row in the table because each OS has the same thing. Google's location provider is a separate thing.

[thestinger]

@eylenburg

In "Features": can the OS find the (approximate) location without GNSS? For example when you're indoors and can't find the satellite. Sounds like this would still be possible on GrapheneOS but through the fused location provider - just the name of the row needs to be changed to something more fitting.

It is possible on GrapheneOS via sandboxed Google Play. The fused location provider is a standard thing that's in AOSP. Google Play has separate definitions of the location providers. @alohapersona does not correctly understand how it works. Their proposal would overcomplicate it and result in simply communicating the same info in a much more confusing way. There is a limitation of what GrapheneOS does which is that we don't currently provide a toggle to reroute the OS location to the Google Play location like the stock OS does, which doesn't need a new row if you want to explain the fine details. We could easily provide it but people who actually want to use Google Play location can just be using the Google Play Store variants of apps. It would be an incredibly niche toggle to support, so we didn't add it yet. It being possible to add a super niche feature doesn't mean it makes sense.

It could also be possible through the existing SUPL support if we offered a toggle for it. SUPL is cell tower based network location, but is currently used in a form which doesn't provide results when there isn't adequate GNSS reception to avoid inaccurate estimates due to bad cell tower data, etc.

In "Degoogling": will the phone connect to Google servers when the (non-GNSS) location is requested by an app (e.g. the example for a weather apps requesting a rough location every hour)? Here, it would be "no" for GrapheneOS, although right now I'm a bit confused whether it should say "no, because the location is always retrieved through GNSS" or "no, unless you decide to install Play Services which can then get the location from Google"

The current info is correct, and this would not make sense especially based on how the other operating systems do not show which network location is used by default or if it's used by default, which is a privacy issue if it is.

The whole section on Google connections is problematic because it specifically singles out Google as a problem when there are more privacy invasive services, some of which are used by these other operating systems. It also doesn't list all the connections. It comes across as if it's listing privacy relevant / default connections but it's just listing ones involving Google and not all.