Peter Cai
e48f9aa828
All checks were successful
/ build-debug (push) Successful in 4m51s
* ApduInterfaces also need a concept of validity based on the underlying APDU channel. For example, OMAPI depends on SEService being still connected. * We then rely on this validity to wait for reconnection; we do not need to manually remove all channels under a slot because the rest will be invalid anyway, and the next attempt at connection will lazily recreate the channel. * We had to manage channels manually before during reconnect because `valid` may result in SIGSEGV's when the underlying APDU channel has become invalid. This is avoided by the validity concept added to APDU channels.
19 lines
573 B
Kotlin
19 lines
573 B
Kotlin
package net.typeblog.lpac_jni
|
|
|
|
/*
|
|
* Should reflect euicc_apdu_interface in lpac/euicc/interface.h
|
|
*/
|
|
interface ApduInterface {
|
|
fun connect()
|
|
fun disconnect()
|
|
fun logicalChannelOpen(aid: ByteArray): Int
|
|
fun logicalChannelClose(handle: Int)
|
|
fun transmit(tx: ByteArray): ByteArray
|
|
|
|
/**
|
|
* Is this APDU connection still valid?
|
|
* Note that even if this returns true, the underlying connection might be broken anyway;
|
|
* callers should further check with the LPA to fully determine the validity of a channel
|
|
*/
|
|
val valid: Boolean
|
|
} |