It’s not really Escort’s Fault.. it’s who they contracted the work out to… Mutual Mobility. (Shouldn’t name your files after your company and then link me with about 4 hits from your company on linked in)
The issue with The GPS Stack in the com/escort/androidui//gps directory.
Inparticularly, the GPS Manager, the InvalidateReciever, and the LocationReciever Files.
You See, there is an onReceive Method called from the Dalvik-Cache in both files. Only difference is… Our motorola phones return the value of 5 in the InvalidateReciever.java source for the .locals variable, which then calls the GPSManager File and in turn never allows “–” which they’ve set as a constant string in the destination register, to be over-written by the Posted Speed Limit Value. I went into the Escort.db40 file and noticed that I keep getting 5’s all over the place.
In the LocationReciever Source, The same OnReceive Method is called from the Dalvik-Cache– only this time, it sets the .local variable to 4, which inturn allows the application to set the content and intent paramaters in the Dalvik-Cache and continue to invoke a slew of other methods necessary for setting the current location and the associated PSL.
Now if you notice on our Motorola phones… we have a grey dot.
Do me a favor… zoom in ALLLLL the way on the map view… see that blue circle that constantly changes? your “grey dot won’t be blue until that’s the same size as the grey dot itself. It’s interesting that the Program GPS-Test can tells us we have an accuracy up to 1 meter when EL says we never have an accuracy less than 8 meters.
I suspect this is why our phones are being defaulted to the InvalidateReciever Method rather than the Virtual Methods located in the LocationReceiver.java file.
If mutual mobility can’t work with our chipsets, you guys should atleast include a buffer zone to give us an approximate location so we don’t get invalidated…. at least…that’s what we’re doing 🙂