IssueTracker

What

More information

If I'm not mistaken, I need to reproduce the bug while the bug report is being generated, is that correct?

When

Time and frequency

Time when bug report was triggered: Apr 6, 2025 4:42 PM GMT+03:00

Where

Build and device data

- Build Number: google/panther_beta/panther:16/BP22.250221.015/13278879:user/release-keys
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)

Debugging information
Google Play services
com.google.android.gms
Version 251134035 (25.11.34 (260400-740024306))
System App (Updated)

Android System WebView
com.google.android.webview
Version 699813533 (134.0.6998.135)
System App (Updated)

Network operator: Vodafone UA
SIM operator: Vodafone UA

Filed by Android Beta Feedback. Version (Updated): 2.46-betterbug.external_20241023_RC01 (DOGFOOD)
To learn more about our feedback process, please visit https://developer.android.com/preview/feedback#feedback-app.

Information redacted by Android Beta Feedback.

What

More information

by the way, my friend, who also has a pixel 7, also noticed this bug, but since he is not participating in the beta testing program, he can't write about it here

Where

Build and device data

- Build Number: google/panther_beta/panther:16/BP22.250221.015/13278879:user/release-keys
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)

Debugging information
Google Play services
com.google.android.gms
Version 251134035 (25.11.34 (260400-740024306))
System App (Updated)

Android System WebView
com.google.android.webview
Version 699813533 (134.0.6998.135)
System App (Updated)

Network operator: Vodafone UA
SIM operator: Vodafone UA

Filed by Android Beta Feedback. Version (Updated): 2.46-betterbug.external_20241023_RC01 (DOGFOOD)
To learn more about our feedback process, please visit https://developer.android.com/preview/feedback#feedback-app.

Information redacted by Android Beta Feedback.

We’ve shared this with our product and engineering teams and will continue to provide updates as more information becomes available.

We are aware of the issue and a fix is rolling out to users. We expect it to reach 100% of devices around March 7th. We expect the fix to reach all of Google Play Services Public Beta enrolled devices by Friday February 26th. You can then test the mitigation yourself by using an account that is enrolled in Google Play Services Public Beta Program, please let us know if you still observe the issue. Note that a device might require a restart to fully activate the mitigation.

Thank you!

Hello again, i'd like to re-open this issue if possible as we're seeing more and and more reports of bad altitude data coming from the Fused Location Provider. You may remember our altitude / speed graphs from earlier in the year - well here's another one from a Pixel 6 Pro. This is the second Pixel 6 pro that has come in with strange GPS data issues. One of the owners actually works for Google.

I've attached the graph showing alt/speed from the FusedLocationProvider. You can see its super spiky.

When the speed is consistent and alt is going up, the user is on a ski lift. When the speed is spiky and going down they're skiing downhill. Now - would you expect the altitude data to look as it does? I certainly wouldn't.

The issue facing out customers is false ski lift detection as you can see represented by the grey dots while the customer is skiing.

The google employee who first came in with this issue is testing the same workaround that we put in last this we faced issues with FusedLocationProvider, which is falling back the android LocationManager API.

The ski season is just kicking off and i'd really not like a repeat of last year with GPS data chaos.

All help would be much appreciated!

Many thanks, Olly

Would you require this bug report from a pixel device as usual? Or would any device suffice? We don't currently have employees skiing with Pixels at the moment, and i'd hate to ask a customer for a bug report, regardless of whether they work for google or not.

Thanks etn@ for following up on reported altitude issues - and thanks Mark, David and Oliver for reporting these.

regarding the other issue:

several OEMs have very stringent battery optimizers that effectively shut down our location requests when the app is not in the foreground and with the device's screen turned on

you may want to check both that you are

• using a foreground service of type location, so your hiking/fitness tracker stays on (with a user-visible notification) when not the top app, and
• the current location battery saver mode where if it's one that disables GPS or All location with Screen Off, you may post a notification to users to suggest they turn off battery saver mode for a better experience with the tracking app. (Starting in Android 12, the default on Pixel and recommendation to other Android OEMs is use Foreground only - which works with the Foreground Service mentioned above.)

Sorry for the delay, i've been off for christmas break. A colleague has provided me with a bug report from a Pixel 5 from today's skiing. The GPS looks garbage to me apart from a small section at the end which looks fine. The time on the graph is UTC and the time in the bug report appears to be + 1h, so please bear that in mind when comparing timestamps.

I've attached a gps speed/alt/skiing graph with annotations.

The bug report is available here and should srtill be shared with android-bugreport@google.com from last time.

Hi developers, could you please provide us with an APK of your app (Wikiloc, Carv, etc.) that still requests location updates from FLP (and not from LocationManager)?

We'd like to test our fix with your app while our colleagues ski early next week.

Thanks!

You can switch this over yourself in the Carv app: Go to More -> Settings -> Press and hold App Version for a few seconds -> Enter 2805 -> Disable 'Remote settings' (so we don't override the change on next app open) -> Disable 'Use legacy GPS' -> Restart the app.

You might struggle to see the GPS data without access to our dashboards though... There's a debugging screen in the app which graphs various incoming data that you could use but i don't want to share the details on how to use it on a public forum. Is there an email address i can email directly?

I've been able to verify it with our own logs, thanks!

The fix should roll out early March, I'll update this bug when it's available to 100% of users. Thanks!

Hi, the fix has been rolled out to 100% of users today. Could you please give it a try at your earliest convenience? If so, would you mind if I enabled additional logging for your testing accounts (which I'll need) so that if you send us a bugreport I can verify everything is set up correctly?

Thanks!

Hi! We're currently debugging another GPS related issue at the moment so might be using the LocationManager provider tonight at night skiing, but if i manage to reproduce that issue at my desk today, i'll switch over to Fused and test. I'm logged in with both my work and personal google accounts on my personal device which i use for testing. Work is oliver@motionmetrics.co, personal is olly@oliverdelange.co.uk

Hello,

I'm very happy to see that you finally resolved this issue reported in 2021.

That said, I'm wondering how another FusedLocationProvider issue I reported back in 2017 still hasn't been addressed beyond the "We have passed this to the development team and will update this issue with more information as it becomes available." copy pasta.

I'd be happy that it is taken seriously as it has reproducing steps, and it's way worse than this wrong altitude problem (the coordinates are fully wrong, kilometers away, when this issue strikes): CRITICAL: Fused Location Provider UNRELIABLE for Wi-Fi.

Thank you for considering, and have a great day!

Louis CAD

Hi Google, i'm afraid i'd like to re-open this bug as we're seeing increased reports of innacurate altitude data from customers again this season. The most recent i've attached a graph for showing incorrect drops in altitude data reported via the fused location provider. Presumably due to incorrect altitude data from alternative locatoin sources such as wifi.

Hi Oliver, thanks for letting us know, and sorry about that.

Do you have a device and a set up that can reproduce the issue?

In order to help us debug the altitude problems you're seeing we need the account on the device to join a specific google group that will enable more logging on the device. Before adding that gmail account to the group could you please acknowledge the below consent?

Confidentiality Agreement:
 By joining the program, I agree that additional logging of application usage, crash reports, battery usage and other performance metrics may be gathered and shared with Google from the dogfood device.

We would get those logs via a bugreport shared from that device after being added to the group and taken right after reproducing the issue.

Thanks!

Reproducing is difficult. The customers reporting the issues are skiing in the mountains. Maybe google could pay for us all to go skiing together and try and reproduce the issue? :) Seriously though, I can ask the customers who report the issue whether they're willing to join this google group and submit bug reports, however i sympathise with their situation that they may not want to, they've already had a lot of comms with us to debug various GPS related issues (the legacy LocationProvider wasn't playing nicely for them either, and was often not sending data to our app)

No internal staff have experienced the issue so far as far as i'm aware.

Thanks Oliver, to confirm the app you're using is Carv? We can try to reproduce the issue ourselves then ;)

Hi Carlo, thanks for your input. Would you be interested in us logging more data on your device (locally only) so that you can take a bugreport right after skiing for a bit?

If so, the first step would be to acknowledge the test in #comment35.

The next step would be (once I let you know that I have enabled additional logging) to go skiing and right after seeing the issue, take a bugreport following these instructions. And then share it with me (mariagpuyol@google.com).

Thanks.

Hi Carlo, just by saying "I acknowledge ...."

But we have some colleagues skiing in the next few days. So let me get back to you if I need more information.

Thanks and regards

Hi Carlo, I haven't added you to a group for extended logging yet.

I don't need that yet. Can you please take a bugreport and attach it here by following these instructions?

I'd like to look at what version of Google Play Services you're running and what flags your device has on.

Thanks

Actually instead of attaching to this ticket, you maybe consider sharing it with me only using a Google Drive link (mariagpuyol@google.com).

Thanks a lot Carlo.

I was able to verify thanks to the bugreport and a test Carlo conducted on his device that it doesn't have a pressure sensor. Three of my colleagues have been skiing and the data looks great when the device as a barometer.

Oliver: could you please check if the users reporting issues have devices without a pressure sensor?

Thanks!

Hi Maria, we have this data to hand as we're investigating a vaguely related issue, but let me know if you need a larger sample set. In summary this does not appear to be a barometer issue, since we see this issue alot in Pixel devices, all of which i beleive have barometers. Of a sample of ~1500 sessions, we found the following problem phones: Pixel 6, Pixel 6 pro, Pixel 5, Samsung SM-G988W, Pixel 4, Nokia X20

Out of interest, what phones were your colleagues using and were they also using Carv? (I know there's quite a few googlers who use it, so i'd be interested to look at their raw data)

Thanks a lot Oliver. I haven't been able to see a single issue so far collected by my colleagues. We use mostly Pixel devices with pressure sensors, yes.

We've been using skitracker app which also uses FLP altitude. This is one example on Pixel 6.

My understanding with Carv was that we needed to have the Carv sensor? Is that not the case? Could you help us get set up? (I don't know any Googlers who use it).

I'm building an app with similar features.I debug my app on an oneplus 9. The altitude value got from fusedlcoationprovider fixed to a constant. It's confusing. Is this still a bug for devives from certain manufactures? I'm using the latest library.

As far as the original issue around constant altitudes is concerned, that got fixed 2 years ago. The conversation then went onto a seperate issue around 'spiky' altitude readings, which is the result of spiky barometer data. Might be worth checking the version of google play services on the device in question.

irontk2706@gmail.com, thanks for your input. Can you give us a bit of a description of how you're testing altitude? Is it while static, driving, skiing, etc?

If you're interested I can allowlist your account to collect detailed location logs and if you upload a bugreport (or send it to me) I can help debug.

You'd have to consent to:

Confidentiality Agreement:
 By joining the program, I agree that additional logging of application usage, crash reports, battery usage and other performance metrics may be gathered and shared with Google from the dogfood device.

Thanks!

Please share the information requested in comment#51 to proceed further.

Thank you for reporting this issue, The original issue has been fixed, please feel free to open a new bug for any other newly observed problems and attach a bug report.