This is the gecko bug for the user story -- Bug 931160, targeting on activating/deactivating a SIM.

1.3? as this blocks 1.3+ user story, bug 931160.

It is 1.3+. and set milestone in sprint 5. If it isn't reasonable, please update it.

Where did this requirement come from? There is a need to activate/deactivate subscription but that's independent from the sim.

(In reply to Michael Schwartz [:m4] from comment #3) > Where did this requirement come from? There is a need to > activate/deactivate subscription but that's independent from the sim. It's coming from bug 931160.

Edgar, can you take this bug?

(In reply to Ken Chang from comment #5) > Edgar, can you take this bug? Sure, I will take this.

(In reply to Michael Schwartz [:m4] from comment #3) > Where did this requirement come from? There is a need to > activate/deactivate subscription but that's independent from the sim. Hi m4, I saw there are some discussions about activate/deactivate subscription in bug 856553, but I still have some questions about it 1). Per my best knowledge, it seems there is not standard Android ril request for activate/deactivate subscription. Do you have any idea about how gecko should communicate with rild/modem about is? 2). If we deactivate a specific subscription, can gecko performs some operations to the sim card like reading EF ... etc. And can gecko still detect this sim card? Could you help to give some information? Thanks in advance. :)

1) Please refer to RIL_REQUEST_SET_UICC_SUBSCRIPTION in ril.h on codeaurora.org. 2) Activating/Deactivating the subscriptions does not change the content of the card, so accessing EFs is still a valid operation. The answer to the second part of your question is "it depends". Some parts of gecko -- mainly the parts that deal with enabling/disabling subscriptions -- will need to always be aware of all the cards and potential subscriptions, regardless of activation status. Other parts of gecko should treat inactive subscriptions much it would with a missing sim card (i.e. the sim status icon)

(In reply to pgravel from comment #8) > 1) Please refer to RIL_REQUEST_SET_UICC_SUBSCRIPTION in ril.h on > codeaurora.org. > > 2) Activating/Deactivating the subscriptions does not change the content of > the card, so accessing EFs is still a valid operation. The answer to the > second part of your question is "it depends". Some parts of gecko -- mainly > the parts that deal with enabling/disabling subscriptions -- will need to > always be aware of all the cards and potential subscriptions, regardless of > activation status. Other parts of gecko should treat inactive subscriptions > much it would with a missing sim card (i.e. the sim status icon) Thanks for the information, it's really useful :)

Kevin, without this bug we won't be able to use the patch from bug 932730. What if you guys implement an interface like below in gecko and we can take care of testing this along with other gaia changes that are almost ready on your side. void enableSim(in unsigned long clientId, /* callback */) void disableSim(in unsigned long clientId, /* callback */) - or - void setSimEnabled(in unsigned long clientId, in bool OnOrOff, /* callback */)

(In reply to Anshul from comment #10) > Kevin, without this bug we won't be able to use the patch from bug 932730. > What if you guys implement an interface like below in gecko and we can take > care of testing this along with other gaia changes that are almost ready on > your side. > > void enableSim(in unsigned long clientId, /* callback */) > void disableSim(in unsigned long clientId, /* callback */) > - or - > void setSimEnabled(in unsigned long clientId, in bool OnOrOff, /* callback > */) It's a good idea. However, to only provide interface isn't able to get r+ and check into m-c.

Or, I am thinking another way: to separate this into 2 bugs, one for interface only, and another one is for internal implementation. How is that?

(In reply to Kevin Hu [:khu] from comment #12) > Or, I am thinking another way: to separate this into 2 bugs, one for > interface only, and another one is for internal implementation. How is that? Then the question remains -- we still don't have implementation to verify and examine the interface. Unfortunately, the patch couldn't be review granted in that case.

Hsin-Yi, as agreed by Kevin, we will test the interfaces for you and provide the feedback.

(In reply to Anshul from comment #14) > Hsin-Yi, as agreed by Kevin, we will test the interfaces for you and provide > the feedback. Anshul, it's always great to have your feedback and test. We do appreciate your valuable help. We could come out an interface together that sounds good for both of us. However, the interface should be merged into our code base together with the implementation code.

Moving to 1.4? as the user story bug 931160 is moved to 1.4.

Per bug 931160 comment 10.

Put this bug into backlog.

Unassigning myself as I am no longer working on this.

Firefox OS is not being worked on