Ken Chang[:kenkai] Reporter
	Description • 11 years ago

Currently, Firefox has supported WCDMA and CDMA. However, we don't know which network capabilities HW platform supports. We need a method to tell Gaia which network capabilities current platform supports. Then Gaia can decide to show which network types for users.

	Ken Chang[:kenkai] Reporter
	Comment 1 • 11 years ago

Edgar, please take this bug. You can discuss with Marco to know from which ro. we can get the network capabilities. Thanks.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 2 • 11 years ago

Maybe |supportedTypes| or |availableTypes| as an array under |mozMobileConnection[n].{voice|data}|?

	Ken Chang[:kenkai] Reporter
	Comment 3 • 11 years ago

We also need to consider the LTE.

	Edgar Chen [:edgar] Assignee
	Comment 4 • 11 years ago

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #2)
> Maybe |supportedTypes| or |availableTypes| as an array under
> |mozMobileConnection[n].{voice|data}|?

Array is a good idea. But currently we don't support set preferredType for data or voice individually [1], it seems we don't need to have separated |supportedNetworkTypes| for voice/data.

So my idea is having |mozMobileConnections[x].supportedNetworkTypes| as an array indicating the HW capabilities,
for example,
- Support gsm only = > ['gsm']
- Support gsm + wcdma => ['gsm', 'wcdma']
- Support 1xrtt + evdo => ['cdma', 'evdo']
- World phone => ['gsm', 'wcdma', 'cdma', 'evdo']
- Support 1xrtt + lte => ['cdma', 'lte'] 
- World phone + lte => ['gsm', 'wcdma', 'cdma', 'evdo', 'lte']

Tim, Hsinyi, how does this sound?

Thank you

[1] https://github.com/android/platform_hardware_ril/blob/master/include/telephony/ril.h#L2773

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 5 • 11 years ago

I proposed to put the |supportedTypes| under {voice|data} out of idea of symmetry, since |type| is under them; also, I am not sure if we will ever encounter a porting target where {voice|data} utilizes different support types. If that's not possible at all put it under |mozMobileConnection[n]| should be fine.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 6 • 11 years ago

(In reply to Edgar Chen [:edgar][:echen] from comment #4)
> - Support gsm only = > ['gsm']
> - Support gsm + wcdma => ['gsm', 'wcdma']
> - Support 1xrtt + evdo => ['cdma', 'evdo']
> - World phone => ['gsm', 'wcdma', 'cdma', 'evdo']
> - Support 1xrtt + lte => ['cdma', 'lte'] 
> - World phone + lte => ['gsm', 'wcdma', 'cdma', 'evdo', 'lte']

I also wonder if we want to expose the combination capabilities here too. For example, for a world phone, it's possible to switch to gsm+wcdma mode or cdma+evdo phone, but it's not possible to switch to gsm+cdma. We also need these strings for setting the mozSettings entry on user perfered network type. This is probably not something needed in this bug but it's something worthy to think about in the future.

	shawn ku [:sku]
	Comment 7 • 11 years ago

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #6)
> (In reply to Edgar Chen [:edgar][:echen] from comment #4)
> > - Support gsm only = > ['gsm']
> > - Support gsm + wcdma => ['gsm', 'wcdma']
> > - Support 1xrtt + evdo => ['cdma', 'evdo']
> > - World phone => ['gsm', 'wcdma', 'cdma', 'evdo']
> > - Support 1xrtt + lte => ['cdma', 'lte'] 
> > - World phone + lte => ['gsm', 'wcdma', 'cdma', 'evdo', 'lte']
> 
> I also wonder if we want to expose the combination capabilities here too.
> For example, for a world phone, it's possible to switch to gsm+wcdma mode or
> cdma+evdo phone, but it's not possible to switch to gsm+cdma. We also need
> these strings for setting the mozSettings entry on user perfered network
> type. This is probably not something needed in this bug but it's something
> worthy to think about in the future.

My two cents,
preferred network mode could be gsm+cdma by some partner's solution. EX: HTC has a auto mode for both GSM + CDMA. And
modem will trigger mode change event to let uppper layer know there is a switching between GSM and CDMA.

In short, it should be possible to switch to gsm+cdma.

thanks!!
sku

	Marco Chen [:mchen]
	Comment 8 • 11 years ago

As I know that SVLTE (CDMA + LTE) and CSFB (WCDMA + LTE) are all possible.

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 9 • 11 years ago

I'd like to echo Tim's comment: wonder if we want to expose the combination capabilities here. It seems yes?
And I'm also wondering if gecko is able to get the combination capabilities from ro properties.

	Edgar Chen [:edgar] Assignee
	Comment 10 • 11 years ago

((I guess exposing combination capabilities is for setPreferredNetworkType()))
IMHO, exposing combination capabilities doesn't make too much sense to me. The valid inputs of |setPreferredNetwork()| are well-defined (Please see [1][2]). We could have some logic to filter out invalid combination by checking |supportedNetworkTypes|.

For example, 
1). if |supportedNetworkTypes| => ['gsm'], the possible combination will be,
    - 'gsm'
2). if |supportedNetworkTypes| => ['gsm', 'wcdma'], the possible combination will be,
    - 'gsm'
    - 'wcdma'
    - 'wcdma/gsm'
    - 'wcdma/gsm-auto'
3). if |supportedNetworkTypes| => ['gsm', 'wcdma', 'cdma', 'evdo'], the possible combination will be,
    - 'gsm'
    - 'wcdma'
    - 'wcdma/gsm'
    - 'wcdma/gsm-auto'
    - 'cdma'
    - 'evdo'
    - 'cdma/evdo'
    - 'wcdma/gsm/cdma/evdo'
....


And to check a specific capability, it is much easier by using |supportedNetworkTypes|.
For example, we want to show LTE specific configuration only in the device that supports LTE, then we can have below check,

  if (mozMobileConnection.supportedNetworkType.indexOf('lte') != -1) {
    // Setup LTE specific configuration.
  }

thank you

[1] http://dxr.mozilla.org/mozilla-central/source/dom/network/interfaces/nsIDOMMobileConnection.idl?from=nsIDOMMobileConnection.idl#132
[2] https://github.com/mozilla-b2g/platform_hardware_ril/blob/master/include/telephony/ril.h#L110

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 11 • 11 years ago

Thank to Edgar's comment. After reading this and offline discussion with Edgar, I re-thought about the combination proposal and I agree with Edgar's comment 10 -- not exposing combination, given that this new attribute is used to provide 'supported' network types and 'combination' isn't an actual type. "Combination" string is instead a preference telling modem to try to camp on the network whose type fits the preference string well. 

Also, per my best knowledge, there's no HW having distinct supported types for voice and data, so |mozMobileConnections[n].supportedNetworkTypes| looks reasonable to me.

	Edgar Chen [:edgar] Assignee
	Comment 12 • 11 years ago

To achieve this, we also need gonk provide ro properties to indicate the HW capabilities.

My idea is having ro.moz.ril.[n].network_types, and the value is the network types (separated by comma) which are supported by specific radio. (The MAX length of property name is 32 [1].)

Take the possible setup for existing device as example,
(1) Fugu (Multi-SIM device),
    ro.moz.ril.0.network_types = gsm,wcdma
    ro.moz.ril.1.network_types = gsm

(2) Unagi (Single-sim device),
    ro.moz.ril.0.network_types = gsm,wcdma

Hsinyi, do you have any other suggestions for the format or naming?
Thank you.

[1] https://github.com/mozilla-b2g/platform_bionic/blob/master/libc/include/sys/system_properties.h#L38

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 13 • 11 years ago

(In reply to Edgar Chen [:edgar][:echen] from comment #12)
> To achieve this, we also need gonk provide ro properties to indicate the HW
> capabilities.
> 
> My idea is having ro.moz.ril.[n].network_types, and the value is the network
> types (separated by comma) which are supported by specific radio. (The MAX
> length of property name is 32 [1].)
> 
> Take the possible setup for existing device as example,
> (1) Fugu (Multi-SIM device),
>     ro.moz.ril.0.network_types = gsm,wcdma
>     ro.moz.ril.1.network_types = gsm
> 
> (2) Unagi (Single-sim device),
>     ro.moz.ril.0.network_types = gsm,wcdma
> 
> Hsinyi, do you have any other suggestions for the format or naming?
> Thank you.
> 
> [1]
> https://github.com/mozilla-b2g/platform_bionic/blob/master/libc/include/sys/
> system_properties.h#L38

Sounds good, no better ideas than this. :)

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 14 • 11 years ago

Any progress here? Please make sure people have time to write Gaia patch in bug 953439 before code freeze date.

If we could work on this in parallel that would be great too.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 15 • 11 years ago

Sorry, wrong bug, I was meant to say bug 950185.

	Edgar Chen [:edgar] Assignee
	Comment 16 • 11 years ago

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #14)
> Any progress here? Please make sure people have time to write Gaia patch in
> bug 953439 before code freeze date.
> 
> If we could work on this in parallel that would be great too.

I am working on this. Patches are almost ready, but still under testing, will upload later.
Basically, the new API and implementation is based on comment #4.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 17 • 11 years ago

Thank you! I've ask George for help on the Gaia part.

	Edgar Chen [:edgar] Assignee
	Comment 19 • 11 years ago

nsIMobileConnectionListener is not changed, need not to modify its uuid.

	Edgar Chen [:edgar] Assignee
	Comment 23 • 11 years ago

Comment on attachment 8357634 [details] [diff] [review]
Part 1: IDL changes, v2

Please see comment #4 and comment #10 for the details of new attribute, |supportedNetworkTypes|, in mozMobileConnection.
Thank you.

	Vicamo Yang [:vicamo][:vyang]
	Comment 24 • 11 years ago

Comment on attachment 8357634 [details] [diff] [review]
Part 1: IDL changes, v2

Review of attachment 8357634 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/network/interfaces/nsIDOMMobileConnection.idl
@@ +94,5 @@
> +   * Array of network types that are supported by this radio.
> +   *
> +   * Possible values: 'gsm', 'wcdma', 'cdma', 'evdo', 'lte'
> +   */
> +  readonly attribute jsval supportedNetworkTypes;   // DOMString[]

Please use 'nsIDOMDOMStringList' instead.

::: dom/network/interfaces/nsIMobileConnectionProvider.idl
@@ +61,5 @@
>    nsIDOMMozMobileConnectionInfo getDataConnectionInfo(in unsigned long clientId);
>    DOMString getIccId(in unsigned long clientId);
>    DOMString getNetworkSelectionMode(in unsigned long clientId);
>    DOMString getRadioState(in unsigned long clientId);
> +  jsval getSupportedNetworkTypes(in unsigned long clientId);

ditto.

	Edgar Chen [:edgar] Assignee
	Comment 25 • 11 years ago

Comment on attachment 8357634 [details] [diff] [review]
Part 1: IDL changes, v2

Should address comment #24 first. Cancel the review request.
Thank you

	Edgar Chen [:edgar] Assignee
	Comment 26 • 11 years ago

Comment on attachment 8357635 [details] [diff] [review]
Part 2: DOM changes, v1

Should address comment #24 first. Cancel the review request.
Thank you

	Edgar Chen [:edgar] Assignee
	Comment 27 • 11 years ago

Comment on attachment 8357636 [details] [diff] [review]
Part 3: RIL implementation, v1

Should address comment #24 first. Cancel the review request.
Thank you

	Edgar Chen [:edgar] Assignee
	Comment 28 • 11 years ago

Comment on attachment 8357638 [details] [diff] [review]
Part 4: Test cases, v1

Should address comment #24 first. Cancel the review request.
Thank you

	Andrew Overholt [:overholt]
	Comment 29 • 11 years ago

Blocks a blocker (bug 950185)

	Junior Hsu
	Comment 30 • 11 years ago

Hi all, apologize for stupid questions from a non-engineers. So what is our capability with 1.3 now?
WCDMA + GSM (GPRS)? 
Was told that the SIM2 slot only supports GSM. Will we prompt users with such info so they don't put in the wrong slot? 

Will be enable WCDMA + WCDMA and CDMA+CDMA?

	Edgar Chen [:edgar] Assignee
	Comment 31 • 11 years ago

(In reply to jhsu from comment #30)
> Hi all, apologize for stupid questions from a non-engineers. So what is our
> capability with 1.3 now?
> WCDMA + GSM (GPRS)? 

As I know, the capability of fugu is 
slot 0 -> WCDMA + GSM
slot 1 -> GSM

> Was told that the SIM2 slot only supports GSM. Will we prompt users with
> such info so they don't put in the wrong slot? 
> 
> Will be enable WCDMA + WCDMA and CDMA+CDMA?

I guess you mean
slot 0: WCDMA
slot 1: WCDMA
or
slot 0: CDMA
slot 1: CDMA

If so, it is possible, it's depended on the capability of modem.

	Edgar Chen [:edgar] Assignee
	Comment 32 • 11 years ago

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #24)
> Comment on attachment 8357634 [details] [diff] [review]
> Part 1: IDL changes, v2
> 
> Review of attachment 8357634 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/network/interfaces/nsIDOMMobileConnection.idl
> @@ +94,5 @@
> > +   * Array of network types that are supported by this radio.
> > +   *
> > +   * Possible values: 'gsm', 'wcdma', 'cdma', 'evdo', 'lte'
> > +   */
> > +  readonly attribute jsval supportedNetworkTypes;   // DOMString[]
> 
> Please use 'nsIDOMDOMStringList' instead.
> 
> ::: dom/network/interfaces/nsIMobileConnectionProvider.idl
> @@ +61,5 @@
> >    nsIDOMMozMobileConnectionInfo getDataConnectionInfo(in unsigned long clientId);
> >    DOMString getIccId(in unsigned long clientId);
> >    DOMString getNetworkSelectionMode(in unsigned long clientId);
> >    DOMString getRadioState(in unsigned long clientId);
> > +  jsval getSupportedNetworkTypes(in unsigned long clientId);
> 
> ditto.

Since we use javascript to implement nsIMobileConnectionProvider currently. If we want to return a nsIDOMDOMStringList in provider interface, we need to implement nsIDOMDOMStringList in javascript. But in this way we are unable to use array indexing, foo[i], to access it. (Array indexing is only available for nsDOMStringList which is implemented by C++) 

So my idea is keep provider interface returns jsval and convert it to nsDOMStringList in MobileConnection. Hi smaug, could you kindly share your opinion about this thought? Thank you in advance.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 33 • 11 years ago

DOMStringList is deprecated, please don't use it if possible.
The API exposed to web should probably use [Cached] attribute sequence<DOMString>?
if it was converted to webidl
(See for example 942631 and Bug 946294)

If one needs to return an array of something in .idl, using nsIVariant is one possibility.
Something like http://mxr.mozilla.org/comm-esr17/source/mozilla/content/base/src/nsDOMMutationObserver.cpp?mark=581-608#581 in C++ (that returns an array of objects, but strings should be supported too).

	Edgar Chen [:edgar] Assignee
	Comment 34 • 11 years ago

(In reply to Olli Pettay [:smaug] from comment #33)
> DOMStringList is deprecated, please don't use it if possible.
> The API exposed to web should probably use [Cached] attribute
> sequence<DOMString>?
> if it was converted to webidl
> (See for example 942631 and Bug 946294)
> 
> If one needs to return an array of something in .idl, using nsIVariant is
> one possibility.
> Something like
> http://mxr.mozilla.org/comm-esr17/source/mozilla/content/base/src/
> nsDOMMutationObserver.cpp?mark=581-608#581 in C++ (that returns an array of
> objects, but strings should be supported too).

This information is really helpful. Thank you very much.

	Edgar Chen [:edgar] Assignee
	Comment 35 • 11 years ago

Use nsIVariant

	Edgar Chen [:edgar] Assignee
	Comment 36 • 11 years ago

Use nsIVariant

	Anshul
	Comment 37 • 11 years ago

(In reply to Ken Chang[:ken] from comment #0)
> Currently, Firefox has supported WCDMA and CDMA. However, we don't know
> which network capabilities HW platform supports. We need a method to tell
> Gaia which network capabilities current platform supports. Then Gaia can
> decide to show which network types for users.

Ken, please CC us on such important bugs that would affect QCRIL as well, specifically so close to 1.3 commercialization. I just came to know about this bug accidentally.

	Ken Chang[:kenkai] Reporter
	Comment 38 • 11 years ago

(In reply to Anshul from comment #37)
> Ken, please CC us on such important bugs that would affect QCRIL as well,
> specifically so close to 1.3 commercialization. I just came to know about
> this bug accidentally.
Sure, we will do it. For this bug, please let us know when you are ready.
Edgar, please wait for signal from Anshul to checkin this code. Thanks.

	Edgar Chen [:edgar] Assignee
	Comment 39 • 11 years ago

(In reply to Ken Chang[:ken] from comment #38)
> (In reply to Anshul from comment #37)
> > Ken, please CC us on such important bugs that would affect QCRIL as well,
> > specifically so close to 1.3 commercialization. I just came to know about
> > this bug accidentally.
> Sure, we will do it. For this bug, please let us know when you are ready.
> Edgar, please wait for signal from Anshul to checkin this code. Thanks.

Anshul, please let me know when commercial ril is ready. Thank you in advance.

	Anshul
	Comment 40 • 11 years ago

Ken, QC RIL change would be ready soon. However doesn't seem like Gaia is using this new API so this Gecko bug can land without waiting for QC RIL. Please land this change.

Do you know how Gaia plans to use this API and could you please point me to the specific Gaia bug that will use this new API?

	Edgar Chen [:edgar] Assignee
	Comment 41 • 11 years ago

(In reply to Anshul from comment #40)
> Ken, QC RIL change would be ready soon. However doesn't seem like Gaia is
> using this new API so this Gecko bug can land without waiting for QC RIL.
> Please land this change.
> 
> Do you know how Gaia plans to use this API and could you please point me to
> the specific Gaia bug that will use this new API?

Please see bug 950185. Thank you.

	Arthur Chen [:arthurcc][inactive after 6/30]
	Comment 42 • 11 years ago

Anshul, bug 949741 will use the new API, too. We will also use the new API to determine what to show in the preferred network type list.

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 43 • 11 years ago

Comment on attachment 8357636 [details] [diff] [review]
Part 3: RIL implementation, v1

Review of attachment 8357636 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/RadioInterfaceLayer.js
@@ +1094,5 @@
>    };
>  
> +  // Get supported network types from system properties.
> +  let key = "ro.moz.ril." + this.clientId + ".network_types";
> +  this.supportedNetworkTypes = libcutils.property_get(key, "").split(",");

I'd like to have an internal function for line #1098 to line #1106 because I don't want to have a value which has not be processed/checked to be saved to 'this.supportedNetworkTypes.'

@@ +1098,5 @@
> +  this.supportedNetworkTypes = libcutils.property_get(key, "").split(",");
> +  for (let type of this.supportedNetworkTypes) {
> +    if (RIL.GECKO_SUPPORTED_NETWORK_TYPES.indexOf(type) < 0) {
> +      this.debug("Unknown network type: " + type);
> +      this.supportedNetworkTypes = RIL.GECKO_SUPPORTED_NETWORK_TYPES_DEFAULT.split(",");

nit: wrap the line at 80th character.

::: dom/system/gonk/ril_consts.js
@@ +423,5 @@
>    GECKO_PREFERRED_NETWORK_TYPE_EVDO_ONLY,
>    GECKO_PREFERRED_NETWORK_TYPE_WCDMA_GSM_CDMA_EVDO
>  ];
>  
> +this.GECKO_SUPPORTED_NETWORK_TYPES_DEFAULT = "gsm,wcdma,cdma,evdo";

Could you explain how we come out the default types?

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 44 • 11 years ago

Comment on attachment 8357638 [details] [diff] [review]
Part 4: Test cases, v1

Review of attachment 8357638 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/network/tests/marionette/test_mobile_preferred_network_type.js
@@ +10,5 @@
>     "connection is instanceof " + connection.constructor);
>  
> +function testSupportedNetworkTypes() {
> +  let supportedNetworkTypes = connection.supportedNetworkTypes;
> +

Has the property "ro.moz.ril._id_.network_types" been added to emulator as well?

	Edgar Chen [:edgar] Assignee
	Comment 45 • 11 years ago

Thanks for your review. :)

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #43)
> Comment on attachment 8357636 [details] [diff] [review]
> Part 3: RIL implementation, v1
> 
> Review of attachment 8357636 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/system/gonk/RadioInterfaceLayer.js
> @@ +1094,5 @@
> >    };
> >  
> > +  // Get supported network types from system properties.
> > +  let key = "ro.moz.ril." + this.clientId + ".network_types";
> > +  this.supportedNetworkTypes = libcutils.property_get(key, "").split(",");
> 
> I'd like to have an internal function for line #1098 to line #1106 because I
> don't want to have a value which has not be processed/checked to be saved to
> 'this.supportedNetworkTypes.'
Okay, I will add an internal function for this.

> 
> @@ +1098,5 @@
> > +  this.supportedNetworkTypes = libcutils.property_get(key, "").split(",");
> > +  for (let type of this.supportedNetworkTypes) {
> > +    if (RIL.GECKO_SUPPORTED_NETWORK_TYPES.indexOf(type) < 0) {
> > +      this.debug("Unknown network type: " + type);
> > +      this.supportedNetworkTypes = RIL.GECKO_SUPPORTED_NETWORK_TYPES_DEFAULT.split(",");
> 
> nit: wrap the line at 80th character.
Okay.

> 
> ::: dom/system/gonk/ril_consts.js
> @@ +423,5 @@
> >    GECKO_PREFERRED_NETWORK_TYPE_EVDO_ONLY,
> >    GECKO_PREFERRED_NETWORK_TYPE_WCDMA_GSM_CDMA_EVDO
> >  ];
> >  
> > +this.GECKO_SUPPORTED_NETWORK_TYPES_DEFAULT = "gsm,wcdma,cdma,evdo";
> 
> Could you explain how we come out the default types?

Gaia will reference this value to show the preferred network type, and currently Gaia put all preferred network type by default. So I use world phone as default value to consist with current behavior.

	Edgar Chen [:edgar] Assignee
	Comment 46 • 11 years ago

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #44)
> Comment on attachment 8357638 [details] [diff] [review]
> Part 4: Test cases, v1
> 
> Review of attachment 8357638 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/network/tests/marionette/test_mobile_preferred_network_type.js
> @@ +10,5 @@
> >     "connection is instanceof " + connection.constructor);
> >  
> > +function testSupportedNetworkTypes() {
> > +  let supportedNetworkTypes = connection.supportedNetworkTypes;
> > +
> 
> Has the property "ro.moz.ril._id_.network_types" been added to emulator as
> well?

Because the default value is "gsm,wcdma,cdma,evdo", so it is ok for emulator without property setup.
(If we change the default value, then yes, we need to set property first before we land the test cases)

Thank you

	Edgar Chen [:edgar] Assignee
	Comment 47 • 11 years ago

Add r=smaug,hsinyi after r+.

	Edgar Chen [:edgar] Assignee
	Comment 48 • 11 years ago

Add r=smaug after r+.

	Edgar Chen [:edgar] Assignee
	Comment 49 • 11 years ago

1). Rebase
2). Address review comment #43.

	Edgar Chen [:edgar] Assignee
	Comment 50 • 11 years ago

Add r=hsinyi after r+.

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 51 • 11 years ago

Comment on attachment 8359697 [details] [diff] [review]
Part 3: RIL implementation, v2

Review of attachment 8359697 [details] [diff] [review]:
-----------------------------------------------------------------

Thank you!!!!

	Edgar Chen [:edgar] Assignee
	Comment 52 • 11 years ago

Try server: https://tbpl.mozilla.org/?tree=Try&rev=0d636c9a7830

	Edgar Chen [:edgar] Assignee
	Comment 53 • 11 years ago

Hi Shawn,

Could you please help to share the information about ro.moz.ril.[n].network_types to partners?
(Please see comment #12 for more details)
And we probably need to add proper config into all existing devices.

Thank you

	Edgar Chen [:edgar] Assignee
	Comment 54 • 11 years ago

Comment on attachment 8359697 [details] [diff] [review]
Part 3: RIL implementation, v2

Review of attachment 8359697 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/RadioInterfaceLayer.js
@@ +1112,5 @@
>      byType: {},
>      byApn: {}
>    };
>  
> +  this.supportedNetworkTypes = this.getSupportedNetworkTypes()

Oops, miss a semicolon here.

	Edgar Chen [:edgar] Assignee
	Comment 55 • 11 years ago

Address comment #54.

	Edgar Chen [:edgar] Assignee
	Comment 56 • 11 years ago

Try server again: https://tbpl.mozilla.org/?tree=Try&rev=4852ef42b162

	Edgar Chen [:edgar] Assignee
	Comment 57 • 11 years ago

(In reply to Edgar Chen [:edgar][:echen] from comment #56)
> Try server again: https://tbpl.mozilla.org/?tree=Try&rev=4852ef42b162
Weird, this try doesn't start. :(

Try again: https://tbpl.mozilla.org/?tree=Try&rev=8cd0c7df8be5

	Anshul
	Comment 58 • 11 years ago

Ken, is this change really needed for 1.3?

	Edgar Chen [:edgar] Assignee
	Comment 59 • 11 years ago

(In reply to Edgar Chen [:edgar][:echen] from comment #57)
> (In reply to Edgar Chen [:edgar][:echen] from comment #56)
> > Try server again: https://tbpl.mozilla.org/?tree=Try&rev=4852ef42b162
> Weird, this try doesn't start. :(
> 
> Try again: https://tbpl.mozilla.org/?tree=Try&rev=8cd0c7df8be5

Fail in mochitest-debug-1, but it was fixed in bug 883975. So it is safe to put into inbound.

	Edgar Chen [:edgar] Assignee
	Comment 60 • 11 years ago

https://hg.mozilla.org/integration/b2g-inbound/rev/238b3d2bf757
https://hg.mozilla.org/integration/b2g-inbound/rev/6af90b41226f
https://hg.mozilla.org/integration/b2g-inbound/rev/362f1c80ccd1
https://hg.mozilla.org/integration/b2g-inbound/rev/6e0af6d62dbb

	Ed Morley [:emorley]
	Comment 61 • 11 years ago

https://hg.mozilla.org/mozilla-central/rev/238b3d2bf757
https://hg.mozilla.org/mozilla-central/rev/6af90b41226f
https://hg.mozilla.org/mozilla-central/rev/362f1c80ccd1
https://hg.mozilla.org/mozilla-central/rev/6e0af6d62dbb

	Ryan VanderMeulen [:RyanVM]
	Comment 62 • 11 years ago

https://hg.mozilla.org/releases/mozilla-aurora/rev/0a54809f94a1
https://hg.mozilla.org/releases/mozilla-aurora/rev/86df5d094ae5
https://hg.mozilla.org/releases/mozilla-aurora/rev/054bb6f1eef5
https://hg.mozilla.org/releases/mozilla-aurora/rev/14be3d1cdd14

	shawn ku [:sku]
	Comment 63 • 11 years ago

Hi Sam:
 Please help setup below properties for fugu/tarako. (see comment 12 for detail).
Thanks!!
Shawn


(1) Fugu (Multi-SIM device),
    ro.moz.ril.0.network_types = gsm,wcdma
    ro.moz.ril.1.network_types = gsm

(2) Unagi (Single-sim device),
    ro.moz.ril.0.network_types = gsm,wcdma

	sam.hua
	Comment 64 • 11 years ago

in the base.mk?

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 65 • 11 years ago

(In reply to sam.hua from comment #64)
> in the base.mk?

Sorry for missing this.

Yes, it could be in base.mk. Please add the quirk so that bug 953439 could move on.

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 66 • 11 years ago

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #65)
> (In reply to sam.hua from comment #64)
> > in the base.mk?
> 
> Sorry for missing this.
> 
> Yes, it could be in base.mk. Please add the quirk so that bug 953439 could
> move on.

I filed bug 980831 for tracking this!