Interaction between android application and ACR122U in card emulation

Question

I have my ACR122U in card emulation mode and an Android application which has to start when the emulated tag is detected and send a message, for example: "Hello".

When emulate the tag and scan it with my phone it successfully opens the application by catching it with the android.nfc.action.TAG_DISCOVERED intent filter.

I have three questions about this situation.

Question 1

I read that the TAG_DISCOVERED has the lowest priority and you can't be sure your application will be selected after a tag discovery. Using card emulation, is the only way to catch an intent by using the android.nfc.action.TAG_DISCOVERED intent filter, or is there an other (better) way?

Question 2

I think this question is related to question 1. When i use the tgSetData command on the PN532 i gues i just send plain text to the android device. For example: FF 00 00 00 08 D4 8E 61 73 64 61 73 64 sends the string "asdasd". Is it also possible in card emulation to send a NDEF message or something similar? I suppose if that's possible Question 1 is answered to because you can use the NDEF intent filter.

Question 3

This question is about the application select part. From the first tgGetData i recieve the bytes 00 a4 04 00 07 d2 76 00 00 85 01 00. I read that this is the application select. I also noticed that won't get this procedure when the Android application is opened. I gues that's probably because the application is opened in the front. But how do i interact with this response when my application isn't in the front? My current interaction is this:

• getData D4 86
• Response = D5 87 00 00 A4 04 00 07 D2 76 00 00 85 01 01 00
• setData D4 8E 61 73 64 61 73 64 (just a random string)
• Response = D5 8F 00 90 00
• Use send- / getData to transmit data.

This doesn't work when the application isn't openend. Is this because this procedure is wrong or maybe my handling in Android is wrong?

Any information is welcome related to the questions.

Many thanks!

Regards.

Answer 1

Question 1

Using TAG_DISCOVERED with the foreground dispatch is perfectly fine. In that case your activity has priority over other apps and TAG_DISCOVERED is a simple catch-all mechanism.

However, you should normally not use TAG_DISCOVERED as an intent filter in your manifest. In that situation TAG_DISCOVERED acts as a fall back and catches only tags that were not handled by any other app's intent filters. (Actually TAG_DISCOVERED is there for backwards compatibility to the very limited first generation of the Android NFC API.)

In that case you could use the TECH_DISCOVERED intent filter in combination with a tech filter file for NfcA or/and IsoDep. (The ACR122U will emulate an ISO/IEC 14443-4 card (= IsoDep) on top of IOS/IEC 14443 Type A (= NfcA).)

Question 2

Sending an NDEF message is not that easy but using your emulated tag as NFC tag (that contains an NDEF message) can be done. The ACR122U emulates an ISO/IEC 14443-4 tag. Consequently, you would need to implement the NFC Forum Type 4 Tag Operation specification on the tag side in order to use the emulated tag as NFC Forum Type 4 tag that contains an NDEF message. See the NFC Forum's freely available specifications for further details. You may also want to have a look at ISO/IEC 7816-4 which defines the APDU-based protocol and the application structures that are used over the ISO-DEP transport protocol.

Once you implemented such a tag, you can, of course, use the NDEF_DISCOVERED intent filter.

Question 3

See ISO/IEC 7816-4 on how APDUs and smartcard application structures work. The command you receive from the Android device

00 A4 04 00 07 D2 76 00 00 85 01 01 00

is a SELECT command for the NFC Forum Type 4 Tag application (Version 1.1). An Android device will automatically isse that command (and usually some further commands, see the NFC Forum Type 4 Tag Operation specification) in order to check if the tag contains an NDEF message. When you receive such a command, you should answer with an appropriate status code according to ISO/IEC 7816-4 (e.g. 6A82 which means file or application not found).

While transfering non-standard (i.e. non ISO/IEC 7816-4) frames over ISO-DEP (like plain ASCII text in your case) works, I strongly recommend to adhere to ISO/IEC 7816-4 in order to work smoothly with Android devices.