Closed Bug 965191 Opened 8 years ago Closed 8 years ago

Geolocation is broken in non release builds

Categories

(Firefox OS Graveyard :: Vendcom, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 977725

People

(Reporter: daleharvey, Unassigned)

References

Details

(Whiteboard: [b2g], [mwcdemo2014],[apps watch list])

Attachments

(4 files)

In the last year dogfooding I think I got a fix once, I know we have the whole partner / service issue, but unless I can get a phone with working GPS then its pretty much a brick to me. 

Hopefully the new location services stuff helps
I don't see any locsrv in the logcat; what I get instead is : 
01-31 02:02:48.770: E/QCALOG(190): [MessageQ] ProcessNewMessage: [XT-CS] unknown deliver target [OS-Agent]
01-31 02:02:49.000: E/QCALOG(190): [MessageQ] ProcessNewMessage: [XTWWAN-PE] unknown deliver target [OS-Agent]
01-31 02:02:49.000: E/QCALOG(190): [MessageQ] ProcessNewMessage: [XTWiFi-PE] unknown deliver target [OS-Agent]
blocking-b2g: --- → 1.4?
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Component: General → Geolocation
Product: Firefox OS → Core
To note: I used a buri device.

Alexandre Lissy pointed out to two things that could be the issue:
1) "Reuben fixed a permission issue
(https://bugzilla.mozilla.org/show_bug.cgi?id=955906) that was
specifically triggered with geolocation. I've used geolocation no later
than one hour ago with a build done a few hours ago, both on Nexus S and
HTC Desire Z."

2) https://bugzilla.mozilla.org/show_bug.cgi?id=908151#c7
Though I'm pretty sure QC uses /system/etc/gps.conf and it's not embedded in the bootloader.  I could be mistaken for the geeksphone.  Meaning the cert can be created for the server that we're now switched to, all we have to do is create a SuplRootCert : http://blog.cryptomilk.org/2012/07/24/how-to-create-a-suplrootcert-for-supl-google-com/ is my guess.
I think this bug might be a dup of bug 955880, reading on their issue.
Geolocation is still broken in today's build which does have the fix in bug 955906: 
01-31 17:04:47.319: E/QCALOG(187): [MessageQ] ProcessNewMessage: [XTWiFi-PE] unknown deliver target [OS-Agent]
01-31 17:04:47.339: E/QCALOG(187): [MessageQ] ProcessNewMessage: [XTWWAN-PE] unknown deliver target [OS-Agent]
01-31 17:04:47.349: E/QCALOG(187): [MessageQ] ProcessNewMessage: [XT-CS] unknown deliver target [OS-Agent]

Gaia      aedd5c9636f305d4433491056a0ca984dfb859b1
Gecko     http://hg.mozilla.org/mozilla-central/rev/735a648bca0d
BuildID   20140131095418
Version   29.0a1
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013
Buri

If the GPS doesn't work without the QC geolocation and only our code, how is "Where's my fox?" going to work?  Also what about the MWC demo devices that rely on the use of GPS?
To note, I can get GPS working with the configs that I have in this zip file using Google SUPL server for v1.2_devices.cfg OEM build.

Using the same configs, I cannot get it to work for 1.4
Hey Naoki!

This is a very important observation.  As I mentioned on IRC, the blobs from QC *must* match the gecko we are running or there is a chance for RIL and Geolocation breakage.  I believe that is what you are seeing here.  If you want to test against 1.4, you will need to ask the OEM to provide a QC blob that contains an update.


For everyone else -- Do NOT point at Google SUPL server.  We have absolutely zero right to do that.
Component: Geolocation → Vendcom
Product: Core → Firefox OS
If I understand this correctly, this would pose as a blocker per device for testing "Where's my fox?"
Depends on: 955880
Blocks: 908151
Attached file gps_buri1.2_iza.zip
revamped to using the supl.izatcloud.net server.
Whiteboard: [b2g] → [b2g], [mwcdemo2014]
Affects the Sora device as well, running 1.3.   John, can you attach any logs and STR when you reproduce?
Flags: needinfo?(jhammink)
Flags: needinfo?(jhammink)
Attached the two logs from different geolocation tests.  Here maps does not work, fb checkin does - but it's very inconsistent.  I would definitely not want to have to demo this, as it's simply not reliable.

Sora build 3:
Gaia      741869c9f0eaae242351f312c18fa6051715c086
Gecko     96b3233f80637206d502b52f238196fa86769ec9
BuildID   20140207155315
Version   28.0
ro.build.version.incremental=221
Tested with v1.3 buri

Gaia      df60e9b49207d64da5647ab15760c122adabfba4
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/0714a73350d8
BuildID   20140217164003
Version   28.0

It doesn't work. Mark it as v1.3?
blocking-b2g: 1.4? → 1.3?
Status: NEW → RESOLVED
blocking-b2g: 1.3? → ---
Closed: 8 years ago
No longer depends on: 955880
Resolution: --- → DUPLICATE
Duplicate of bug: 951785
Whiteboard: [b2g], [mwcdemo2014] → [b2g], [mwcdemo2014],[apps watch list]
Note - there's two problems here:

* Browser case is bug 951785
* App case is bug 974976

I've duped to one of the two bugs, but technically this is a dupe of both bugs.
On the latest build here maps opened to the netherlands, so im gonna go ahead and reopen
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(In reply to Dale Harvey (:daleharvey) from comment #18)
> On the latest build here maps opened to the netherlands, so im gonna go
> ahead and reopen

That's not the same bug as this. Please open a specific bug focusing on the exact context of the problem, not a "geolocation is broken" bug.
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 951785
(In reply to Jason Smith [:jsmith] from comment #19)
> (In reply to Dale Harvey (:daleharvey) from comment #18)
> > On the latest build here maps opened to the netherlands, so im gonna go
> > ahead and reopen
> 
> That's not the same bug as this. Please open a specific bug focusing on the
> exact context of the problem, not a "geolocation is broken" bug.
> 
> *** This bug has been marked as a duplicate of bug 951785 ***

Although I don't think what you are describing is a bug anyways - HERE Maps won't open to your location until your location is found. Your location is found when the dot goes green.
and the dot will not go green because geolocation is broken on non release builds which is the exact context the problem that I reported this bug for
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Geolocation is broken → Geolocation is broken in non release builds
Requesting blocking. This is a *development blocker*. Anyone using eng builds cannot test geolocation features at all.
blocking-b2g: --- → 1.4?
I remember seeing doug mention tarako will be using mozilla location services, are we just going to have all non production builds use them? bug open to track?
Flags: needinfo?(dougt)
Doug,

Is there anything steps pending on Moz' end? This seems to be an ongoing release issue.

Please weigh in.
will be fixed by 977725.  kind of.

See https://wiki.mozilla.org/B2G/Geolocation for background.
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 977725
blocking-b2g: 1.4? → ---
Flags: needinfo?(dougt)
You need to log in before you can comment on or make changes to this bug.