[TOPBLOCKER] Location services not getting location

[Ondrej Kubik]

Failing to get location fix from application.
Neither network based nor gps location works.
Bug has now been seen on 3 phones with and without SIM installed.
HERE service seems to be running, but no reasonable location is reported.
GPS is failing to get fix, tested with phone placed for 2 hours outside.

On two of those phones location was working fine, but with OTA update to ~135 stopped working.
hard to guess working image but somewhere around 129~131

Problem is now reproducible on RTM release 137

[Loïc Minier (lool)]

To test whether the low-level HERE stack gets a location, put http://people.canonical.com/~lool/espoo-cli on your phone (will be included along HERE bits in the future) and run with:
chmod a+x espoo-cli
GLOG_logtostderr=1 GLOG_v=100 LD_LIBRARY_PATH=/custom/vendor/here/location-provider/lib/arm-linux-gnueabihf ./espoo-cli 5

NB: 5 is the number of location updates after which the tool exits; updates should come in at approx 15s interval. Output looks like:
I1101 21:30:01.285964 4403 cli.cpp:117] Requested number of updates is 2
I1101 21:30:01.299002 4403 cli.cpp:133] Starting location updates
I1101 21:30:01.301888 4403 cli.cpp:141] Starting GLib main loop
I1101 21:30:11.304612 4403 cli.cpp:158] Location: tstamp=1414891811 lat=xyz long=foo hor. acc.=2569 alt=nan vert. acc.=nan tech=cell
I1101 21:30:11.306061 4403 cli.cpp:170] Remaining updates: 1
I1101 21:30:26.736821 4403 cli.cpp:158] Location: tstamp=1414891826 lat=xyz long=foo hor. acc.=2824 alt=nan vert. acc.=nan tech=cell
I1101 21:30:26.738348 4403 cli.cpp:148] Stopping location updates

This worked for me on mako and krillin with respectively latest vivid and rtm from yesterday (139); however I did manage to get a "general error" in one case on krillin, seemingly because I started this when the device was still booting.

Interestingly, I get tech=cell for krillin and tech=wifi for mako, despite both being on the same table; this suggests these dont have the same wifi and/or cell visibility.

[Thomas Voß (thomas-voss)]

Please note that we only managed to reproduce this issue on phones that have been exposed to multiple OTA updates.

[Ondrej Kubik (ondrak)]

Some breakthrough:
Problem is caused by corrupted nvram data, when gps stack fails to identify underlying hw and therefore does not know how to function.
Underlying hw info is stored in /userdata/android-data/misc/GPS_CHIP.cfg, which is empty on broken phones, it should have text with chipset name.
Empty file is consequence of corrupted nvram file.
I have seen this one already during gps bring up, which was done on PVT phone, so nvram there was formatted several time, but now have this on production hw, so we need to investigate this further.
This bug should be moved to barajas project, since location service is just place where it pops out.

Two issues should be addressed:
1) when gps interface is started, start function never returns. Even if gps stack fails to initialise, it should at least return. Or in other case location service needs to initialise providers asynchronously to prevent one misbehaving provider taking whole service down. Ideally both should be done, with priority on gps stack always returning from start. Thomas any opinion here?

2) this is real problem and solution, we need to identify what is corrupting nvram data during OTA

[Thomas Voß (thomas-voss)]

> 1) when gps interface is started, start function never returns. Even if gps stack fails to initialise, it should at least return. Or in other > case location service needs to initialise providers asynchronously to prevent one misbehaving provider taking whole service down. > Ideally both should be done, with priority on gps stack always returning from start. Thomas any opinion here?

+1 for moving out of process, logged a different bug for tracking purposes here:

  https://bugs.launchpad.net/barajas/+bug/1389834

[Rick Spencer (rick-rickspencer3)]

If I'm seeing this, does that mean I am experiencing the issue on my phone?

phablet@ubuntu-phablet:~$ sudo cat /userdata/android-data/misc/GPS_CHIP.cfg
[sudo] password for phablet:
0x6582%s

[Ondrej Kubik (ondrak)]

0x6582%s from /userdata/android-data/misc/GPS_CHIP.cfg is correct value.
6582 represents mtk platform m6582.
When nvram gets corrupted GPS_CHIP.cfg is empty, as gps stack was not able to determine underlying platform.
So this seems to be different issue what you are seeing Rick.

[Ondrej Kubik (ondrak)]

Corrupted nvram file issue is now tracked by new bug in specific to krillin: Bug #1389865

[Victor Tuson Palau (vtuson)]

is this still a top blocker?

[Thomas Voß (thomas-voss)]

No, the fix has been released to both Vivid and RTM. Manually marked as "Fix Released"