It seems that the RIL that goes with the latest v188 is reporting empty SIM slots as available and this breaks the Mobile ID API. Attached is a small log with the Mobile ID API debug output. Note the "iccInfo {"iccId":null,"mcc":"","mnc":"","msisdn":null,"operator":null,"serviceId":0,"roaming":false}" line. That shouldn't be appearing if no SIM is inserted in that SIM slot.

[Blocking Requested - why for this release]: Fernando, did this work on previous images like v184 and v180? if yes, this should be blocking.

(In reply to Tony Chung [:tchung] from comment #2) > [Blocking Requested - why for this release]: > > Fernando, did this work on previous images like v184 and v180? if yes, this > should be blocking. yes, it was working fine with those previous images. It seems to be a vendor issue because with v188 base and removing QC RIL so using Mozilla one we have not reproduced this issue. In that case, Tony, I am not sure about the blocking flag to nominate... but be aware that we need to have this fixed also in 2.0 as Loop is going to be landed with that version and with that base image or higher.

Can you share the output of this command on the v188 build? adb shell cat /firmware/verinfo/ver_info.txt

(In reply to Diego Wilson [:diego] from comment #4) > Can you share the output of this command on the v188 build? > > adb shell cat /firmware/verinfo/ver_info.txt M8610AAAAANFYD1530.1

(In reply to Maria Angeles Oteo (:oteo) from comment #5) > (In reply to Diego Wilson [:diego] from comment #4) > > Can you share the output of this command on the v188 build? > > > > adb shell cat /firmware/verinfo/ver_info.txt > > M8610AAAAANFYD1530.1 Anshul, Could the RIL update be causing this issue?

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #0) > It seems that the RIL that goes with the latest v188 is reporting empty SIM > slots as available and this breaks the Mobile ID API. > > Attached is a small log with the Mobile ID API debug output. Note the > "iccInfo > {"iccId":null,"mcc":"","mnc":"","msisdn":null,"operator":null,"serviceId":0, > "roaming":false}" line. That shouldn't be appearing if no SIM is inserted in > that SIM slot. Fernando, where do you see the SIM is reported present, on the UI or using some API? Note that in the above message iccId is null indicating that the SIM is absent. In addition to providing build info as per comment #4 please also provide the build info for the build in which this scenario was working for you.

> In addition to providing build info as per comment #4 please > also provide the build info for the build in which this scenario was working > for you. I've tested this with many different base builds as coming from the vendor (180, 184 and 187) and the failure can be reproduced in all of them. Unfortunately, we have not detected this issue before as we normally flash new builds on top of the vendor ones.

Sorry I'm no expert so would like to double confirm: 1. this is really an issue but not false alarm? (per comment#7 I guess might related to the test method) 2. If it's an issue, the flow will be: a QCT patch, then T2M to integrate, then release v189, is this right understanding? 3. what's the user impact of this problem? Just trying to understand if this is a blocker for v188 to public. (ie make v188 available to all Flame users in the world) And the possible way forward. Thanks.

(In reply to Wesly Huang from comment #9) > Sorry I'm no expert so would like to double confirm: > > 1. this is really an issue but not false alarm? (per comment#7 I guess might > related to the test method) Yes, this is a real issue > 2. If it's an issue, the flow will be: a QCT patch, then T2M to integrate, > then release v189, is this right understanding? The issue is that Commercial and Mozilla RIL behaves differently. Our tests have been focused in Mozilla RIL but with commercial RIL this issue appears. The alternative is doing a workaround in Gecko to handle properly the Commercial RIL behaviour. > 3. what's the user impact of this problem? > This is a blocker for Loop, this feature (MSISDN Verification) should be able to be used when no SIM Card is inserted, and without a solution for this issue, it won't be possible. > Just trying to understand if this is a blocker for v188 to public. (ie make > v188 available to all Flame users in the world) And the possible way > forward. Thanks. As I said, afaik this issue is currently only blocking Loop, not sure if any other app might be affected, I doubt so.

[Blocking Requested - why for this release]: This is a blocker for Loop, this feature (MSISDN Verification) should be able to be used when no SIM Card is inserted, and without a solution for this issue, it won't be possible. Fernando will prepare the workaround patch in Gecko (I think it will be quicker than requesting the RIL change), so assigning the bug to him and nominating the bug to 2.0 as this is a must-have for Loop.

(In reply to Anshul from comment #7) > (In reply to Fernando Jiménez Moreno [:ferjm] from comment #0) > > It seems that the RIL that goes with the latest v188 is reporting empty SIM > > slots as available and this breaks the Mobile ID API. > > > > Attached is a small log with the Mobile ID API debug output. Note the > > "iccInfo > > {"iccId":null,"mcc":"","mnc":"","msisdn":null,"operator":null,"serviceId":0, > > "roaming":false}" line. That shouldn't be appearing if no SIM is inserted in > > that SIM slot. > Fernando, where do you see the SIM is reported present, on the UI or using > some API? Note that in the above message iccId is null indicating that the > SIM is absent. In this case I am considering that the SIM is present if it is listed in the iccInfo array. Which now I see that it's an incorrect assumption. I believe the root of this issue is that MOZ RIL and QC RIL behaves differently to report absent SIMs. On the MOZ RIL, if there is no SIM we don't list it within IccInfo, but with MOZ QC, it seems that we do list it with null or empty values. As mentioned above, I'll write a patch for the Mobile ID API to make the API work with both RILs. I'm traveling today, but I'll try to upload the patch for review tonight.

Jonas: I'm told daniel/maria needinfo'd you on this, but I don't see it here (email?). Hit me up in IRC if you have any questions. Thanks

(In reply to Randell Jesup [:jesup] from comment #13) > Jonas: I'm told daniel/maria needinfo'd you on this, but I don't see it here > (email?). Hit me up in IRC if you have any questions. Thanks Hey Randell! it was not for this bug but for bug 1079974 and it seems Jonas already provided the required feedback. Sorry for the confusion... and thanks!

triaged to block 2.0+. ni? bhavana to follow up with vendor

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #12) > (In reply to Anshul from comment #7) > > (In reply to Fernando Jiménez Moreno [:ferjm] from comment #0) > > > It seems that the RIL that goes with the latest v188 is reporting empty SIM > > > slots as available and this breaks the Mobile ID API. > > > > > > Attached is a small log with the Mobile ID API debug output. Note the > > > "iccInfo > > > {"iccId":null,"mcc":"","mnc":"","msisdn":null,"operator":null,"serviceId":0, > > > "roaming":false}" line. That shouldn't be appearing if no SIM is inserted in > > > that SIM slot. > > Fernando, where do you see the SIM is reported present, on the UI or using > > some API? Note that in the above message iccId is null indicating that the > > SIM is absent. > > In this case I am considering that the SIM is present if it is listed in the > iccInfo array. Which now I see that it's an incorrect assumption. > Fernando, you should look at how Gaia handles this scenario as Gaia can properly show or hide sim absent icon based on the availability of IccId. What you encountered is really an issue due to lack of proper documentation of Gaia APIs or unclear APIs. > I believe the root of this issue is that MOZ RIL and QC RIL behaves > differently to report absent SIMs. On the MOZ RIL, if there is no SIM we > don't list it within IccInfo, but with MOZ QC, it seems that we do list it > with null or empty values. > > As mentioned above, I'll write a patch for the Mobile ID API to make the API > work with both RILs. I'm traveling today, but I'll try to upload the patch > for review tonight.

Comment on attachment 8510219 [details] [diff] [review] v1 Thanks Fernando!

Thank you Sam. https://hg.mozilla.org/integration/b2g-inbound/rev/d09af495bc92

Comment on attachment 8510219 [details] [diff] [review] v1 NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] Bug caused by (feature/regressing bug #): Mobile ID User impact if declined: This issue completely breaks the Mobile ID functionality with QC RIL. Testing completed: Local tests and unit test added. Risk to taking this patch (and alternatives if risky): Very low. We only added a more specific condition to skip SIMs. String or UUID changes made by this patch: none

Approving, and Ni anshul so he's aware of this blocking change. Anshul please refer to comment #11 here for he need.

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/1f3980c9599a https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/b32862f6c1a0