882983 - B2G RIL: Support for CDMA OTASP - expose ota status

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

[Anshul]

Gaia needs to listen to the events from RIL regarding OTASP and launch a new CDMA OTASP UI to enable users to provision the phone. The phone UI should also have a dialer to press the keys as instructed on the OTASP call.

Comment 1

[Szu-Yu Chen [:aknow] (inactive)]

Hi Anshul,

Does gecko have to involve in OTASP procedure? Does all OTASP REQ/RSP messages (ex: CONFIG_REQ, DOWNLOAD_REQ) handled in modem? If not, how could gecko receive/send the related message?

>> Gaia needs to listen to the events from RIL regarding OTASP

I only found this (RIL_UNSOL_CDMA_OTA_PROVISION_STATUS) in ril interface. That means gecko could notify gaia the status (ex: CDMA_OTA_PROVISION_STATUS_NAM_DOWNLOADED) when received the update from ril. Is this what you mean?

>> The phone UI should also have a dialer to press the keys as instructed on the OTASP call.

As I know, OTASP is activated when user dial a special service code (ex: *288). Since this is a call and user is currently in the dialer, the keypad is already existed for selecting the followed options. I might misunderstand the points. Would you please clarify this part.

Thank you.

Comment 2

[Anshul]

(In reply to Szu-Yu Chen [:aknow] from comment #1)
> Hi Anshul,
> 
> Does gecko have to involve in OTASP procedure? Does all OTASP REQ/RSP
> messages (ex: CONFIG_REQ, DOWNLOAD_REQ) handled in modem? If not, how could
> gecko receive/send the related message?
All gecko's involvement is to notify the gaia that OTA is needed and that OTA is done. OTA could also be started if the subscription is not available on the SIM by RIL.


> 
> >> Gaia needs to listen to the events from RIL regarding OTASP
> 
> I only found this (RIL_UNSOL_CDMA_OTA_PROVISION_STATUS) in ril interface.
> That means gecko could notify gaia the status (ex:
> CDMA_OTA_PROVISION_STATUS_NAM_DOWNLOADED) when received the update from ril.
> Is this what you mean?
> 
> >> The phone UI should also have a dialer to press the keys as instructed on the OTASP call.
> 
> As I know, OTASP is activated when user dial a special service code (ex:
> *288). Since this is a call and user is currently in the dialer, the keypad
> is already existed for selecting the followed options. I might misunderstand
> the points. Would you please clarify this part.
So I think we should introduced an API that would let RIL send the status of OTASP so that if OTA is needed, the dialer can show the OTA UI and when OTA is done as notified by RIL_UNSOL_CDMA_OTA_PROVISION_STATUS RIL can notify Gaia and dialer can remove the OTA UI. 

In Android OTA is a completely differet UI then dialer but that is actually not needed. So if we show OTA as a regular call then what we currently have in dialer is good enough.

> 
> Thank you.

Comment 3

[Szu-Yu Chen [:aknow] (inactive)]

Thanks Anshul.

> All gecko's involvement is to notify the gaia that OTA is needed and that
> OTA is done. OTA could also be started if the subscription is not available
> on the SIM by RIL.

So, gecko shall notify gaia:
1) the device need an OTASP update now ?
2) the status chagne for an existed OTASP session

> So I think we should introduced an API that would let RIL send the status of
> OTASP so that if OTA is needed, the dialer can show the OTA UI and when OTA
> is done as notified by RIL_UNSOL_CDMA_OTA_PROVISION_STATUS RIL can notify
> Gaia and dialer can remove the OTA UI. 

> In Android OTA is a completely differet UI then dialer but that is actually
> not needed. So if we show OTA as a regular call then what we currently have
> in dialer is good enough.

Would you please show an UI image for android cdma OTASP (not FOTA, system update) or describe it in detailed? My question is that how could we know an OTASP is needed.

For example, RPL (prefer roaming list)
http://en.wikipedia.org/wiki/Preferred_Roaming_List

Quote >> "Many operators provide the ability for the user to download the latest PRL to their device by dialing an Over-the-air (OTA) feature code. In the US, this feature code is *228 (*ACT) for Verizon/MetroPCS/US Cellular"

User could perform the action anytime he/she want to update the list. However, when should we notify the user an OTASP is needed? Is there any condition we could check?

Comment 4

[Anshul]

Szu-Yu RIL should send the information about when should OTA be started automatically up to Gaia; we will take care of that in commercial RIL. I will send you a screen shot of how OTA UI looks like in Android soon.

Comment 5

[Szu-Yu Chen [:aknow] (inactive)]

Hi Anshul,

Got your idea. So there will be a RIL unsolicited response from commercial RIL that indicates the OTA is needed. I would like to know is there a similar unsolicited response in reference-ril.

Comment 6

[Anshul]

Szu-Yu, for reference RIL you would have to check fro Mozilla's reference RIL team.

Comment 7

[Ken Chang[:kenkai]]

(In reply to Anshul from comment #6)
> Szu-Yu, for reference RIL you would have to check fro Mozilla's reference
> RIL team.

Anshul, do you know what is the unsolicited response from RILD for the OTA indication? Can you provide a screen shot of OTA UI? Thanks.

Comment 8

[Anshul]

Ken, I provided some snapshots as part of bug 890820.

Comment 9

[Szu-Yu Chen [:aknow] (inactive)]

In this bug, we decide to add an event to pass OTA provision status from gecko to gaia. Other OTA controlling logic (ex: ota is needed, success, failure) could be handle in gaia based on this provision status and MIN value in subscription info.

Comment 10

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: Part 1: Add ota status event (idl, webidl)

Comment 11

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: Part 2: Add ota status event (dom)

Comment 12

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: Part 3: Pass ota status (ril)

Comment 13

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

(In reply to Szu-Yu Chen [:aknow] from comment #12)
> Created attachment 788003 [details] [diff] [review]
> Part 3: Pass ota status (ril)

A quick question: how do we launch dialer app? Don't we need a system message as well?

Comment 14

[Szu-Yu Chen [:aknow] (inactive)]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #13)
> (In reply to Szu-Yu Chen [:aknow] from comment #12)
> > Created attachment 788003 [details] [diff] [review]
> > Part 3: Pass ota status (ril)
> 
> A quick question: how do we launch dialer app? Don't we need a system
> message as well?

Everything is controlled by gaia.

[OTA is needed]
When power on, gaia will check whether we need an OTASP by checking MIN value in subscription info. If it not valid or equal to some default value, gaia should dial a predefined number to start the OTASP process (maybe from a special purpose app).

[OTA results]
Gaia listen to the event we introduce in this bug so it could know the progress of the current OTASP session. A typical successful session is ended by a |commit| status, that means the data is correctly write into the nvram of modem. OTASP is just like a normal call. Gaia just check whether it reach the |commit| status after call disconnected. If yes, the process is successful. Otherwise, it fails.

Comment 15

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

(In reply to Szu-Yu Chen [:aknow] from comment #14)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #13)
> > (In reply to Szu-Yu Chen [:aknow] from comment #12)
> > > Created attachment 788003 [details] [diff] [review]
> > > Part 3: Pass ota status (ril)
> > 
> > A quick question: how do we launch dialer app? Don't we need a system
> > message as well?
> 
> Everything is controlled by gaia.
> 
> [OTA is needed]
> When power on, gaia will check whether we need an OTASP by checking MIN
> value in subscription info. If it not valid or equal to some default value,
> gaia should dial a predefined number to start the OTASP process (maybe from
> a special purpose app).
> 
> [OTA results]
> Gaia listen to the event we introduce in this bug so it could know the
> progress of the current OTASP session. A typical successful session is ended
> by a |commit| status, that means the data is correctly write into the nvram
> of modem. OTASP is just like a normal call. Gaia just check whether it reach
> the |commit| status after call disconnected. If yes, the process is
> successful. Otherwise, it fails.

Ha, I recall that right now. The solution sounds good!

Comment 16

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

Comment on attachment 787997 [details] [diff] [review]
Part 1: Add ota status event (idl, webidl)

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

::: dom/network/interfaces/nsIDOMMobileConnection.idl
@@ +53,4 @@
>    const long CLIR_SUPPRESSION = 2;
>  
>    /**
> +   * The status for an OTASP/OTAPA session.

Please provide the meaning for OTASP and OTAPA, and the spec reference.

@@ +335,5 @@
>     */
>    [implicit_jscontext] attribute jsval oncfstatechange;
> +
> +  /**
> +   * The 'onotastatuschange' evnet it notified whenever the ota provision status

s/evnet it/event is

::: dom/webidl/MozOtaStatusEvent.webidl
@@ +23,5 @@
> +   * otapa_started
> +   * otapa_stopped
> +   * otapa_aborted
> +   */
> +  readonly attribute DOMString? status;

Would we ever have a null status? What does that mean if so?

Comment 17

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

Comment on attachment 788003 [details] [diff] [review]
Part 3: Pass ota status (ril)

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

::: dom/system/gonk/RadioInterfaceLayer.js
@@ +1400,5 @@
>    },
>  
> +  handleOtaStatus: function handleOtaStatus(message) {
> +    gMessageManager.sendMobileConnectionMessage("RIL:OtaStatusChanged",
> +                                                this.clientId, message);

Sending |message.status| to RILContentHelper is enough. We don't need to send out the all object. Revise accordingly in RILContentHelper.js.

::: dom/system/gonk/ril_worker.js
@@ +6180,5 @@
>  RIL[UNSOLICITED_RESTRICTED_STATE_CHANGED] = null;
>  RIL[UNSOLICITED_ENTER_EMERGENCY_CALLBACK_MODE] = null;
>  RIL[UNSOLICITED_CDMA_CALL_WAITING] = null;
> +RIL[UNSOLICITED_CDMA_OTA_PROVISION_STATUS] = function UNSOLICITED_CDMA_OTA_PROVISION_STATUS() {
> +  let status = Buf.readUint32();

According to ril.h, the response is int*. You should do

let status = Buf.readUint32List();
this.sendChromeMessage({rilMessageType: "otastatuschange",
		status: status[0]});

Comment 18

[Szu-Yu Chen [:aknow] (inactive)]

Comment on attachment 787997 [details] [diff] [review]
Part 1: Add ota status event (idl, webidl)

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

::: dom/webidl/MozOtaStatusEvent.webidl
@@ +28,5 @@
> +};
> +
> +dictionary MozOtaStatusEventInit : EventInit
> +{
> +  DOMString status = "";

Should I set the value to one of the above string, e.g., "committed"?

Comment 19

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

Comment on attachment 787997 [details] [diff] [review]
Part 1: Add ota status event (idl, webidl)

s/evnet/event/

At some point we may want to make the .webidl to use enum, but given the
current code generator that isn't possible atm.


sr=me for the event, but it is not quite clear to me why we need
both the consts and strings for the same status.

Please change that, or explain why the consts are needed.

Comment 20

[Szu-Yu Chen [:aknow] (inactive)]

(In reply to Olli Pettay [:smaug] from comment #19)
> Comment on attachment 787997 [details] [diff] [review]
> Part 1: Add ota status event (idl, webidl)
> 
> s/evnet/event/
> 
> At some point we may want to make the .webidl to use enum, but given the
> current code generator that isn't possible atm.
> sr=me for the event, but it is not quite clear to me why we need
> both the consts and strings for the same status.
> 
> Please change that, or explain why the consts are needed.

I would like to convert the status code from number to string. Currently, the coversion is handled in dom layer, and I am using the consts to refer to those magic number.

I found that I could also do the conversion in lower layer. Then, the consts are not needed in idl file. Maybe this kind of solution is better.

Comment 21

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: Part 1#2: Add ota status event (idl, webidl)

Comment 22

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: Part 2#2: Add ota status event (dom)

Comment 23

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: Part 3#2: Pass ota status (ril)

Comment 24

[Anshul]

(In reply to Szu-Yu Chen [:aknow] from comment #14)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #13)
> > (In reply to Szu-Yu Chen [:aknow] from comment #12)
> > > Created attachment 788003 [details] [diff] [review]
> > > Part 3: Pass ota status (ril)
> > 
> > A quick question: how do we launch dialer app? Don't we need a system
> > message as well?
> 
> Everything is controlled by gaia.
> 
> [OTA is needed]
> When power on, gaia will check whether we need an OTASP by checking MIN
> value in subscription info. If it not valid or equal to some default value,
> gaia should dial a predefined number to start the OTASP process (maybe from
> a special purpose app).
Hello Szu-Yu, could you please point me to the gaia change that listens for the MIN value to know if the subscription is needed? I think the logic is not as straightforward and so I prefer it resides in RIL rather than in Gaia, but can confirm once I see the gaia change.

> 
> [OTA results]
> Gaia listen to the event we introduce in this bug so it could know the
> progress of the current OTASP session. A typical successful session is ended
> by a |commit| status, that means the data is correctly write into the nvram
> of modem. OTASP is just like a normal call. Gaia just check whether it reach
> the |commit| status after call disconnected. If yes, the process is
> successful. Otherwise, it fails.

Comment 25

[Szu-Yu Chen [:aknow] (inactive)]

(In reply to Anshul from comment #24)
> (In reply to Szu-Yu Chen [:aknow] from comment #14)
> > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #13)
> > > (In reply to Szu-Yu Chen [:aknow] from comment #12)
> > > > Created attachment 788003 [details] [diff] [review]
> > > > Part 3: Pass ota status (ril)
> > > 
> > > A quick question: how do we launch dialer app? Don't we need a system
> > > message as well?
> > 
> > Everything is controlled by gaia.
> > 
> > [OTA is needed]
> > When power on, gaia will check whether we need an OTASP by checking MIN
> > value in subscription info. If it not valid or equal to some default value,
> > gaia should dial a predefined number to start the OTASP process (maybe from
> > a special purpose app).
> Hello Szu-Yu, could you please point me to the gaia change that listens for
> the MIN value to know if the subscription is needed? I think the logic is
> not as straightforward and so I prefer it resides in RIL rather than in
> Gaia, but can confirm once I see the gaia change.

This part is not yet designed and implemented. It will be included in Bug 891734
The logic might be similar to the android design.

 http://goo.gl/PAuxaP
 http://goo.gl/GfsBi8

Any problem for this part?

http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.2.2_r1/com/android/internal/telephony/cdma/CdmaServiceStateTracker.java#1595
> 
> > 
> > [OTA results]
> > Gaia listen to the event we introduce in this bug so it could know the
> > progress of the current OTASP session. A typical successful session is ended
> > by a |commit| status, that means the data is correctly write into the nvram
> > of modem. OTASP is just like a normal call. Gaia just check whether it reach
> > the |commit| status after call disconnected. If yes, the process is
> > successful. Otherwise, it fails.

Comment 26

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: Part 2#3: Add ota status event (dom)

Comment 27

[Anshul]

(In reply to Szu-Yu Chen [:aknow] from comment #25)
> (In reply to Anshul from comment #24)
> > (In reply to Szu-Yu Chen [:aknow] from comment #14)
> > > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #13)
> > > > (In reply to Szu-Yu Chen [:aknow] from comment #12)
> > > > > Created attachment 788003 [details] [diff] [review]
> > > > > Part 3: Pass ota status (ril)
> > > > 
> > > > A quick question: how do we launch dialer app? Don't we need a system
> > > > message as well?
> > > 
> > > Everything is controlled by gaia.
> > > 
> > > [OTA is needed]
> > > When power on, gaia will check whether we need an OTASP by checking MIN
> > > value in subscription info. If it not valid or equal to some default value,
> > > gaia should dial a predefined number to start the OTASP process (maybe from
> > > a special purpose app).
> > Hello Szu-Yu, could you please point me to the gaia change that listens for
> > the MIN value to know if the subscription is needed? I think the logic is
> > not as straightforward and so I prefer it resides in RIL rather than in
> > Gaia, but can confirm once I see the gaia change.
> 
> This part is not yet designed and implemented. It will be included in Bug
> 891734
> The logic might be similar to the android design.
> 
>  http://goo.gl/PAuxaP
>  http://goo.gl/GfsBi8
> 
> Any problem for this part?
> 
> http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/
> android/4.2.2_r1/com/android/internal/telephony/cdma/CdmaServiceStateTracker.
> java#1595
Many SIM cards for CDMA don't have MIN values, if gaia were to implement the code you pointed to then gaia would think that OTA is needed when it is not. 


> > 
> > > 
> > > [OTA results]
> > > Gaia listen to the event we introduce in this bug so it could know the
> > > progress of the current OTASP session. A typical successful session is ended
> > > by a |commit| status, that means the data is correctly write into the nvram
> > > of modem. OTASP is just like a normal call. Gaia just check whether it reach
> > > the |commit| status after call disconnected. If yes, the process is
> > > successful. Otherwise, it fails.

Comment 28

[Szu-Yu Chen [:aknow] (inactive)]

Anshul,
The logic is from android reference design and it is also used in QRD. For the SIM card without MIN value, is there any common rule to handle the situation. Please give us some suggestion. Thank you.

Comment 29

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

Comment on attachment 788899 [details] [diff] [review]
Part 3#2: Pass ota status (ril)

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

Looks great. Thank you.

Comment 30

[Anshul]

(In reply to Szu-Yu Chen [:aknow] from comment #28)
> Anshul,
> The logic is from android reference design and it is also used in QRD. For
> the SIM card without MIN value, is there any common rule to handle the
> situation. Please give us some suggestion. Thank you.
Szu-Yu, that piece of code in Android may be buggy as I have seen that MIN value on SIM card is empty on live Verizon SIM. I think the correct logic may need more complexity than what Gaia can handle. So I am suggesting to move the logic to RIL. I am going to do some more tests to confirm.

Comment 31

[Ken Chang[:kenkai]]

(In reply to Anshul from comment #30)
> Szu-Yu, that piece of code in Android may be buggy as I have seen that MIN
> value on SIM card is empty on live Verizon SIM. I think the correct logic
> may need more complexity than what Gaia can handle. So I am suggesting to
> move the logic to RIL. I am going to do some more tests to confirm.
Anshul, Thanks for your information. It is great. May you be able to share which correct logic we need to implement in Gecko? It will be helpful for Aknow's implementation.

Comment 32

[Anshul]

Ken, we can take care of that logic in commercial RIL.

Comment 33

[Anshul]

Ken, we can take care of that logic in commercial RIL.

Comment 34

[Ken Chang[:kenkai]]

(In reply to Anshul from comment #33)
> Ken, we can take care of that logic in commercial RIL.
We also need this logic in reference RIL. 
Or is it possible for you to tell us what interfaces/information you need for your implementation? We can create these interfaces for you. Then you can get the necessary information via these interfaces to implement your own design.

Comment 35

[Anshul]

Ken, as I initially proposed it would be better to have a system message something like "ota_needed" that RIL can send to tell dialer that OTA is needed.

Comment 36

[Ken Chang[:kenkai]]

(In reply to Anshul from comment #35)
> Ken, as I initially proposed it would be better to have a system message
> something like "ota_needed" that RIL can send to tell dialer that OTA is
> needed.
Anshul, your proposal is too rough. For example, when OTA is fail, should we make gaia display anything? Does Gaia need to display the OTA progress? Moreover, I think it is hard to get r+ for a interface without any logic implementation insides.
If you just only need a interface to tell Gaia status in you commercial RIL, is it possible for you to use the 'onotastatuschange' what Aknow implemented in his patch to tell Gaia the status and use a fake min value in you commercial RIL?

Comment 37

[Szu-Yu Chen [:aknow] (inactive)]

Anshul, Ken,

There is no need to provide new interface for Anshul's proposal. Just broadcast "ota_needed" system message in commercial RIL. Then modify gaia part to observe and handle the system message.

In our reference design, we will implement the logic for ota_needed in gaia. If needed, it shows the OTA UI. You could just show the same UI when receiving system message "ota_needed".

Maybe we could also add a new preference value to config whether gaia should use its own ota_needed logic (our reference design) or system message (Anshul's proposal) for showing the OTA UI.

Then, during the ota, gaia could receive the status update and use them to determine whether the procedure is successful or failure. For both proposals, this part could be the same without further modification.

Comment 38

[Anshul]

(In reply to Ken Chang from comment #36)
> (In reply to Anshul from comment #35)
> > Ken, as I initially proposed it would be better to have a system message
> > something like "ota_needed" that RIL can send to tell dialer that OTA is
> > needed.
> Anshul, your proposal is too rough. For example, when OTA is fail, should we
> make gaia display anything? Does Gaia need to display the OTA progress?
> Moreover, I think it is hard to get r+ for a interface without any logic
> implementation insides.
Please see my comments at https://bugzilla.mozilla.org/show_bug.cgi?id=890820#c4 

> If you just only need a interface to tell Gaia status in you commercial RIL,
> is it possible for you to use the 'onotastatuschange' what Aknow implemented
> in his patch to tell Gaia the status and use a fake min value in you
> commercial RIL?
I completely understand but the min value logic might fail as per current implementation in Gaia even with Moz RIL. Let me do some more test this week and get back to you.

Comment 39

[Ken Chang[:kenkai]]

(In reply to Szu-Yu Chen [:aknow] from comment #37)
> There is no need to provide new interface for Anshul's proposal. Just
> broadcast "ota_needed" system message in commercial RIL. Then modify gaia
> part to observe and handle the system message.
> 
> In our reference design, we will implement the logic for ota_needed in gaia.
> If needed, it shows the OTA UI. You could just show the same UI when
> receiving system message "ota_needed".
Anshul, does what Sze-Yu proposal make sense to you? If yes, we will start to do this implementation in Gaia.

Comment 40

[Anshul]

Ken, if reference RIL is going to use the MIN logic can they not do that in RIL code itself rather than relying on gaia? That way we won't need to have two separate solutions each for Moz Ril and commercial RIL.

Moz RIL can send the OTA needed message from RIL based on the min value logic they already have. There is no use of passing the min value to gaia as in bug 869778.

Comment 41

[Ken Chang[:kenkai]]

(In reply to Anshul from comment #40)
> Ken, if reference RIL is going to use the MIN logic can they not do that in
> RIL code itself rather than relying on gaia? That way we won't need to have
> two separate solutions each for Moz Ril and commercial RIL.
> 
> Moz RIL can send the OTA needed message from RIL based on the min value
> logic they already have. There is no use of passing the min value to gaia as
> in bug 869778.

Anshul, you're very familiar with OTASP mechanism so that you can provide a signal solution in commercial RIL, but we aren't. Moreover, we expect this OTASP function is going to be modified for some carriers. We don't want to change the RIL code again when the preceding modification is happened. That's why we pass the min value to gaia to let Gaia own this modification. 
What you proposal is inclusive of a implicit OTASP implementation in moz RIL. That is different from we original design.
It's fine for you to keep the OTASP mechanism in commercial RIL.

Comment 42

[Anshul]

Ken, I understand your concern. What I am saying is that just the min value alone is not good enough for gaia can really not make that decision. The design you are proposing won't work even with Moz ril. Please test on a live CDMA card such as Verizon and let me know what you see. I am going to do some experimentation next week on my end and confirm.

Comment 43

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Comment on attachment 789350 [details] [diff] [review]
Part 2#3: Add ota status event (dom)

I'm going to defer to khuey here. Thanks!

Comment 44

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Comment on attachment 789350 [details] [diff] [review]
Part 2#3: Add ota status event (dom)

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

r=me

Comment 45

[Szu-Yu Chen [:aknow] (inactive)]

I know that the ota_needed mechanism is still under the discussion and might need further confirmation. However I would like to land this patch first because the modification here is completed and required no mater our final solution for the ota_needed. So, I change the title to show that this bug focuses on exposing ota status. Once we found that we need further works for ota_need, we could file another bug for it.

Comment 46

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: [Final] Part 1: Add ota status event (idl, webidl). r=hsinyi, sr=smaug

Comment 47

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: [Final] Part 2: Add ota status event (dom). r=khuey

Comment 48

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: [Final] Part 3: Pass ota status (ril). r=hsinyi

Comment 49

[Szu-Yu Chen [:aknow] (inactive)]

https://tbpl.mozilla.org/?tree=Try&rev=d22eae355adb

Comment 50

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/9cadfd1f1474
https://hg.mozilla.org/integration/b2g-inbound/rev/914fad593e56
https://hg.mozilla.org/integration/b2g-inbound/rev/5eae375272c6

Should this have tests?

Comment 51

[Szu-Yu Chen [:aknow] (inactive)]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #50)
> https://hg.mozilla.org/integration/b2g-inbound/rev/9cadfd1f1474
> https://hg.mozilla.org/integration/b2g-inbound/rev/914fad593e56
> https://hg.mozilla.org/integration/b2g-inbound/rev/5eae375272c6
> 
> Should this have tests?

I tested it locally with marionette and some hacking.
However, for the formal way, we should create a new emulator command so that it could generate the unsolicited ril response used in this bug.
-- File Bug 909805

Comment 52

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9cadfd1f1474
https://hg.mozilla.org/mozilla-central/rev/914fad593e56
https://hg.mozilla.org/mozilla-central/rev/5eae375272c6

Comment 53

[Ken Chang[:kenkai]]

(In reply to Anshul from comment #42)
> Ken, I understand your concern. What I am saying is that just the min value
> alone is not good enough for gaia can really not make that decision. The
> design you are proposing won't work even with Moz ril.
You know my concerns. may I know what your suggestion is if we don't want to have modification in RIL for OTASP?