Issues with Android 16

[qgjdev]

Hi people,
ever since GrapheneOS updated to Android 16, OwnTracks stopped working properly. It will only update my location whenever I open the app.

I know this sounds like a battery optimization thing, however I double-checked that the background usage was set to unrestricted and the option to pause the app when unused was deactivated.

I have no idea what to do or how to debug this problem.

Here's my configuration:

{
  "_type" : "configuration",
  "_id" : "myid",
  "waypoints" : [ ],
  "_build" : 420504022,
  "autostartOnBoot" : true,
  "cleanSession" : false,
  "clientId" : "myclientid",
  "cmd" : true,
  "connectionTimeoutSeconds" : 30,
  "debugLog" : false,
  "deviceId" : "mydeviceid",
  "discardNetworkLocationThresholdSeconds" : 0,
  "enableMapRotation" : false,
  "encryptionKey" : "",
  "experimentalFeatures" : [ ],
  "extendedData" : true,
  "fusedRegionDetection" : true,
  "host" : "mydomain.org",
  "ignoreInaccurateLocations" : 0,
  "ignoreStaleLocations" : 0.0,
  "info" : true,
  "keepalive" : 60,
  "locatorDisplacement" : 500,
  "locatorInterval" : 60,
  "mapLayerStyle" : "OpenStreetMapNormal",
  "mode" : 0,
  "monitoring" : 1,
  "moveModeLocatorInterval" : 10,
  "mqttProtocolLevel" : 3,
  "notificationEvents" : true,
  "notificationGeocoderErrors" : true,
  "notificationHigherPriority" : false,
  "notificationLocation" : true,
  "opencageApiKey" : "",
  "osmTileScaleFactor" : 1.0,
  "password" : "XxXxXxXx",
  "pegLocatorFastestIntervalToInterval" : false,
  "ping" : 15,
  "port" : 1883,
  "pubQos" : 1,
  "pubRetain" : true,
  "pubTopicBase" : "owntracks/%u/%d",
  "publishLocationOnConnect" : true,
  "remoteConfiguration" : false,
  "reverseGeocodeProvider" : "Device",
  "showRegionsOnMap" : true,
  "sub" : true,
  "subQos" : 2,
  "subTopic" : "owntracks/+/+",
  "theme" : "Auto",
  "tid" : "id",
  "tls" : false,
  "tlsClientCrt" : "",
  "username" : "myusername",
  "ws" : false
}

[thesyntaxslinger]

I have been experiencing this on both iOS and Android. I have no idea what the issue could be though considering it is both OS's.

Both are using MQTT as the backend.

I can make another issue on the iOS repo as well, but I am also unsure how to debug this issue.
Everything in the logs says it is essentially working.
Has been working for a while and now is just broken and only updates the locations if you are on the app.

I suspect it might have something to do with network changes for both iOS and Android, as the client seems to work fine if you open the app on roaming data, publish, exit the app/lock screen, drive somewhere and connect to a public wifi or something, then drive back. It will show the last location was at the place with the public wifi and the Status shows 0 queued endpoints waiting to publish.

Edit: iOS is having no issues. There was a configuration problem on my end.

[hastyeagle]

Same here w/ GrapheneOS. It seems like it just started after QPR1 was installed. Never had issues before QPR1.

It seems related to a GPS change in QPR1, is my guess. If I have the OT app open and in significant changes mode it will update as expected every 90 seconds (what I have it set to). If I have the app not in the foreground, it won't send updates. If I have a maps app open (e.g., MagicEarth), it works as expected updating every 90 seconds as well. If I close the maps app, it won't send anymore updates.

After I open OT and go into the logs after it hasn't updated for a while, I'll see:

W [main] MapViewModel: no location available
D [main] OSMMapFragment: OSMMapFragment initMap locationEnabled=true
D [main] MapActivity: Checking and requesting notification permissions
D [main] MapActivity: Checking and requesting location permissions
D [main] MapActivity: Has location permissions
D [main] MapActivity: Check and request location services
D [main] BackgroundService: no intent or action provided, setting up location request and scheduling location ping.

and then it will update after that (since the app is open, apparently).

[WarrenGandy]

Same issue with GrapheneOS. Over the past year it seemed like owntracks had evened out for me and was pretty reliable but then I just looked at my history for this past month and it's almost entirely empty! I guess it's the downside of Graphene where updates are more or less automatic, including major android OS jumps. I noticed the change in the battery icon in the bar but didn't put two and two together to realize it was a jump to version 16...

[thesyntaxslinger]

Any updates on this? OwnTracks has been completely broken on Android for me since December last year.

Anyone found a workaround for the time being until there is a fix from devs?

[thesyntaxslinger]

This is being tracked more closely in the GOS issue tracker as it is a more broader issue with GOS when you explicitly turn off Network Location in the GOS settings: GrapheneOS/os-issue-tracker#7103

[thestinger]

Android 16 QPR1 changed the QUALITY_BALANCED_POWER_ACCURACY mode for used location to stop using GNSS. Network location needs to be enabled by stock OS users to be available but they have it toggled on by default in the setup wizard and then prompt people to enable it. However, network location can be off in the stock OS too and will result in a similar situation. Android 16 QPR1 / Android 16 QPR2 are only available for the stock OS on Pixels in practice so that's why it hasn't been noticed elsewhere. It's not a GrapheneOS issue. GrapheneOS does support network location via our own implementation but we don't prompt people to turn it on right now.

[thesyntaxslinger]

Thank you for that correction @thestinger.

There is some more to add for OwnTracks.
When toggling the Network Location on, it does still not fix the background location updates for OwnTracks and the GNSS — and instead just defaults back to cell towers when driving in a car in a rural area (no wifi networks around).

I tried this with the "Significant changes" mode, and am going to be doing some more testing today to see if the issue gets mitigated when using a different mode like "Move" as I'm assuming that this is not using the fused location API (this is probably untrue and an assumption as I'm not a dev lol) — also wanted to add. Did this with MQTT and not HTTPS pub endpoint.

[thesyntaxslinger]

I have done some more testing. As suspected move mode seems to be unaffected, and significant changes mode has become very very inaccurate.

I have tried to interprete this in a drawn image below

• Blue: The road I drove
• Green: Significant changes mode
• Red: Move mode
• Yellow: What significant changes mode used to look like before QPR1

The Green line for Significant changes mode did not use to be this inaccurate, and the only thing I can think of is possibly cell towers or spots where I dipped in and out of a Wifi tracking zone? Significant changes mode used to work by just grabbing the exact location every few hundread meters or so, which is not what is happening here.

[thestinger]

QUALITY_BALANCED_POWER_ACCURACY won't use GNSS at all anymore since Android 16 QPR1 so that's likely just a consequence of that. This app should be enabling the high power mode. We plan to add some kind of workaround to GrapheneOS but haven't decided on the exact details yet. We may just revert it back to using GNSS for the balanced mode for all cases. However, this is not at all specific to GrapheneOS. It's just that a lot fewer GrapheneOS users have network location enabled since we aren't prompting people to do it and if we were fewer people would enable it for privacy reasons. We do have our own implementation which uses Apple's service but the data for that is as good as Google's service in western countries.

[toas-koas]

I have done some more testing. As suspected move mode seems to be unaffected, and significant changes mode has become very very inaccurate.

I observe the same thing with iodeOS (Android16).

[thestinger]

We changed QUALITY_BALANCED_POWER_ACCURACY to work the same way it did previously for now which likely addressed this issue for the app. We plan to change QUALITY_BALANCED_POWER_ACCURACY to solely use network location as they did when network location is enabled and detected as working though.

[toas-koas]

We changed QUALITY_BALANCED_POWER_ACCURACY to work the same way it did previously for now which likely addressed this issue for the app. We plan to change QUALITY_BALANCED_POWER_ACCURACY to solely use network location as they did when network location is enabled and detected as working though.

Does that mean that OwnTracks is working properly again now? Also in the significant changes mode?

[thestinger]

It should work perfectly fine on GrapheneOS again. We plan to make the code more sophisticated by checking when network location is enabled and functioning to use it for the balanced mode without GNSS. OwnTracks is not using the correct mode for the kind of app it is and is going to be purely using network location on the stock OS in most cases without GNSS with Android 16 QPR1 and later. It no longer works as it's likely intended to work on Pixels with the stock OS. It does work as the developers likely intended on GrapheneOS for now since we rolled back the change but we plan to more closely match what standard Android is doing to save power. OwnTracks should likely default to high power mode and give users a configuration option to decide if they want to save power by using only network location.

[sonicdmonkey]

Working perfectly for me on GrapheneOS after the changes were rolled back.