History log of /frameworks/opt/telephony/src/java/com/android/internal/telephony/IccCard.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
3522c54a64f577f2b657a775dae9b4eb2d8003d5 25-Oct-2013 Wink Saville <wink@google.com> Few PIN/PUK fixes

Following changes have been made as part of this:
-> Changes done to display retry counter on wrong entry of
PIN1,and message to indicate Code accepted/PIN1 blocked
during PIN1 verification as per certain carrier requirements.
-> The current APIs that are used to verify the PIN and PUK only convey
whether the operation succeeded or failed. As a result on ANY failure
clients ask the user to re-enter the PIN.
Add 2 new APIs that report the actual error code and returns the
number of attempts remaing in case of failure.
-> FDN Service state was derived based on the state of PIN2. Update the
state of FDN service based on the FACILTY_LOCK messages instead.
-> Change the default value of function getIccLockEnabled to false.
When sim is deactivated/absent & user navigates to
Settings->Security->Set up SIM/RUIM card lock,
checkbox for "Lock Sim Card" option should be
unchecked by default.
-> PIN1 can be changed only after enabling SIM lock. RIL returns
REQUEST_NOT_SUPPORTED error if user tries to change PIN1 without
enabling SIM lock.
Handle the error and display appropriate message when trying to
change PIN1 using MMI code.
-> Added MMI support for change PIN1/PIN2 and unblocking PIN2

Bug: 9928717
Change-Id: I73718c9e6a8aa7244097e0dd4593a6226ff0ac08
/frameworks/opt/telephony/src/java/com/android/internal/telephony/IccCard.java
d720945f2be5ea5fe0faf67e67d9ea0e184eba67 01-Aug-2012 Alex Yakavenka <ayakav@codeaurora.org> Telephony: Move uicc classes into uicc package

Reduce constructor visibility to package where
possible

Dependent Changes:
I3b718b9aea1f21c7906c8243b4ca0db6af495a08
I80204a2f3dc57cac875abeab390bb9db7a636ff7
Ib9c19e8b157dc7ec74eb14baca5bd3b5caf08c47

Change-Id: Ib4f43374c041cb5eaf2e3883e5ea28b2eb2c9a69
/frameworks/opt/telephony/src/java/com/android/internal/telephony/IccCard.java
e287feac673ff68565b766e0e463d105fa9cef9d 10-Jul-2012 Alex Yakavenka <ayakav@codeaurora.org> Telephony: Remove CdmaLteUicc objects

-Pass IccCard object to GsmMmiCode
-Create IccCardProxy
-Make IccCard an interface and pass instance of IccCardProxy to
external applications (PhoneApp). IccCardProxy will use internal
UiccCard to map Icc requests to current active application on
UiccCard to maintain backwards compatibility for external
applications
-Add documentation to UiccController

The primary advantage of UiccController is that we can work with
multiple uicc applications at the same time. And that is a
requirement for modes like Cdma/Lte. The existing code supports
Cdma/Lte only partially and with guessing on modem side. However,
some things modem can guess, while others - it can't.

For instance, when a user tries to edit the fdn list the current
code will pass ef_id for fdn (0x6F3B). But the modem will have no
clue which fdn list the user wants to edit (csim or usim, both
have path 7FFF), and it's impossible for modem to guess correctly
all the time. All the modem can do is try to be consistent and
hope another device is doing same things. Imagine you bring your
card from another Cdma/Lte device to your new Cdma/Lte device:
if this modem uses different fdn file, it won't work as all
existing entries won't be there.

Another example is when the modem's guess is wrong for files like
csim/ef_li (7FFF 6F3A) versus usim/ef_adn (7FFF 6F3A). They have
same ef_ids so Android really should pass aid of the app it wants
to access. Without aids there is no way modem can know for sure
which file Android wants to read! However, in the current code
even Android doesn't know which aid it wants to read file from
since CdmaLteRecords has only 1 aid.

All of these problems cause more and more hacks, both in the modem
and in Android side. UiccController cleans up current code and
provides framework to work with multiple Uicc applications at the
same time.

Change-Id: I60216887b14140bdf833a8ed579ba16cad932bdc
/frameworks/opt/telephony/src/java/com/android/internal/telephony/IccCard.java
f92aefb45aa708772779a1ea10622b38f965fab5 13-Aug-2012 Alex Yakavenka <ayakav@codeaurora.org> Telephony: Always create IccCard

There is some bug in master branch which is not in AOSP code
that prevents KeyGuard from showing up unless IccCard broadcasts
its status

Force creation of IccCard (even if it really is absent) so that
it broadcasts its state and KeyGuard gets displayed

Fix NullPointerException in case card was removed by checking
return value of phone.getIccCard()

bug: 6983013
Change-Id: I95de1cc8a70a9e3d66d3e5d6059e82626057c5d4
/frameworks/opt/telephony/src/java/com/android/internal/telephony/IccCard.java
bb36adde615d3d85fa0fc23935197c6bc6a799ed 27-Jul-2012 Alex Yakavenka <ayakav@codeaurora.org> Telephony: Dynamically instantiate IccCard

Instantiate when get_sim_status request returns

Change-Id: I9c9333d23f1e0b23256731b245577d1a25721647
/frameworks/opt/telephony/src/java/com/android/internal/telephony/IccCard.java
c38bb60d867c5d61d90b7179a9ed2b2d1848124f 12-Jul-2012 Wink Saville <wink@google.com> Create telephony-common - DO NOT MERGE

telephony-common was created by moving some of
frameworks/base/telephony
to:
frameworks/opt/telephony

Change-Id: I32cbb5eec1fa239c1587e055c8f7ef4fc48fb62c
/frameworks/opt/telephony/src/java/com/android/internal/telephony/IccCard.java