Zebra RFD40 Android Integration with RFID API3

The Zebra RFD40 is a sled-style UHF RFID reader that pairs with a host Android handheld over Bluetooth, rather than integrating a UHF module directly into a single device. That architecture — two devices, one radio link between them — is exactly where Zebra's own tutorial code falls short of production readiness, and Zebra says so directly.

What the vendor docs don't tell you

Zebra's "Hello RFID" tutorial is the standard starting point for RFD40 integration, and it includes a disclaimer that's easy to skim past: the sample is explicitly scoped to tutorial use, not production.

Setup

RFID API3 ships as a Zebra-distributed .jar/.aar through their developer portal (Zebra requires a developer account to access the SDK downloads).

Copydependencies {
    implementation files('libs/RFIDAPI3.jar')
    implementation files('libs/SrfidLibrary.aar')
}

Declare Bluetooth permissions appropriate to the target API level — API 31+ requires the runtime BLUETOOTH_CONNECT permission in addition to the manifest declaration.

Copy<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
<uses-permission android:name="android.permission.BLUETOOTH_SCAN" />

Discovering and connecting to the sled

RFID API3 discovers available readers through the Readers class, then establishes a connection via RFIDReader.

Copyclass RfdConnectionManager(private val context: Context) {
    private var reader: RFIDReader? = null
 
    fun connect(onConnected: (RFIDReader) -> Unit, onError: (String) -> Unit) {
        val readers = Readers(context, ENUM_TRANSPORT.BLUETOOTH)
        val available = readers.GetAvailableRFIDReaderList()
 
        val target = available.firstOrNull() ?: run {
            onError("No RFD40 sled found in range")
            return
        }
 
        reader = target.rfidReader
        try {
            reader?.connect()
            reader?.Events?.setInvTagReadEvent(true)
            onConnected(reader!!)
        } catch (e: InvalidUsageException) {
            onError("Connect failed: ${e.message}")
        } catch (e: OperationFailureException) {
            onError("Operation failure: ${e.vendorMessage}")
        }
    }
}

Reconnection: the part the tutorial skips

Register a connection event listener and treat disconnection as a routine, expected state — not an exception path that only gets a log line.

Copyreader?.Events?.addEventsListener(object : RfidEventsListener {
    override fun eventStatusNotify(statusEvents: RfidStatusEvents?) {
        when (statusEvents?.StatusEventData?.statusEventType) {
            STATUS_EVENT_TYPE.DISCONNECTION_EVENT -> {
                scope.launch { attemptReconnect(maxAttempts = 5) }
            }
            STATUS_EVENT_TYPE.CONNECTION_EVENT -> {
                onReconnected()
            }
            else -> Unit
        }
    }
 
    override fun eventReadNotify(e: RfidReadEvents?) { /* tag read handling */ }
})
 
private suspend fun attemptReconnect(maxAttempts: Int) {
    var attempt = 0
    while (attempt < maxAttempts) {
        delay(1000L * (attempt + 1)) // linear backoff
        try {
            reader?.connect()
            return
        } catch (e: Exception) {
            attempt++
        }
    }
    onReconnectExhausted()
}

Surface a visible UI state for "reconnecting" versus "disconnected, action needed" — an operator mid-shift needs to know whether to wait or physically re-pair the sled.

Reading tags

Once connected, inventory reads arrive through the same event listener rather than a polling loop, which is the main structural difference from UART-based handhelds like the Chainway line.

Copyfun startInventory() {
    reader?.Actions?.Inventory?.perform()
}
 
fun stopInventory() {
    reader?.Actions?.Inventory?.stop()
}
 
// in eventReadNotify:
override fun eventReadNotify(e: RfidReadEvents?) {
    val tagData = reader?.Actions?.getReadTags(100) ?: return
    tagData.forEach { tag ->
        onTagRead(tag.tagID, tag.peakRSSI)
    }
}

Production considerations

• Build the reconnection state machine before anything else. It's the single biggest gap between the tutorial and a shift-length deployment.
• Release the reader connection explicitly (reader?.disconnect() / reader?.Dispose()) in onPause — a sled left connected to a backgrounded app can block a different app on the same handheld from acquiring it.
• Handle OperationFailureException and InvalidUsageException distinctly rather than catching a generic Exception — API3 uses these to distinguish transient radio-level failures from usage errors that indicate a code bug.
• Log disconnect frequency in the field. An RFD40 that disconnects far more than expected on a specific handheld model usually indicates a Bluetooth stack or power-management conflict specific to that host device, not the sled itself.

Common errors