Peter Cai
6e590cfd48
All checks were successful
/ build-debug (push) Successful in 4m12s
Unfortunately, AOSP is not really good at handling more than one eUICC chips per device, even though the EuiccService interface should technically allow for such a situation. Let's do the next best thing -- only ever report one eUICC chip to AOSP. If the device has an internal one, then only report that one; otherwise, select the first available eUICC chip to report to the system. We might make this more configurable in the future, but for now I think this should work for most of the situations. Note that this does NOT affect how the rest of OpenEUICC behaves. This does mean however OpenEUICC will keep hold of some APDU channels that it will never access via OpenEuiccService. A mitigation is to make EuiccChannelManager close unused channels automatically after some timeout. |
||
|---|---|---|
| .. | ||
| angry/openeuicc | ||