In diesem Dokument werden die grundlegenden NFC-Aufgaben beschrieben, die Sie in Android ausführen. Darin wird erläutert, wie NFC-Daten in Form von NDEF-Nachrichten gesendet und empfangen werden. Außerdem werden die Android-Framework-APIs beschrieben, die diese Funktionen unterstützen. Fortgeschrittene Themen, einschließlich einer Diskussion zum Arbeiten mit Nicht-NDEF-Daten, finden Sie unter Erweiterte NFC.
Es gibt zwei Hauptanwendungsfälle bei der Arbeit mit NDEF-Daten und Android:
- NDEF-Daten aus einem NFC-Tag lesen
- NDEF-Nachrichten mit Android BeamTM von einem Gerät an ein anderes übertragen
Das Lesen von NDEF-Daten aus einem NFC-Tag wird mit dem Tag-Versandsystem gehandhabt, das erkannte NFC-Tags analysiert, die Daten entsprechend kategorisiert und eine Anwendung startet, die an den kategorisierten Daten interessiert ist. Eine Anwendung, die das gescannte NFC-Tag verarbeiten möchte, kann einen Intent-Filter deklarieren und eine Anfrage zur Verarbeitung der Daten stellen.
Mit der Android BeamTM-Funktion kann ein Gerät eine NDEF-Nachricht auf ein anderes Gerät übertragen, indem die Geräte physisch zusammengehalten werden. Diese Interaktion ermöglicht das Senden von Daten im Vergleich zu anderen drahtlosen Technologien wie Bluetooth, da bei NFC keine manuelle Geräteerkennung oder -kopplung erforderlich ist. Die Verbindung wird automatisch hergestellt, wenn zwei Geräte in Reichweite sind. Android Beam ist über eine Reihe von NFC APIs verfügbar, sodass jede App Informationen zwischen Geräten übertragen kann. Die Anwendungen Kontakte, Browser und YouTube verwenden beispielsweise Android Beam, um Kontakte, Webseiten und Videos mit anderen Geräten zu teilen.
Das Tag-Weiterleitungssystem
Android-Geräte suchen normalerweise nach NFC-Tags, wenn der Bildschirm entsperrt ist, es sei denn, NFC ist in den Einstellungen des Geräts deaktiviert. Wenn ein Android-Gerät ein NFC-Tag erkennt, soll der Intent von der am besten geeigneten Aktivität verarbeitet werden, ohne den Nutzer zu fragen, welche Anwendung verwendet werden soll. Da Geräte NFC-Tags in sehr kurzer Reichweite scannen, wäre es wahrscheinlich, dass Nutzer, wenn sie eine Aktivität manuell auswählen würden, sie dazu zwingen, das Gerät vom Tag wegzubewegen und die Verbindung zu trennen. Sie sollten Ihre Aktivität so entwickeln, dass sie nur die NFC-Tags verarbeitet, die für Ihre Aktivität wichtig sind, um zu verhindern, dass die Aktivitätsauswahl angezeigt wird.
Um Sie dabei zu unterstützen, stellt Android ein spezielles Tag-Weiterleitungssystem bereit, das gescannte NFC-Tags analysiert, sie parst und versucht, Anwendungen zu finden, die an den gescannten Daten interessiert sind. Dies geschieht durch:
- Parsen des NFC-Tags und Ermitteln des MIME-Typs oder eines URI, der die Datennutzlast im Tag identifiziert.
- Kapselung des MIME-Typs oder -URI und der Nutzlast in einem Intent. Diese ersten beiden Schritte werden unter Zuordnung von NFC-Tags zu MIME-Typen und URIs beschrieben.
- Startet eine Aktivität basierend auf dem Intent. Dies wird unter Senden von NFC-Tags an Anwendungen beschrieben.
Zuordnung von NFC-Tags zu MIME-Typen und URIs
Bevor Sie mit dem Schreiben Ihrer NFC-Anwendungen beginnen, sollten Sie sich mit den verschiedenen Arten von NFC-Tags vertraut machen. Außerdem sollten Sie wissen, wie das Tag-Weiterleitungssystem NFC-Tags parst und welche spezielle Arbeit das Tag-Weiterleitungssystem ausführt, wenn es eine NDEF-Nachricht erkennt. NFC-Tags gibt es in einer Vielzahl von Technologien und können Daten auf viele verschiedene Arten in sie schreiben. Android bietet die größte Unterstützung für den NDEF-Standard, der durch das NFC-Forum definiert wird.
NDEF-Daten werden in einer Nachricht (NdefMessage
) gekapselt, die einen oder mehrere Datensätze (NdefRecord
) enthält. Jeder NDEF-Eintrag muss gemäß der Spezifikation des Eintragstyps, den Sie erstellen möchten, wohlgeformt sein. Android unterstützt auch andere Arten von Tags, die keine NDEF-Daten enthalten. Mit den Klassen im Paket android.nfc.tech
können Sie arbeiten. Weitere Informationen zu diesen Technologien finden Sie unter Erweiterte NFC. Wenn Sie mit diesen anderen Tag-Typen arbeiten, müssen Sie einen eigenen Protokollstack schreiben, um mit den Tags zu kommunizieren. Wir empfehlen daher, nach Möglichkeit NDEF zu verwenden, um die Entwicklung zu vereinfachen und Android-Geräte bestmöglich zu unterstützen.
Hinweis:Wenn Sie die vollständigen NDEF-Spezifikationen herunterladen möchten, rufen Sie die Website NFC Forum Specifications & Application Documents auf. Beispiele zum Erstellen von NDEF-Einträgen finden Sie unter Häufig verwendete Typen von NDEF-Einträgen erstellen.
Sie kennen nun einige Hintergrundinformationen zu NFC-Tags. In den folgenden Abschnitten wird ausführlicher beschrieben, wie Android mit NDEF-formatierten Tags umgeht. Wenn ein Android-Gerät ein NFC-Tag mit NDEF-formatierten Daten scannt, parst es die Nachricht und versucht, den MIME-Typ der Daten oder den identifizierenden URI der Daten zu ermitteln. Dazu liest das System die erste NdefRecord
in NdefMessage
, um zu bestimmen, wie die gesamte NDEF-Nachricht interpretiert wird (eine NDEF-Nachricht kann mehrere NDEF-Einträge haben). In einer wohlgeformten NDEF-Nachricht enthält der erste NdefRecord
die folgenden Felder:
- 3-Bit-TNF (Type Name Format)
- Gibt an, wie das Feld für den Typ der Variablenlänge zu interpretieren ist. Die gültigen Werte werden in Tabelle 1 beschrieben.
- Typ der Variablenlänge
- Der Datensatztyp wird beschrieben. Wenn Sie
TNF_WELL_KNOWN
verwenden, geben Sie in diesem Feld die Definition des Eintragstyps (Record Type Definition, RTT) an. Die gültigen RTD-Werte sind in Tabelle 2 beschrieben. - ID der Variablenlänge
- Eine eindeutige Kennung für den Eintrag. Dieses Feld wird nicht oft verwendet. Wenn Sie jedoch ein Tag eindeutig identifizieren müssen, können Sie eine ID dafür erstellen.
- Nutzlast bei variabler Länge
- Die tatsächliche Datennutzlast, die Sie lesen oder schreiben möchten. Eine NDEF-Nachricht kann mehrere NDEF-Einträge enthalten. Gehen Sie also nicht davon aus, dass sich die vollständige Nutzlast im ersten NDEF-Eintrag der NDEF-Nachricht befindet.
Das Tag-Weiterleitungssystem verwendet die TNF- und Typfelder, um der NDEF-Nachricht einen MIME-Typ oder -URI zuzuordnen. Bei Erfolg werden diese Informationen zusammen mit der tatsächlichen Nutzlast in einen ACTION_NDEF_DISCOVERED
-Intent eingebunden. Es gibt jedoch Fälle, in denen das Tag-Weiterleitungssystem den Datentyp nicht anhand des ersten NDEF-Eintrags ermitteln kann. Dies geschieht, wenn die NDEF-Daten keinem MIME-Typ oder -URI zugeordnet werden können oder wenn das NFC-Tag keine NDEF-Daten enthält. In solchen Fällen wird ein Tag
-Objekt mit Informationen zu den Technologien des Tags und der Nutzlast in einem ACTION_TECH_DISCOVERED
-Intent gekapselt.
In Tabelle 1 wird beschrieben, wie das System zur Tag-Weiterleitung TNF- und Typfelder MIME-Typen oder URIs zuordnet. Außerdem wird beschrieben, welche TNFs keinem MIME-Typ oder -URI zugeordnet werden können.
In diesen Fällen verwendet das Tag-Weiterleitungssystem ACTION_TECH_DISCOVERED
.
Wenn das Tag-Weiterleitungssystem beispielsweise einen Datensatz vom Typ TNF_ABSOLUTE_URI
findet, wird das Typfeld mit variabler Länge dieses Eintrags einem URI zugeordnet. Das Tag-Weiterleitungssystem kapselt diesen URI zusammen mit anderen Informationen über das Tag, z. B. der Nutzlast, im Datenfeld eines ACTION_NDEF_DISCOVERED
-Intents ein. Wird hingegen ein Datensatz vom Typ TNF_UNKNOWN
erkannt, wird ein Intent erstellt, der stattdessen die Technologien des Tags enthält.
Tabelle 1 Unterstützte TNFs und ihre Zuordnungen
Typnamenformat (TNF) | Zuordnung |
---|---|
TNF_ABSOLUTE_URI |
URI basierend auf dem Feld „type“. |
TNF_EMPTY |
Fällt auf ACTION_TECH_DISCOVERED zurück. |
TNF_EXTERNAL_TYPE |
URI basierend auf der URN im Feld „type“. Die URN wird im NDEF-Typfeld in verkürzter Form codiert: <domain_name>:<service_name> .
Android ordnet dies einem URI im folgenden Format zu: vnd.android.nfc://ext/<domain_name>:<service_name> . |
TNF_MIME_MEDIA |
MIME-Typ basierend auf dem Feld für den Typ. |
TNF_UNCHANGED |
Ungültiger Wert im ersten Eintrag, daher wird ACTION_TECH_DISCOVERED verwendet. |
TNF_UNKNOWN |
Fällt auf ACTION_TECH_DISCOVERED zurück. |
TNF_WELL_KNOWN |
MIME-Typ oder -URI abhängig von der Eintragstypdefinition (Record Type Definition, RTT), die Sie im Feld "type" festgelegt haben. Weitere Informationen zu verfügbaren RTDs und ihren Zuordnungen finden Sie in Tabelle 2. |
Tabelle 2 Unterstützte RTDs für TNF_WELL_KNOWN und ihre Zuordnungen
Definition des Datensatztyps | Zuordnung |
---|---|
RTD_ALTERNATIVE_CARRIER |
Fällt auf ACTION_TECH_DISCOVERED zurück. |
RTD_HANDOVER_CARRIER |
Fällt auf ACTION_TECH_DISCOVERED zurück. |
RTD_HANDOVER_REQUEST |
Fällt auf ACTION_TECH_DISCOVERED zurück. |
RTD_HANDOVER_SELECT |
Fällt auf ACTION_TECH_DISCOVERED zurück. |
RTD_SMART_POSTER |
URI, der auf dem Parsen der Nutzlast basiert. |
RTD_TEXT |
MIME-Typ: text/plain |
RTD_URI |
URI basierend auf Nutzlast. |
Senden von NFC-Tags an Anwendungen
Wenn das Tag-Weiterleitungssystem einen Intent erstellt hat, der das NFC-Tag und die zugehörigen Informationen einkapselt, sendet es den Intent an eine interessierte Anwendung, die nach dem Intent filtert. Wenn mehr als eine Anwendung den Intent verarbeiten kann, wird die Aktivitätsauswahl angezeigt, sodass der Nutzer die Aktivität auswählen kann. Das Tag-Weiterleitungssystem definiert drei Intents, die von der höchsten zur niedrigsten Priorität geordnet sind:
-
ACTION_NDEF_DISCOVERED
: Dieser Intent wird verwendet, um eine Aktivität zu starten, wenn ein Tag, das eine NDEF-Nutzlast enthält, gescannt wird und von einem erkannten Typ ist. Dies hat den Intent mit der höchsten Priorität. Das System zur Tag-Weiterleitung versucht nach Möglichkeit, eine Aktivität mit diesem Intent vor jedem anderen Intent zu starten. ACTION_TECH_DISCOVERED
: Wenn keine Aktivitäten für die Verarbeitung desACTION_NDEF_DISCOVERED
-Intents registriert werden, versucht das Tag-Weiterleitungssystem, eine Anwendung mit diesem Intent zu starten. Dieser Intent wird auch direkt gestartet (ohne zuerstACTION_NDEF_DISCOVERED
zu starten), wenn das gescannte Tag NDEF-Daten enthält, die keinem MIME-Typ oder URI zugeordnet werden können, oder wenn das Tag keine NDEF-Daten enthält, aber mit einer bekannten Tag-Technologie verknüpft ist.ACTION_TAG_DISCOVERED
: Dieser Intent wird gestartet, wenn keine Aktivitäten die IntentsACTION_NDEF_DISCOVERED
oderACTION_TECH_DISCOVERED
verarbeiten.
Das Tag-Weiterleitungssystem funktioniert im Wesentlichen so:
- Versuchen Sie, eine Aktivität mit dem Intent zu starten, der vom Tag-Weiterleitungssystem beim Parsen des NFC-Tags (entweder
ACTION_NDEF_DISCOVERED
oderACTION_TECH_DISCOVERED
) erstellt wurde. - Wenn für diesen Intent keine Aktivitäten gefiltert werden, versuchen Sie, eine Aktivität mit dem Intent mit der nächstniedrigeren Priorität (
ACTION_TECH_DISCOVERED
oderACTION_TAG_DISCOVERED
) zu starten, bis eine Anwendung nach dem Intent filtert oder das Tag-Weiterleitungssystem alle möglichen Intents versucht. - Wenn keine Anwendungen nach einem Intent filtern, wird nichts unternommen.
![](https://developer.android.com/static/images/nfc_tag_dispatch.png?authuser=6&hl=de)
Verwenden Sie nach Möglichkeit NDEF-Nachrichten und den Intent ACTION_NDEF_DISCOVERED
, da dies die spezifischste der drei ist. Mit diesem Intent können Sie Ihre Anwendung zu einem geeigneten Zeitpunkt als die anderen beiden Intents starten, um die Nutzerfreundlichkeit zu verbessern.
NFC-Zugriff im Android-Manifest anfordern
Bevor du auf die NFC-Hardware eines Geräts zugreifen und NFC-Intents richtig verarbeiten kannst, musst du die folgenden Elemente in der Datei AndroidManifest.xml
deklarieren:
- Das NFC-Element
<uses-permission>
für den Zugriff auf die NFC-Hardware:<uses-permission android:name="android.permission.NFC" />
- Die SDK-Mindestversion, die Ihre App unterstützt. API-Level 9 unterstützt nur eine begrenzte Tag-Weiterleitung über
ACTION_TAG_DISCOVERED
und gewährt nur Zugriff auf NDEF-Nachrichten über das Extra-EXTRA_NDEF_MESSAGES
. Auf andere Tag-Eigenschaften oder E/A-Vorgänge kann nicht zugegriffen werden. API-Level 10 bietet umfassende Unterstützung für Lese-/Autoren sowie NDEF-Push im Vordergrund. API-Level 14 bietet eine einfachere Möglichkeit, NDEF-Nachrichten mit Android Beam an andere Geräte zu senden, sowie zusätzliche Methoden zum Erstellen von NDEF-Einträgen.<uses-sdk android:minSdkVersion="10"/>
- Das
uses-feature
-Element, damit deine App bei Google Play nur auf Geräten mit NFC-Hardware angezeigt wird:<uses-feature android:name="android.hardware.nfc" android:required="true" />
Wenn Ihre Anwendung NFC-Funktionen verwendet, diese aber für Ihre Anwendung nicht entscheidend ist, können Sie das Element
uses-feature
weglassen und während der Laufzeit auf NFC-Verfügbarkeit prüfen. Dazu prüfen Sie, obgetDefaultAdapter()
den Wertnull
hat.
Nach NFC-Intents filtern
Damit Ihre App gestartet wird, wenn ein gewünschtes NFC-Tag gescannt wird, kann sie im Android-Manifest nach einem, zwei oder allen drei NFC-Intents filtern. Normalerweise ist es jedoch sinnvoller, nach dem Intent ACTION_NDEF_DISCOVERED
zu filtern, um genau zu steuern, wann die Anwendung gestartet wird. Der Intent ACTION_TECH_DISCOVERED
ist ein Fallback für ACTION_NDEF_DISCOVERED
, wenn keine Anwendungen nach ACTION_NDEF_DISCOVERED
filtern oder die Nutzlast nicht NDEF ist. Das Filtern nach ACTION_TAG_DISCOVERED
ist für eine Kategorie normalerweise zu allgemein, um danach zu filtern. Viele Anwendungen filtern vor dem ACTION_TAG_DISCOVERED
nach ACTION_NDEF_DISCOVERED
oder ACTION_TECH_DISCOVERED
. Die Startwahrscheinlichkeit ist also gering. ACTION_TAG_DISCOVERED
steht nur als letzte Option zum Filtern von Anwendungen zur Verfügung, wenn keine anderen Anwendungen installiert sind, um den Intent ACTION_NDEF_DISCOVERED
oder ACTION_TECH_DISCOVERED
zu verarbeiten.
Da NFC-Tag-Bereitstellungen variieren und häufig nicht von Ihnen gesteuert werden, ist dies nicht immer möglich. Daher können Sie bei Bedarf auf die anderen beiden Intents zurückgreifen. Wenn Sie die Kontrolle über die Arten der geschriebenen Tags und Daten haben, empfiehlt es sich, Ihre Tags mit NDEF zu formatieren. In den folgenden Abschnitten wird beschrieben, wie Sie nach den einzelnen Intent-Typen filtern.
ACTION_NDEF_DISCOVERED
Wenn Sie nach ACTION_NDEF_DISCOVERED
-Intents filtern möchten, deklarieren Sie den Intent-Filter zusammen mit dem Datentyp, nach dem Sie filtern möchten. Im folgenden Beispiel wird nach ACTION_NDEF_DISCOVERED
-Intents mit dem MIME-Typ text/plain
gefiltert:
<intent-filter> <action android:name="android.nfc.action.NDEF_DISCOVERED"/> <category android:name="android.intent.category.DEFAULT"/> <data android:mimeType="text/plain" /> </intent-filter>
Im folgenden Beispiel wird nach einem URI im Format https://developer.android.com/index.html
gefiltert.
<intent-filter> <action android:name="android.nfc.action.NDEF_DISCOVERED"/> <category android:name="android.intent.category.DEFAULT"/> <data android:scheme="https" android:host="developer.android.com" android:pathPrefix="/index.html" /> </intent-filter>
ACTION_TECH_DISCOVERED
Wenn Ihre Aktivitäten nach dem Intent ACTION_TECH_DISCOVERED
filtern, müssen Sie eine XML-Ressourcendatei erstellen, in der die von Ihrer Aktivität unterstützten Technologien innerhalb eines tech-list
-Satzes angegeben sind. Ihre Aktivität gilt als Übereinstimmung, wenn das Set tech-list
eine Teilmenge der Technologien ist, die vom Tag unterstützt werden und die Sie durch Aufrufen von getTechList()
abrufen können.
Wenn das gescannte Tag beispielsweise MifareClassic, NdefFormatable und NfcA unterstützt, müssen in Ihrem tech-list
-Satz alle drei, zwei oder eine der Technologien (und sonst nichts) angegeben werden, damit Ihre Aktivität abgeglichen werden kann.
Im folgenden Beispiel werden alle Technologien definiert. Entfernen Sie diejenigen, die von Ihrem NFC-Tag nicht unterstützt werden. Speichern Sie diese Datei im Ordner <project-root>/res/xml
. Sie können ihr einen beliebigen Namen geben.
<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2"> <tech-list> <tech>android.nfc.tech.IsoDep</tech> <tech>android.nfc.tech.NfcA</tech> <tech>android.nfc.tech.NfcB</tech> <tech>android.nfc.tech.NfcF</tech> <tech>android.nfc.tech.NfcV</tech> <tech>android.nfc.tech.Ndef</tech> <tech>android.nfc.tech.NdefFormatable</tech> <tech>android.nfc.tech.MifareClassic</tech> <tech>android.nfc.tech.MifareUltralight</tech> </tech-list> </resources>
Sie können auch mehrere tech-list
-Sets angeben. Jedes tech-list
-Dataset wird unabhängig betrachtet und Ihre Aktivität gilt als übereinstimmend, wenn ein einzelnes tech-list
-Set eine Teilmenge der Technologien ist, die von getTechList()
zurückgegeben werden. Dies bietet AND
- und OR
-Semantik für Abgleichtechnologien. Im folgenden Beispiel werden Tags abgeglichen, die die NfcA- und Ndef-Technologien oder die NfcB- und Ndef-Technologien unterstützen können:
<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2"> <tech-list> <tech>android.nfc.tech.NfcA</tech> <tech>android.nfc.tech.Ndef</tech> </tech-list> <tech-list> <tech>android.nfc.tech.NfcB</tech> <tech>android.nfc.tech.Ndef</tech> </tech-list> </resources>
Geben Sie in der Datei AndroidManifest.xml
die soeben erstellte Ressourcendatei im Element <meta-data>
innerhalb des Elements <activity>
an, wie im folgenden Beispiel gezeigt:
<activity> ... <intent-filter> <action android:name="android.nfc.action.TECH_DISCOVERED"/> </intent-filter> <meta-data android:name="android.nfc.action.TECH_DISCOVERED" android:resource="@xml/nfc_tech_filter" /> ... </activity>
Weitere Informationen zur Verwendung von Tag-Technologien und dem Intent ACTION_TECH_DISCOVERED
finden Sie im Dokument zu erweiterten NFC unter Arbeiten mit unterstützten Tag-Technologien.
ACTION_TAG_DISCOVERED
Verwenden Sie den folgenden Intent-Filter, um nach ACTION_TAG_DISCOVERED
zu filtern:
<intent-filter> <action android:name="android.nfc.action.TAG_DISCOVERED"/> </intent-filter>
Informationen aus Intents erhalten
Wenn eine Aktivität aufgrund eines NFC-Intents gestartet wird, können Sie vom Intent Informationen über das gescannte NFC-Tag abrufen. Intents können je nach gescanntem Tag die folgenden Extras enthalten:
EXTRA_TAG
(erforderlich): EinTag
-Objekt, das das gescannte Tag darstellt.EXTRA_NDEF_MESSAGES
(optional): Ein Array von NDEF-Nachrichten, die vom Tag geparst wurden. Dieses Extra ist fürACTION_NDEF_DISCOVERED
-Intents obligatorisch.EXTRA_ID
(optional): Die Low-Level-ID des Tags.
Um diese Extras zu erhalten, müssen Sie prüfen, ob Ihre Aktivität mit einem der NFC-Intents gestartet wurde. So können Sie prüfen, ob ein Tag gescannt wurde, und die Extras dann aus dem Intent abrufen. Im folgenden Beispiel wird auf den Intent ACTION_NDEF_DISCOVERED
geprüft und die NDEF-Nachrichten werden von einem zusätzlichen Intent abgerufen.
Kotlin
override fun onNewIntent(intent: Intent) { super.onNewIntent(intent) ... if (NfcAdapter.ACTION_NDEF_DISCOVERED == intent.action) { intent.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES)?.also { rawMessages -> val messages: List<NdefMessage> = rawMessages.map { it as NdefMessage } // Process the messages array. ... } } }
Java
@Override protected void onNewIntent(Intent intent) { super.onNewIntent(intent); ... if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(intent.getAction())) { Parcelable[] rawMessages = intent.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES); if (rawMessages != null) { NdefMessage[] messages = new NdefMessage[rawMessages.length]; for (int i = 0; i < rawMessages.length; i++) { messages[i] = (NdefMessage) rawMessages[i]; } // Process the messages array. ... } } }
Alternativ können Sie ein Tag
-Objekt vom Intent abrufen, das die Nutzlast enthält und es Ihnen ermöglicht, die Technologien des Tags aufzulisten:
Kotlin
val tag: Tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG)
Java
Tag tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);
Allgemeine Typen von NDEF-Einträgen erstellen
In diesem Abschnitt wird beschrieben, wie Sie gängige Typen von NDEF-Einträgen erstellen, die Ihnen beim Schreiben in NFC-Tags oder beim Senden von Daten mit Android Beam helfen. Ab Android 4.0 (API-Level 14) ist die Methode createUri()
verfügbar, um URI-Einträge automatisch zu erstellen. Ab Android 4.1 (API-Level 16) sind createExternal()
und createMime()
zum Erstellen von MIME- und NDEF-Einträgen vom externen Typ verfügbar. Verwenden Sie nach Möglichkeit diese Hilfsmethoden, um Fehler beim manuellen Erstellen von NDEF-Einträgen zu vermeiden.
Außerdem wird in diesem Abschnitt beschrieben, wie Sie den entsprechenden Intent-Filter für den Eintrag erstellen. Alle Beispiele für NDEF-Einträge sollten im ersten NDEF-Eintrag der NDEF-Nachricht enthalten sein, die Sie in ein Tag schreiben oder Beaming schreiben.
TNF_ABSOLUTE_URI
Hinweis: Wir empfehlen, den Typ RTD_URI
anstelle von TNF_ABSOLUTE_URI
zu verwenden, da dies effizienter ist.
So erstellen Sie einen NDEF-Eintrag für TNF_ABSOLUTE_URI
:
Kotlin
val uriRecord = ByteArray(0).let { emptyByteArray -> NdefRecord( TNF_ABSOLUTE_URI, "https://developer.android.com/index.html".toByteArray(Charset.forName("US-ASCII")), emptyByteArray, emptyByteArray ) }
Java
NdefRecord uriRecord = new NdefRecord( NdefRecord.TNF_ABSOLUTE_URI , "https://developer.android.com/index.html".getBytes(Charset.forName("US-ASCII")), new byte[0], new byte[0]);
Der Intent-Filter für den vorherigen NDEF-Eintrag würde so aussehen:
<intent-filter> <action android:name="android.nfc.action.NDEF_DISCOVERED" /> <category android:name="android.intent.category.DEFAULT" /> <data android:scheme="https" android:host="developer.android.com" android:pathPrefix="/index.html" /> </intent-filter>
TNF_MIME_MEDIA
Sie können einen NDEF-Eintrag für TNF_MIME_MEDIA
auf folgende Arten erstellen:
Mit der Methode createMime()
:
Kotlin
val mimeRecord = NdefRecord.createMime( "application/vnd.com.example.android.beam", "Beam me up, Android".toByteArray(Charset.forName("US-ASCII")) )
Java
NdefRecord mimeRecord = NdefRecord.createMime("application/vnd.com.example.android.beam", "Beam me up, Android".getBytes(Charset.forName("US-ASCII")));
NdefRecord
manuell erstellen:
Kotlin
val mimeRecord = Charset.forName("US-ASCII").let { usAscii -> NdefRecord( NdefRecord.TNF_MIME_MEDIA, "application/vnd.com.example.android.beam".toByteArray(usAscii), ByteArray(0), "Beam me up, Android!".toByteArray(usAscii) ) }
Java
NdefRecord mimeRecord = new NdefRecord( NdefRecord.TNF_MIME_MEDIA , "application/vnd.com.example.android.beam".getBytes(Charset.forName("US-ASCII")), new byte[0], "Beam me up, Android!".getBytes(Charset.forName("US-ASCII")));
Der Intent-Filter für den vorherigen NDEF-Eintrag würde so aussehen:
<intent-filter> <action android:name="android.nfc.action.NDEF_DISCOVERED" /> <category android:name="android.intent.category.DEFAULT" /> <data android:mimeType="application/vnd.com.example.android.beam" /> </intent-filter>
TNF_WELL_KNOWN mit RTD_TEXT
So erstellen Sie einen NDEF-Eintrag vom Typ TNF_WELL_KNOWN
:
Kotlin
fun createTextRecord(payload: String, locale: Locale, encodeInUtf8: Boolean): NdefRecord { val langBytes = locale.language.toByteArray(Charset.forName("US-ASCII")) val utfEncoding = if (encodeInUtf8) Charset.forName("UTF-8") else Charset.forName("UTF-16") val textBytes = payload.toByteArray(utfEncoding) val utfBit: Int = if (encodeInUtf8) 0 else 1 shl 7 val status = (utfBit + langBytes.size).toChar() val data = ByteArray(1 + langBytes.size + textBytes.size) data[0] = status.toByte() System.arraycopy(langBytes, 0, data, 1, langBytes.size) System.arraycopy(textBytes, 0, data, 1 + langBytes.size, textBytes.size) return NdefRecord(NdefRecord.TNF_WELL_KNOWN, NdefRecord.RTD_TEXT, ByteArray(0), data) }
Java
public NdefRecord createTextRecord(String payload, Locale locale, boolean encodeInUtf8) { byte[] langBytes = locale.getLanguage().getBytes(Charset.forName("US-ASCII")); Charset utfEncoding = encodeInUtf8 ? Charset.forName("UTF-8") : Charset.forName("UTF-16"); byte[] textBytes = payload.getBytes(utfEncoding); int utfBit = encodeInUtf8 ? 0 : (1 << 7); char status = (char) (utfBit + langBytes.length); byte[] data = new byte[1 + langBytes.length + textBytes.length]; data[0] = (byte) status; System.arraycopy(langBytes, 0, data, 1, langBytes.length); System.arraycopy(textBytes, 0, data, 1 + langBytes.length, textBytes.length); NdefRecord record = new NdefRecord(NdefRecord.TNF_WELL_KNOWN, NdefRecord.RTD_TEXT, new byte[0], data); return record; }
Der Intent-Filter für den vorherigen NDEF-Eintrag würde so aussehen:
<intent-filter> <action android:name="android.nfc.action.NDEF_DISCOVERED" /> <category android:name="android.intent.category.DEFAULT" /> <data android:mimeType="text/plain" /> </intent-filter>
TNF_WELL_KNOWN mit RTD_URI
Sie können einen NDEF-Eintrag für TNF_WELL_KNOWN
auf folgende Arten erstellen:
Mit der Methode createUri(String)
:
Kotlin
val rtdUriRecord1 = NdefRecord.createUri("https://example.com")
Java
NdefRecord rtdUriRecord1 = NdefRecord.createUri("https://example.com");
Mit der Methode createUri(Uri)
:
Kotlin
val rtdUriRecord2 = Uri.parse("https://example.com").let { uri -> NdefRecord.createUri(uri) }
Java
Uri uri = Uri.parse("https://example.com"); NdefRecord rtdUriRecord2 = NdefRecord.createUri(uri);
NdefRecord
manuell erstellen:
Kotlin
val uriField = "example.com".toByteArray(Charset.forName("US-ASCII")) val payload = ByteArray(uriField.size + 1) //add 1 for the URI Prefix payload [0] = 0x01 //prefixes https://www. to the URI System.arraycopy(uriField, 0, payload, 1, uriField.size) //appends URI to payload val rtdUriRecord = NdefRecord(NdefRecord.TNF_WELL_KNOWN, NdefRecord.RTD_URI, ByteArray(0), payload)
Java
byte[] uriField = "example.com".getBytes(Charset.forName("US-ASCII")); byte[] payload = new byte[uriField.length + 1]; //add 1 for the URI Prefix payload[0] = 0x01; //prefixes https://www. to the URI System.arraycopy(uriField, 0, payload, 1, uriField.length); //appends URI to payload NdefRecord rtdUriRecord = new NdefRecord( NdefRecord.TNF_WELL_KNOWN, NdefRecord.RTD_URI, new byte[0], payload);
Der Intent-Filter für den vorherigen NDEF-Eintrag würde so aussehen:
<intent-filter> <action android:name="android.nfc.action.NDEF_DISCOVERED" /> <category android:name="android.intent.category.DEFAULT" /> <data android:scheme="https" android:host="example.com" android:pathPrefix="" /> </intent-filter>
TNF_EXTERNE_TYP
Sie können einen NDEF-Eintrag für TNF_EXTERNAL_TYPE
auf folgende Arten erstellen:
Mit der Methode createExternal()
:
Kotlin
var payload: ByteArray //assign to your data val domain = "com.example" //usually your app's package name val type = "externalType" val extRecord = NdefRecord.createExternal(domain, type, payload)
Java
byte[] payload; //assign to your data String domain = "com.example"; //usually your app's package name String type = "externalType"; NdefRecord extRecord = NdefRecord.createExternal(domain, type, payload);
NdefRecord
manuell erstellen:
Kotlin
var payload: ByteArray ... val extRecord = NdefRecord( NdefRecord.TNF_EXTERNAL_TYPE, "com.example:externalType".toByteArray(Charset.forName("US-ASCII")), ByteArray(0), payload )
Java
byte[] payload; ... NdefRecord extRecord = new NdefRecord( NdefRecord.TNF_EXTERNAL_TYPE, "com.example:externalType".getBytes(Charset.forName("US-ASCII")), new byte[0], payload);
Der Intent-Filter für den vorherigen NDEF-Eintrag würde so aussehen:
<intent-filter> <action android:name="android.nfc.action.NDEF_DISCOVERED" /> <category android:name="android.intent.category.DEFAULT" /> <data android:scheme="vnd.android.nfc" android:host="ext" android:pathPrefix="/com.example:externalType"/> </intent-filter>
Verwenden Sie TNF_EXTERNAL_TYPE
für allgemeinere NFC-Tag-Bereitstellungen. So werden sowohl Android- als auch Nicht-Android-Geräte besser unterstützt.
Hinweis: URNs für TNF_EXTERNAL_TYPE
haben das kanonische Format urn:nfc:ext:example.com:externalType
. In der RTD-Spezifikation für das NFC-Forum ist jedoch deklariert, dass der urn:nfc:ext:
-Teil der URN im NDEF-Eintrag weggelassen werden muss. Sie müssen also nur die Domain (im Beispiel example.com
) und den Typ (im Beispiel externalType
) getrennt durch einen Doppelpunkt angeben.
Beim Senden von TNF_EXTERNAL_TYPE
wandelt Android die urn:nfc:ext:example.com:externalType
-URN in einen vnd.android.nfc://ext/example.com:externalType
-URI um. Das wird durch den Intent-Filter im Beispiel deklariert.
Datensätze zu Android-Apps
Ein in Android 4.0 (API-Level 14) eingeführter Android Application Record (AAR) bietet eine höhere Sicherheit, dass Ihre App gestartet wird, wenn ein NFC-Tag gescannt wird. Ein AAR hat den Paketnamen einer Anwendung, die in einen NDEF-Eintrag eingebettet ist. Sie können jedem NDEF-Eintrag Ihrer NDEF-Nachricht ein AAE hinzufügen, da Android in der gesamten NDEF-Nachricht nach AAE sucht. Wenn ein AAE gefunden wird, wird die Anwendung basierend auf dem Paketnamen im AAE gestartet. Ist die App nicht auf dem Gerät vorhanden, wird Google Play gestartet, um sie herunterzuladen.
AAE sind nützlich, wenn Sie verhindern möchten, dass andere Anwendungen nach demselben Intent filtern und möglicherweise bestimmte von Ihnen bereitgestellte Tags verarbeiten. AAE werden aufgrund der Einschränkung des Paketnamens nur auf Anwendungsebene unterstützt und nicht wie bei der Intent-Filterung auf Aktivitätsebene. Wenn Sie einen Intent auf Aktivitätsebene verarbeiten möchten, verwenden Sie Intent-Filter.
Wenn ein Tag AAE enthält, löst das Tag-Weiterleitungssystem die Weiterleitung so aus:
- Versuchen Sie, eine Aktivität mit einem Intent-Filter wie gewohnt zu starten. Wenn die Activity, die dem Intent entspricht, auch dem AAE entspricht, starten Sie die Aktivität.
- Wenn die Aktivität, die für den Intent filtert, nicht dem automatisch angewendeten Attributionsmodell entspricht, wenn mehrere Aktivitäten den Intent verarbeiten können oder wenn keine Aktivität den Intent verarbeitet, starten Sie die durch AAE angegebene Anwendung.
- Wenn keine App mit automatisch angewendeten Empfehlungen starten kann, lade die App bei Google Play herunter, die auf automatisch angewendeten Empfehlungen basiert.
Hinweis:Sie können AAE und das Intent-Weiterleitungssystem mit dem Weiterleitungssystem im Vordergrund überschreiben. Dadurch hat eine Aktivität im Vordergrund Vorrang, wenn ein NFC-Tag erkannt wird. Bei dieser Methode muss sich die Aktivität im Vordergrund befinden, um AAE und das Intent-Weiterleitungssystem zu überschreiben.
Wenn Sie trotzdem nach gescannten Tags filtern möchten, die kein AAE enthalten, können Sie Intent-Filter wie gewohnt deklarieren. Dies ist nützlich, wenn Ihre Anwendung an anderen Tags interessiert ist, die kein AAE enthalten. Vielleicht möchten Sie beispielsweise dafür sorgen, dass Ihre Anwendung proprietäre Tags, die Sie bereitstellen, sowie allgemeine Tags von Drittanbietern verarbeitet. AAE sind spezifisch für Geräte mit Android 4.0 oder höher. Wenn Sie Tags bereitstellen, sollten Sie daher eine Kombination aus automatisch angewendeten Empfehlungen und MIME-Typen/URIs verwenden, um eine möglichst große Bandbreite von Geräten zu unterstützen. Überlegen Sie bei der Bereitstellung von NFC-Tags, wie Sie die NFC-Tags schreiben möchten, um die Unterstützung für die meisten Geräte (Android-Geräte und andere Geräte) zu ermöglichen. Dazu können Sie einen relativ eindeutigen MIME-Typ oder URI definieren, damit Anwendungen leichter unterscheiden können.
Android bietet eine einfache API zum Erstellen von automatisch angewendeten Empfehlungen: createApplicationRecord()
. Sie müssen das AAE lediglich an einer beliebigen Stelle in Ihrem NdefMessage
einbetten. Sie sollten den ersten Datensatz von NdefMessage
nur dann verwenden, wenn der AAR der einzige Datensatz im NdefMessage
ist. Das liegt daran, dass das Android-System den ersten Eintrag eines NdefMessage
prüft, um den MIME-Typ oder den URI des Tags zu ermitteln. Damit wird ein Intent für Anwendungen erstellt, die gefiltert werden sollen. Der folgende Code zeigt, wie Sie ein AAE erstellen:
Kotlin
val msg = NdefMessage( arrayOf( ..., NdefRecord.createApplicationRecord("com.example.android.beam") ) )
Java
NdefMessage msg = new NdefMessage( new NdefRecord[] { ..., NdefRecord.createApplicationRecord("com.example.android.beam")} ); )
NDEF-Nachrichten an andere Geräte übertragen
Android Beam ermöglicht einen einfachen Peer-to-Peer-Datenaustausch zwischen zwei Android-Geräten. Die Anwendung, die Daten auf ein anderes Gerät beamen möchte, muss sich im Vordergrund befinden und das Gerät, das die Daten empfängt, darf nicht gesperrt sein. Wenn das Beaming-Gerät nah genug mit einem empfangenden Gerät in Kontakt ist, zeigt es die Benutzeroberfläche "Zum Beamen berühren" an. Der Nutzer kann dann auswählen, ob die Nachricht auf das empfangende Gerät übertragen werden soll.
Hinweis:Die NDEF-Übertragung im Vordergrund war auf API-Ebene 10 verfügbar, die ähnliche Funktionen wie Android Beam bietet. Diese APIs wurden inzwischen eingestellt, unterstützen aber ältere Geräte. Weitere Informationen findest du in den enableForegroundNdefPush()
.
Sie können Android Beam für Ihre App aktivieren, indem Sie eine der beiden Methoden aufrufen:
setNdefPushMessage()
: Akzeptiert einenNdefMessage
, der als Nachricht für das Beamen festgelegt werden soll. Die Nachricht wird automatisch gesendet, wenn sich zwei Geräte in unmittelbarer Nähe zueinander befinden.setNdefPushMessageCallback()
: Akzeptiert einen Callback, der eincreateNdefMessage()
-Element enthält, das aufgerufen wird, wenn sich ein Gerät in Reichweite befindet, an das Daten strahlen können. Mit dem Callback können Sie die NDEF-Nachricht nur bei Bedarf erstellen.
Eine Aktivität kann nur jeweils eine NDEF-Nachricht senden, sodass setNdefPushMessageCallback()
Vorrang vor setNdefPushMessage()
hat, wenn beide festgelegt sind. Für die Verwendung von Android Beam müssen die folgenden allgemeinen Richtlinien eingehalten werden:
- Die Aktivität, bei der die Daten gesendet werden, muss im Vordergrund ausgeführt werden. Auf beiden Geräten muss der Bildschirm entsperrt sein.
- Die Daten, die Sie beamen, müssen in ein
NdefMessage
-Objekt gekapselt werden. - Das NFC-Gerät, das die übertragenen Daten empfängt, muss das NDEF-Push-Protokoll
com.android.npp
oder das SNEP (Simple NDEF Exchange Protocol) des NFC-Forums unterstützen. Dascom.android.npp
-Protokoll ist für Geräte mit API-Level 9 (Android 2.3) bis API-Level 13 (Android 3.2) erforderlich.com.android.npp
und SNEP sind beide auf API-Level 14 (Android 4.0) und höher erforderlich.
Hinweis:Wenn durch Ihre Aktivität Android Beam aktiviert wird und im Vordergrund ausgeführt wird, ist das Standard-Intent-Weiterleitungssystem deaktiviert. Wenn Ihre Aktivität jedoch auch die Weiterleitung im Vordergrund aktiviert, können trotzdem Tags gescannt werden, die den Intent-Filtern entsprechen, die in der Weiterleitung im Vordergrund festgelegt wurden.
So aktivieren Sie Android Beam:
- Erstellen Sie ein
NdefMessage
mit denNdefRecord
s, die Sie auf das andere Gerät übertragen möchten. - Rufen Sie
setNdefPushMessage()
mit einemNdefMessage
odersetNdefPushMessageCallback
auf und übergeben Sie einNfcAdapter.CreateNdefMessageCallback
-Objekt in deronCreate()
-Methode Ihrer Aktivität. Für diese Methoden ist mindestens eine Aktivität erforderlich, die Sie mit Android Beam aktivieren möchten, zusammen mit einer optionalen Liste anderer zu aktivierender Aktivitäten.Im Allgemeinen verwenden Sie normalerweise
setNdefPushMessage()
, wenn Ihre Aktivität immer nur dieselbe NDEF-Nachricht senden muss, wenn sich zwei Geräte in Reichweite zur Kommunikation befinden. Sie verwendensetNdefPushMessageCallback
, wenn Ihre Anwendung den aktuellen Kontext der Anwendung benötigt und eine NDEF-Nachricht senden möchte, je nachdem, was der Nutzer in Ihrer Anwendung tut.
Das folgende Beispiel zeigt, wie eine einfache Aktivität NfcAdapter.CreateNdefMessageCallback
in der Methode onCreate()
einer Aktivität aufruft. Das vollständige Beispiel finden Sie in AndroidBeamDemo. Dieses Beispiel enthält auch Methoden zum Erstellen eines MIME-Eintrags:
Kotlin
package com.example.android.beam import android.app.Activity import android.content.Intent import android.nfc.NdefMessage import android.nfc.NdefRecord import android.nfc.NfcAdapter import android.nfc.NfcAdapter.CreateNdefMessageCallback import android.nfc.NfcEvent import android.os.Bundle import android.os.Parcelable import android.widget.TextView import android.widget.Toast import java.nio.charset.Charset class Beam : Activity(), NfcAdapter.CreateNdefMessageCallback { private var nfcAdapter: NfcAdapter? = null private lateinit var textView: TextView override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.main) textView = findViewById(R.id.textView) // Check for available NFC Adapter nfcAdapter = NfcAdapter.getDefaultAdapter(this) if (nfcAdapter == null) { Toast.makeText(this, "NFC is not available", Toast.LENGTH_LONG).show() finish() return } // Register callback nfcAdapter?.setNdefPushMessageCallback(this, this) } override fun createNdefMessage(event: NfcEvent): NdefMessage { val text = "Beam me up, Android!\n\n" + "Beam Time: " + System.currentTimeMillis() return NdefMessage( arrayOf( createMime("application/vnd.com.example.android.beam", text.toByteArray()) ) /** * The Android Application Record (AAR) is commented out. When a device * receives a push with an AAR in it, the application specified in the AAR * is guaranteed to run. The AAR overrides the tag dispatch system. * You can add it back in to guarantee that this * activity starts when receiving a beamed message. For now, this code * uses the tag dispatch system. *///,NdefRecord.createApplicationRecord("com.example.android.beam") ) } override fun onResume() { super.onResume() // Check to see that the Activity started due to an Android Beam if (NfcAdapter.ACTION_NDEF_DISCOVERED == intent.action) { processIntent(intent) } } override fun onNewIntent(intent: Intent) { // onResume gets called after this to handle the intent setIntent(intent) } /** * Parses the NDEF Message from the intent and prints to the TextView */ private fun processIntent(intent: Intent) { textView = findViewById(R.id.textView) // only one message sent during the beam intent.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES)?.also { rawMsgs -> (rawMsgs[0] as NdefMessage).apply { // record 0 contains the MIME type, record 1 is the AAR, if present textView.text = String(records[0].payload) } } } }
Java
package com.example.android.beam; import android.app.Activity; import android.content.Intent; import android.nfc.NdefMessage; import android.nfc.NdefRecord; import android.nfc.NfcAdapter; import android.nfc.NfcAdapter.CreateNdefMessageCallback; import android.nfc.NfcEvent; import android.os.Bundle; import android.os.Parcelable; import android.widget.TextView; import android.widget.Toast; import java.nio.charset.Charset; public class Beam extends Activity implements CreateNdefMessageCallback { NfcAdapter nfcAdapter; TextView textView; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); TextView textView = (TextView) findViewById(R.id.textView); // Check for available NFC Adapter nfcAdapter = NfcAdapter.getDefaultAdapter(this); if (nfcAdapter == null) { Toast.makeText(this, "NFC is not available", Toast.LENGTH_LONG).show(); finish(); return; } // Register callback nfcAdapter.setNdefPushMessageCallback(this, this); } @Override public NdefMessage createNdefMessage(NfcEvent event) { String text = ("Beam me up, Android!\n\n" + "Beam Time: " + System.currentTimeMillis()); NdefMessage msg = new NdefMessage( new NdefRecord[] { createMime( "application/vnd.com.example.android.beam", text.getBytes()) /** * The Android Application Record (AAR) is commented out. When a device * receives a push with an AAR in it, the application specified in the AAR * is guaranteed to run. The AAR overrides the tag dispatch system. * You can add it back in to guarantee that this * activity starts when receiving a beamed message. For now, this code * uses the tag dispatch system. */ //,NdefRecord.createApplicationRecord("com.example.android.beam") }); return msg; } @Override public void onResume() { super.onResume(); // Check to see that the Activity started due to an Android Beam if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(getIntent().getAction())) { processIntent(getIntent()); } } @Override public void onNewIntent(Intent intent) { // onResume gets called after this to handle the intent setIntent(intent); } /** * Parses the NDEF Message from the intent and prints to the TextView */ void processIntent(Intent intent) { textView = (TextView) findViewById(R.id.textView); Parcelable[] rawMsgs = intent.getParcelableArrayExtra( NfcAdapter.EXTRA_NDEF_MESSAGES); // only one message sent during the beam NdefMessage msg = (NdefMessage) rawMsgs[0]; // record 0 contains the MIME type, record 1 is the AAR, if present textView.setText(new String(msg.getRecords()[0].getPayload())); } }
In diesem Code werden automatisch angewendete Empfehlungen auskommentiert, die Sie entfernen können. Wenn Sie AAE aktivieren, empfängt die im AAE angegebene Anwendung immer die Android Beam-Nachricht. Ist die App nicht vorhanden, wird sie von Google Play heruntergeladen. Daher ist der folgende Intent-Filter technisch nicht erforderlich für Geräte mit Android 4.0 oder höher, wenn AAE verwendet wird:
<intent-filter> <action android:name="android.nfc.action.NDEF_DISCOVERED"/> <category android:name="android.intent.category.DEFAULT"/> <data android:mimeType="application/vnd.com.example.android.beam"/> </intent-filter>
Mit diesem Intent-Filter kann die com.example.android.beam
-Anwendung jetzt gestartet werden, wenn sie ein NFC-Tag scannt oder einen Android Beam mit einem AAR vom Typ com.example.android.beam
empfängt, oder wenn eine NDEF-formatierte Nachricht einen MIME-Eintrag vom Typ application/vnd.com.example.android.beam
enthält.
Obwohl AAE garantieren, dass eine Anwendung gestartet oder heruntergeladen wird, werden Intent-Filter empfohlen, da Sie damit eine Aktivität Ihrer Wahl in Ihrer Anwendung starten können, anstatt die Hauptaktivität innerhalb des durch ein AAE angegebenen Pakets immer zu starten. AAE haben keinen Detaillierungsgrad auf Aktivitätsebene. Da einige Android-Geräte keine AAE unterstützen, sollten Sie außerdem identifizierende Informationen in den ersten NDEF-Eintrag Ihrer NDEF-Nachrichten einbetten und sicherheitshalber auch danach filtern. Weitere Informationen zum Erstellen von Einträgen finden Sie unter Häufige Typen von NDEF-Einträgen erstellen.