Android 13问题 – NFC – HostApduService – Type 4标签

huangapple go评论68阅读模式
英文:

Android 13 problem - NFC - HostApduService - Type 4 Tag

问题

我在回应我的这个问题时写道,该问题已经成功解决:
https://stackoverflow.com/questions/74351717/how-to-substitute-nfcadapter-createndefmessagecallback-since-android-api-level-2

我正在使用Type 4标签操作与AdpuHostService来从一个Android设备发送NdefMessage到另一个Android设备。一切都在Android 11(即API级别30)上运行得很好。但自从客户将设备从Android 11升级到Android 13(API级别33)后,它不再起作用。

当我尝试调试时,似乎这个部分存在问题:

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. 选择APDU命令 - OK
  2. 选择CC APDU命令 - OK
  3. 读取CC文件命令 - 结果正常,但之后连接丢失

在我看来,NFC读卡器似乎不知道如何处理下面的响应,之后断开连接:

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

但这个响应根据官方文档 完全正确。可能的问题是什么?有没有办法调试NFC读卡器设备上接收到的ADPU响应的处理?

来自文档:
预期响应:

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

有什么想法可能出了什么问题?

更新:

到目前为止,我已经发现,当我将CC文件中的最大NDEF文件大小设置为7FFFh(即32767字节)时,它可以正常工作。但在文档中写明NDEF文件大小的有效值应在0005h至FFFEh之间。似乎第一个字节的值(7F)不是没有原因的大约半个字节(127)。

但我不知道为什么会这样。所以总结一下,当我发送这个响应时,它可以正常工作:

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

I am writing in response of this question of mine, that has been successfully resolved:
https://stackoverflow.com/questions/74351717/how-to-substitute-nfcadapter-createndefmessagecallback-since-android-api-level-2

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

答案1

得分: 2

Type 4标签文档中,您在问题底部的第5.1.2.1节中链接的内容提到:

NDEF文件的最大大小受ReadBinary和NDEF Update C-APDUs(请参见表16、表17、表22和表23)的Offset和Length Le字段的限制。NDEF文件的最大大小已减小到7FFFh + FFh = 80FEh字节。

因此,Android可能已经进行了错误修复,以匹配规范中定义的最大NDEF文件大小。

英文:

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.

答案2

得分: 1

The solution was to change r-apdu from:

00 11 20 FF FF FF FF 04 06 E1 04 FF FE 00 00 90 00

to:

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

Although I can't explain why, the first r-apdu works just fine with Android 11. The second works on Android 12 and 13. The only limitation of this solution is that the possible max. size of ndef file is not:

FFFEh -> 65534 bytes

but:

7FFFh -> 32767 bytes

So for larger data some kind of custom packet system is required.

英文:

The solution was to change r-apdu from:

00 11 20 FF FF FF FF 04 06 E1 04 FF FE 00 00 90 00

to:

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

Although I can't explain why, the first r-apdu works just fine with Android 11. The second works on Android 12 and 13. The only limitation of this solution is that the possible max. size of ndef file is not:

FFFEh -> 65534 bytes

but:

7FFFh -> 32767 bytes

So for larger data some kind of custom packet system is required.

huangapple
  • 本文由 发表于 2023年3月7日 18:47:06
  • 转载请务必保留本文链接:https://go.coder-hub.com/75660996.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定