Warum erreicht ein Lesegerät eine andere Anwendung als Ihre?

Die Tabelle entscheidet zuerst

Der NFC-Controller hält eine Tabelle für die Weiterleitung: eine endliche Liste von Regeln, deren jede eine Kennung mit einem Ziel paart, dem Hauptprozessor, auf dem Anwendungen laufen, oder einem angeschlossenen sicheren Element. Sendet ein Lesegerät ein SELECT, paart der Controller die Kennung und schickt diesen Befehl und jeden danach an dieses Ziel, bis ein weiteres SELECT ankommt oder die Verbindung abreißt. Androids Leitfaden zur Kartenemulation beschreibt die Tabelle und sagt, dass Anwendungen sie nie einstellen; die Plattform baut sie aus den installierten Diensten und aus dem, was die Nutzenden gewählt haben.

Zwei Folgen ergeben sich. Teilweise Übereinstimmungen, die die ISO/IEC 7816-4 zulässt, unterstützt die Host Card Emulation von Android nicht, eine Kennung passt also ganz oder gar nicht. Und die Tabelle hat eine Größe, wobei der Leitfaden von Geräten verlangt, die von Ihrer Anwendung eingetragenen Kennungen an den Host zu leiten.

Wie Android einen Konflikt löst

Mehrere Dienste können dieselbe Kennung eintragen, und der Leitfaden gibt die Reihenfolge an. Die Anwendung, die die Rolle der Standard-Wallet hält, gewinnt, wenn sie die Kennung eingetragen hat. Andernfalls wird der einzelne Dienst aufgerufen, der sie eingetragen hat. Haben es mehrere getan, fragt Android die Nutzenden, welcher es sein soll.

Die Kategorie der Zahlung verengt das weiter. Es ist immer nur eine Gruppe für Zahlungen auf dem Gerät eingeschaltet, und eine Anwendung, die Zahlungskennungen einträgt, wickelt einen Vorgang nur ab Android 15 als Inhaberin der Rolle der Wallet ab, oder aus dem Vordergrund. Ein Verfahren, das bei einem einzigen Händler arbeitet, gehört in die andere Kategorie, deren Gruppen dauerhaft aktiv bleiben können und die nicht um diesen einen Platz streitet.

Eine Anwendung kann um die Rolle bitten, statt auf sie zu hoffen: RoleManager.ROLE_WALLET mit createRequestRoleIntent, und isRoleHeld, um zu wissen, wie sie steht.

Was eine Aktivität im Vordergrund ändert

setPreferredService benennt den Dienst, der zu bevorzugen ist, solange eine Aktivität fortgesetzt ist, und es kehrt die Auflösung oben um. Die Referenz zu CardEmulation verlangt es in onResume und unsetPreferredService in onPause, da das System die Vorliebe nicht aufbewahrt: Sie muss bei jeder Fortsetzung der Aktivität erneut gesetzt werden.

Der Aufruf scheitert in zwei Fällen, beide über die Zahlung. Wenn der Dienst Zahlungskennungen einträgt und die Nutzenden Anwendungen im Vordergrund nicht erlauben, den Standarddienst für Zahlungen zu übergehen. Und wenn er Kennungen der anderen Kategorie einträgt, die der Standarddienst für Zahlungen ebenfalls behandelt, unter derselben Wahl der Nutzenden. categoryAllowsForegroundPreference antwortet, bevor Sie es versuchen.

Was zu prüfen ist, wenn ein Antippen woanders landet

Fragen Sie die Plattform, was sie denkt. isDefaultServiceForCategory antwortet für eine Kategorie, aber die Referenz warnt, dass es immer falsch zurückgibt, wenn die Art der Auswahl immer fragen oder bei Konflikt fragen lautet; in diesen Arten ist isDefaultServiceForAid die Frage, die Sinn ergibt. getSelectionModeForCategory sagt Ihnen, in welcher Art Sie sind.

Schauen Sie dann außerhalb Ihrer Anwendung. Eine andere installierte Anwendung kann dieselbe Kennung eintragen, und ein Dienst außerhalb des Hosts kann sie für ein sicheres Element beanspruchen, in welchem Fall der Austausch nie irgendeinen Code auf dem Host erreicht. Die von Ihrem Dienst eingetragenen Kennungen zu lesen und sie mit dem zu vergleichen, was das Lesegerät auswählt, klärt die meisten dieser Fälle schneller, als darüber nachzudenken: Die Seite zur APDU behandelt das SELECT selbst.