android - writeNdefMessage 中断 I/O 后 NFC Tag 变为 "corrupted"

Question

我们有一个与自定义硬件设备上的 NFC 标签通信的 Android 应用程序。硬件设备还可以对安装在其上的标签进行通信和操作。

Android 应用程序通过两种方式与 NFC 标签通信:

IsoDep#transceive(byte[])用于触发硬件设备的电源循环。

Ndef#writeNdefMessage(NdefMessage)用于编写带有一些用户数据的 NdefMessage/NdefRecord。

从功能上讲，这些操作类似于:

private static final byte[] NDEF_SELECT_APP_FRAME = new byte[] {
    (byte) 0x00, (byte) 0xA4, (byte) 0x04,                  
    (byte) 0x00, (byte) 0x07, (byte) 0xD2,                  
    (byte) 0x76, (byte) 0x00, (byte) 0x00,                  
    (byte) 0x85, (byte) 0x01, (byte) 0x01                   
}; 

private static final byte[] SYSTEM_FILE_SELECT = new byte[] {   
    (byte) 0x00, (byte) 0xA4, (byte) 0x00,                  
    (byte) 0x0C, (byte) 0x02, (byte) 0xE1,                  
    (byte) 0x01                                             
};                                                              

private static final byte[] TOGGLE_GPO = new byte[] {           
    (byte) 0xA2, (byte) 0xD6, (byte) 0x00,                  
    (byte) 0x1F, (byte) 0x01, (byte) 0x00                   
}; 

boolean recordSuccess = writeRecord(tag, intent, context);
if (recordSuccess) {
    boolean success = transceive(NDEF_SELECT_APP_FRAME, tag, context)
            && transceive(SYSTEM_FILE_SELECT, tag, context)
            && transceive(TOGGLE_GPO, tag, context);
    if (success) {
        // Success!
    } else {
        // Error!
    }
}

我们发现，在写入 Ndef 数据时，I/O 似乎有可能在极少数情况下被中断(我们不确定为什么，但我们假设在正确的时间将手机从标签上拉开是原因)。这似乎导致标签处于类似“损坏”的状态，在该状态下无法再在标签上找到以前的 Ndef 数据。事实上， tag.getTechList()甚至不会列出 Ndef作为标签上的可用技术，尽管它最初是可用的。

将 Ndef 数据写入标签的所有进一步尝试都将失败，因为 Ndef.get(tag)将返回 null .

据我所知，从这一点开始的正常程序是使用 NdefFormatable 重新格式化标签。 .但是， NdefFormatable未在 tag.getTechList() 中列为技术类型，等等 NdefFormatable.get(tag)也返回 null .

问题:

为什么标签似乎被损坏/删除了？

为什么 Ndef 在损坏后没有被列为标签技术，即使标签最初支持它？

鉴于 NdefFormatable.get(tag)，我们如何才能从这种状态中恢复？似乎返回 null ?

编辑: NFC 芯片似乎是 M24SR04-Y。规范表可在此处找到: https://www.st.com/resource/en/datasheet/m24sr04-g.pdf .

TagInfo 应用程序显示的能力容器内容:

# Capability Container (CC) file content:
Mapping version 2.0
CC length: 15 bytes
Maximum Le value: 246 bytes
Maximum Lc value: 246 bytes
NDEF File Control TLV:
* Length: 6 bytes
* NDEF file ID: 0x0001
* Maximum NDEF data size: 512 bytes
* NDEF access: Read & Write
[0] 00 0F 20 00 F6 00 F6 04 06 00 01 02 00 00 00    |.. ............ |

Answer 1

在浏览了您共享的数据表后，以下是我的观察:

0xE103 : CC 文件

0x0001 : NDEF 文件

CC 文件对 RF 和 I2C 都是只读的

最大 NDEF 文件大小:512 字节

读写:免费访问

一次操作可以读取或写入的最大字节数:246 字节

假设 CC 内容从未改变:
00 0F 20 00 F6 00 F6 04 06 00 01 02 00 00 00:15字节

引用您分享的操作代码 fragment :

你在 TOGGLE_GPO 中做什么？ session 打开、WIP 还是 MIP？

我怀疑卡在此阶段中断时会进入类似损坏的状态

假设您没有在 writeRecord() 中修改 CC 文件内容。

如果可能，请分享您正在执行的每个步骤的低级细节，这将有助于更好地理解。

更新:

现在已经排除了损坏 CC 的可能性，下一步将对 NDEF TLV 执行相同的操作，尤其是 NDEF 文件 ID Max 所在的 V block 。通过比较 Working 和 Corrupted 状态值来存储 NDEF 大小和 NDEF 文件的读/写访问权限。

确定发生错误时卡进入损坏状态的步骤。这可以通过记录每一步来实现。如果卡在特定步骤中一直被中断损坏，那么它将缩小搜索范围。

当卡处于损坏状态时，尝试设置 StateControl。这只是一个随机的想法，但可能会有所帮助。

干杯!