Closed Bug 881862 Opened 12 years ago Closed 12 years ago

[Gaia] B2G CDMA: Network mode support in settings

Categories

(Firefox OS Graveyard :: Gaia::Settings, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:koi+)

RESOLVED FIXED
blocking-b2g koi+

People

(Reporter: skamat, Assigned: arthurcc)

References

Details

(Whiteboard: [UX ETA:9/6], [FT:RIL], [Sprint:4])

Attachments

(2 files)

Need an UI setting for selecting various network modes like CDMA only, CDMA/EvDo preferred, CDMA/EvDo auto and so on. Currently the Network mode setting under Network Operator setting only has Automatic, 2G only, 3G only. Either we keep these settings and add a new network mode setting or extend the existing one. Android keeps them separate. However hides the network operator setting if the network mode in CDMA family.
Blocks: b2g-ril-cdma
Assignee: nobody → echen
RIL is already supporting all network mode in bug 834118. Now all we need is UI setting supports this. The possible values of network mode are in http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_consts.js#343.
Assignee: echen → nobody
Component: Gaia → Gaia::Settings
After a offline discussion with Edgar, what we need to do here is, 1. Find a way to detect what mode the device is in, - If GSM -> show the options for wcdma/gsm/both - If CDMA -> show cdma/evDo/both - If dual mode are supported -> then need UX input/study on how to provide the options. 2. If approach 1 cannot be achieved due to the the lack of some APIs, we might need to do some customization at Gaia build time. i.e., to choose one group of options from "GSM" or "CDMA".
Assignee: nobody → rlu
(In reply to Rudy Lu [:rudyl] from comment #2) > After a offline discussion with Edgar, what we need to do here is, > > 1. Find a way to detect what mode the device is in, > - If GSM -> show the options for wcdma/gsm/both > - If CDMA -> show cdma/evDo/both > - If dual mode are supported -> then need UX input/study on how to > provide the options. > > 2. If approach 1 cannot be achieved due to the the lack of some APIs, we > might need to do some customization at Gaia build time. i.e., to choose one > group of options from "GSM" or "CDMA". Approach 1 seems can not be achieved due to there is no such API to get the capability of device. Maybe we should consider approach 2.
Rudy, FFOS is not there yet but eventually it could support all network modes (global phone) so should have an ability to show all gsm and cdma network modes. So I think we should not consider GSM and CDMA as mutually exclusive but a list of network modes to display (gsm and/or cdma) based on some preference.
Hi Anshul, Yes, I agree that Firefox OS should support more than one network mode. Comment 2 is just an example. To support this, we can customize the network mode options at build time, and the configuration mechanism should be flexible enough to represent any set of options.
Per discussion with Rudy, take the bug.
Assignee: rlu → arthur.chen
(In reply to Rudy Lu [:rudyl] from comment #5) > Hi Anshul, > > Yes, I agree that Firefox OS should support more than one network mode. > Comment 2 is just an example. > > To support this, we can customize the network mode options at build time, > and the configuration mechanism should be flexible enough to represent any > set of options. Rudy, it will be ideal if this is a run time customizable then build time so that we can test both gsm/cdma on a phone that supports both, specifically to make sure adding CDMA features shouldn't break the existing GSM features.
Anshul, we can add both gsm and cdma options at build time, which also allows us to test gsm/cdma on a phone.
Jose, the patch is made for enabling customizing network type options from a json file (/distribution/network.json). Although we don't have detail UX spec yet, would you mind take a look at this approach at first? Thanks!
Attachment #773128 - Flags: feedback?(josea.olivera)
Comment on attachment 773128 [details] link to https://github.com/mozilla-b2g/gaia/pull/10877 I like the idea of having this network.json file and build the list on the fly but if the OEM needs to change the application-data.js file it has to do it by hand and this is not convenience at all. I would prefer to have an API to check whether the device supports CDMA and built the list based on that information instead. I don't see why we cannot expose this information through mozMobileConnection API for example.
Attachment #773128 - Flags: feedback?(josea.olivera) → feedback+
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #10) > Comment on attachment 773128 [details] > link to https://github.com/mozilla-b2g/gaia/pull/10877 > > I like the idea of having this network.json file and build the list on the > fly but if the OEM needs to change the application-data.js file it has to do > it by hand and this is not convenience at all. I would prefer to have an API > to check whether the device supports CDMA and built the list based on that > information instead. I don't see why we cannot expose this information > through mozMobileConnection API for example. Antonio, there is no RIL API that would tell you what is the capability of the modem. RIL only tells you what the current network mode is and what is the registered radio technology but not whether the modem supports a particular radio tech.
(In reply to Anshul from comment #11) > Antonio, there is no RIL API that would tell you what is the capability of > the modem. RIL only tells you what the current network mode is and what is > the registered radio technology but not whether the modem supports a > particular radio tech. I was wondering how to implement something like `TelephonyManager.getPhoneType()` (see [1]) from Android. [1] http://developer.android.com/reference/android/telephony/TelephonyManager.html#getPhoneType%28%29
Antonio, the way Android implements that is based on the following two. 1. Look at the settings for network mode and start with either a GSM or a CDMA phone type 2. When RIL sends a voice radio tech changed message, Android looks at it and change phone types if the radio tech reported is different. In both the cases above, the pre-requisite is that the user has selected some network mode in the UI that would end up setting the network mode in the modem. So this definitely doesn't solve the problem you are trying to address. Android shows only the GSM modes by default and have a build time configuration that when turned on would show all the network modes (CDMA and GSM). OEMs then customize this UI to show only the modes they want. I think by default we should show all the GSM and CDMA modes so we all can test all these modes and let OEM, whoever that would be for 1.2, make the change in their builds.
Antonio, are you suggesting that gecko should provide API similar to `TelephonyManager.getPhoneType()`? It seems like the proposed patch only supports customizing phones that supports only one network type. Consider phones with multi-sims and supporting multiple network types, settings app or all related UI should reflect the types of the current connected networks at runtime. We may need ways to get the types of the connected networks after the phone boots up.
Flags: needinfo?(josea.olivera)
(In reply to Arthur Chen [:arthurcc] from comment #14) > Antonio, are you suggesting that gecko should provide API similar to > `TelephonyManager.getPhoneType()`? > > It seems like the proposed patch only supports customizing phones that > supports only one network type. Consider phones with multi-sims and > supporting multiple network types, settings app or all related UI should > reflect the types of the current connected networks at runtime. We may need > ways to get the types of the connected networks after the phone boots up. Arthur that won't solve your problem as modem might just report GSM (due to a setting in the modem) in which case how are you going to know if the modem supports CDMA. I don't think you can come up with a dynamic solution for this problem. You might have to make this configurable and let OEM make the decision on which setting to display based on which networks the phone is intended to be used with.
Clearing ni? since Anshul provided comment #15.
Flags: needinfo?(josea.olivera)
blocking-b2g: --- → koi+
Summary: B2G CDMA: Network mode support in settings → [Gaia] B2G CDMA: Network mode support in settings
Ivan and Candice, this one looks like something in Settings app. Can you make sure it's under your radar?
Flags: needinfo?(itsay)
Flags: needinfo?(cserran)
(In reply to khu from comment #17) > Ivan and Candice, this one looks like something in Settings app. Can you > make sure it's under your radar? Yes, it is under system platform setting app and Arthur in TW gaia team has taken the bug. Per discussion with Kevin so far, CDMA team links the bug to CDMA user story and system platform will have sync-up with CDMA team for tracking.
Flags: needinfo?(itsay)
Thank you, Ivan and Arthur.
Flags: needinfo?(cserran)
Whiteboard: [UX ETA:9/6]
Whiteboard: [UX ETA:9/6] → [UX ETA:9/6], [FT:RIL], [Sprint:4]
What's the status of this change?
After the UX part finalized, we will use the current customization mechanism as the provided patch to implement the feature.
Had an offline discussion with Ken, we will implement the feature for QA testing at first, and file another bug for improving the UX.
Comment on attachment 773128 [details] link to https://github.com/mozilla-b2g/gaia/pull/10877 Jose, I've tested it on my CDMA device and worked well, please help review the patch, thanks!
Attachment #773128 - Flags: review?(josea.olivera)
(In reply to Arthur Chen [:arthurcc] from comment #23) > Comment on attachment 773128 [details] > link to https://github.com/mozilla-b2g/gaia/pull/10877 > > Jose, I've tested it on my CDMA device and worked well, please help review > the patch, thanks! Leave some comments on github. Could you take a look please? Thanks! Anshul, the type that we are going to show for now are: + 'types': ['wcdma/gsm', 'gsm', 'wcdma'] It's correct, isn't it?
Flags: needinfo?(arthur.chen)
Flags: needinfo?(anshulj)
Attached file network.json
Put network.json to GAIA_DIR/distribution and make reset-gaia to have a build for CDMA.
Flags: needinfo?(arthur.chen)
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #24) > (In reply to Arthur Chen [:arthurcc] from comment #23) > > Comment on attachment 773128 [details] > > link to https://github.com/mozilla-b2g/gaia/pull/10877 > > > > Jose, I've tested it on my CDMA device and worked well, please help review > > the patch, thanks! > > Leave some comments on github. Could you take a look please? Thanks! > > Anshul, the type that we are going to show for now are: > > + 'types': ['wcdma/gsm', 'gsm', 'wcdma'] > > It's correct, isn't it? Antonio, what about the CDMA network types? This bug is about adding the support for CDMA networks and not the wcdma/gsm as they already exist.
Flags: needinfo?(anshulj)
The code shown in comment 24 is the default configuration. It will be overrided if we put correct json file in the distribution directory as comment 25. Antonio, I've addressed your comment in github, could you help take a look at it again?
Flags: needinfo?(josea.olivera)
(In reply to Arthur Chen [:arthurcc] from comment #27) > The code shown in comment 24 is the default configuration. It will be > overrided if we put correct json file in the distribution directory as > comment 25. Is there any reason for not adding all the GSM and CDMA modes? Anyway this approach works for me also (same for you Anshul?) but I thought we wanted to add all the GSM and CDMA modes as Anshul commented. (In reply to Anshul from comment #13) > I think by default we should show all the GSM and CDMA modes so we all can > test all these modes and let OEM, whoever that would be for 1.2, make the > change in their builds.
Flags: needinfo?(josea.olivera)
By doing this there are risks of the settings app displays GSM and CDMA options at the same time if we don't put correct json file in the distribution folder. I would prefer to have a default set that won't break anything. What do you think?
Arthur, since the support for CDMA is being added, I think it is alright to see all the GSM and CDMA modes together. The OEMs can change the JSON to filter only the network modes they support but it would be much easier during the development phase if all the modes are available.
Hi Anshul, Are there still CDMA only, EVDO only, and CDMA/EVDO preferred items in network mode setting? These items are also helpful for testing when we just want to check CDMA 1x functionality or EVDO vice versa. Just want to confirm again in case there will be only gsm/cdma item left in the end. Thanks.
Flags: needinfo?(anshulj)
We will list all network options by default.
Flags: needinfo?(anshulj)
Anshul, thanks for the suggestion. It shows all network options by default as suggested, which was landed in bug 891742. The patch is updated based on that. Antonio, could you help review it again? Thanks!
Comment on attachment 773128 [details] link to https://github.com/mozilla-b2g/gaia/pull/10877 Arthur, thanks for you work. Left a couple of comments in github. Please address them before landing the patch. r=me with this comments addressed. I would recommend to leave a message in the patch about the user will see both GSM and CDMA options in the setting app. Since this is a bit confusing we would inform in that message that this is only for debugging purposes while developing CDMA support in B2G. I would also file a bug because we should change that at some point. I mean, once the development for CDMA support gets finished we should show only the GSM options by default and let OEMs to change them in case of CDMA devices. Could you file a bug, leave a message and add the bug number to the message please?
Attachment #773128 - Flags: review?(josea.olivera) → review+
Comment addressed and Bug 903232 filed as suggested. Antonio, thanks for reviewing! master: https://github.com/mozilla-b2g/gaia/commit/1ba090abb7191e609f20df46df913bb2b4b57b08
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
(In reply to Arthur Chen [:arthurcc] from comment #33) > Anshul, thanks for the suggestion. It shows all network options by default > as suggested, which was landed in bug 891742. The patch is updated based on > that. Antonio, could you help review it again? Thanks! This looks good Arthur, I wasn't aware of bug 891742.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: