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

VERIFIED FIXED in Firefox OS v2.0

Status

Firefox OS
GonkIntegration
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: YeojinC, Assigned: viralwang)

Tracking

(Blocks: 1 bug)

unspecified
2.1 S5 (26sep)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

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

Details

(Whiteboard: [POVB], URL)

Attachments

(4 attachments)

(Reporter)

Description

3 years ago
Created attachment 8493306 [details]
logcat_20140922_NotAskingSIMPIN.txt

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
(Reporter)

Comment 1

3 years ago
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)
Blocks: 1069372
[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
(Reporter)

Updated

3 years ago
Whiteboard: [2.1-exploratory-2]
(Reporter)

Updated

3 years ago
Whiteboard: [2.1-exploratory-2]
Basic functionality broken.
blocking-b2g: 2.0? → 2.0+
Do we have any updates here?
Flags: needinfo?(frlee)

Comment 9

3 years ago
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)

Comment 10

3 years ago
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)

Comment 11

3 years ago
verified and fixed with Flame KK base image v188
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Whiteboard: [POVB]

Comment 12

3 years ago
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 → ---

Comment 13

3 years ago
(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)

Comment 14

3 years ago
(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)

Comment 15

3 years ago
(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

Comment 16

3 years ago
(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)
(Assignee)

Comment 17

3 years ago
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)
(Assignee)

Comment 18

3 years ago
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.

Comment 23

3 years ago
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 24

3 years ago
Created attachment 8538956 [details] [diff] [review]
[Diff] getprop_diff_pvt_v188

Comment 25

3 years ago
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)

Comment 26

3 years ago
(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)

Comment 27

3 years ago
(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)

Updated

3 years ago
Component: Vendcom → GonkIntegration
(Assignee)

Comment 28

3 years ago
Created attachment 8539163 [details] [review]
set persist.radio.apm_sim_not_pwdn=0 in init.target.rc

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 29

3 years ago
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+
(Assignee)

Comment 30

3 years ago
add reviewer in comment
Assignee: nobody → vwang
Keywords: checkin-needed
https://github.com/mozilla-b2g/device-flame/commit/275ab3513688d7bc2256c5d6d0dbc5e296fe55f6
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
status-b2g-v1.4: affected → wontfix
status-b2g-v2.0: --- → fixed
status-b2g-v2.1: affected → fixed
status-b2g-v2.2: affected → fixed

Comment 32

3 years ago
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
status-b2g-v2.0: fixed → verified
status-b2g-v2.1: fixed → verified
status-b2g-v2.2: fixed → verified

Comment 33

3 years ago
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

Comment 34

3 years ago
Created attachment 8547334 [details]
VIDEO0226_Compress.MP4

Comment 35

3 years ago
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.