Diese Seite wurde von der Cloud Translation API übersetzt.

NFC – Grundlagen

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 des ACTION_NDEF_DISCOVERED-Intents registriert werden, versucht das Tag-Weiterleitungssystem, eine Anwendung mit diesem Intent zu starten. Dieser Intent wird auch direkt gestartet (ohne zuerst ACTION_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 Intents ACTION_NDEF_DISCOVERED oder ACTION_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 oder ACTION_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 oder ACTION_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.

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, ob getDefaultAdapter() den Wert null 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): Ein Tag-Objekt, das das gescannte Tag darstellt.
EXTRA_NDEF_MESSAGES (optional): Ein Array von NDEF-Nachrichten, die vom Tag geparst wurden. Dieses Extra ist für ACTION_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 einen NdefMessage, 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 ein createNdefMessage()-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. Das com.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 den NdefRecords, die Sie auf das andere Gerät übertragen möchten.
Rufen Sie setNdefPushMessage() mit einem NdefMessage oder setNdefPushMessageCallback auf und übergeben Sie ein NfcAdapter.CreateNdefMessageCallback-Objekt in der onCreate()-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 verwenden setNdefPushMessageCallback, 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.