cancel
Showing results for 
Search instead for 
Did you mean: 

Problems with ST25DV16K and Android 8.0

Hi ST Community,

I am having trouble to make a NDEF record in a ST25DV16k tag be recognized by Android 8.0, I already read both AN4910 and AN4911 and understood the limitations in Android 8.1 regarding the NDEF and CC headers, but my problem is that even when I clone the memory content from a working ST25DV04K tag into a ST25DV16K, the 16K tag is still not being recognized by the Android 8.1 smartphone, here are the memory contents of both tags:

0693W000007DO8rQAG.png 

0693W000007DO9VQAW.png 

As can be seen on the images, the whole content of the 04K tag was mirrored into the 16K tag, including the CC file and the NDEF header, so for all intents and purposes the 16K tag must be interpreted as a 512 Bytes tag, and the NDEF record (ST website) must be correctly identified, right?

The Android 8.0 phone correctly identifies the 04K tag record and opens the website, but when the 16k tag is presented it only gives the option to open ST25 app, showing that the NDEF record was not recognized by the android system.

In a smartphone with Android 10 both tags are correctly identified and the website is opened.

Could someone help to understand why I see this behavior?

Both tags have the same NFC command set, right? so they should not be treated differently by the Android system.

And if I set the CC file to limit the tag to 512bytes, the Android system should treat it as a 512 bytes tag, right?

Thanks in advance,

Best Regards

Gustavo

1 ACCEPTED SOLUTION

Accepted Solutions
Olivier L
ST Employee

Hi Gustavo,

Support of "NFC Type 5 Tags with Extended memory" has been added in Android 9. With earlier Android versions, it is not possible to read natively any NFC Tags with more than 2040 bytes of memory.

"And if I set the CC file to limit the tag to 512bytes, the Android system should treat it as a 512 bytes tag, right?"

Unfortunately, this workaround doesn't work. In Android versions earlier than Android 9, there is a piece of code that checks the size returned by the command getSystemInfo() and the size indicated in the CCFile. If those 2 sizes don't match, the Android stack raised an error and didn't go further. This is what is preventing from reading natively the content of a tag with extended memory (mem size > 2040 bytes).

If you can use a ST25DV04K you will not get this issue because it doesn't use extended memory. It will work with every Android versions.

For your information, when using a ST25DV16K or ST25DV64K, it is possible to develop an Android application. This application can set some filters in order to be notified when a Type5 tag is tapped. It can read the content of the tag and do the actions that you want.

Best regards

Olivier

View solution in original post

2 REPLIES 2
Olivier L
ST Employee

Hi Gustavo,

Support of "NFC Type 5 Tags with Extended memory" has been added in Android 9. With earlier Android versions, it is not possible to read natively any NFC Tags with more than 2040 bytes of memory.

"And if I set the CC file to limit the tag to 512bytes, the Android system should treat it as a 512 bytes tag, right?"

Unfortunately, this workaround doesn't work. In Android versions earlier than Android 9, there is a piece of code that checks the size returned by the command getSystemInfo() and the size indicated in the CCFile. If those 2 sizes don't match, the Android stack raised an error and didn't go further. This is what is preventing from reading natively the content of a tag with extended memory (mem size > 2040 bytes).

If you can use a ST25DV04K you will not get this issue because it doesn't use extended memory. It will work with every Android versions.

For your information, when using a ST25DV16K or ST25DV64K, it is possible to develop an Android application. This application can set some filters in order to be notified when a Type5 tag is tapped. It can read the content of the tag and do the actions that you want.

Best regards

Olivier

Hi Olivier,

Thanks for clarifying it, I was not aware of this lower level checking in Android 8 and below, now it makes sense.

In our case we need to continue using the 16K variant, as 512bytes would not be enough in some cases (we store some logs in NDEF records).

For now we will support only Adnroid 9+, if required later we will check this workaround of manually reading the memory, decoding NDEF, re-encoding and writing back.

Thanks for the support!