Closed Bug 1071210 Opened 11 years ago Closed 11 years ago

[RIL][KK] cardstatechange not triggered when enabling/disabling RIL via airplane mode

Categories

(Firefox OS Graveyard :: GonkIntegration, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v1.4 wontfix, b2g-v2.0 verified, b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
2.1 S5 (26sep)
blocking-b2g 2.0+
Tracking Status
b2g-v1.4 --- wontfix
b2g-v2.0 --- verified
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: ychung, Assigned: viralwang)

References

()

Details

(Whiteboard: [POVB])

Attachments

(4 files)

Description: When the SIM PIN is enabled and the user enables and disables the Airplane mode, the user is not prompted to enter the PIN. Pre-requisite: Insert a valid SIM with SIM PIN enabled. Repro Steps: 1) Update the device with V.180 base image. 2) Pull down the utility tray, and turn on the airplane mode by tapping the icon at the bottom. 3) Turn off the airplane mode by tapping the icon again. Actual: The user is not prompted to enter the SIM PIN. Even when the user makes a call in the Phone app, the user is not prompted to enter the SIM PIN. Expected: The user is prompted to enter the SIM PIN when disabling airplane mode. Repro Rates: 100% See attached: logcat, Video http://youtu.be/UcmUChBK9hM
This issue reproduces on Flame v.180 Base only, Flame 2.0(KK), Flame 2.1(KK), Flame 2.2(KK): Flame v180 Base only Enviromental Variables: Device: Flame 2.0 BuildID: 20140904160718 Gaia: Base Gecko: Base Version: 32.0 (2.0) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Flame 2.0 Environmental Variables: Device: Flame 2.0 BuildID: 20140920152249 Gaia: 0658006be8a00fdb5931ee15a0aa353a3ab231ba Gecko: c0086da55273 Version: 32.0 (2.0) Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Flame 2.1 Environmental Variables: Device: Flame 2.1 BuildID: 20140922053548 Gaia: 689c4ad4d8c3e4aa95805a2e49ae6cf786a1ae91 Gecko: 185fc54d29c1 Version: 34.0a2 (2.1) Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Flame 2.2 Environmental Variables: Device: Flame Master BuildID: 20140922040649 Gaia: 3802009e1ab6c3ddfc3eb15522e3140a96b33336 Gecko: 5e704397529b Version: 35.0a1 (Master) Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 The user is not prompted to enter the SIM PIN. ----------------------------------------------------------------------- This issue does NOT reproduces on Flame 2.0(JB),Flame 2.1(JB),Flame 2.2(JB): Flame 2.0 (JB) Environmental Variables: Device: Flame 2.0 BuildID: 20140922082143 Gaia: 0658006be8a00fdb5931ee15a0aa353a3ab231ba Gecko: dc61f92b855e Version: 32.0 (2.0) Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Flame 2.1 (JB) Environmental Variables: Device: Flame Master BuildID: 20140922080342 Gaia: 689c4ad4d8c3e4aa95805a2e49ae6cf786a1ae91 Gecko: c1c7a4eed459 Version: 34.0a2 (Master) Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Flame 2.2 (JB) Environmental Variables: Device: Flame Master BuildID: 20140922040649 Gaia: 3802009e1ab6c3ddfc3eb15522e3140a96b33336 Gecko: 5e704397529b Version: 35.0a1 (Master) Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 The user is prompted to enter the SIM PIN when disabling airplane mode. --------------------------------------------------------------------- Open C does not support dual SIMs.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
[Blocking Requested - why for this release]: Security issue? not prompting for sims
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Assignee: nobody → mhenretty
Target Milestone: --- → 2.1 S5 (26sep)
I did some investigations, and it seems the `cardstatechange` event is NOT being fired from the MozIcc object either when enabling or disabling airplane mode. However, the radioState of the MozMobileConnection object does indeed change appropriately, so the problem is probably with the event itself. The only log I see that could be related is this vague one: E/RILQ ( 300): (0/300): RIL[0][cmd-22(64)] qcril_cm_ss_convert_gsm8bit_alpha_string_to_utf8: Invalid parameters for GSM alphabet to UTF8 conversion, input len = 0 Vicamo, could you help us take a look here? As comment 1 mentions, this worked with the JB base image but not with any of the KK builds, including Flame 2.0 KK. Is this a vendcom issue?
Component: Gaia::System → RIL
Flags: needinfo?(vyang)
Summary: [Flame][KK] Not prompting to enter SIM PIN after enabling and disabling airplane mode. → [RIL][KK] cardstatechange not triggered when enabling/disabling RIL via airplane mode
Adding another RIL owner to get more eyes on this.
Flags: needinfo?(htsai)
(In reply to Michael Henretty [:mhenretty] from comment #4) > Adding another RIL owner to get more eyes on this. Working on this.
Flags: needinfo?(htsai)
In summary, MozRIL doesn't work on Flame-kitkat, emulator-kitkat doesn't have enough features to emulate this, but with a hack that pre-set SIM status to PIN LOCKED, turning on and off airplane mode does bring up that Enter SIM PIN dialog. So, I'll say this is vendcom issue.
Component: RIL → Vendcom
Flags: needinfo?(vyang)
Assignee: mhenretty → nobody
Whiteboard: [2.1-exploratory-2]
Whiteboard: [2.1-exploratory-2]
Basic functionality broken.
blocking-b2g: 2.0? → 2.0+
Do we have any updates here?
Flags: needinfo?(frlee)
hi Mike, could you please have a quick check on v184 if we can reproduce this issue? hi Gregor, we just received the new build v184 last night, let's wait for Mike's test result for further discussion. thank you very much
Flags: needinfo?(frlee) → needinfo?(mlien)
verify with the latest KK base image v184, it still has this problem Hi Youlong, could you help to check this issue, thanks
Flags: needinfo?(mlien) → needinfo?(youlong.jiang)
verified and fixed with Flame KK base image v188
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [POVB]
reopen this issue since v188 fixed this issue but full flash pvt build still can reproduce it change component to RIL again Gaia-Rev db34a4b7edc0e08ede425f21f8a5b5e161e7dda8 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/65fe0274b476 Build-ID 20141020161201 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141020.194750 FW-Date Mon Oct 20 19:48:03 EDT 2014 Bootloader L1TC00011880
Status: RESOLVED → REOPENED
Component: Vendcom → RIL
Resolution: FIXED → ---
(In reply to Mike Lien[:mlien] from comment #12) > reopen this issue since v188 fixed this issue but full flash pvt build still > can reproduce it Hi Mike, I cannot reproduce it with v188 + shallow flash gecko and gaia. It seems full flash pvt bring the issue back. Could you help to confirm this? If so, I guess there is some wrong in pvt build, maybe it doesn't use latest image to generate the backup?
Flags: needinfo?(youlong.jiang) → needinfo?(mlien)
(In reply to Edgar Chen [:edgar][:echen] from comment #13) > (In reply to Mike Lien[:mlien] from comment #12) > > reopen this issue since v188 fixed this issue but full flash pvt build still > > can reproduce it > > Hi Mike, I cannot reproduce it with v188 + shallow flash gecko and gaia. It > seems full flash pvt bring the issue back. Could you help to confirm this? > > If so, I guess there is some wrong in pvt build, maybe it doesn't use latest > image to generate the backup? Yes, shallow flash cannot reproduce this issue Gaia-Rev db34a4b7edc0e08ede425f21f8a5b5e161e7dda8 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/65fe0274b476 Build-ID 20141020161201 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental 39 FW-Date Thu Oct 16 18:19:14 CST 2014 Bootloader L1TC00011880
Flags: needinfo?(mlien)
(In reply to Mike Lien[:mlien] from comment #14) > (In reply to Edgar Chen [:edgar][:echen] from comment #13) > > (In reply to Mike Lien[:mlien] from comment #12) > > > reopen this issue since v188 fixed this issue but full flash pvt build still > > > can reproduce it > > > > Hi Mike, I cannot reproduce it with v188 + shallow flash gecko and gaia. It > > seems full flash pvt bring the issue back. Could you help to confirm this? > > > > If so, I guess there is some wrong in pvt build, maybe it doesn't use latest > > image to generate the backup? > > Yes, shallow flash cannot reproduce this issue > Gaia-Rev db34a4b7edc0e08ede425f21f8a5b5e161e7dda8 > Gecko-Rev > https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/65fe0274b476 > Build-ID 20141020161201 > Version 34.0 > Device-Name flame > FW-Release 4.4.2 > FW-Incremental 39 > FW-Date Thu Oct 16 18:19:14 CST 2014 > Bootloader L1TC00011880 Thank you, Mike. Change component back to Vendcom.
Component: RIL → Vendcom
(In reply to Edgar Chen [:edgar][:echen] from comment #13) > (In reply to Mike Lien[:mlien] from comment #12) > > reopen this issue since v188 fixed this issue but full flash pvt build still > > can reproduce it > > Hi Mike, I cannot reproduce it with v188 + shallow flash gecko and gaia. It > seems full flash pvt bring the issue back. Could you help to confirm this? > > If so, I guess there is some wrong in pvt build, maybe it doesn't use latest > image to generate the backup? Hi Viral, could you help to confirm the flame-kk pvt build is also using v188 to generate the full image? Thank you.
Flags: needinfo?(vwang)
Hi Catlee, I'm not sure if you know the detail of flame-kk PVT build. Since partner will release their base image to us recently, I think backup-flame should also updated as well. Do you know the detail of build script for flame-kk? Maybe we should remove "$OUT/firmware.hash" to make sure we have latest binary/library. Thanks.
Flags: needinfo?(vwang) → needinfo?(catlee)
One possible reason is that PVT still use v180 or v184 as base image. AFAIK, once TAM get latest Rom from partner, QA will help to verify it. TAM will also update MDN for public if Rom goods look. Not sure when PVT build updated to latest Rom. Since QA also test full image PVT build, I think we should know the exact time that PVT move to latest build for backup-flame Hi Tony, Not sure if you know the process. Any input is welcome. Thanks :)
Flags: needinfo?(tchung)
(In reply to viral [:viralwang] from comment #18) > One possible reason is that PVT still use v180 or v184 as base image. > > AFAIK, once TAM get latest Rom from partner, QA will help to verify it. > TAM will also update MDN for public if Rom goods look. > Not sure when PVT build updated to latest Rom. > Since QA also test full image PVT build, I think we should know the exact > time that PVT move to latest build for backup-flame > > Hi Tony, > > Not sure if you know the process. > Any input is welcome. Thanks :) That is correct. i believe pvtbuilds are still setup to use v180 at the moment. I was told to hold off on v188 late last week, but if we feel that its okay to move into the next image, we can file a separate bug to include v188 with current flame-kk backup images. ni? Nthomas, as we had that conversation in another bug (i can't recall where). nick, what will it take to get v188 added?
Flags: needinfo?(tchung) → needinfo?(nthomas)
Indeed, pvt-builds are still using v180. Just drop a comment in bug 1085759 stating which image to use.
Flags: needinfo?(nthomas)
Flags: needinfo?(catlee)
Whats the status here?
I can't speak to this bug as originally filed, but we're still blocked on switching to the v188 image. See bug 1085759 and bug 1092002 for the latest.
Verified again with today's PVT master build, even currently we already move to v188 based but still encounter this problem Gaia-Rev 8ffb48c321bb9595ad437086c5eb450bc90aa714 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/8401afdb6e6c Build-ID 20141216160204 Version 37.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141216.193052 FW-Date Tue Dec 16 19:31:04 EST 2014 Bootloader L1TC10011880
Comment on attachment 8538956 [details] [diff] [review] [Diff] getprop_diff_pvt_v188 Comparing the properties setup in pvt build and v188, I found one configuration is suspicious. In v188: `persist.radio.apm_sim_not_pwdn = 0` In pvt: `persist.radio.apm_sim_not_pwdn = 1` And I changed persist.radio.apm_sim_not_pwdn to 0 in pvt build, it works as expected. Could you try it on your side as well, Mike? Thank you. steps: 1. adb shell setprop persist.radio.apm_sim_not_pwdn 0 2. adb shell reboot Thank you.
Flags: needinfo?(mlien)
(In reply to Edgar Chen [:edgar][:echen] from comment #25) > Comment on attachment 8538956 [details] [diff] [review] > [Diff] getprop_diff_pvt_v188 > > Comparing the properties setup in pvt build and v188, I found one > configuration is suspicious. > > In v188: `persist.radio.apm_sim_not_pwdn = 0` > In pvt: `persist.radio.apm_sim_not_pwdn = 1` > > And I changed persist.radio.apm_sim_not_pwdn to 0 in pvt build, it works as > expected. > > Could you try it on your side as well, Mike? Thank you. > > steps: > 1. adb shell setprop persist.radio.apm_sim_not_pwdn 0 > 2. adb shell reboot > > Thank you. After modified property, the problem doesn't happen anymore
Flags: needinfo?(mlien)
(In reply to Mike Lien[:mlien] from comment #26) > (In reply to Edgar Chen [:edgar][:echen] from comment #25) > > Comment on attachment 8538956 [details] [diff] [review] > > [Diff] getprop_diff_pvt_v188 > > > > Comparing the properties setup in pvt build and v188, I found one > > configuration is suspicious. > > > > In v188: `persist.radio.apm_sim_not_pwdn = 0` > > In pvt: `persist.radio.apm_sim_not_pwdn = 1` > > > > And I changed persist.radio.apm_sim_not_pwdn to 0 in pvt build, it works as > > expected. > > > > Could you try it on your side as well, Mike? Thank you. > > > > steps: > > 1. adb shell setprop persist.radio.apm_sim_not_pwdn 0 > > 2. adb shell reboot > > > > Thank you. > > After modified property, the problem doesn't happen anymore This issue is caused by the unsynced configuration in pvt build and v188. How should we handle this? Should we correct this in our pvt build? Hi Viral, I am not sure if you are the right person to answer this. Or could you please help to forward to right person. Thank you.
Flags: needinfo?(vwang)
Component: Vendcom → GonkIntegration
Hi Michael, I can't change it in flame.mk since qcom add it in device/qcom/common/common.mk PRODUCT_PROPERTY_OVERRIDES += \ persist.radio.apm_sim_not_pwdn=1 I think I set this property in init.target.rc should be fine.
Flags: needinfo?(vwang)
Attachment #8539163 - Flags: review?(mwu)
Comment on attachment 8539163 [details] [review] set persist.radio.apm_sim_not_pwdn=0 in init.target.rc I think we can do a little better than this, but this is fine for now.
Attachment #8539163 - Flags: review?(mwu) → review+
add reviewer in comment
Assignee: nobody → vwang
Keywords: checkin-needed
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
This problem is verified not to happen on Flame2.0/2.1/2.2. According to video, could you please help to confirm the issue repro steps, thanks! Flame 2.2: Gaia-Rev f5e481d4caf9ffa561720a6fc9cf521a28bd8439 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/bb8d6034f5f2 Build-ID 20150111010223 Version 37.0a1 Flame 2.1 ia-Rev 64db236bea9a0510567ab7ced2f2b4688737123c Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/273f24a1d1fe Build-ID 20150111001202 Version 34.0 Flame 2.0 Gaia-Rev 31d6c9422cd0a8213df9f96019c9ab7168ec3ab3 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/a05a5378cb1f Build-ID 20150111000203 Version 32.0
This problem is verified not to happen on Flame2.0/2.1/2.2. According to video, could you please help to confirm the issue repro steps, thanks! Flame 2.2: Gaia-Rev f5e481d4caf9ffa561720a6fc9cf521a28bd8439 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/bb8d6034f5f2 Build-ID 20150111010223 Version 37.0a1 Flame 2.1 ia-Rev 64db236bea9a0510567ab7ced2f2b4688737123c Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/273f24a1d1fe Build-ID 20150111001202 Version 34.0 Flame 2.0 Gaia-Rev 31d6c9422cd0a8213df9f96019c9ab7168ec3ab3 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/a05a5378cb1f Build-ID 20150111000203 Version 32.0
Attached video VIDEO0226_Compress.MP4
refer to comment 33, mark as VERIFIED FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: