GrapheneOS

type: logcat
osVersion: google/husky/husky:15/AP4A.250205.002/2025022700:user/release-keys
package: app.grapheneos.networklocation:35, targetSdk 35
buffers: main,system,crash,events,kernel
level: verbose

--------- beginning of main
02-27 23:46:11.453  2040  2262 D WifiPositioningServiceCache: clean() removed 11 items
02-27 23:48:14.789  2040  4696 D TrafficStats: tagSocket(71) with statsTag=0xffffffff, statsUid=-1
02-27 23:49:17.757  2040  4696 D TrafficStats: tagSocket(71) with statsTag=0xffffffff, statsUid=-1
02-27 23:49:53.803  2040  4696 D TrafficStats: tagSocket(71) with statsTag=0xffffffff, statsUid=-1
02-27 23:50:13.979  2040  4696 D TrafficStats: tagSocket(71) with statsTag=0xffffffff, statsUid=-1
02-27 23:50:40.479  2040  4696 D TrafficStats: tagSocket(71) with statsTag=0xffffffff, statsUid=-1

1 user profile, no Play Services, never tried to turn developer options on, Wi-Fi and Bluetooth scanning on, network location through GrapheneOS proxy, SUPL and PSDS Graphene too.

    Jdjdoefndbej

    Do you have Google Play Services installed?

    I'm not an expert and also can't test it right now but this looks to me like Organic Maps requires Google Play Services to determine precise location:

    If your Android device can not determine your location, enable (or disable, if enabled) “Google Play Services” option in the app settings. Note: you can see it only if you have Google Play services installed (enabled) on your Android device. Google play services are used to determine location more precisely, if you experience issues with location accuracy after you disabled the option, turn it on.

    source: https://organicmaps.app/faq/map/can-not-find-position/

    I installed Organic Maps in a profile without Google Play Services and this option does not show up in the app settings.

        Murcielago No, it works fine outside. With GPS I guess. My problem is not limited to Organic Maps, Vanadium can't determine my location too.

            Murcielago Organic Maps uses the fused location provider provided by the OS which transparently supports network location. By default, GrapheneOS reroutes requests to Google Play to the OS location API. Organic Maps will behave the same way with or without their Google location toggle enabled by default unless you disable rerouting requests to the OS.

                The built-in battery optimization we've added for our next release should work as expected with the next OS release to avoid people needing to disable Battery Saver. We just want to fix a regression reported with the Location toggle being disabled first and then we can do another OS release. The current one will remain in Alpha due to needing a couple fixes for network location and a fix for 5G only mode limiting availability to carriers supporting real standalone 5G.

                sustained5314 it scans for Wi-Fi access points, so you need to either keep Wi-Fi on, or turn on always on Wi-Fi scanning which allows apps with the precise location or nearby devices permissions to scan for Wi-Fi access points even when Wi-Fi is off.

                In the near future, cell towers will be supported for getting a rough location estimate and it can use that if Wi-Fi is unavailable.

                  First off all, thank you for the amazing update! I have a couple of question regarding some of the changes.

                  1. Can you explain exactly what the 5G and 4G-only mode does? I'm not well-versed on this topic.
                  2. If you block phone numbers that are not in your contacts, do you still receive a missed conversation notification with that number?

                  GrapheneOS got a new log with some strings which I didn't see before. Maybe this could help

                  type: logcat
osVersion: google/husky/husky:15/AP4A.250205.002/2025022700:user/release-keys
package: app.grapheneos.networklocation:35, targetSdk 35
buffers: main,system,crash,events,kernel
level: verbose

--------- beginning of events
02-28 10:33:50.732  2031  2031 I auditd  : avc=type=1400 audit(0.0:38): avc:  denied  { read } for  comm="networklocation" name="u:object_r:odsign_prop:s0" dev="tmpfs" ino=293 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:odsign_prop:s0 tclass=file permissive=0 app=app.grapheneos.networklocation
02-28 10:33:50.736  2031  2031 I auditd  : avc=type=1400 audit(0.0:39): avc:  denied  { getattr } for  comm="networklocation" path="/apex/apex-info-list.xml" dev="tmpfs" ino=91 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:apex_info_file:s0 tclass=file permissive=0 app=app.grapheneos.networklocation
02-28 10:33:50.864  2031  2031 I auditd  : avc=type=1400 audit(0.0:43): avc:  denied  { read } for  comm="main" name="u:object_r:build_attestation_prop:s0" dev="tmpfs" ino=114 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:build_attestation_prop:s0 tclass=file permissive=0 app=app.grapheneos.networklocation
02-28 10:33:50.864  2031  2031 I auditd  : avc=type=1400 audit(0.0:44): avc:  denied  { read } for  comm="main" name="u:object_r:build_attestation_prop:s0" dev="tmpfs" ino=114 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:build_attestation_prop:s0 tclass=file permissive=0 app=app.grapheneos.networklocation
02-28 10:33:50.864  2031  2031 I auditd  : avc=type=1400 audit(0.0:45): avc:  denied  { read } for  comm="main" name="u:object_r:build_attestation_prop:s0" dev="tmpfs" ino=114 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:build_attestation_prop:s0 tclass=file permissive=0 app=app.grapheneos.networklocation
02-28 10:33:50.864  2031  2031 I auditd  : avc=type=1400 audit(0.0:47): avc:  denied  { read } for  comm="main" name="u:object_r:build_attestation_prop:s0" dev="tmpfs" ino=114 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:build_attestation_prop:s0 tclass=file permissive=0 app=app.grapheneos.networklocation
02-28 10:33:50.864  2031  2031 I auditd  : avc=type=1400 audit(0.0:48): avc:  denied  { read } for  comm="main" name="u:object_r:build_attestation_prop:s0" dev="tmpfs" ino=114 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:build_attestation_prop:s0 tclass=file permissive=0 app=app.grapheneos.networklocation
02-28 10:33:50.936  2031  2031 I auditd  : avc=type=1400 audit(0.0:55): avc:  denied  { read } for  comm="binder:2031_2" name="u:object_r:qemu_sf_lcd_density_prop:s0" dev="tmpfs" ino=317 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:qemu_sf_lcd_density_prop:s0 tclass=file permissive=0 app=app.grapheneos.networklocation
02-28 10:33:50.936  2031  2031 I auditd  : avc=type=1400 audit(0.0:56): avc:  denied  { read } for  comm="binder:2031_2" name="u:object_r:qemu_sf_lcd_density_prop:s0" dev="tmpfs" ino=317 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:qemu_sf_lcd_density_prop:s0 tclass=file permissive=0 app=app.grapheneos.networklocation
--------- beginning of main
02-28 10:34:18.169  2031  4577 D CompatChangeReporter: Compat change id reported: 312399441; UID 10180; state: ENABLED
02-28 10:34:18.183  2031  4577 D TrafficStats: tagSocket(71) with statsTag=0xffffffff, statsUid=-1

                    GrapheneOS

                    We'll provide database downloads to support offline network location.

                    Can you already tell in which format the offline database will be available?

                      phone-company there are real world instances of tails users who didn't have a VPN being compromised because of correlations between ISP packets sent and data received while using compromused Tor nodes and users who had VPNs prior to connecting to Tor were not compromised in the same way. It might help to not say anything if you have no idea what youre talking about and live in a bubble of righteous ignorance.

                          angela there are real world instances of tails users who didn't have a VPN being compromised because of correlations between ISP packets sent and data received while using compromused Tor nodes and users who had VPNs prior to connecting to Tor were not compromised in the same way.

                          True, but we are talking about sending your true real-life location here. I would strongly advise against mixing real-life activity such as your real-life location with anonymous activity such as what you would typically send through a VPN or Tor. If you use the same VPN for sending your real-life location, and for your anonymous activity, you are revealing to the other end of the VPN exactly where the person doing that anonymous activity is located, ruining all anonymity a VPN alone would give. Same if the location queries are sent out through the same Tor exit as the anonymous traffic, which of course can be prevented, but still.

                          I think there are very good and strong reason to only send queries regarding your real-life location out through the direct internet connection, as your direct internet connection already is approximately tied to your real-life location (if it is a residential connection, or through cellular triangulation). And then only use VPN and Tor for the activity you actually want to keep private, and isolated from real-life location.

                              ryrona I like this but don't know if I agree with it.

                                  angela I like this but don't know if I agree with it.

                                  Well, please just agree with it. Otherwise you could just as well not use Tor or a VPN to begin with. You mustn't reveal to the other end who you are, that ruins all anonymity such solutions give. And if you are telling the other end which Wifi hotspots are closest to you, you are revealing to the other end exactly where you are. Tor and VPN are supposed to enable you to send out traffic without the other end being able to tell where you are or who you are. If you intentionally tell them that anyway, by telling the other end your exact location, what was the point of even using Tor or VPN?

                                  I mean, it is pretty much equivalent to using VPN+Tor to create an anonymous social media account, and then immediately make a post on that social media account at which real-life residential address you are located. Not very meaningful.

                                    This made me thinking. @GrapheneOS, @soupslurpr, does the network location provider app bypass VPN? Or is there a risk this will start being a serious privacy issue for people who use a VPN, because they don't realize enabling this functionality would now cause the other end of the VPN to learn their exact location?

                                      ryrona if you don't want it to go through VPN, presumably adding the Network Location system app to your vpn's split tunneling would achieve that purpose. I'd rather not have system apps secretly bypassing my VPN connection. We should be able to decide that for ourselves on an individual level depending on our threat models

                                        I am having some issue since this update. Usually once an hour, at different times, while in a user profile on pix 8 pro, the phone does a soft reboot back to owner profile. I can log straight back into the user profile without having to type in the owner profile password...so i assume this is a soft reboot?

                                        Once logged into the user profile a graphene os notification pops up to say "system_ server crashed"

                                          L8437 The network location provider uncovered an upstream Android bug causing system_server crashes. It's why the release didn't move beyond the Alpha channel. We've fixed it and it will be included in today's release which will hopefully be able to go to Beta and then also Stable within a couple days.