952043 - [B2G] [Gecko] To provide the network types supported by platform for Gaia.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

[Ken Chang[:kenkai]]

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.

Comment 1

[Ken Chang[:kenkai]]

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

Comment 2

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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

Comment 3

[Ken Chang[:kenkai]]

We also need to consider the LTE.

Comment 4

[Edgar Chen [:edgar]]

(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

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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.

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(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.

Comment 7

[shawn ku [:sku]]

(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

Comment 8

[Marco Chen [:mchen]]

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

Comment 9

[Hsin-Yi Tsai (she/her) [:hsinyi]]

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.

Comment 10

[Edgar Chen [:edgar]]

((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

Comment 11

[Hsin-Yi Tsai (she/her) [:hsinyi]]

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.

Comment 12

[Edgar Chen [:edgar]]

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

Comment 13

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(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. :)

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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.

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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

Comment 16

[Edgar Chen [:edgar]]

(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.

Comment 17

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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

Comment 18

[Edgar Chen [:edgar]]

Attachment: Part 1: IDL changes, v1

Comment 19

[Edgar Chen [:edgar]]

Attachment: Part 1: IDL changes, v2

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

Comment 20

[Edgar Chen [:edgar]]

Attachment: Part 2: DOM changes, v1

Comment 21

[Edgar Chen [:edgar]]

Attachment: Part 3: RIL implementation, v1

Comment 22

[Edgar Chen [:edgar]]

Attachment: Part 4: Test cases, v1

Comment 23

[Edgar Chen [:edgar]]

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.

Comment 24

[Vicamo Yang [:vicamo][:vyang]]

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.

Comment 25

[Edgar Chen [:edgar]]

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

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

Comment 26

[Edgar Chen [:edgar]]

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

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

Comment 27

[Edgar Chen [:edgar]]

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

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

Comment 28

[Edgar Chen [:edgar]]

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

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

Comment 29

[Andrew Overholt [:overholt]]

Blocks a blocker (bug 950185)

Comment 30

[Junior Hsu]

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?

Comment 31

[Edgar Chen [:edgar]]

(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.

Comment 32

[Edgar Chen [:edgar]]

(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.

Comment 33

[Olli Pettay [:smaug][[e-mail]]]

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).

Comment 34

[Edgar Chen [:edgar]]

(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.

Comment 35

[Edgar Chen [:edgar]]

Attachment: Part 1: IDL changes, v3

Use nsIVariant

Comment 36

[Edgar Chen [:edgar]]

Attachment: Part 2: DOM changes, v2

Use nsIVariant

Comment 37

[Anshul]

(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.

Comment 38

[Ken Chang[:kenkai]]

(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.

Comment 39

[Edgar Chen [:edgar]]

(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.

Comment 40

[Anshul]

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?

Comment 41

[Edgar Chen [:edgar]]

(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.

Comment 42

[Arthur Chen [:arthurcc][inactive after 6/30]]

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.

Comment 43

[Hsin-Yi Tsai (she/her) [:hsinyi]]

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?

Comment 44

[Hsin-Yi Tsai (she/her) [:hsinyi]]

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?

Comment 45

[Edgar Chen [:edgar]]

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.

Comment 46

[Edgar Chen [:edgar]]

(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

Comment 47

[Edgar Chen [:edgar]]

Attachment: Part 1: IDL changes, v3, r=smaug,hsinyi

Add r=smaug,hsinyi after r+.

Comment 48

[Edgar Chen [:edgar]]

Attachment: Part 2: DOM changes, v2, r=smaug

Add r=smaug after r+.

Comment 49

[Edgar Chen [:edgar]]

Attachment: Part 3: RIL implementation, v2

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

Comment 50

[Edgar Chen [:edgar]]

Attachment: Part 4: Test cases, v1, r=hsinyi

Add r=hsinyi after r+.

Comment 51

[Hsin-Yi Tsai (she/her) [:hsinyi]]

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

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

Thank you!!!!

Comment 52

[Edgar Chen [:edgar]]

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

Comment 53

[Edgar Chen [:edgar]]

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

Comment 54

[Edgar Chen [:edgar]]

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.

Comment 55

[Edgar Chen [:edgar]]

Attachment: Part 3: RIL implementation, v3, r=hsinyi

Address comment #54.

Comment 56

[Edgar Chen [:edgar]]

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

Comment 57

[Edgar Chen [:edgar]]

(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

Comment 58

[Anshul]

Ken, is this change really needed for 1.3?

Comment 59

[Edgar Chen [:edgar]]

(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.

Comment 60

[Edgar Chen [:edgar]]

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

Comment 61

[Ed Morley [:emorley]]

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

Comment 62

[Ryan VanderMeulen [:RyanVM]]

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

Comment 63

[shawn ku [:sku]]

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

Comment 64

[sam.hua]

in the base.mk?

Comment 65

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(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.

Comment 66

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(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!