Our latest 2025032500 release greatly improved our built-in network-based location. It's usually better than Google's network-based location in urban areas where Apple has competitive data. Unlike Google's service, position estimation is done locally by fetching location data for nearby networks.

You can enable this feature via the toggle we added at Settings > Location > Location services > Network location. You can optionally enable the standard Wi-Fi scanning toggle in the Location services menu to allow Wi-Fi scans when Wi-Fi is otherwise disabled to keep network-based location working.

Our implementation is currently based entirely on Wi-Fi Access Points (APs). Location data for nearby APs is fetched in batches from either Apple's service or a GrapheneOS proxy server. We also ask the service for up to 100 nearby APs which it provides with a reasonable density over a large area.

Our implementation caches location data for up to 10000 APs in an in-memory Least-Recently-Used cache with 15 minute expiry after last usage of an AP. This avoids persisting a local location history while enabling semi-offline usage. We can make these parameters user configurable in the future.

Most navigation apps use the fused location service providing the best result from GNSS (GPS, Galileo, etc.) or network-based location (when it's enabled). Other apps often prefer network-based location for lower power usage and quicker results not requiring GNSS reception. Some apps can't use GNSS.

Most apps on the Play Store use the Google Play services location service instead of the OS provided location service. By default, our sandboxed Google Play compatibility layer reroutes location requests from these apps to the OS location service so there's no need to give Location to Play services.

Nearly all users on Google Mobile Services devices have their network-based location enabled. This means some apps assume it's always available. For improved compatibility, our default enabled rerouting emulates the presence of network location with GNSS when the OS network location service is off.

In the near future, we'll be making several major improvements to our network location service including Wi-Fi RTT (Round-Trip-Time) for improved distance estimation and cell tower fallback to make it work better outside cities. There will also be a lot more efficiency and other improvements to it.

Longer term, we'll be providing our own location service rather than only a proxy along with full offline support via database downloads. It already works offline for a while based on the cache. We'll be using data from Apple's service to bootstrap our service, but we'll also be using other sources.

Source code is available here:

https://github.com/GrapheneOS/platform_packages_apps_NetworkLocation

It's new code and still being built out so it hasn't had much refactoring, optimization or tuning yet. It's a mix of Kotlin and Rust since we wrote position estimation in Rust for significantly better performance.

#GrapheneOS

Reply to this note

Please Login to reply.

Discussion

Thanks for the summary!

What's the privacy of the current implementation?

Default option for this setting sends any network location requests through a GrapheneOS proxy. If they don't want that, they can choose to request Apple directly or not use the feature. By default all location requests are routed through GNSS.

No other information is submitted beyond the BSSIDs being requested. As discussed in the above post it submits a wide range of access points rather than a small amount which should broaden out the range of the search.

Is there any plan for smartphones to detect a face different from the user who should be using it and automatically shut down?