This issue is being resolved in Android version 4.1 Jelly Bean and above with a new CtsVerifier CTS test that will cause a device to fail the test if it exhibits the behavior discussed above. So, for Android devices Jelly Bean and above, this issue should be resolved.
Full discussion of this issue for anyone interested is at the original patch submission link:
On Friday, April 6, 2012 1:11:34 PM UTC-4, Sean Barbeau wrote:
--StarTrax,Interesting, you're right, looks like something funky happened with the embedded URLs for the links in my first post. There also seemed to be an issue with my first post getting stuck in the moderator queue (so sorry for the double post), not sure if this is related. If you use the links in the second post the embedded URLs seem to work fine, or just copy and paste the text of the link into your browser.For the GPS provider and "platform", I'm referring to the Java-based portion of Android. For the GPS provider, here's the code:There's a method in the GpsLocationProvider that is called from native code to tell the provider what the underlying capabilities of native code are:Native code seems to be telling the Java portion of framework that the native code will handle refreshing GPS at the minTime interval, so the Java portion of Android is then hands-off on GPS scheduling. But, native code doesn't actually seem to be doing the job, and the 1Hz rate is the result (I should note that I've also seen some device do other strange things, like a 1Hz update for 13 seconds, then rest for minTime, then repeat).I believe the only native code related to GPS for AOSP is included in this header file:which means the implementation of this interface would be OEM-specific, and not included in the Android project itself. This link seems to confirm that:From talking with others, I believe that the native code controlling the GPS scheduling is provided by the GPS hardware manufacturer, such as Broadcom for the Nexus S 4G:If this is the code that has the problem, it would explain why it appears in devices from multiple OEMs.I haven't done much with the NMEA listening capabilities of Android, but would be interested in hearing more about differences between NMEA messages and LocationListener output.Sean
On Thursday, April 5, 2012 6:47:03 PM UTC-4, StarTraX wrote:Hey Sean,Thanks for your post. Seems like there is some intelligence out there after all!I tried to follow your links but hit an Office Outlook web access login page, so couldn't progress. Is that me or is there a way through?When you refer to "the GPS provider", I wonder what component you are actually referring to? Could you direct me to some more reading on "...GPS provider has two built-in scheduling modes..."At the hardware layer, on my SGS11, the PVT data is provided by the CSR SiRF chip, whose data page talks about the "host SDK" providing most of the interface stuff. I have written to CSR to get some user specs on this software, but have not made much progress to date. My guess is that the implementation of the response to the requestLocationUpdates minTime call is implemented by Samsung using that SDK.In an earlier versions of my code, I have seen my NMEA location listener event being raised far less frequently than 1 Hz, in a pattern that indicated some interaction with my speed and route - at highway speeds, in a straight(ish) direction, it was firing at around 10 - 15 seconds. Unfortunately I can't reproduce that behaviour (at that time I was wanting exactly 1Hz response, so binned the code and started again!).Now I desperately want to return to that behaviour, but can't reproduce it!
On Thursday, March 29, 2012 2:22:02 AM UTC+11, Sean Barbeau wrote:Hi all,I've been working with the Android platform code lately, and had a chance to look at this issue of the GPS provider ignoring the minTime parameter on a number of devices more in depth. The GPS provider has two built-in scheduling modes, native and platform, that are designed to follow the minTime parameter, so the problem isn't lack of capability in Android.After some research, I believe the issue stems from native code reporting that it can handle GPS refresh scheduling, but then the native code doesn't actually do the scheduling, effectively preventing the Android platform from properly handling the scheduling. I posted a more detailed description about this issue in the Android Contributors group:I submitted a patch to the Android project (still under review) that essentially implements a fail-safe switch as a workaround for this problem, so the developer can force the Android platform to properly handle the GPS refresh scheduling if the native code isn't working properly:I've tested this patch on a custom Android build on a Nexus S 4G, and it works. Without the patch, the Nexus S 4G just spits out locations at 1Hz no matter what you set the minTime parameter to.If this issue has affected you as an Android developer and you'd like to see this patch make its way into Ice Cream Sandwich for all future Android device updates, I would suggest voicing your support by replying to my post on the Android Contributors list. It would help if you mention the make and model of the device that has the problem as well, so we can track which phones are currently affected.I haven't gotten much response about this from Google yet, but hopefully if they see this is an issue that is important to developers they would be willing to accept this patch. If the patch is accepted, it would provide a fail-safe method for developers on all future Android devices to ensure that GPS scheduling performs as intended from the application's perspective.Thanks,SeanSean BarbeauCenter for Urban Transportation ResearchUniversity of South Florida
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment