NTAG 424 DNA am Pixel: „Check NDEF Failed, status = 3"

Was der Android-Stack bei jedem Tap tut

Mitgeschnitten per adb-logcat. Der Ablauf ist bei jedem Tap identisch:

1. Der Tag wird sauber als Typ 4 aktiviert (T4T, ISO_DEP for tech A, nfc type=0x4). RF und ISO-DEP sind in Ordnung.
2. isMifareDESFire meldet 1. Der Chip antwortet mit ATQA 0x0344 und SAK 0x20, und genau das löst die DESFire-Erkennung aus.
3. Es folgt eine GetVersion-Probe, danach steht doIsNdefFormatable auf 1.
4. Der Stack macht nur einen weichen reconnect. Im Log steht nativeNfcTag_doReconnect mit retCode 0, ein deactivate und activate fehlt.
5. doCheckNdef ruft NFA_RwDetectNDef, drei APDUs gehen hinaus, alle Flags bleiben unbekannt, das Ergebnis ist status = 3.

NfcService: isMifareDESFire: return=1
NativeNfcTag: doTransceive raw=1 ... 9 bytes
NativeNfcTag: doIsNdefFormatable: is formattable=1
NativeNfcTag: nativeNfcTag_doReconnect retCode=0
NfcService: doCheckNdef -> NFA_RwDetectNDef
RwT4t: rw_t4t_send_to_lower (x3) -> flag all unknown
NativeNfcTag: Check NDEF Failed, status = 3
NfcService: dispatchTag ... message: null
NfcService: tech [IsoDep, NfcA, NdefFormatable] -> no match

Danach meldet dispatchTag die Nachricht null und die Tech-Liste IsoDep, NfcA, NdefFormatable, für die kein Intent-Filter greift. Für den Nutzer sieht es aus, als sei nichts geschehen.

Die Falle: „NdefFormatable" heißt nicht „leere Karte"

Der naheliegende Schluss aus der Tech-Liste lautet, die Karte sei leer und müsse beschrieben werden. Das ist falsch, und es ist die teuerste Fehldeutung an dieser Stelle: Wer daraufhin formatiert, überschreibt eine funktionierende Konfiguration.

Der Eintrag entsteht allein daraus, dass die DESFire-Heuristik nach der GetVersion-Antwort annimmt, sie könne die Karte selbst einrichten. Über den Inhalt sagt das nichts. Der Capability Container derselben Karte ist einwandfrei, die NDEF-Datei ist frei lesbar.

Am Kontaktleser nachgestellt, ohne Pixel

Damit der Befund nicht an einem einzelnen Gerät hängt, wurde er auf einem Kontaktleser nachgestellt. Zuerst der saubere Lesevorgang als Vergleichspunkt:

# saubere Sitzung, Kontaktleser
CC: 0017 20 0100 00FF ... E104 MaxSize256  Read=frei Write=frei   # standardkonform
NDEF: OK -> https://shiftscan.de/t/04XXXXXXXXXX90?c=0000XX&m=XXXXXXXXXXXXXXXX
      (SDM-Zaehler steigt, CMAC frisch -> SUN arbeitet)

Der Capability Container ist standardkonform, das Lesen frei, die NDEF-Datei liefert die erwartete URL, der SDM-Zähler steigt und der CMAC ist frisch. Der Tag arbeitet also genau so, wie er soll. UID und CMAC sind hier gekürzt: Eine vollständige Scan-URL gehört nicht in einen Fachtext.

Jetzt derselbe Ablauf in einer einzigen Sitzung, ohne Feld-Reset dazwischen, also so, wie Android es macht:

# EINE Sitzung, kein Feld-Reset dazwischen: so macht es Android
> 90 60 00 00 00                      # GetVersion
< 04 04 02 30 00 11 05  91AF          # 9 Bytes, Kette OFFEN

> 00 A4 04 00 07 D2760000850101 00    # Select NDEF-Anwendung
< 6985                                # Conditions not satisfied

# neue Sitzung MIT echtem Feld-Reset
> 00 A4 04 00 07 D2760000850101 00
< 9000                                # liest sofort wieder

Die GetVersion-Antwort endet auf 91AF, das ist die Aufforderung, die Kette fortzusetzen. Genau diese neun Bytes sieht auch Android. Bricht man hier ab und wählt stattdessen die NDEF-Anwendung aus, antwortet der Chip mit 6985, „Conditions not satisfied". Er ist nicht defekt, er wartet auf die Fortsetzung.

Eine neue Sitzung mit echtem Feld-Reset liest sofort wieder. Damit ist die Ursache eingekreist: Nicht die Auswahl der Anwendung ist das Problem, sondern der Zustand, in dem der Chip vorher zurückgelassen wurde.

Was nicht hilft

Am Tag lässt sich das nicht beheben. ATQA und SAK, die die DESFire-Erkennung überhaupt erst auslösen, sind im Silizium festgelegt, und das GetVersion-Chaining ebenso. Keine SDM-Einstellung, keine andere Rechtevergabe auf den Dateien und kein anderer Speicherplan ändern daran etwas.

Auch eine kürzere URL oder ein anderes Mirror-Layout hilft nicht, denn der Fehler tritt ein, bevor die NDEF-Datei überhaupt gelesen wird.

Was tatsächlich hilft

• ›Ein echter Feld-Reset zwischen Probe und Auswahl. Das kann nur der NFC-Stack des Geräts, nicht die Anwendung.
• ›Ein Reader-Mode in der geöffneten App (Web NFC über NDEFReader.scan() oder der native Reader-Mode) umgeht die Zuordnung durch das Betriebssystem. Das setzt eine offene App voraus und taugt deshalb nicht für den kalten Tap.
• ›Ein Typ-2-Tag (NTAG21x) für den kalten Tap wird ohne DESFire-Umweg gelesen. Der Preis dafür ist hoch: Ein Typ-2-Tag beherrscht kein SDM und ist beliebig kopierbar. Wer einen Nachweis braucht, tauscht damit genau das weg, wofür der 424 im Einsatz ist.

Wie verbreitet ist das

Nachgemessen mit denselben Tags: Pixel 8 Pro zeigt den Fehler, Pixel 10 Pro mit dem Patch aus August 2026 ebenfalls, Pixel 9 Pro auf demselben Android 17 dagegen nicht. Es hängt also an Gerät und Firmware-Variante, nicht pauschal an einer Android-Version.

Außerdem ist es ein Rennen und kein harter Fehler: Einzelne Taps gelingen, wenn das Feld zwischendurch kurz abfällt. In einer kontrollierten Sitzung standen 8 von 8 Versuchen auf Fehlschlag. Wer gegenprüft, sollte deshalb nicht nach einem gelungenen Tap aufhören.

Stand bei Google

Der Befund liegt Google zweimal vor. Die erste Meldung vom 22.07.2026 wurde am 06.08. als „Won't Fix (Infeasible)" geschlossen, allerdings nicht aus technischen Gründen, sondern weil der angeforderte Bugreport nicht nachgereicht worden war. Inhaltlich bewertet wurde sie nie. Die zweite Meldung vom 16.08.2026 enthält den Bugreport und steht bislang ohne Rückmeldung.

Issue 547210633 im Google Issue Tracker

Ein zweiter, unabhängiger Stolperstein

Getrennt davon zu betrachten: Ist „Secure NFC" aktiv, liest ein gesperrtes Pixel überhaupt kein Tag. Im Log steht dann nur ON_LOCKED, eine Erkennung findet gar nicht erst statt. Das ist kein Fehler, sondern eine Einstellung, kostet aber jeden Ablauf, der davon lebt, dass ein Tap ohne Entsperren funktioniert.

Häufige Fragen