1

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.

S.Pols
  • 3,414
  • 2
  • 21
  • 42

1 Answers1

2

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.

Michael Roland
  • 39,663
  • 10
  • 99
  • 206
  • After your fantastic answer i read some things about the ISO standard and i do have one more (general) question about how the parts are related to each other. I understand the `NFC Forum Tag Type 4` sits on top of `ISO/IEC 14443-4` and `ISO/IEC 7816-4`. But i'm trying to understand what the `ISO/IEC 14443-4` parts specifies and what the `ISO/IEC 7816-4` specifies. Is it true that they are both specify a standard for communication between 2 devices? If it is, what is the difference between them and why would you use the one over the other? – S.Pols Aug 21 '14 at 11:46
  • And one question on the last part of your answer. If i send a command using APDU, for example `FF 00 00 00 07 D4 8E 48 65 6C 6C 6F 00)`, isn't that valid `ISO/IEC 7816-4`? Following the ACR122U manual i think it is correct if i compare it with the `ISO7816-4 APDU Format`. – S.Pols Aug 21 '14 at 11:56
  • 1
    *(1)* ISO/IEC 14443-4 defines a transport protocol (frames) that can carry protocol-data units and takes care about connection establishment and securing* the transmission layer. This transport protocol is also called ISO-DEP. ( *) In this context securing does *not* mean cryptography but making sure that packets are received by the other side by acknowledgment/resending mechanisms.) From your point of view, this protocol is completely transparent and handled by the NFC stack (on the Android side) and the PN532 NFC chip (on the ACR122U side). – Michael Roland Aug 21 '14 at 13:20
  • 1
    ISO/IEC 7816-4 defines an application protocol (application protocol-data units) that can be (and typically is) spoken over the ISO-DEP link. ISO/IEC 7816-4 is the same protocol that contact smartcards speak over their contact interface. So the idea is to abstract the actual communication link with the smartcard and to make communication inedpendent of the actual path that is used to communicate with the smartcard. The NFC Forum Type 4 Tag Operation specification is then built on top of that protocol. – Michael Roland Aug 21 '14 at 13:20
  • 1
    *(2)* That APDU is still in a valid format. However, you are right that the class byte is invalid according to ISO/IEC 7816-4. The idea behind the use of the class byte `0xFF` has its origin in the PC/SC standards (interface standards between smartcard readers and personal computers). There, this class byte is used to escape commands that should be interpreted by the smartcard reader and that are not sent to an actual smartcard (thus, the use of an otherwise invalid value). – Michael Roland Aug 21 '14 at 13:29
  • 1
    This is also the case with the ACR122U: That command is interpreted by the reader's microcontroller and converted into a command that is interpreted by the reader's PN532 NFC controller (that command is the part starting with D4...) – Michael Roland Aug 21 '14 at 13:29
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/59734/discussion-between-s-pols-and-michael-roland). – S.Pols Aug 21 '14 at 13:36
  • I responsed in the chat, are you ok with that? – S.Pols Aug 21 '14 at 13:54