androidtagsnfcapduhce

Android 13 problem - NFC - HostApduService - Type 4 Tag

I am writing in response of this question of mine, that has been successfully resolved: How to substitute NfcAdapter.CreateNdefMessageCallback since android API level 29?

I am using Type 4 Tag Operations with AdpuHostService to send a NdefMessage from one Android device to another. Everything worked just fine with version Android 11 (i.e. API level 30). But since the client updated the devices from Android 11 to Android 13 (API level 33) it no longer works.

When I have tried to debug it, it seems there is problem in this part:

ProcessCommandApdu | incoming commandApdu: 00A4040007D276000085010100
C_APDU_SELECT | response: 9000
ProcessCommandApdu | incoming commandApdu: 00A4000C02E103
C_APDU_CAPABILITY_CONTAINER_SELECT | response: 9000
ProcessCommandApdu | incoming commandApdu: 00B000000F
C_APDU_READ_CAPABILITY_CONTAINER | response: 000F20FFFFFFFF0406E104FFFE00FF9000
OnDeactivated | reason: LinkLoss
  1. select apdu command - OK
  2. select CC apdu command - OK
  3. read CC file command - result ok, but after that the link is lost

It seems to me that the nfc reader doesn't know what to do with this response below and after that disconnects:

00 0F 20 FF FF FF FF 04 06 E1 04 FF FE 00 00 90 00

But the response is considering the official documentation completely fine. What could be the problem? Is there any way how to debug processing received adpu responses on the nfc reader device?

From documentation: Expected Response:

00 0F 20 00 3B 00 34 04 06 E1 04 00 32 00 00 90 00

Any idea what could be wrong?

UPDATE:

So far I have found out that when I set the max. ndef file size in CC file to 7FFFh (i.e. 32767 bytes) it works. But in the documentation there is written that the ndef file size value is valid between: 0005h to FFFEh. It seems that the value of the first byte (7F) is not without a reason just about the half of a byte (127).

But I have no clue why it is like this. So to sum this up, when I send this response, it works just fine:

00 0F 20 00 3B 00 34 04 06 E1 04 7F FF 00 00 90 00

Solution

  • In the Type 4 Tag documentation you linked in the question at the bottom of Section 5.1.2.1 it says

    The maximum size of the NDEF file is limited by the Offset and Length Le fields of ReadBinary and NDEF Update C-APDUs (see Table 16, Table 17, Table 22, and Table 23). The maximum size of the NDEF file is reduced to 7FFFh + FFh = 80FEh bytes.

    So Android have probably made a bug fix to match the max NDEF file size defined in the spec.