970174 - [Fugu] After PUK is locked, RIL_REQUEST_GET_SIM_STATUS seems doesn't response correct result.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Vendcom, defect)

Description

[Edgar Chen [:edgar]]

+++ This bug was initially created as a clone of Bug #962927 +++

After entering 10th incorrect PUK code, fugu's rilc reports |app_state| as "6", but it seems there is no such define in ril.h [1]. So gecko treats it as 'unknown' state. (RIL_REQUEST_GET_SIM_STATUS [2])

--
02-10 11:32:10.250   106   223 I Gecko   : RIL Worker[0]: iccStatus: {"cardState":1,"universalPINState":0,"gsmUmtsSubscriptionAppIndex":0,"cdmaSubscriptionAppIndex":8,"imsSubscriptionAppIndex":8,"apps":[{"app_type":2,"app_state":6,"perso_substate":0,"aid":null,"app_label":null,"pin1_replaced":0,"pin1":0,"pin2":0}]}
--

Check the design of AOSP [3], |app_state| will stay in 'RIL_APPSTATE_PUK' and |pin1_state| will be 'RIL_PINSTATE_ENABLED_PERM_BLOCKED' [4] in such case.

Hi Sam, could you help to check about this? Thank you.

[1] https://github.com/mozilla-b2g/platform_hardware_ril/blob/master/include/telephony/ril.h#L471-L479
[2] https://github.com/mozilla-b2g/platform_hardware_ril/blob/master/include/telephony/ril.h#L812-L824
[3] http://androidxref.com/source/xref/frameworks/opt/telephony/src/java/com/android/internal/telephony/IccCardProxy.java#347
[4] https://github.com/mozilla-b2g/platform_hardware_ril/blob/master/include/telephony/ril.h#L487

Comment 1

[sam.hua]

ok.
could u give me log about -b radio?
I don't know the right PUK2 code about my test SIM card, so i can't reproduce it.

Comment 2

[sam.hua]

And in sprd_ril.h

typedef enum {
    RIL_APPSTATE_ILLEGAL               = -1,
    RIL_APPSTATE_UNKNOWN               = 0,
    RIL_APPSTATE_DETECTED              = 1,
    RIL_APPSTATE_PIN                   = 2, /* If PIN1 or UPin is required */
    RIL_APPSTATE_PUK                   = 3, /* If PUK1 or Puk for UPin is required */
    RIL_APPSTATE_SUBSCRIPTION_PERSO    = 4, /* perso_substate should be look at
                                               when app_state is assigned to this value */
    RIL_APPSTATE_READY                 = 5,
    RIL_APPSTATE_BLOCKED               = 6
} RIL_AppState;

I think u have this file.

Comment 3

[Edgar Chen [:edgar]]

Attachment: fugu_puk_locked.txt

(In reply to sam.hua from comment #1)
> ok.
> could u give me log about -b radio?
> I don't know the right PUK2 code about my test SIM card, so i can't
> reproduce it.

Here you are, putting a puk locked sim card into slot 0.

02-10 13:27:54.400   106   225 I Gecko   : RIL Worker[0]: iccStatus: {"cardState":1,"universalPINState":0,"gsmUmtsSubscriptionAppIndex":0,"cdmaSubscriptionAppIndex":8,"imsSubscriptionAppIndex":8,"apps":[{"app_type":2,"app_state":6,"perso_substate":0,"aid":null,"app_label":null,"pin1_replaced":0,"pin1":0,"pin2":0}]}

Comment 4

[Edgar Chen [:edgar]]

(In reply to sam.hua from comment #2)
> And in sprd_ril.h
> 
> typedef enum {
>     RIL_APPSTATE_ILLEGAL               = -1,
>     RIL_APPSTATE_UNKNOWN               = 0,
>     RIL_APPSTATE_DETECTED              = 1,
>     RIL_APPSTATE_PIN                   = 2, /* If PIN1 or UPin is required */
>     RIL_APPSTATE_PUK                   = 3, /* If PUK1 or Puk for UPin is
> required */
>     RIL_APPSTATE_SUBSCRIPTION_PERSO    = 4, /* perso_substate should be look
> at
>                                                when app_state is assigned to
> this value */
>     RIL_APPSTATE_READY                 = 5,
>     RIL_APPSTATE_BLOCKED               = 6
> } RIL_AppState;
> 
> I think u have this file.

But AOSP has already provided a way to handle this, could we follow the same way instead of using a sprd specific define? Thank you.

Comment 5

[sam.hua]

I am afraid that our modem won't change their response. I will change it in RILC.

the original response to RIL_WORKER:
        /* SIM_BLOCK = 6 */
        { RIL_APPTYPE_SIM, RIL_APPSTATE_BLOCKED, RIL_PERSOSUBSTATE_UNKNOWN,
            NULL, NULL, 0, RIL_PINSTATE_UNKNOWN, RIL_PINSTATE_UNKNOWN },
I will change them to 
        /* SIM_BLOCK = 6 */
        { RIL_APPTYPE_SIM, RIL_APPSTATE_BLOCKED, RIL_PERSOSUBSTATE_UNKNOWN,
            NULL, NULL, 0, RIL_PINSTATE_ENABLED_PERM_BLOCKED, RIL_PINSTATE_UNKNOWN },

but which app state should be return? RIL_APPSTATE_PIN or RIL_APPSTATE_PUK

Comment 6

[shawn ku [:sku]]

(In reply to sam.hua from comment #5)
> I am afraid that our modem won't change their response. I will change it in
> RILC.
> 
> the original response to RIL_WORKER:
>         /* SIM_BLOCK = 6 */
>         { RIL_APPTYPE_SIM, RIL_APPSTATE_BLOCKED, RIL_PERSOSUBSTATE_UNKNOWN,
>             NULL, NULL, 0, RIL_PINSTATE_UNKNOWN, RIL_PINSTATE_UNKNOWN },
> I will change them to 
>         /* SIM_BLOCK = 6 */
>         { RIL_APPTYPE_SIM, RIL_APPSTATE_BLOCKED, RIL_PERSOSUBSTATE_UNKNOWN,
>             NULL, NULL, 0, RIL_PINSTATE_ENABLED_PERM_BLOCKED,
> RIL_PINSTATE_UNKNOWN },
> 
> but which app state should be return? RIL_APPSTATE_PIN or RIL_APPSTATE_PUK

Sam,
RIL_APPSTATE_PUK please, (see Bug 930394).

Shawn

Comment 7

[sam.hua]

OK
I will upload the .so later,please test it and i will commit it if it is ok.

Comment 8

[Edgar Chen [:edgar]]

(In reply to sam.hua from comment #7)
> OK
> I will upload the .so later,please test it and i will commit it if it is ok.

Thank you, Sam and Shawn.

Comment 9

[sam.hua]

Attachment: libreference-ril_sp.so

new rilc lib

Comment 10

[sam.hua]

Hi edgar,
The bug is fixed or not with new lib?

Comment 11

[Edgar Chen [:edgar]]

Attachment: fugu_entering_wrong_puk_10_times.txt

(In reply to sam.hua from comment #10)
> Hi edgar,
> The bug is fixed or not with new lib?

Hi Sam, after apply new lib, the response of RIL_REQUEST_GET_SIM_STATUS for a blocked sim is what we expect now.

--
02-12 16:39:07.250   106   225 I Gecko   : RIL Worker[0]: iccStatus: {"cardState":1,"universalPINState":0,"gsmUmtsSubscriptionAppIndex":0,"cdmaSubscriptionAppIndex":8,"imsSubscriptionAppIndex":8,"apps":[{"app_type":2,"app_state":3,"perso_substate":0,"aid":null,"app_label":null,"pin1_replaced":0,"pin1":5,"pin2":0}]}
--

But I found another issue about UNSOLICITED_RESPONSE_SIM_STATUS_CHANGED, after entering wrong puk 10 times into a pukRequired sim, gecko did not receive UNSOLICITED_RESPONSE_SIM_STATUS_CHANGED to indicate the sim status is changed. So gecko doesn't update the cardState in this case. Could you help to check on this as well? Thank you.

Comment 12

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

(In reply to Edgar Chen [:edgar][:echen] from comment #11)
> But I found another issue about UNSOLICITED_RESPONSE_SIM_STATUS_CHANGED,
> after entering wrong puk 10 times into a pukRequired sim, gecko did not
> receive UNSOLICITED_RESPONSE_SIM_STATUS_CHANGED to indicate the sim status
> is changed. So gecko doesn't update the cardState in this case. Could you
> help to check on this as well? Thank you.

Yeah Sam,

Gaia needs this event to pup up puk locked dialog ! Thanks :)

Comment 13

[sam.hua]

Hi echen,
OK,i will add it. and please test it after i attach the new lib.

Comment 14

[sam.hua]

Attachment: libreference-ril_sp.so

pls check if it is ok.

Comment 15

[Edgar Chen [:edgar]]

Comment on attachment 8373166 [details]
libreference-ril_sp.so

Obsolete old one.

Comment 16

[Edgar Chen [:edgar]]

Attachment: fugu_entering_wrong_puk_10_times_20140117.txt

(In reply to sam.hua from comment #14)
> Created attachment 8375391 [details]
> libreference-ril_sp.so
> 
> pls check if it is ok.

Gecko still doesn't receive UNSOLICITED_RESPONSE_SIM_STATUS_CHANGED. :(

Comment 17

[sam.hua]

Attachment: libreference-ril_sp_feb24.so

please use it to test RIL will send SIM_STATUS_CHANGED to RIL_WORKER when PUK is locked

Comment 18

[Edgar Chen [:edgar]]

(In reply to sam.hua from comment #17)
> Created attachment 8380447 [details]
> libreference-ril_sp_feb24.so
> 
> please use it to test RIL will send SIM_STATUS_CHANGED to RIL_WORKER when
> PUK is locked

Thank you, Sam. I will test it and get back to you later.

ni? me for tracking.

Comment 19

[Edgar Chen [:edgar]]

Attachment: fugu_entering_wrong_puk_10_times_20140303.txt

Gecko still doesn't receive UNSOLICITED_RESPONSE_SIM_STATUS_CHANGED. :(

Comment 20

[sam.hua]

Attachment: libreference-ril_sp_mar_03.so

lib updated.

AT+SIND:0 is the indication from modem.

Comment 21

[Edgar Chen [:edgar]]

I don't have enough sim card to verify it. (All of my sim card became to "permanentBlocked" now :()
I will try to find one to test it. And if you can help to test it in your side, that will be great. ;)

Comment 22

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar][:echen] from comment #21)
> I don't have enough sim card to verify it. (All of my sim card became to
> "permanentBlocked" now :()
> I will try to find one to test it. And if you can help to test it in your
> side, that will be great. ;)

Hi Sam,

Due to I don't have enough sim card now, is it possible to help to test it on you side?

Thank you.

Comment 23

[sam.hua]

okay.

Comment 24

[bhavana bajaj [:bajaj]]

Joe, not sure wht this was nominated for 1.4? Looks like a POVB issue so clearing the nomination for now till we have a better understanding here.

Comment 25

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to bhavana bajaj [:bajaj] from comment #24)
> Joe, not sure wht this was nominated for 1.4? Looks like a POVB issue so
> clearing the nomination for now till we have a better understanding here.

This bug blocks bug 962927, which is a 1.4+ bug.

Comment 26

[Preeti Raghunath(:Preeti)]

Sam

Would it be ok if this bug is assigned to you, given your active participation?

Please advice.

Comment 27

[Joe Cheng [:jcheng] (please needinfo)]

triage: 1.4+ to unblock another 1.4+ bug
Steven, do you mind checking with partner? Thanks

Comment 28

[sam.hua]

I will test it in latest build of Tarako.

Comment 29

[Ken Chang[:kenkai]]

Sam seems to be the assignee of this bug.

Comment 30

[Steven Yang [:styang]]

Hi Sam, please update the result of Tarako once done. thanks!

Comment 31

[sam.hua]

it is fixed now

Comment 32

[sam.hua]

Fixed in Tarako,not fugu

Comment 33

[sam.hua]

Fixed in Tarako,not fugu

Comment 34

[Kai-Chih Hu [:khu]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #25)
> (In reply to bhavana bajaj [:bajaj] from comment #24)
> > Joe, not sure wht this was nominated for 1.4? Looks like a POVB issue so
> > clearing the nomination for now till we have a better understanding here.
> 
> This bug blocks bug 962927, which is a 1.4+ bug.

Now, bug 962927 was resolved. The original reason for this bug to be 1.4+ is not existed anymore. Suggest to remove 1.4+.

Comment 35

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

(In reply to Kevin Hu [:khu] from comment #34)
> Now, bug 962927 was resolved. The original reason for this bug to be 1.4+ is
> not existed anymore. Suggest to remove 1.4+.

Hi Kevin, 

Eric needs this bug fixed to verify bug 962927. You can check comments there !

Comment 36

[Kai-Chih Hu [:khu]]

Do we have an ETA for this bug? Thanks!

Comment 37

[Jason Smith [:jsmith]]

Discussed in triage - we can unblock this since the blocking bug landed. We just got Flame builds available for trunk, so QA is unblocked here for testing.

Comment 38

[sam.hua]

it is fixed  now

Comment 39

[Eric Chang [:ericcc] [:echang]]

(In reply to sam.hua from comment #38)
> it is fixed  now
Hi, Sam, Thanks, so it is fixed for Fugu, could you send the firmware to me, thank you.

Comment 40

[sam.hua]

We don't maintain fugu now. 

Could u use dolphin or tarako?

Comment 41

[Eric Chang [:ericcc] [:echang]]

Our dolphin is not ready yet, and tarako is a v1.3 phone. 
(In reply to sam.hua from comment #40)
> We don't maintain fugu now. 
> 
> Could u use dolphin or tarako?