Two GPS compatible apps conflict and loose GPS

Bug #1468020 reported by Ronnie Tucker on 2015-06-23
82
This bug affects 15 people
Affects Status Importance Assigned to Milestone
Canonical System Image
High
Thomas Voß
location-service (Ubuntu)
High
Unassigned

Bug Description

Meizu MX4 with Ubuntu 15.04 r2

1. run OSMscout (for example)
2. drive/cycle a distance to confirm that GPS tracking is working fine
3. run the camera app (for example)
4. take a few photos (they'll be tagged with GPS info)
5. switch to OSMscout
6. drive/cycle and OSM will now not update from GPS

Haven't tested this with other apps as yet, but it seems that one app will take control of the GPS and not hand it back. (For want of a better explanation.)

Ronnie Tucker (ronnietucker) wrote :

This actually now seems like it's the first GPS app run will keep the GPS and not release it when closed.

Try this:
1 Reboot the MX4
2 Open (for example) HERE maps
3 Check it's got your location right
4 Keep HERE open, but choose a different GPS app (eg: OSMTouch)
5 The second GPS app will have your location
6 Move to a new location
7 HERE maps (in this case) will update fine
8 Second app will not update to the new location

Even closing the first app before opening the second makes no difference. The GPS is locked to that first app until a reboot is done. Also applies to the Nearby scope (as a second app).

Sergi Quiles Pérez (sergiqp) wrote :

I have a similar issue with uNAV and SensorsStatus:

1st - I open uNAV and I set a destination. It works well.
2nd - I open SensorsStatus and I wait to receive data on GPS section.
3rd - I go back to uNAV. A while after, it doesn't receive GPS data anymore and it looks like frozen.
4th - I go back to SensorsStatus. It isn't receiving data. I wait a while and it starts to receive data again.
5th - I go back to uNAV and it doesn't work anymore.
6th - I close/kill SensorsStatus but uNAV still doesn't work.

I hope this to be useful.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in location-service (Ubuntu):
status: New → Confirmed
Changed in location-service (Ubuntu):
importance: Undecided → High
Changed in canonical-devices-system-image:
assignee: nobody → Thomas Voß (thomas-voss)
importance: Undecided → High
milestone: none → ww08-2016
status: New → Confirmed
Thomas Voß (thomas-voss) wrote :

Some background first: Applications do not compete or have control over the GPS at all. Location service is handling all of the access. With that, an app is not able to block or exclusively own the GPS. There are multiple other reasons why the apps could appear to not receive any updates, though. That being said: We have problems reproducing the bug on latest rc-proposed images. If someone is able to reproduce, it would be really helpful if we could get gdb backtraces of both apps and the location service. Please see:

  http://dirac.org/linux/gdb/06-Debugging_A_Running_Process.php

for a good overview of how to attach to a running process. Once attached, you should enter "t a a bt full" in gdb, and pastebin the trace(s). Please note that you need to execute gdb with elevated privileges (sudo) to be able to attach.

Changed in location-service (Ubuntu):
status: Confirmed → Incomplete
Changed in canonical-devices-system-image:
status: Confirmed → Incomplete
Pat McGowan (pat-mcgowan) wrote :

The fix for bug #1387643 went into ota8 and would help a good deal here, perhaps as all the reports were on previous versions it has been improved

Sergi Quiles Pérez (sergiqp) wrote :

In my bq Aquaris E4.5 Ubuntu Edition with Ubuntu 15.04 (r296) I have done these tests:

A. uNav running alone:
     - A few times it has arrived to a state of not receiving new positions. I think this is due to not having access to AGPS because the network is down or the phone has not access to a network.

B. uNav and SensorsStatus running at the same time:
     - With uNav on the foreground and SensorsStatus on the background, after a while uNav arrives to a state of not receiving new positions.
     - Changing to SensorsStatus it initially doesn't show any position and immediately it receives new positions.
     - Changing to uNav it starts again to receive new positions and after a while it stops receiving new positions.
     - If you change again to SensorsStatus and after that to uNav, it starts again to receive new positions.
     - If you kill SensorsStatus uNav receives new positions and it works well.

C. uNav and HERE Maps running at the same time:
     - You can reproduce the same described in B with these two apps.

D. uNav and Google maps (in the browser) running at the same time:
     - If you permit to Google maps to access to your location you can reproduce the same described in B with these two apps.
     - If you do not permit access to your location uNav gets positions as expected.

I hope this to be useful to resolve this bug.

Pat McGowan (pat-mcgowan) wrote :

Can't reproduce so far with the info in comment #6

Changed in canonical-devices-system-image:
milestone: ww08-2016 → 11
costales (costales) wrote :

This bug persist

Thomas Voß (thomas-voss) wrote :

@costales: Could you please try to grab the gdb backtrace we are asking for in #4.

Also: Please try removing cache directories for the involved applications under ~/.cache.

costales (costales) wrote :

@thomas-voss: Impossible for me report that info, as I'm driving or in bike when that happens :( I'm so sorry.

Sergi Quiles Pérez (sergiqp) wrote :

@thomas-voss

I have removed ~/.cache directory a lot of times and the issue is still there.

If you want to reproduce the issue you can do what I say in comment #2. You can use those two GPS applications of your choice.

On Fri, Apr 8, 2016 at 7:12 PM, Sergi Quiles Pérez <email address hidden> wrote:
> @thomas-voss
>
> I have removed ~/.cache directory a lot of times and the issue is still
> there.
>
> If you want to reproduce the issue you can do what I say in comment #2.
> You can use those two GPS applications of your choice.
>

I did, works fine for me.

Cheers,

  Thomas
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1468020
>
> Title:
> Two GPS compatible apps conflict and loose GPS
>
> Status in Canonical System Image:
> Incomplete
> Status in location-service package in Ubuntu:
> Incomplete
>
> Bug description:
> Meizu MX4 with Ubuntu 15.04 r2
>
> 1. run OSMscout (for example)
> 2. drive/cycle a distance to confirm that GPS tracking is working fine
> 3. run the camera app (for example)
> 4. take a few photos (they'll be tagged with GPS info)
> 5. switch to OSMscout
> 6. drive/cycle and OSM will now not update from GPS
>
> Haven't tested this with other apps as yet, but it seems that one app
> will take control of the GPS and not hand it back. (For want of a
> better explanation.)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1468020/+subscriptions

Sergi Quiles Pérez (sergiqp) wrote :

@thomas-voss I forgot to say in my comments that the those tests were made travelling inside a car. So the phone was sometimes trying to connect to AGPS to know the satellites positions when I was travelling in 'dark zones' for satellites.

I've just tested it and it works well for me. Tested with Here and uNav.

Ronnie Tucker (ronnietucker) wrote :

Try running uNav for a bit, switch to the camera and take some photos, and a quick video. Return to uNav, and see if uNav updates your GPS position.

I did those steps a day/two ago and uNav wouldn't update my location for a couple of minutes.

Thomas Voß (thomas-voss) wrote :

Let's clarify on the terminology here first: AGPS refers to assistance
technology that
enables a GPS chipset to query relevant information
(ephemeris/almanac) over a data link (mobile data/wifi)
that offers more bandwidth than the satellite down link (~1Hz). With
that, *if* you are travelling in
situations with little satellite visibility, AGPS will be of no help,
as the GPS chipset just has no beacons
from satellites to determine which ones are visible and subsequently
triangulate a position.

I think you are referring to the network-based positioning which
estimates positions based on visible wifis and the radio cell
the phone is currently connected to. For the scenario you are
mentioning: What kind of "dark zones" did you drive through?
Did you have wifi enabled?

On Sat, Apr 9, 2016 at 12:29 AM, Sergi Quiles Pérez <email address hidden> wrote:
> @thomas-voss I forgot to say in my comments that the those tests were
> made travelling inside a car. So the phone was sometimes trying to
> connect to AGPS to know the satellites positions when I was travelling
> in 'dark zones' for satellites.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1468020
>
> Title:
> Two GPS compatible apps conflict and loose GPS
>
> Status in Canonical System Image:
> Incomplete
> Status in location-service package in Ubuntu:
> Incomplete
>
> Bug description:
> Meizu MX4 with Ubuntu 15.04 r2
>
> 1. run OSMscout (for example)
> 2. drive/cycle a distance to confirm that GPS tracking is working fine
> 3. run the camera app (for example)
> 4. take a few photos (they'll be tagged with GPS info)
> 5. switch to OSMscout
> 6. drive/cycle and OSM will now not update from GPS
>
> Haven't tested this with other apps as yet, but it seems that one app
> will take control of the GPS and not hand it back. (For want of a
> better explanation.)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1468020/+subscriptions

costales (costales) wrote :

Hi, I'm not using AGPS.

Sergi Quiles Pérez (sergiqp) wrote :

@thomas-voss As I can see I didn't explain it well.

With <So the phone was sometimes trying to connect to AGPS to know the satellites positions when I was travelling in 'dark zones' for satellites.> I mean that when you are travelling in that 'dark zone' the GPS doesn't receive positions. If that 'dark zone' is short, when you exit the phone finds the satellites position easily; but if that zone is long when you exit it tries to connect to AGPS to determine the satellites positions and is then when it fails. I.e. if you cross a short tunnel the phone doesn't need AGPS when exit but if you cross a long one it needs it and the location services fails.

There are only my thoughts after analyse what I have observed.

It happens either if you have wifi enabled or only phone network.

Apart of that:
   - I haven't tried if the phone gets positions with only GPS. I tried it one year ago and it didn't work but I haven't tried it again.
   - I tried today to put the phone in plain mode, clear .cache, reboot and open SensorsStatus. It has received positions in about 2 minutes (without wifi nor phone network, i.e. without AGPS).
   - I'll try to travel in plane mode (with 2 GPS apps opened) when I have a chance.

I hope this to be useful. :-)

mindaugasd (mindaugasdi) wrote :

I can confirm I experience exactly the same problem as described in #6 comment, and filled a duplicate bug lately #1573140. But I cannot confirm information in other comments #1, #2, because GPS always starts working again if I switch apps, but GPS stops again after a minute and apps have to be switched again and so on. Its exactly as described in #6 comment.

mindaugasd (mindaugasdi) wrote :

Position does not only freeze as I described in previous message, but if there is other GPS apps running, then uNav app, for example, does not only looses position, but it works very strangely, it is very choppy, and does not know the direction (map swings in many directions constantly), and finally freezes untill the the apps are switched again. But If no other gps apps are running, all working very well.

Changed in canonical-devices-system-image:
milestone: 11 → backlog
Launchpad Janitor (janitor) wrote :

[Expired for location-service (Ubuntu) because there has been no activity for 60 days.]

Changed in location-service (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers