Proposal: Add command "force_platform_scheduling" to GPS provider

[Sean Barbeau]

Android Platform Modification Proposal:
Allow applications to force the Android platform to schedule GPS
refreshes, instead of solely relying on the native code to properly
report its GPS scheduling capabilities. This is implemented through
the addition of a "force_platform_scheduling" command for the GPS
provider.

Motivation:
Lately I’ve been working on implementing a custom Android location
provider based on GPS, which has forced me to revisit an issue related
to the GPS provider that has bothered me for a while.

In the majority of Android phones I’ve tested, when an application
passes in a “minTime” parameter (i.e., interval of time between
location updates) to the GPS location provider via
LocationManager.requestLocationUpdates() (http://goo.gl/XGgZy), the
GPS provider typically ignores this value and proceeds to update the
application via callbacks to the LocationListener.onLocationChanged()
(http://goo.gl/1BVAV) method every second (i.e., 1Hz update rate).
This is strange behavior, since the Android docs themselves suggest
that apps use minTime values of 60 seconds or greater to avoid a
significant negative impact on battery life. A stock build of AOSP
ICS 4.0.3 on the Nexus S 4G has the same behavior of ignoring the
minTime parameter, so the behavior is not due to an OEM modification
of the platform source.

Upon further investigation of the Android source, the
GpsLocationProvider (http://goo.gl/b1xHE) has two scheduling modes for
GPS refreshes:
a) native-scheduled, and
b) platform-scheduled.

The GpsLocationProvider defers to the native code to handle scheduling
IF the native code says it supports scheduling, since in theory the
native code should be more efficient than the platform for GPS
scheduling. If native code can’t support scheduling, the platform
takes over.

So, if Android supports more than one scheduling mode, why can’t an
app get anything other than a 1Hz location update rate on many
devices?

I believe I’ve narrowed down the problem to faulty capability
reporting from native code to the GpsLocationProvider in the Android
platform. In a custom AOSP build on the same Nexus S 4G, I hard-coded
values in the GpsLocationProvider to indicate that the native code was
NOT capable of handling GPS scheduling. Voila, the platform took over
and properly followed the minTime parameter (60 seconds in this case)
and delivered location updates to the app 60 seconds apart.

So, it seems to me that the native code is telling the platform “I can
handle GPS scheduling”, but then it doesn’t, resulting in a 1Hz update
rate no matter the minTime interval requested by the application.

Workarounds:
The only workaround for this problem on devices that ignore the
minTime parameter is for application developers to implement their own
version of GPS scheduling at the application level, which almost
certainly isn’t going to be as efficient as the scheduling
implementation in the platform.

Detailed proposal:
I propose adding a feature to Android to allow an app to send a
command to the platform forcing it to use platform-scheduled GPS. For
devices that properly communicate native capabilities, app developers
don’t need to do anything. However, for devices that have faulty
native GPS scheduling capability reporting, it allows an app developer
to override this setting and use the GPS scheduling implementation in
the platform, rather than implementing their own scheduling solution
at the app level.

Would Google consider adopting this proposal as a feature in Android?
I wanted to discuss this issue on the list before submitting anything
via Gerrit. I’ve sketched out how I see this working in a proposed
implementation below for anyone that wants to see the details.

I’d also welcome feedback from anyone else that has a different
opinion/insight of the reason behind the faulty behavior or alternate
solutions.

Thanks,
Sean

Sean Barbeau, M.S.
Research Associate
Center for Urban Transportation Research
University of South Florida

------------------------------------------

Proposed Implementation:
Add a “force_platform_scheduling” command to the GpsLocationProvider
(http://goo.gl/Fn7vR), triggered via an application call to the
LocationManager.sendExtraCommand() method (http://goo.gl/kGkIm), that
would override the native scheduling capability information for the
GPS engine. The GpsLocationProvider.hasCapability() method (http://
goo.gl/Q20tB) would be modified to check if this command has been
issued by an app, and if so it would force Android to use platform-
scheduled GPS recalculations, instead of native-scheduled GPS
recalculations.

New hasCapability() method would be something like:
private boolean hasCapability(int capability) {
if(capability == GPS_CAPABILITY_SCHEDULING &&
mForcePlatformScheduling){
//Return false to force the platform to handle GPS
scheduling,
//since on some devices (e.g., Nexus S 4G) native code
falsely reports
//that it can handle GPS scheduling, but then doesn't,
effectively ignoring
//the interval value that the application has requested
return false;
}

//Otherwise return native-reported capabilities
return ((mEngineCapabilities & capability) != 0);

}

Known devices that ignore minTime parameter, either with 1Hz rate or
variable rate:
Samsung Nexus S 4G (Gingerbread and ICS, AOSP stock build and
commercial build) on Sprint
HTC EVO 4G (Froyo and Gingerbread) on Sprint
HTC EVO 3D (Gingerbread) on Sprint
Samsung Captivate (Gingerbread) on AT&T
HTC Hero (Cupcake and Eclair) on Sprint
Motorola Droid X (Gingerbread) on Verizon
Samsung Epic 4G (Gingerbread) on Sprint

[Sean Barbeau]

I've successfully implemented and tested this feature using a Nexus S 4G, and I've uploaded the patch to Gerrit for review:

https://android-review.googlesource.com/#/c/34230/

Any feedback is welcome.

Sean

[Alan Smith]

I don't see much activity on this post, so am adding my support for your proposal. 

I have found the doco on the behaviour of the  LocationManager requestLocationUpdates minTime parameter very confusing, and was delighted when I came across your explanation of this bug. 

Maybe you can check out my response to your post on the Android Developers forum? 

[NickT]

I would like to add my support for this proposal. For far too long
this inconsistency in behaviour across devices has been allowed to
persist in the platform. Developers need certainty within
specifications and treating a method argument as merely a 'hint' is
really not good enough. When my Samsung Galaxy S2 failed to honour the
minTime contract, I was forced to implement my own scheduler as a
service. Since the update to ICS it now respects the minTime argument.
Let's nail this one down, it's important.

[Sean Barbeau]

Just wanted to close the loop on this thread:

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:

https://android-review.googlesource.com/#/c/34230/