Handle support calling line identification restriction feature through MMI codes.

WIP. MMI codes: CLIR (non-temporary ones)

Carol, since CLIR feature handled by MMI codes is already supported by commercial RIL could you take a look at how we have implemented it please? We still need to figure out how to implement the *31#<number> case.

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #2) > Created attachment 775584 [details] [diff] [review] > WIP v2 > > Carol, since CLIR feature handled by MMI codes is already supported by > commercial RIL could you take a look at how we have implemented it please? > We still need to figure out how to implement the *31#<number> case. Yeah, looks about right here.

Fernando, this patch adds support for calling line identification restriction feature through MMI codes. Could you take a look please? Thanks!

Comment on attachment 777395 [details] [diff] [review] MMI codes: support CLIR. v1 Review of attachment 777395 [details] [diff] [review]: ----------------------------------------------------------------- Thanks jaoo! r=me with the nits addressed, please. ::: dom/system/gonk/ril_consts.js @@ +2600,5 @@ > +this.MMI_SM_CLIR_PERMANENT = "smClirPermanent"; > +this.MMI_SM_CLIR_DEFAULT_ON_NEXT_CALL_ON = "smClirDefaultOnNextCallOn"; > +this.MMI_SM_CLIR_DEFAULT_ON_NEXT_CALL_OFF = "smClirDefaultOnNextCallOff"; > +this.MMI_SM_CLIR_DEFAULT_OFF_NEXT_CALL_ON = "smClirDefaultOffNextCallOn"; > +this.MMI_SM_CLIR_DEFAULT_OFF_NEXT_CALL_OFF = "smClirDefaultOffNextCallOff"; Use the same nomenclature as the rest of the status message key strings: MMI_SM_KS_*, please. ::: dom/system/gonk/ril_worker.js @@ +5003,5 @@ > options.n = Buf.readUint32(); // Will be TS 27.007 +CLIR parameter 'n'. > options.m = Buf.readUint32(); // Will be TS 27.007 +CLIR parameter 'm'. > + > + if (options.rilMessageType === "sendMMI") { > + var statusMessage; s/var/let @@ +5005,5 @@ > + > + if (options.rilMessageType === "sendMMI") { > + var statusMessage; > + // TS 27.007 +CLIR parameter 'm'. > + switch (options.m) { In general, add a default case for switch statements where possible. In this case unexpected n or m parameter should probably trigger a generic error. @@ +5024,5 @@ > + case 3: > + // TS 27.007 +CLIR parameter 'n'. > + switch (options.n) { > + // Default. > + case 0: Is it possible to use the consts that you declared in ril_consts.js for the case conditions? CLIR_DEFAULT = 0; CLIR_INVOCATION = 1; CLIR_SUPPRESSION = 2; @@ +5030,5 @@ > + break; > + // CLIR invocation. > + case 1: > + statusMessage = MMI_SM_CLIR_DEFAULT_ON_NEXT_CALL_ON; > + break; You don't need to dup the case handlers. // Default. case 0: // CLIR invocation. case 1: statusMessage = MMI_SM_CLIR_DEFAULT_ON_NEXT_CALL_ON; break; @@ +5050,5 @@ > + case 1: > + statusMessage = MMI_SM_CLIR_DEFAULT_OFF_NEXT_CALL_ON; > + break; > + // CLIR suppression. > + case 2: Same as above, group the cases by handler. @@ +5056,5 @@ > + break; > + } > + break; > + } > + options.statusMessage = statusMessage; This assignment will be done even if statusMessage is not valid as result of a previosly identified error. Could you just directly assign to options.statusMesssage instead of using the statusMessage variable? @@ +5066,5 @@ > options.success = (options.rilRequestError === 0); > if (!options.success) { > options.errorMsg = RIL_ERROR_TO_GECKO_ERROR[options.rilRequestError]; > } > + if (options.success && options.rilMessageType === "sendMMI") { This works but is more clear this way: |if (options.success && (options.rilMessageType === "sendMMI"))|

The user story has been tested with satisfactory results. The tests have been executed with a SIM Tuenti. We tested several movistar SIMS, but we could not activating you supplementary services to this type of SIM.