924949 - [Shared] IccHelper.getCardLockRetryCount always return 0

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Fernando Campo (:fcampo)]

We use this function to check in advance for the number of retries left (for entering a correct PIN code), as opposed to trying with a PIN and wait for an error displaying the number of tries left.

This is very useful for the times that we enter couple of wrong PIN codes (ending up with only 1 try left), and for whatever reason the phone is reseted. Then we are able to see the number of tries left BEFORE entering a new PIN (and possibly locking the SIM card).

Sadly, the function always return 0, so it's unusable at the moment.

This is used by FTU, Settings and System components.

Comment 1

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Hi,

We only implemented the required functionality in the reference RIL and Emulator. On the phones, we don't have a way for asking rild about these counters, because we depend on what Android provides here. Returning 0 in the case of an error is what previous code did, although -1 might have been a better choice.

Comment 2

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Hi again,

To clarify the problems this a bit:

 - the functionality for reading these counters is specified by ETSI TS 127.007, Sec 8.65 as optional, and
 - Android's RIL daemon doesn't expose an interface for accessing them.

We implemented the first point in the Emulator, and had to add a new command to the reference RIL to access the counters.

Comment 3

[Fernando Campo (:fcampo)]

So it's my understanding that we have no way to retrieve the retryCount in advance because Android is not exposing the functionality, am I correct?

In that case, the bug will be WONTFIX, and we should re-think the flow on the PIN screens.

Comment 4

[Michael Vines [:m1] [:evilmachines]]

We do support this in the commercial FxOS builds

Comment 5

[Thomas Zimmermann [:tzimmermann] [:tdz]]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #4)
> We do support this in the commercial FxOS builds

Is that an extension to the RIL daemon? Last time I looked there was no way to implement this feature?

I'd be happy to add support for this feature. On the emulator we have an environment variable to tell Gecko that the interface for reading the retry counters is available. We could do something similar here.

Comment 6

[Michael Vines [:m1] [:evilmachines]]

The feature is already implemented in the commercial devices so you can test the Gaia part on partner builds or emulator.

Comment 7

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(In reply to Fernando Campo (:fcampo) from comment #3)
> So it's my understanding that we have no way to retrieve the retryCount in
> advance because Android is not exposing the functionality, am I correct?
>
This feature needs support from modem, and this feature is not available in Android AOSP(see libril), so Mozilla RIL cannot retrieve retryCount in advance. So you always get 0 on Mozilla RIL on device.

However this feature is available from Partner builds or emulator as Micahel/Tomas mentioned.

> In that case, the bug will be WONTFIX, and we should re-think the flow on
> the PIN screens.

Close this as WONTFIX.

Comment 8

[Thomas Zimmermann [:tzimmermann] [:tdz]]

> > In that case, the bug will be WONTFIX, and we should re-think the flow on
> > the PIN screens.
> 
> Close this as WONTFIX.

Wait a second... I just checked the ril_worker.js and only the Emulator's interface (i.e., REQUEST_GET_UNLOCK_RETRY_COUNT) is supported. Do Partner builds implement the same interface? Is 'ro.moz.ril.query_icc_count' set to true on these devices?

Comment 9

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

REQUEST_GET_UNLOCK_RETRY_COUNT is just our reference impl on emulator,
I think the parter uses their own vendor specific RIL request since they own the modem code also, it's easier for them.

Also in case you don't know, parter uses their own implemented RIL stack, so they won't use ril_worker.js, the common part is only the Content process(WebAPI + RILContentHelper).

Comment 10

[Thomas Zimmermann [:tzimmermann] [:tdz]]

(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #9)

> they won't use ril_worker.js, the common part is only the Content
> process(WebAPI + RILContentHelper).

Ok, thank you. This is the part I was missing.