如何成熟的是Android的NFC ISODep支持？ [英] How mature is the Android NFC ISODep support?

问题描述

据我所知，这是一个讨论的话题，有没有明确的答案，但我真的想使用IsoDep使用APDU帧的DESFire卡的通信进行开发时，NFC应用服务的Andr​​oid，尤其是期待一些反馈。

I understand that this is a "discussion" topic that has no definite answer, but I would really like some feedback on what to expect when developing NFC APPs for Android, in particular using IsoDep to communicate with DESFire cards using APDU frames.

• 在我能想到的是发送给特定的DESFire卡相同的APDU帧相同的跨Android设备和版本？
响应
• 什么的Andr​​oid版本和设备要我考的最低限度要合理地覆盖？
• 是它在Android驱动程序的bug或回归普通或我可以预期，这些都是前铲除了很长时间？
• 什么是机器人的最早版本为你推荐支持，以避免太麻烦了？

到目前为止，我的经验是出奇的混合（3器件，3分歧），我真的想从其他开发商的消息。 例如：同样的APDU命令是在S3（安卓4.1.2）的工作不上S4（安卓4.3）（错误的长度失败3日autenticate握手，一切就OK了到那时）工作。这些手机有不同的NFC的芯片组，但我没想到APDU帧的抽象水平的差异。

So far my experience has been surprisingly mixed (3 devices, 3 differences) and I would really like to hear from other developers. For example: The same APDU commands that work on a S3 (Android 4.1.2) does not work on an S4 (Android 4.3) ("wrong length" failure on the 3rd autenticate handshake, everything OK until then). These phones have different NFC chipsets, but I did not expect differences on the abstraction level of APDU frames.

推荐答案

这确实是一个讨论的话题，我仍然认为这是有关Android的NFC开发者和我将thereofre，给我的体验报告在这里：

This is indeed a discussion topic, still I think it's relevant to Android NFC developers and I will, thereofre, give my experience report here:

• 我能想到的是发送给特定的DESFire卡相同的APDU帧相同的跨Android设备和版本？
响应

是的，但仅适用于符合ISO / IEC 7816-4的一些额外的限制要求（例如，不是所有的设备都支持扩展长度的APDU，有些设备似乎有问题的情况下-1的APDU）的APDU命令。

Yes, but only for APDU commands that fulfill the requirements of ISO/IEC 7816-4 with some additional restrictions (e.g. not all devices support extended length APDUs, some devices seem to have problems with case-1 APDUs).

还有一些在博通NFC堆栈的最新版本的一些已知缺陷（见下文）。

Also there are some known bugs in the latest version of the Broadcom NFC stack (see below).

• 什么的Andr​​oid版本和设备我应该测试作为最低限度，以合理盖好？

最多的问题，我经历至今是三星的设备与Broadcom的NFC芯片。虽然不是APDU相关的，特别是当它涉及到使用MIFARE经典，他们表现得不同于其他设备与Broadcom的芯片组。例如，该块S4的MIFARE经典标记在系统的含量，因此，不允许读取标签（N）的UID。 （从MF经典诵读的数据是不可能与Broadcom的芯片组反正...）

The most problems I experienced so far were with Samsung devices with the Broadcom NFC chipset. Though not APDU-related, particularly when it comes to using MIFARE Classic, they behave quite differently than other devices with Broadcom chipset. For instance the S4 blocks MIFARE Classic tags at system level and, therefore, does not permit to read the tags (N)UID. (Reading data from MF Classic would not be possible with Broadcom chipsets anyways...)

对于测试，我因此建议至少一个的Nexus设备的每个NFC控制器（即，一个与恩智浦的芯片组和一个与Broadcom芯片组）和同为一个或两个其他的手机制造商。 （对于三星与恩智浦芯片组的设备表现得非常类似的Nexus设备，所以我想你了Nexus S / Galaxy Nexus的和EG的S3可以当它涉及到的NFC读/写器模式的经验被看作是等价的。）

Regarding testing, I would therefore suggest at least one Nexus device for each NFC controller (i.e. one with NXP chipset and one with Broadcom chipset) and the same for one or two other handset manufacturers. (For Samsung the devices with NXP chipset behave very similar to the Nexus devices, so I guess you the Nexus S/Galaxy Nexus and e.g. the S3 can be seen as equivalent when it comes to the NFC reader/writer mode experience.)

对于Android的平台，我会坚持到那些您拥有用户最多的平台。 （也就是您必须卸载的率高平台。）

Regarding Android platforms I would stick to those platforms on which you have the most users. (And also those platforms where you have high rates of uninstalls.)

• 它是常见的在Android驱动程序的bug或回归，或我可以预期，这些都是前铲除了很长时间？

正如我meantioned之前，也有一些已知问题与博通NFC协议栈。特别是当它涉及到MIFARE DESFire非，还有的是，NFC协议栈后的发送任意APDU的命令，可卡的将它传递给一个应用程序的已知问题。因此，这些命令可能会干扰卡和应用程序之间的持续沟通（如力APDU为基础的通信方式，而不是本机命令模式，改变应用程序/文件选择，等等）。看到这个 bug报告这<一href="http://stackoverflow.com/questions/19589534/android-nfc-communication-with-mifare-desfire-ev1">stackoverflow问题进一步的细节。

As I meantioned before there are some known issues with the Broadcom NFC stack. Particularly when it comes to MIFARE DESFire, there is a known problem that the NFC stack sends arbitrary APDU-based commands to the card after passing it to an app. As a consequence, those commands may interfere with ongoing communication between the card and that app (e.g. force APDU-based communication mode instead of native command mode, change application/file selection, etc). See this bug report and this stackoverflow question for further details.

和翻翻<一个href="http://$c$c.google.com/p/android/issues/list?can=2&q=nfc&sort=-id&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars&cells=tiles"相对=nofollow> bug跟踪系统，肯定有更多的悬而未决的问题。

And looking through the bug tracker, there are definitely more unresolved issues.

• Android是什么，你推荐支持，以避免太麻烦了最早的版本？

对于APDU为基础的通信（带的DESFire或与其它卡），API 10（安卓2.3.3）和后来的工作没关系。当涉及到NFC API的可用性（除了简单的APDU交换）和漂亮的应用程序的设计，我会坚持到Android 4.0.3及更高版本。但是，请记住，最新的平台特别的Andr​​oid 4.3和Android 4.4引入了许多奇怪的行为/错误/（特征？）。

With regard to APDU-based communication (with DESFire or with other cards), API 10 (Android 2.3.3) and later work okay. When it comes to usability of the NFC API (besides simple APDU exchange) and to nice app design, I would stick to Android 4.0.3 and later. But keep in mind that the newest platforms particularly Android 4.3 and Android 4.4 introduced many odd behaviors/bugs/("features"?).

要得到什么的Andr​​oid版本的用户提供NFC设备目前拥有的，我给大家介绍了当前设备安装分布的 NFC TagInfo 的（尽管这可略微偏向作为NFC TagInfo不用于普通用户）：

To get a feeling for what Android versions users with NFC devices currently have, I'll share the current device installs distribution for NFC TagInfo (though this may be slightly biased as NFC TagInfo is not intended for the average user):

1. Android的4.1：36％
2. Android的4.3：21％
3. Android的4.2：19％
4. Android 4.4系统：18％
5. 的Andr​​oid 4.0.3 - 4.0.4：4％
6. 的Andr​​oid 2.3.3 - 2.3.7：2％
7. 的Andr​​oid 4.0 - 4.0.2：0％
8. 安卓3.2：0％

这篇关于如何成熟的是Android的NFC ISODep支持？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！