SIM card can get permanently disabled due to too many
PUK retries. The PERM_BLOCKED pin state of SIM application
represents this state.
This change decodes permanent disabled state and broadcasts it
via ICC_ABSENT intent with PERM_DISABLED reason. It also update
the lockscreen to show the prompt message.
bug:4392059
Change-Id: I5e60dd65f48f42aa2e54db4cdebf803d6e666b99
Enhance the debug info for GET_SIM_STATUS. Print out the
Card status and App status instead of Object id. It helps
to debug PUK lock and other SIM related issues.
Change-Id: I489f3933529a9719827a8799c41de8e999db6b40
Unless user had selected a desired locale, EFli or EFpl will be
used to decide the locale to be used.
Note this locale setting is not persistent - only valid while
SIM card is present.
Change-Id: I1f3945f7bc02624dff94b90e7f1a658a136033e8
For non-phone device, i.e. tablet doesn't have voice capability,
getDeviceId returns null while getPhoneType returns PHONE_TYPE_NONE.
This behavior is suggested by developer scheme
http://android-developers.blogspot.com/2011/03/identifying-app-installations.html
and enforced by CTS testGetDeviceId.
bug:4464907
Change-Id: Iaa3832b7323a50deccd438cb884c8e776a7a9640
While in HO, data connection type may temporary become "unknown".
This triggers TelephonyRegistry picks up the wrong data connection
state, ending up notifying bogus state to ConnectivityService.
The patch is just to pick up the status from ApnContext which
should be maintaining the right state. Also cleaned up unnecessary
lines which was added earlier phase.
Change-Id: I07e74ce55f09ad31f2d8d09e2a144dc0b600eb0c
In case of LTE & CDMA hybrid system, provision information will be
read from CSIM records.
Also CSIM records can be updated over the air. No data connection
attempt should be made until CSIM provisioning is notified
via SIM_REFRESH event.
Change-Id: I001db48d07d90af22104cb958df638e15e0d494a
For non-phone device, i.e. tablet doesn't have voice capability,
getDeviceId returns null while getPhoneType returns PHONE_TYPE_NONE.
This behavior is suggested by developer scheme
http://android-developers.blogspot.com/2011/03/identifying-app-installations.html
and enforced by CTS testGetDeviceId.
bug:4464907
Change-Id: Iaa3832b7323a50deccd438cb884c8e776a7a9640
If the preferred network had updated before rild restarts,
the new setting value is ignored on RIL_CONNECT event.
bug: IKXEVERESTLTE-1494
Change-Id: Iec6395187c0d749208904db857b80e28f7d92c21
If rild is reset while RIL_DEACTIVATE_DATA_CALL is pending
response, the ApnContext is not force cleaned up since
link to DCAC is cleared in the begining of release.
This patch fixes:
1) Hold DCAC reference until the DC is disconnected. This is
to ensure DC won't be stuck in DcDisconnectingState so force
reset can kick in.
2) In "clearCleanUpConnection", make sure the status of ApnContext
can be reset to IDLE even if no reference to DCAC.
Change-Id: Ic69271da7c6bc9dcb2c38ec53a9bd2e8ce785adc
In case of CDMA and LTE hybrid system, UICC card contains
both USIM and CSIM data. FW needs to read out from both
to aqcuire information required for the service.
Change-Id: I4a714252bc97c037fa419352f23d8f38f6206406
Refining SIM ready condition on UICC w/ multiple apps.
Also migration for RIL to use SIM_READY indication in case of UICC
presence instead of current NV_READY message.
Change-Id: I3445a628e2d32a24292e6a69785fe72422481221
If UICC with multiple applications are used, delive the status
based on both status instead of just looking at one.
Change-Id: I98cf689327e5302bb4174985935511aff02939f6
With current design the code maps to the same DC, but no indications go out.
With this, making it more async in nature that the request goes all the way
to DC and all the data indications would be triggered by parallel paths through DCT.
Change-Id: I4c6e64912dafe19154d910bbd0441b10ada36cff
ApnContext and DC were not disassociated when force
"cleanUpConnection" was called. Causing the setup
request was not happening if applyNewStatus() was
the trigger.
Change-Id: I6d73a53edb72bb9ab4ebb92fffd06e6fe1f0c4aa
