microg
Location requests staying active indefinitely (roaming still not addressed)
Describe the bug With the new 0.3.4 installed, any location request results in microG staying active indefinitely.
To Reproduce Steps to reproduce the behavior:
- Start any app which require (network) location.
- Send the app in the background.
- The location icon in the status bar remains on indefinitely, although no application is currently asking for location
- Long press quick button location. The last request is always microG. The fact that microG consistently shows last location request being made 0 minutes ago is an indication that microG (network) location remains active indefinitely.
Expected behavior Any/all location requests should be momentary, especially when all location-requesting apps are in the background.
Screenshots See attached screenshot
System Android Version: 13 Custom ROM: Samsung S20 (original firmware, debloated)
Additional context
Add any other context about the problem here.
Your screenshot show Déjà Vu Location Service, this means you are not using the latest version of microG (v0.3.4.240913)
I understand where you're coming from however, things are not what they seem. DejaVu was, indeed, one of the unified location nlp backends used with the older microG versions. I installed as a system app (through Magisk) and upon upgrading, the newer versions of microG did NOT remove it. Now it's just sitting there doing nothing, and in fact I could simply just disable it. I am on the latest 3.4 version and I wasn't reporting this just for fun. Can we get real now and try to figure out what's really causing the location in the 3.4 to remain on indefinitely? I'm the first one reporting it, however I'm positive that more similar reports will soon pop up.
Confirm Also some people from microG community on 4pda reported same problem.
Here you have the proof.
- I AM on 3.4,
- I no longer have any active unified NLP (disabled)
- The microG location still stays on indefinitely.
Note: reverting back to any previous version simply just doesn't work. A simple reinstallation will result in microG continuously crashing. Probably wiping data might solve the crashing problem however, doing so will also delete all previously stored cloud messaging push notifications - which means that all previously registered apps will have to be uninstalled & reinstalled to re register. I have 68 registered apps. Go figure!
As we stand, we went from bad (no network location) to worse (always location). This FU must be addressed with the utmost urgency.
Can you post the output of adb shell dumpsys activity service location and adb shell dumpsys location?
My guess is that there is not actually a (network) location request ongoing, but instead the passive GPS listener in microG (that doesn't activate GPS but will make sure GPS locations are fused if any other app activates GPS) is displayed as "active" request.
Can you post the output of
adb shell dumpsys activity service locationandadb shell dumpsys location?My guess is that there is not actually a (network) location request ongoing, but instead the passive GPS listener in microG (that doesn't activate GPS but will make sure GPS locations are fused if any other app activates GPS) is displayed as "active" request.
Please see attached (text file containing both requests). Dumpsys location.txt
@sconim can you test with the version from https://microg.org/dl/core-nightly.apk? I can't reproduce the issue on any of my devices, so it's hard to guess what causes this.
@mar-v-in This version solves the issue for me at a first glance. Edit: With both 'Remember from GPS' turned on, microG doesn't appear anymore in the list of apps having requested location, don't know if this is intended, just fyi.
@sconim As a workaround you can disable both 'Remember from GPS' settings in Location and force close microG and restart, that solved the issue of constant GPS lock in background for me.
Somo more info about nightly build from other user
https://4pda.to/forum/index.php?showtopic=724118&view=findpost&p=133408758 Updating to nightly helped but:
Upd: disabled "Remember GPS", rebooted, but still active.
"Remember from GPS" should work independently, there hasn't been any changes on that functionality recently either. I suspect that this is caused by the new fused system location provider support.
As I understand, the issue seems to be fixed for some,but not all users. Can anyone that still has the issue report:
- which apps show up as requesting location, both in microG location settings and system settings, since updating to the nightly or last reboot
- their Android version as well as if it is AOSP based or modified OEM
- output of
adb shell dumpsys activity service locationandadb shell dumpsys location
Thanks
Alternate commands for rooted users with no pc (e.g termux)
su -c dumpsys activity service location> /storage/emulated/0/Download/ActivityServiceLocation.txt
su -c dumpsys location > /storage/emulated/0/Download/Location.txt
ActivityServiceLocation.txt and Location.txt will be stored in downloads folder.
- which apps show up as requesting location, both in microG location settings and system settings, since updating to the nightly or last reboot
After reboot I've started "Transparent Clock and Weather" app to initiate Location request. After closing the app location request by "MicroG" still alive.
- their Android version as well as if it is AOSP based or modified OEM
Android 13 / MIUI 14 (China stable) ROM
- output of
adb shell dumpsys activity service locationandadb shell dumpsys locationLocation.txt ActivityServiceLocation.txt
From your dumpsys output, assuming you did these while the location indicator is active, it looks like more a display issue. The system seems to not actually requesting network location or gps at this time.
From your dumpsys output, assuming you did these while the location indicator is active, it looks like more a display issue. The system seems to not actually requesting network location or gps at this time.
That's a very important point you just made. The dumpsys must be done while the location indicator is active. I, for one, didn't, when I sent you the two files - so those are more, or less useless. With that being said, note that the above commands intended for Android terminal emulator (i.e.Termux) cannot be used (if microG behaves as intended) since transitioning from any app requesting location to a terminal emulator will automatically cause the location to become inactive.
@sconim can you test with the version from https://microg.org/dl/core-nightly.apk? I can't reproduce the issue on any of my devices, so it's hard to guess what causes this.
👍The nightly version appears to have solved the problem. I've tested it with default configuration (no toggling of any settings), and multiple apps, and the location indicator did go off every time I closed the app requesting location.
it looks like more a display issue.
Very strange... "App behavior records" shows that "MicroG is accessing to location now".
If needed I can try to get another logs. What I should to do?
This was NOT a display issue. Please see the above posts about the right way to generate the dumpsys files. If the location request was not active while creating the two files, it may have appeared as a "display issue". Although very logical, I didn't think about this requirement until @mar-v-in made it clear. Moreover, @mar-v-in can confirm the changes made in the linked nightly version - which did address the original problem, in my case.
I think this issue is discussing two separate issues:
- Location requests to the new "fused" system location provider staying active infinitely. These may actually cause location requests (scanning for networks or using GPS). This one should be fixed in the nightly.
- Passive location requests being displayed as "active location requests" and triggering the location indicator on some systems. These do not actually mean location being requested, but rather microG listening if other apps request locations. There is no way to fix this, as microG can't decide what is considered an active location request by the system. I'll add a switch to settings to disable passive listening so affected users can get rid of the location indicator, but this is going to degrade location quality.
I think this issue is discussing two separate issues:
1. Location requests to the new "fused" system location provider staying active infinitely. These may actually cause location requests (scanning for networks or using GPS). This one should be fixed in the nightly. 2. Passive location requests being displayed as "active location requests" and triggering the location indicator on some systems. These do not actually mean location being requested, but rather microG listening if other apps request locations. There is no way to fix this, as microG can't decide what is considered an active location request by the system. I'll add a switch to settings to disable passive listening so affected users can get rid of the location indicator, but this is going to degrade location quality.
@mar-v-in In other words, apps making location requests through the new "fused" location provider can share location with microG when microG makes passive location requests, thus indirectly causing microG (as a location provider) to make less location requests? Intuitively, I believe that should be the case, but could you please clarify whether microG itself also makes location requests using the new fused location system?
microG acts as a provider of fused location, so apps requesting it will always use microG.
The passive listener is for apps directly requesting GPS location, so that microG learns the GPS location and if another app requests the last fused location, microG can include this information.
microG acts as a provider of fused location, so apps requesting it will always use microG.
The passive listener is for apps directly requesting GPS location, so that microG learns the GPS location and if another app requests the last fused location, microG can include this information.
Thank you for clarifying. So, what's the difference between fused and GPS location requests? Does fused include both, GPS and network location requests?
On the other hand, I remember having the passive location requests, which was definitely just a display issue, with Lineage. There was even a setting allowing to hide the intermittent location symbol popping up on the top-right corner of Samsung phones. Anyways, I no longer use Lineage, now I use a heavily debloated version of Samsung's original firmware and I don't have these passive location requests display issues.
Fused location is meant to process information from all possible sources, including GPS, network (WiFi, cell towers, Bluetooth) and additional sensors (like compass, accelerometers, motion sensors, situation, connected car speed and steering, ...).
Most apps should nowadays only use fused location, but previous versions of Android did not support it properly (or only by using play services or microG), so some apps still request GPS or network location (or both) directly.
Fused location is meant to process information from all possible sources, including GPS, network (WiFi, cell towers, Bluetooth) and additional sensors (like compass, accelerometers, motion sensors, situation, connected car speed and steering, ...).
Most apps should nowadays only use fused location, but previous versions of Android did not support it properly (or only by using play services or microG), so some apps still request GPS or network location (or both) directly.
Understood! Appreciate the details.
I think this issue is discussing two separate issues:
1. Location requests to the new "fused" system location provider staying active infinitely. These may actually cause location requests (scanning for networks or using GPS). This one should be fixed in the nightly. 2. Passive location requests being displayed as "active location requests" and triggering the location indicator on some systems. These do not actually mean location being requested, but rather microG listening if other apps request locations. There is no way to fix this, as microG can't decide what is considered an active location request by the system. I'll add a switch to settings to disable passive listening so affected users can get rid of the location indicator, but this is going to degrade location quality.
I've tested the nightly linked here, and I would agree that problem 1 (listed above) has indeed, been addressed.
As for problem 2, given the similar experience I've had with Lineage, and assuming this is purely a display issue, could you maybe try addressing just the display issue by adding a switch that would turn off the passive listener's indicator, rather than disabling the passive listener altogether? I cannot speak for other phones and/or Android versions but on Samsung Lineage 18 and 19, this indicator would be different and independent from the main location indicator in status bar, and it would keep on popping up on the right-top corner, in green color, whenever the passive listener would make a request.
This way the location would not be affected.
microG can't influence when the system decides to add the indicator. If the system says "microG listening passively for location updates" is a signal to add the indicator, then the only way for microG to not trigger the indicator is to not passively listen for location updates.
I haven't checked but I think it is not impossible to disable the passive location inidicator with a static overlay but it is outside the scope of microG and it require changing the system partition.
microG can't influence when the system decides to add the indicator. If the system says "microG listening passively for location updates" is a signal to add the indicator, then the only way for microG to not trigger the indicator is to not passively listen for location updates.
I understand, I was thinking trigger but don't show however, I see your point. If anything, such a restriction would definitely be outside the scope of work of microG. That would be more of an UI tweak and it would be different for each device and/or Android version.
microG can't influence when the system decides to add the indicator. If the system says "microG listening passively for location updates" is a signal to add the indicator, then the only way for microG to not trigger the indicator is to not passively listen for location updates.
Thank You for explanations and for Your Great work! Now, I can confirm that the nightly version solves the problem with location request issue (problem # 1 as You described).