How Does Android Use SUPL Server?

[Away Team]

One way of accelerating a GPS receiver's time to first fix is to use assistance data from a Secure User Plane Location (SUPL) server, e.g. supl.google.com.

This can be achieved in a number of ways:
a. Global almanac data can be downloaded, and/or ephemeris data may be requested using a rough location, i.e. cell id.
b. The request can sent via Wifi or via Mobile Data, which may or may not incur charges.
c. The request may be initiated by the phone, e.g. the app or the platform, or pushed by the network.

This raises some questions:
1. Which of these options are available on Android devices?
2. Can the user control them through the UI?
3. Can the developer control them through the API?

In particular, Java ME (JSR-179) gives control over whether charges may be incurred or not for using a location service. Does Android also allow this control?

[Sean Barbeau]

Great questions!  This I don't know as much about (or my knowledge is somewhat dated), but what I do know (some updated today from quick skimming of the current AOSP source code) is below.

 

This raises some questions:
1. Which of these options are available on Android devices?

a - This post says that circa 2009 SUPL 1.0 was supported:

https://groups.google.com/forum/#!topic/android-platform/w_VnB8suU_A

...and there were some commits earlier this year that reference SUPL 2.0:

https://github.com/android/platform_frameworks_base/blame/462bcd8194cfbcf5ecbed893b19f1a21f721e1ed/core/res/res/values/config.xml#L1793

So, in theory, any capabilities of either standard could be supported on any given device.

b - SUPL is IP-based, and I believe it is primarily managed by the GPS chipset (more on this below), so it could go over either cellular or Wi-Fi, or any other IP-based network communication link.

c - I believe both are available - this commit:

https://github.com/android/platform_frameworks_base/commit/22d1f9fb23015471de6af1a70e40fb5c82ecb665

...and the different modes in the source code (e.g., MS-based, MS-assisted):

https://github.com/android/platform_frameworks_base/blob/master/services/core/java/com/android/server/location/GpsLocationProvider.java#L1249

...seem to support that.

SUPL use in Android is not very transparent, and varies per device - see:

http://mobilesociety.typepad.com/mobile_life/2014/08/supl-reveals-my-identity-and-location-to-google.html

http://mobilesociety.typepad.com/mobile_life/2014/09/how-to-trace-an-a-gps-supl-request.html

2. Can the user control them through the UI?

No.

 

3. Can the developer control them through the API?

Not to my knowledge. From the AOSP source code, it doesn't appear that any APIs are exposed to do this.  An OEM could implement something on a given device, but you'd have no way of knowing that unless it was documented.

 

In particular, Java ME (JSR-179) gives control over whether charges may be incurred or not for using a location service. Does Android also allow this control?

No.  I believe the general design here is that if a device has an internet connection and is configured for SUPL, the GPS chipset manages the SUPL connection.  This is considered a trusted part of the framework, and neither the user nor the 3rd party app developer has any control over it.  If you look at the source code for the Android platform GpsLocationProvider:

https://github.com/android/platform_frameworks_base/blob/master/services/core/java/com/android/server/location/GpsLocationProvider.java#L1249

...you can see that there is a good amount of code related to SUPL there, but all the interesting stuff takes place at the native code (i.e., GPS chipset) level.  You wouldn't even see most of the debug statements related to SUPL (since they only get output if the DEBUG profile is set) unless you built AOSP yourself on a Nexus.  The two "mobilesociety" URLs above shows the length you have to go to to see what's going on.

I should also caveat my last post a bit - when I referenced traditional A-GPS there, I was referring to control plane A-GPS, not SUPL.  Most of my experience with cellular providers is via Sprint, and during the early years (2008-2010) of Android devices on their network.  I know they discussed gpsOneXTRA as the location evolution path on Android, and SUPL was not discussed - see these Sprint ADP presentations from 2009 and 2010:

http://www.slideshare.net/sjbarbeau/adp-oct-2009-lbs-final

http://www.slideshare.net/sjbarbeau/2010-open-dev-conf-lbs-v0-4-f2

However, since Google is managing the SUPL server and communication is over IP, the carriers wouldn't necessary need to be in the loop on this - it would primarily be a device OEM/Google interaction (and the Google Groups post above seems to confirm that).  However, a modern AOSP commit from Sept. indicates that carriers (e.g., Sprint, Verizon) are dictating some of the SUPL requirements:

https://github.com/android/platform_frameworks_base/commit/462bcd8194cfbcf5ecbed893b19f1a21f721e1ed

So, unfortunately, I don't know much of the modern details of SUPL use on today's Android devices.  I can try digging up more info from some contacts, but this is the state of my current knowledge.

Sean

[Away Team]

Thanks for your detailed response, and apologies for my delay in replying.

It seems that there is no control over whether charges are incurred for calculating location on Android, which is both disappointing and a backward step from Java ME.

JSR-179 (https://jcp.org/aboutJava/communityprocess/mrel/jsr179/index2.html) explicitly allows such control in Java ME, using the Criteria class. On page 22, it states:

However, the cost criteria field is treated differently from others. If the application has set the cost field to indicate that the returned location provider is not allowed to incur financial cost to the end user, the implementation must guarantee that the returned location provider does not incur cost.

As Android uses a carbon-copy of the Criteria class (http://developer.android.com/reference/android/location/Criteria.html), including an isCostAllowed() method, it is reasonable to assume that it functions in the same way. However, this is clearly not the case.

I'm unsure whether this is intentional or just down to poor implementation. The API is clearly broken as it is possible to construct a test LocationProvider with cost allowed, and when this is checked against a Criteria with no cost allowed, it somehow meets the criteria. Digging into the source code behind this quickly showed that no cost checks are present, which begs the question: why is the interface there?

// Set up test location provider with cost
String provider = "testLocProv";
boolean hasCost = true;
boolean isAllowed = false;
LocationManager lm = (LocationManager) context.getSystemService(Context.LOCATION_SERVICE);

lm.addTestProvider(provider, false, false, false, hasCost, false, false, false, Criteria.NO_REQUIREMENT, Criteria.ACCURACY_FINE); // has cost
lm.setTestProviderEnabled(provider, true); // enabled

// Check provider meets criteria
LocationProvider lp = lm.getProvider(provider);
Criteria c = new Criteria();
c.setCostAllowed(isAllowed); // not allowed
assertFalse("Fails criteria", lp.meetsCriteria(c)); // fail, returns true

I also found an interesting blog entry (http://mobilesociety.typepad.com/mobile_life/2014/08/supl-reveals-my-identity-and-location-to-google.html) about the contents of SUPL requests from an Android phone, which raises some serious privacy questions if it is true. I have no reason to doubt him, as he describes his investigation method to allow others to reproduce it.

[Sean Barbeau]

 I agree that JSR179 provides much greater granularity of control and information than Android's Location API.

I'm unsure whether this is intentional or just down to poor implementation. The API is clearly broken as it is possible to construct a test LocationProvider with cost allowed, and when this is checked against a Criteria with no cost allowed, it somehow meets the criteria. Digging into the source code behind this quickly showed that no cost checks are present, which begs the question: why is the interface there?

Excellent question :).  My guess is that they originally imitated the JSR179 design before abandoning the Criteria object (for technical and/or legal reasons :)).  Personally, even in JSR179, I think the Criteria object was an unnecessary abstraction of the underlying location technologies.  It was very difficult to guarantee consistent behavior using Criteria on JSR179 across multiple devices/carriers, and as a result most developers I know just requested specific location technologies anyway.

[Sean Barbeau]

On a related note, here's a good description of the differences between autonomous, assisted, and ephemeris extension (EE) GPS fixes:

http://gpsworld.com/innovation-faster-higher-stronger/

gpsOneXTRA is an example of EE GPS fix.

Sean

[Xiang Lee]

Hi, Sean Barbeau.

I am more interested in supl and gpsone. But I don't know the difference between the two and use the scene.I only capture the gpsoneXTRA traffic in wifi traffic and no supl traffic found. I am very confused. I use GPS-TEST for a test.

Could you help me? Thanks.

在 2015年10月29日星期四 UTC+8上午2:04:28，Sean Barbeau写道：

[Sean Barbeau]

Xiang,

Sorry, I don't know much beyond what's already documented in this thread.  If you find more info, please post it here!

Thanks,

Sean

Sean J. Barbeau, Ph.D.

sjba...@gmail.com

http://www.linkedin.com/in/seanbarbeau

--
You received this message because you are subscribed to the Google Groups "GPSTest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gpstest_android+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.