1027462 - (mls-b2g) Integrate Mozilla Location Service into FxOS, and let it be customizable

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: General, enhancement)

Description

[Pin Zhang [:pzhang] (inactive)]

+++ This bug was initially created as a clone of Bug #837987 +++

We have bug 837987 for implementing geolocation API by querying CellID/wifi-hotspot position, Kan-Ru has already provided a patch with r+, however it's not landed for some reason (bug 837987 comment 76), let's file this bug for further discussion on integrating Mozilla Location Service.

As you might know, our Location team is working on Location Project[1], we created an android app MozStumbler[2] for community to help on collecting wireless network locations. According to the stats[3], we have already collected more than 1.4 million unique cells so far, it's a large number! thanks for our communities.

However, as the detailed data[4] shows, for most of countries instead of American and some European countries, the data is far more than enough, take China for example, we only collected 8951 cell towers' position which means we have a long long way to go.

Instead of waiting for our location database be ready for all countries, I think we should integrate our Location Service into FxOS first (maybe disabled by default), and let it be customizable, i.e. could be easily enabled and replaced with 3rd parties' location service (which should be compatible with Mozilla Location Service API[5]) by ODM/OEM/Operator. 

Take China for example, there are several location services that have been widely used in android devices, e.g. Baidu GeoSDK[6] and GaoDe LBS SDK[7] (Baidu and GaoDe are the top 2 map providers in China). In the past months, we have worked with GaoDe closely, they have provided an API that compatible with Mozilla Location Service, we tested it on FxOS 1.4, and it works very well.

Thanks!

[1] https://wiki.mozilla.org/CloudServices/Location
[2] https://github.com/mozilla/MozStumbler/releases
[3] https://location.services.mozilla.com/stats
[4] https://location.services.mozilla.com/stats/countries
[5] https://mozilla-ichnaea.readthedocs.org/en/latest/api/index.html
[6] http://developer.baidu.com/map/geosdk.htm
[7] http://developer.amap.com/api/android-location-sdk/summary/

Comment 1

[Hanno Schlichting]

(In reply to Pin Zhang [:pzhang] from comment #0)
> Instead of waiting for our location database be ready for all countries, I
> think we should integrate our Location Service into FxOS first (maybe
> disabled by default)

As of today MLS (Mozilla Location Service) is used in FxOS. Specifically it will be used in the Tarako and Dolphin devices (1.3T / 1.4 or 1.4D) and is enabled on the development versions of B2G. On the Flame phones it depends on what exact build is used. With a nightly build provided by Mozilla, MLS will be used. If the build is provided by our partner, they ship a different geolocation stack and will not use MLS.

If MLS is used in the actual consumer devices depends on a mixture of our and our partner choices, especially the carrier actually selling the devices.

As one of the next steps we are planning to integrate not only the lookup portion into FxOS, but also enable a lightweight "stumbling" mode, similar to what we are planning with Fennec.

> and let it be customizable, i.e. could be easily
> enabled and replaced with 3rd parties' location service (which should be
> compatible with Mozilla Location Service API[5]) by ODM/OEM/Operator. 

Currently the geo stack is often customized, most often by replacing some of the binaries. One of the reasons here is that the available API's aren't standardized and there's a tighter interaction between the RIL and the geo stack that's custom and proprietary.

That is not to say it should and must stay this way. The use-case of only customizing the web API endpoint while using the MLS/Google geolocate API just hasn't come up yet.

Comment 2

[Pin Zhang [:pzhang] (inactive)]

(In reply to Hanno Schlichting [:hannosch] from comment #1)
> (In reply to Pin Zhang [:pzhang] from comment #0)
> > Instead of waiting for our location database be ready for all countries, I
> > think we should integrate our Location Service into FxOS first (maybe
> > disabled by default)
> 
> As of today MLS (Mozilla Location Service) is used in FxOS. Specifically it
> will be used in the Tarako and Dolphin devices (1.3T / 1.4 or 1.4D) and is
> enabled on the development versions of B2G. On the Flame phones it depends
> on what exact build is used. With a nightly build provided by Mozilla, MLS
> will be used. 

OK, I found bug 977725, thanks for your update!

> As one of the next steps we are planning to integrate not only the lookup
> portion into FxOS, but also enable a lightweight "stumbling" mode, similar
> to what we are planning with Fennec.

May i ask which bug is for enabling stumbling mode on B2G? Thanks.

> 
> > and let it be customizable, i.e. could be easily
> > enabled and replaced with 3rd parties' location service (which should be
> > compatible with Mozilla Location Service API[5]) by ODM/OEM/Operator. 
> 
> Currently the geo stack is often customized, most often by replacing some of
> the binaries. One of the reasons here is that the available API's aren't
> standardized and there's a tighter interaction between the RIL and the geo
> stack that's custom and proprietary.
>

Yes, Hamachi is one of the cases, I think the main reason is that Hamachi has different interfaces to manipulate the GPS HW in gonk layer.

> That is not to say it should and must stay this way. The use-case of only
> customizing the web API endpoint while using the MLS/Google geolocate API
> just hasn't come up yet.

I think we definitely need to support such a use-case, is there a bug for this?

In China, OEM/ODM/Operators don't have Location service, and Google services are often disrupted by GFW, so lots of devices (like Samsung) are shipped with local location services like Baidu/Gaode. So that would really helps if the web API endpoint could be replaced easily.

Comment 3

[Hanno Schlichting]

(In reply to Pin Zhang [:pzhang] from comment #2)
> (In reply to Hanno Schlichting [:hannosch] from comment #1)
> 
> May i ask which bug is for enabling stumbling mode on B2G? Thanks.

https://bugzilla.mozilla.org/show_bug.cgi?id=984982 is the closest we have. But there's probably more thinking to do here. We don't yet have any bugs for any sort of background stumbling involving a local database, and a batch upload of that data for FxOS. This is something we currently work on for Fennec.

> > That is not to say it should and must stay this way. The use-case of only
> > customizing the web API endpoint while using the MLS/Google geolocate API
> > just hasn't come up yet.
> 
> I think we definitely need to support such a use-case, is there a bug for
> this?

Not at this point. But looking at the code again, we actually use the "geo.wifi.uri" setting, which can either use the GOOGLE_API_KEY or MOZILLA_API_KEY build option to get an api key. So maybe this is actually already supported and done.

One complication here is the "stumbling mode". There is no standardized protocol for submitting back observations to the service, so we made up our own protocol (actually two of them). For the pure lookup case we opted to implement the same API as the Google location service, so we have less client code to maintain.

Comment 4

[Hanno Schlichting]

The "customize location provider" part of this bug was answered via the existing geo.wifi.uri preference.

The FxOS stumbling integration work is happening in #1154435.