On devices like the Japanese versions of Sony Xperia 5 II, the telephony
HAL can end up reporting a "ghost" SIM slot that does not actually exist
and (thus) has no IMEI assigned to it. In this case, our code would
crash since we assumed every SIM slot reported to the telephony
framework should be valid. The fix is simple -- abort when we realize
that the SIM slot has no IMEI.
Note that this support is highly experimental. Currently, a few issues
remain to be solved:
* Prebuilt libraries are needed for zxing and asn1bean. This will be
pushed as a separate repository that can be included in the prebuilts/
directory.
* The TelephonyManagerHiddenApi class needs to be excluded in AOSP
builds
* In order to support multiple AOSP versions, the OpenEuiccService class
needs to be turned into a custom interface with a default impl, and
then we need to introduce impls for the system EuiccService depending
on which version of AOSP we are building on. This could be kind of
problematic, and I'm not sure whether we should do this yet.
We would like to reduce dependency on Apache commons as much as
possible. Although we probably won't be able to build this in AOSP
anyway, it is still good to move away when we have better alternatives
in the Kotlin runtime.
This is still pretty hacky. Ideally we should return structured data (at
least separate the status code from the payload, or better, just do
everything in binary) from ApduTransmitter / ApduChannel.
Because the library uses hex-encoded string internally for all APDU
commands, the matchingId itself also needs to be encoded. This is done
by `setMatchingId` and we should also use that when generating
CtxParams1 ourselves.
...although we are only concerned with the first two. Evene when there
is confirmation code enforcement, the SM-DP+ server will inform us of it
(although this is not implemented yet by us)
TheScarastic