matchboxbananasynergy
Fair enough. What exactly is the difference between Network location on the bluetooth/wifi scanning by the way? Does Network location just pull them all together as a kind of Super Location Scanner?
GrapheneOS version 2025032500 released
matchboxbananasynergy Thank you so much! As this is for maps apps to work while you are inside? Or if you you have poor service?
Pixelpioneer88 It's for when you're inside, or there's clouds obstructing your view to the sky, or a way to conserve power (more efficient than just using satellite).
There are many apps that use location that someone would use almost exclusively indoors, such as dating apps, and network location allows you to get a location lock in that setting.
Dumdum The bluetooth and Wi-Fi scanning toggle allow scanning while Wi-Fi and Bluetooth is otherwise disabled. That toggle doesn't do something by itself other than that. The network location feature is what's improving location accuracy indoors.
- Edited
I noticed that my location (while inside) is seemingly jumping around (a few meters every second) was hoping this update would solve that issue but I seem to be getting the same result. There are many wifi APs nearby as I live in an apartment and I am indeed on version 2025032500 and noticed the issue on past versions as well. Outside the location works perfect and is very accurate and stable though.
matchboxbananasynergy Great! Does having wifi scanning on hurt privacy at all? Is that why its off by default? Or am I mistaken?
matchboxbananasynergy
Sure, but the Wifi and BT scanning says it is used to improve location based features which gives the impression that they work similarly. Is it just inaccurate descriptions then?
secrec It does not share signal strengths or location. It's a different approach than Google's location service. It fetches location data for the 15 strongest signal strength APs based on their BSSID and stores that data in a local cache. We also ask for up to 100 nearby APs covering a large area to help fill the cache. The position estimation is local. We're going to be making our own database initially based on Apple's data and using that to create our own service with full offline support through downloading data for an arbitrary area. See https://discuss.grapheneos.org/d/21244-grapheneos-network-based-location-service-improvements for more information about how the current implementation works.
Dumdum Wi-Fi scanning and Bluetooth scanning toggles are standard Android features and are **not specific to the OS provided network location service. The toggles solely exist to allow scans while Wi-Fi and Bluetooth are turned off, but making that not really fully off but rather only for scans triggered for location purposes. Any app with the Location permission granted by the user which requests the relevant low-level Wi-Fi permissions can do throttled Wi-Fi scans. The OS location service just doesn't get throttled for battery saving reasons. Similarly, any app granted Nearby Devices by the user can do filtered Bluetooth scans, or unfiltered Bluetooth scans if they have both Nearby Devices and Location (for legacy apps, this only requires Location, they split it for modern apps to allow filtered scans with a less scary sounding permission).
secrec The proxy idea is interesting, but presumably it must still share a scan of SSID's, signal strengths, and location through to the destination server.
I think the client presents a list of SSIDs and Apple provides their locations. It is not clear why the client would provide relative signal strength information. Apple can infer a location to some extent, but presumably less well than the client.
secrec That potentially tells apple even more information than they would have with a direct connection, such as "there is a grapheneos user at this location".
There are other options... Google's service... GNSS... waiting for the GrapheneOS client to support cell-site info...
Reproach3656 It's normal for it to jump around. It's partly because it's currently using RSSI (signal strength) for distance estimation. It will get less jumpy when we add support for using Wi-Fi RTT (Round-Trip-Time) for distance estimation. Signal strength varies a lot and that means the estimated distances to Wi-Fi networks varies a lot which can impact the result a lot. Wi-Fi RTT and batching the requests more are the only planned major improvements to the Wi-Fi part of it in the near future. Cell tower fallback will be added, but that's separate from how it will usually work in most situations in a city. Making our own database for a non-proxy service and offline support are other major improvements planned for it.
- Edited
I still can not understand how new GrapheneOS feature works. I have enabled "Network Location - GrapheneOS Proxy" and allow Wi-Fi Scanning. But when i try Osmand it can not find my location (With Wi-Fi Off).
Can you explain, please?
Serg I still can not understand how new GrapheneOS feature works. I have enabled "Network Location - GrapheneOS Proxy" and allow Wi-Fi Scanning. But when i try Osmand it can not find my location (With Wi-Fi Off).
You still need an active network connection for the Network location feature to be able to pull the data (WiFi access points) it needs to determine your location. If WiFi is off, then you need an active mobile data connection.
In the future, when an offline database feature is shipped, it sounds like you won't need an active network connection to get a location fix without GNSS, but WiFi scanning will still be needed in that case. I think.
Hi GOS team, when I restart my Pixel 7a I get an error message with G Play service
type: crash
osVersion: google/lynx/lynx:15/BP1A.250305.019/2025032500:user/release-keys
package: com.google.android.gms:250934035, targetSdk 35
process: com.google.android.gms.persistent
processUptime: 1002 + 661 ms
installer: app.grapheneos.apps
GmsCompatConfig version: 154
java.lang.NullPointerException: Attempt to invoke virtual method 'void android.app.StatsManager.setBroadcastSubscriber(android.app.PendingIntent, long, long)' on a null object reference
at com.google.android.gms.common.subscriber.AnomalyConfigIntentOperation.onHandleIntent(:com.google.android.gms@250934035@25.09.34 (260400-738842635):110)
at com.google.android.chimera.IntentOperation.onHandleIntent(:com.google.android.gms@250934035@25.09.34 (260400-738842635):2)
at aott.onHandleIntent(:com.google.android.gms@250934035@25.09.34 (260400-738842635):8)
at sgs.run(:com.google.android.gms@250934035@25.09.34 (260400-738842635):70)
at sgr.run(:com.google.android.gms@250934035@25.09.34 (260400-738842635):152)
at fhby.run(:com.google.android.gms@250934035@25.09.34 (260400-738842635):21)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:651)
at java.lang.Thread.run(Thread.java:1119)interesting thing happened: after update finished but BEFORE reboot - suddenly most of the system interface switched to my second system language, which has never happened before.
after reboot into the new version system interface reverted back to first system language (english)
how? why? what??
After updating to latest release my location is no longer working on both my pixel 8a and 9. I've not changed any settings since it was working. Is anyone else having this issue?
- Edited
legendaryD on my pixel 8 its working (tested with google maps)
What settings do you have?
I have SUPL und PSDS grapheneOs proxy
and for location scanning all off (wifi scanning, bluetooth scanning, network scanning)
yes sorry it's working i had to step outside.
SIGSEGV suddenly most of the system interface switched to my second system language, which has never happened before.
Same, but it's not a regression for me, as it's happened several times in the past, and I'm not sure when exactly it happens. It might correlate with a system update but I'm not sure. Would likely take a lot of time to try to find a reliable way of reproducing it. It doesn't have anything to do with guest profiles as someone else stated in a different thread.