RFID and mobile apps: iOS vs Android

Kürzlich hatten wir bei Liip die Gelegenheit, mit der Bobst SA zusammenzuarbeiten. Das Unternehmen verkauft Geräte, die authentifiziert werden müssen, und wollte seinen aktuellen Prozess verbessern, bei dem die Kunden die Geräte mit einem speziellen Tool scannen und manuell eine Referenz im Webportal von Bobst angeben müssen. Beim neuen Verfahren werden jetzt RFID-Tags verwendet. Unser Ziel bestand darin, eine mobile App zu entwickeln, mit der diese Tags gescannt werden können und die sich automatisch mit dem Konto des Benutzers auf den Servern von Bobst verbindet, um diesem das richtige Zertifikat zuzuweisen. Mit der App kann Bobst dieses Zertifikat dann auf das Gerät schreiben.

Technologien

Wie bei den meisten Apps, die wir bei Liip entwickeln, haben wir uns auch bei dieser dafür entschieden, beide Plattformen mit nativen Technologien zu entwickeln – die Android-App mit Kotlin (Kotlin Version 1.4.10, Ziel Android 11, API 30) und die iOS-App mit Swift (Swift 5, Ziel iOS 14).

Zumeist bevorzugen wir diese Technologien gegenüber plattformübergreifenden Alternativen aus verschiedenen Gründen, unter anderem wegen der Leistung, des zuverlässigen UI-Erlebnisses für Benutzer beider Plattformen und der Wartbarkeit. In diesem Fall ist uns die Wahl sogar noch einfacher gefallen, da die NFC-Funktionen Teil der integrierten Systembibliotheken sind. Eine plattformübergreifende App würde daher sowieso Überbrückungsmodule für beide Plattformen erfordern.

RFID Standards

RFID steht für Radiofrequenz-Identifikation, und einfache RFID-Tags benötigen nicht einmal eine Stromversorgung. RFID-Geräte können nach verschiedenen Standards implementiert werden. Zu diesen gehört beispielsweise die ISO 15693-3, die die Tags von Bobst nutzen.

NFC oder Near Field Communication, st eine präzisere Untergruppe von Radiofrequenzgeräten. NFC-Geräte können sowohl Tags als auch Reader sein, und sie können aktiv miteinander kommunizieren. Moderne Smartphones sind fast alle NFC-fähig. NFC-Geräte kommunizieren standardmässig über NDEF (NFC Data Exchange Format), bei der Kommunikation mit RFID-ISO-Standards muss jedoch ein anderes Format verwendet werden, zum Beispiel: NFC Typ 2 (auch bekannt als Typ A) und Typ 4 (auch bekannt als Typ B) werden für die Kommunikation mit dem RFID-ISO-Standard 14443 verwendet
.
In unserem Fall werden wir für die Kommunikation mit unserem ISO 15693-Tag den NFC-Typ 5 (auch bekannt als Typ V) verwenden.

NFC-Unterstützung für Android seit Mai 2021

NFC-Unterstützung für iOS seit Mai 2021

Implementierung auf beiden Plattformen

In den obigen Tabellen ist ersichtlich, dass sowohl Android als auch iOS die RFID-Chips von Bobst unterstützen. Wir mussten für Android den NfcV -Typ und für iOS den NFCISO15693Tag -Typ verwenden.

Für beide Systeme musste zudem die entsprechende Berechtigung für den Zugriff auf die NFC-Funktionen erteilt werden, aber sowohl Android- als auch iOS-Dokumente decken diesen Bereich im Detail ab.

Mit anderen Worten: Unsere Implementierung musste drei Vorgänge unterstützen:

• ein Tag in Reichweite identifizieren
• den ihalt des Tags lesen
• neuen Inhalt auf das Tag schreiben

Wir haben diese Vorgänge wie folgt verwendet:

1. Identifizieren und lesen: Abwarten, bis ein Tag identifiziert ist (das System erhält dessen individuelle ID), und dann mit dieser individuellen ID einen Lesevorgang anfordern.
2. Das Ergebnis des Lesevorgangs an den Server von Bobst senden, um ein Zertifikat zu erhalten (hier kein RFID-Vorgang).
3. Identifizieren und schreiben: Ein schliessendes Tag identifizieren und sicherstellen, dass es die gleiche ID hat wie das zuvor gelesene (es ist dasselbe Tag). Danach das Zertifikat darauf schreiben.

Schritt 1: Ein Tag identifizieren

Mit beiden Systemen kann die ID eines in der Nähe befindlichen Tags auf einfache Weise übermittelt werden. Sie unterscheiden sich jedoch leicht:

Bei iOS muss das System aufgefordert werden, die Identifizierung von RFID-Tags zu starten. An dieser Stelle wird eine kleine modale Ansicht angezeigt und das System sucht nach einem Tag. Grundsätzlich reichen die folgenden Angaben aus:

func startScan() {
    guard  NFCTagReaderSession.readingAvailable else {
        delegate?.onScanningNotSupported()
        return
    }
    nfcSession = NFCTagReaderSession(pollingOption: NFCTagReaderSession.PollingOption.iso15693, delegate: self, queue: **nil**)
    nfcSession?.alertMessage = ... // whatever alert message such as "hold the phone near the tag"
    nfcSession?.begin()
}

func stopScan() {
    nfcSession?.invalidate()
}

Bei Android wird das System über den Android-Intent-Mechanismus gesteuert. Das bedeutet, dass man die App registrieren muss, damit sie Scan-Intents des entsprechenden NFC-Typs akzeptiert. Danach erhält die App eine entsprechende Meldung. Aus diesem Grund gibt es keine Starttaste. Wenn sich ein Tag in Reichweite befindet, wird die App, selbst wenn sie geschlossen ist, geöffnet und umgehend benachrichtigt!

Die NFC-Fähigkeit im Verzeichnis der Aktivität registrieren, welche die Informationen empfangen soll:

<intent-filter>
    <action android:name="android.nfc.action.TECH_DISCOVERED" />
</intent-filter>
<meta-data
    android:name="android.nfc.action.TECH_DISCOVERED"
    android:resource="@xml/filter_nfc"
/>

Die Filterliste wird in die Ressourcendatei eingefügt, auf die wir im Verzeichnis verwiesen haben, z. B. xml/filter_nfc/xml (in unserem Fall verwenden wir einfach den Typ NfcV, wie in der Tabelle oben):

<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
    <tech-list>
        <tech>android.nfc.tech.NfcV</tech>
    </tech-list>
</resources>

Our activity will be notified via onNewIntent:

override fun onNewIntent(intent: Intent) {
  super.onNewIntent(intent)

  if (NfcAdapter.ACTION_TECH_DISCOVERED == intent.action) {
    val tag = intent.getParcelableExtra<Tag>(NfcAdapter.EXTRA_TAG)
    viewModel.scanned(tag)  // Or whatever else
  }
}

Die beiden Plattformen unterscheiden sich deutlich in der Bedienung, funktionieren aber dennoch auf folgende Weise: Die obigen Schritte ergeben lediglich ein Tag-Objekt, das die ID des erkannten Tags enthält. Nun müssen wir damit lesen oder schreiben, was wir brauchen.

Schritt 2: Ein Tag lesen

Bei iOS beinhaltet das System bereits eine Basisimplementierung der ISO 15693, was alles einfacher macht.

Die konkrete Implementierung hängt von den spezifischen Anforderungen ab. Grundsätzlich besteht die Idee aber darin, die generische Tag-ID in die richtige ISO-Implementierung, welche in die Core-NFC-Bibliothek integriert ist, zu konvertieren:

if case let NFCTag.iso15693(tagType5) = tag {
}

Und dann integrierte Funktionen wie tag.readMultipleBlocks() zu verwenden. Diese Funktion akzeptiert eine Reihe von Argumenten, einschliesslich hilfreicher Request-Flags.

tag.readMultipleBlocks(requestFlags: [.highDataRate], blockRange: NSRange(location: 0, length: NfcService.MAXREADBLOCK)) { data, error in
... // check for error and get data using the variables above
}

An dieser Stelle besteht die einzige Schwierigkeit darin, herauszufinden, wie die Bytes angeordnet wurden. Bobst hat uns eine umfassende Dokumentation zur Verfügung gestellt, damit wir ihre Tags richtig lesen können. In unserem Fall waren sie in der Regel in Viererblöcken, die nach dem Lesen jeweils einzeln umgedreht werden mussten, angeordnet.

Bei Android bietet das System keine integrierte Implementierung der ISO-Standard-Appart-Funktionen zum Senden von unbearbeiteten Byte-Blöcken. Diese Rohblöcke beinhalten eine Befehlsanfrage für das Tag, gegliedert nach ISO 15693 https://www.iso.org/standard/73602.html.

Der erste Schritt ähnelt dem bei iOS: Ermittlung des unserem Tag entsprechenden Systemtyps

val nfcVTag = NfcV.get(tag) ?: return

Der nächste Teil ist allerdings ein bisschen komplizierter. Das 70 Seiten umfassende Dokument zur Beschreibung der ISO 15693 zeigt, dass unter allen möglichen Befehlen die von iOS integrierten readMultipleBlocks tatsächlich durch Senden des Befehlscodes 0x23 ausgegeben werden.

Darin wird zudem mitgeteilt, dass zum Senden eines Befehls folgende Informationen erforderlich sind:
— Flags
— Befehlscode
— Felder für obligatorische und optionale Parameter, je nach Befehl

In unserem Fall müssen die Flags so gesetzt werden, dass ein «adressierter» Befehl ausgegeben wird, d. h. der Befehl nimmt die Tag-ID als Argument und wird nur auf diesem bestimmten Tag ausgeführt. Gemäss Dokumentation entspricht dieses Flag dem sechsten Bit des Flag-Bytes. Zudem wird das High-Rate-Flag (zweites Bit) gesetzt. Unser gesamtes Flag-Byte ist 00100010, was 0x22 entspricht.

Folglich besteht unsere Android-Anfrage aus folgendem Byte-Array:

val offset = 0 // offset of first block to read
val blocks = 32 // number of blocks to read
val cmd = mutableListOf<Byte>().apply {
  add(0x22.toByte()) // flags: addressed (= UID field present) + high data rate
  add(0x23.toByte()) // command: READ MULTIPLE BLOCKS
  addAll(tag.id.toList()) // tag UID
  add((offset and 0x0ff).toByte()) // first block number. add 0xff to ensure we send two bytes
  add((blocks - 1 and 0x0ff).toByte()) // number of blocks (-1 as 0x00 means one block). add 0xff to ensure we send two bytes
}.toByteArray()

Wir empfangen einfach die Antwort mit der transceive -Methode und überprüfen das erste Byte zur Sicherstellung des Erfolgs.

nfcVTag.connect()
val responseBytes = nfcVTag.transceive(cmd)
if (responseBytes.first() != 0x00.toByte()) {
  return NfcResponse.Error.Read
}
nfcVTag.close()

Das Response-Byte-Array konnte nun gemäss der Bobst-Dokumentation geparst werden, um die richtigen Tag-Informationen zu extrahieren.

Schritt 3: Auf ein Tag schreiben

Das Schreiben auf ein Tag ist ungefähr derselbe Prozess wie das Lesen (d. h. ein einfacher bei iOS und ein komplexerer bei Android).

Bei iOS stellen wir alle Informationen zum Schreiben in einem Byte-Array zusammen. Leider waren die Mehrfachschreibvorgänge bei den Bobst-Tags deaktiviert, weshalb wir die Bytes einzeln senden mussten. Wir haben einfach die NFC-Core-Funktion transceive in einem Loop verwendet. Die Funktion übernimmt wiederum alle notwendigen Flags

tag.writeSingleBlock(requestFlags: [.highDataRate, .address], blockNumber: UInt8(startBlock), dataBlock: dataBlock) { error in
    ... // Simply check for error and react accordingly
}

Bei Android
Wie zuvor müssen wir den entsprechenden Byte-Befehl senden und die transceive-Funktion verwenden. Wie zuvor nutzt dieser Befehl einen Flag-Wert von 0x22. Gemäss der ISO 15693-Dokumentation wird die writeSingleBlock-Anfrage mit der Eingabe von 0x21 als Befehlsbyte gestellt. Wie zuvor müssen wir die Tag-ID eingeben, da wir einen «adressierten» Befehl ausführen. Dann können wir die ID-Bytes und anschliessend alle Daten, die wir schreiben wollen, eingeben.

private fun createCommand(tag: Tag, blockOffset: Int, blockData: List<Byte>) = mutableListOf<Byte>().apply {
  add(0x22.toByte()) // flags: addressed (= UID field present) + high data rate : 00100010
  add(0x21.toByte()) // command: WRITE SINGLE BLOCK (multi read not supported)
  addAll(tag.id.toList()) // tag UID
  add((blockOffset and 0x0ff).toByte()) // first block number. add 0xff to ensure we send two bytes
  addAll(blockData) // The bytes for certificate and reference,
}.toByteArray()

Wie bei iOS müssen wir diese Funktion in einem Loop aufrufen und dabei den richtigen Block-Offset eingeben, um alle Blöcke nacheinander zu schreiben.

Schlussfolgerung

Die Benutzererfahrung unterscheidet sich zwischen Android und iOS zwar nur geringfügig, aber das Lesen und Schreiben auf ISO 15693-Tags ist bei Android deutlich komplexer.

Solche Divergenzen beobachten wir oft zwischen den beiden Plattformen: In der Regel bietet das iOS-Framework eine einfache Erfahrung für Entwickler, weil es für viele Funktionen Standardimplementierungen bereitstellt. Android hingegen lässt oft mehr Freiheiten bei der Implementierung, was mit zusätzlichem Aufwand zum Erreichen des gleichen Ergebnisses einhergeht.