NFC开发（一）——HCE基于主机的卡模拟简述

许多提供NFC功能的基于Android的设备已经支持NFC卡模拟。在大多数情况下，该卡由设备中的单独芯片模拟，称为 安全元件(Secure Element) 。无线运营商提供的许多SIM卡还包含安全元件(Secure Element)。

Android 4.4引入了另一种卡模拟方法，它不涉及SE，称为 基于主机的卡模拟 。这允许任何Android应用程序模拟卡并直接与NFC读卡器通话。本文档描述了基于主机的卡仿真（HCE）如何在Android上工作，以及如何使用此技术开发模拟NFC卡的应用程序。

当使用安全元件(Secure Element)提供NFC卡模拟时，将通过Android应用程序将要模拟的卡提供到设备上的安全元件(Secure Element)中。然后，当用户通过NFC终端握住设备时，设备中的NFC控制器将来自读卡器(NFC Reader)的所有数据直接路由到安全元件(Secure Element)。图1说明了这个概念。

安全元件(Secure Element)本身执行与NFC终端的通信，并且完全不涉及Android应用。交易完成后，Android应用程序可以直接查询SE的交易状态并通知用户。

当使用基于主机的卡仿真来仿真NFC卡时，数据将被路由到直接运行Android应用程序的主机CPU，而不是将NFC协议帧路由到SE。图2展示了基于主机的卡仿真如何工作。

NFC标准提供对许多不同协议的支持，并且可以模拟不同类型的卡。

Android 4.4支持当今市场上常见的几种协议。许多现有的非接触式卡已经基于这些协议，例如非接触式支付卡。这些协议也得到了当今市场上众多NFC读卡器的支持，其中包括Android NFC设备可以自己作为读卡器（请参见 IsoDep 课程）。这使您可以仅使用基于Android的设备在HCE周围构建和部署端到端NFC解决方案。

具体而言，Android 4.4支持基于NFC-Forum ISO-DEP规范（基于ISO / IEC 14443-4）的仿真卡，并处理ISO / IEC 7816-4规范中定义的应用协议数据单元（APDU）。Android只强制在Nfc-A（ISO / IEC 14443-3 Type A）技术之上模拟ISO-DEP。支持Nfc-B（ISO / IEC 14443-4 Type B）技术是可选的。所有这些规格的分层如图3所示。

Android中的HCE体系结构基于Android Service 组件（称为“HCE服务”）。服务的一个关键优势是它可以在没有任何用户界面的情况下在后台运行。这对于许多HCE应用程序来说非常合适，例如会员卡或公交卡，用户不需要启动应用程序即可使用它。相反，通过NFC读卡器轻敲设备将启动正确的服务（如果尚未运行）并在后台执行该事务。当然，如果有意义的话，您可以自由地从您的服务中启动额外的UI（例如用户通知）。

当用户将设备连接到NFC读取器时，Android系统需要知道NFC读取器实际想要与哪个HCE服务通话。这就是ISO / IEC 7816-4规范的出处：它定义了一种选择应用程序的方式，以应用程序ID（AID）为中心。一个AID最多由16个字节组成。如果您正在模拟现有NFC读卡器基础架构的卡片，那么这些读卡器所寻找的AID通常是众所周知的并且是公开注册的（例如Visa和MasterCard等支付网络的AID）。

如果您想为自己的应用程序部署新的读卡器基础结构，则需要注册您自己的AID。AID的注册程序在ISO / IEC 7816-5规范中定义。如果您要为Android部署HCE应用程序，Google建议按照7816-5注册AID，因为它可以避免与其他应用程序发生冲突。

在某些情况下，HCE服务可能需要注册多个AID才能实现某个应用程序，并且需要确保它是所有这些AID的默认处理程序（而不是组中的某些AID转到其他服务） 。

一个AID组是应该被OS视为一起归属的AID列表。对于AID组中的所有AID，Android会保证以下其中一项：

换句话说，没有中间状态，组中的一些AID可以路由到一个HCE服务，另一些AID可路由到另一个。

每个AID组都可以与一个类别关联。这允许Android按类别将HCE服务组合在一起，并且反过来又允许用户在类别的级别而不是AID级别设置默认值。通常，避免在应用程序的任何面向用户的部分提及AID：它们对普通用户没有任何意义。

Android 4.4支持两种类别: CATEGORY_PAYMENT （涵盖行业标准支付应用程序）和 CATEGORY_OTHER （对于所有其他HCE应用程序）。

要使用基于主机的卡仿真来模拟NFC卡，您需要创建一个 Service 处理NFC事务的组件。

您的应用程序可以通过检查 FEATURE_NFC_HOST_CARD_EMULATION 功能来检查设备是否支持HCE 。您应该 <uses-feature> 在应用程序清单中使用该标记来声明您的应用程序使用HCE功能，以及该应用程序是否需要运行。

Android 4.4带有一个便利的 Service 类，可以作为实现HCE服务的基础： HostApduService 类。

因此，第一步要扩大 HostApduService 。

HostApduService 声明了两个需要重写和实现的抽象方法。

processCommandApdu() 只要NFC读卡器将应用协议数据单元（APDU）发送到您的服务，就会调用它。APDU也在ISO / IEC 7816-4规范中定义。APDU是在NFC读卡器和您的HCE服务之间交换的应用级数据包。该应用级协议是半双工的：NFC读卡器会向您发送命令APDU，并等待您发送响应APDU作为回报。

如前所述，Android使用AID来确定读者想要与哪个HCE服务交谈。通常，NFC读卡器向您的设备发送的第一个APDU是“SELECT AID”APDU这个APDU包含读卡器想与之交谈的AID。Android从APDU中提取AID，将其解析为HCE服务，然后将该APDU转发给已解析的服务。

您可以通过返回响应APDU的字节来发送响应APDU [processCommandApdu()]( https://developer.android.com/reference/android/nfc/cardemulation/HostApduService.html#processCommandApdu(byte[] , android.os.Bundle))。请注意，此方法将在应用程序的主线程中调用，该线程不应被阻止。所以如果你不能立即计算并返回一个响应APDU，那么返回null。然后，您可以在另一个线程上完成必要的工作，并 sendResponseApdu() 在完成后使用 HostApduService 该类中定义的方法发送响应。

Android会继续将新的APDU从读取器转发到您的服务，直到：

在这两种情况下，你的类的 onDeactivated() 实现都是通过一个参数来调用的，这个参数指出了两者中的哪一个发生了。

如果您正在使用现有的读卡器基础架构，则需要实现读卡器在您的HCE服务中期望的现有应用程序级协议。

如果您正在部署您控制的新读卡器基础架构，则可以定义自己的协议和APDU序列。通常，尝试限制APDU数量和需要交换的数据大小：这样可以确保用户只需将设备通过NFC读取器持续一段时间即可。合理的上限约为1KB的数据，通常可以在 300ms 内交换。

您的服务必须像往常一样在清单中声明，但还必须在服务声明中添加一些附加件。

首先，为了告诉平台它是一个实现 HostApduService 接口的HCE服务 ，你的服务声明必须包含一个 SERVICE_INTERFACE 动作的 Intent Filter 。

另外，为了告知平台哪个AIDs组被这个服务请求，一个 SERVICE_META_DATA <meta-data>标签必须包含在服务的声明中，指向一个XML资源和关于HCE服务的附加信息。

最后，您必须将该 android:exported 属性设置为true，并且 "android.permission.BIND_NFC_SERVICE" 在服务声明中要求权限。前者确保服务可以被外部应用程序绑定。后者然后强制只有拥有该 "android.permission.BIND_NFC_SERVICE" 权限的外部应用程序 才能绑定到您的服务。既然 "android.permission.BIND_NFC_SERVICE" 是一个系统权限，这有效地强制只有Android OS可以绑定到你的服务。

这是一个 HostApduService 清单声明的例子：

这个元数据标签指向一个 apduservice.xml 文件。下面显示了具有包含两个专有AID的单个AID组声明的此类文件的示例：

该 <host-apdu-service>标签需要包含一个 <android:description> 属性，该属性包含可能在UI中显示的用户友好的服务描述。该 requireDeviceUnlock 属性可用于指定在调用此服务来处理APDU之前必须先解锁设备。

在 <host-apdu-service>必须包含一个或多个 <aid-group>标签。每个 <aid-group>标签都需要：

最后，您的应用程序还需要拥有 NFC 可以注册为HCE服务的 权限。

多个 HostApduService 组件可以安装在单个设备上，并且可以由多个服务注册相同的AID。Android平台根据AID属于哪个类别来解决AID冲突。每个类别可能有不同的冲突解决策略。

例如，对于某些类别（如付款），用户可能能够在Android设置UI中选择默认服务。对于其他类别，策略可能总是要求用户在冲突情况下调用哪个服务。要查询特定类别的冲突解决策略，请参阅 getSelectionModeForCategory() 。

应用程序可以使用[isDefaultServiceForCategory(ComponentName, String)]( https://developer.android.com/reference/android/nfc/cardemulation/CardEmulation.html#isDefaultServiceForCategory(android.content.ComponentName , java.lang.String))API 检查其HCE服务是否是某个类别的默认服务。

如果您的服务不是默认设置，则可以请求将其设置为默认设置。看 ACTION_CHANGE_DEFAULT 。

Android会将AID组为“payment”的类别，声明的HCE服务视为支付应用程序。Android 4.4版本包含一个名为“tap＆pay”的top-level设置菜单条目，它列举了所有这些支付应用程序。在此设置菜单中，用户可以选择在点按付款终端时将调用的默认支付应用程序。

为了提供更具视觉吸引力的用户体验，HCE支付应用程序需要为其服务提供额外的resource：所谓的服务标记。

这个asset的大小应该是260x96 dp，并且可以在元数据(meta-data)XML文件中通过添加指向drawable resource android:apduServiceBanner 的 <host-apdu-service>标签的属性来指定 。一个例子如下所示：

当设备的屏幕关闭时，当前的Android实施将NFC控制器和应用程序处理器完全关闭。因此，当屏幕关闭时，HCE服务将无法工作。

然而，HCE服务可以从锁定屏幕中起作用：这由HCE服务标记中的 android:requireDeviceUnlock 属性控制 <host-apdu-service>。默认情况下，不需要设备解锁，即使设备被锁定，您的服务也会被调用。

如果您将 android:requireDeviceUnlock HCE服务的属性设置为“true”，Android会提示用户在您靠近NFC读卡器时解锁设备，NFC读卡器会选择已解析为您的服务的AID。解锁后，Android会显示一个对话框，提示用户再次点击以完成交易。这是必要的，因为用户可能已经将设备从NFC读卡器移开以便解锁它。

本部分对于已经部署依赖SE进行卡模拟的应用程序的开发人员很感兴趣。Android的HCE实现旨在与其他实现卡仿真的方法并行工作，包括使用SE。

这种共存基于一种称为“AID路由”的原则：NFC控制器保留一个由（有限）路由规则列表组成的路由表。每个路由规则都包含一个AID和一个目的地。目标可以是主机CPU（Android应用程序正在运行的地方），也可以是连接的SE。

当NFC读卡器发送具有“SELECT AID”的APDU时，NFC控制器解析它并检查AID是否与其路由表中的任何AID匹配。如果匹配，那么APDU和其后的所有APDU将被发送到与AID相关联的目的地，直到收到另一个“SELECT AID” APDU或NFC链路断开。

图4说明了这种架构。

NFC控制器通常还包含APDU的默认路由。在路由表中找不到AID时，将使用默认路由。尽管此设置可能因设备而异，但Android设备需要确保您的应用注册的AID已正确路由到主机。

实现HCE服务或使用SE的Android应用程序不必担心配置路由表 - 这是由Android自动处理的。Android只需要知道哪些AID可以由HCE服务处理，哪些可以由SE处理。基于哪些服务已安装，以及哪些用户已配置为首选服务，路由表会自动配置。

我们已经介绍了如何声明HCE服务的AID。以下部分说明如何为使用SE进行卡模拟的应用程序声明AID。

使用SE进行卡模拟的应用程序可以在其清单中声明所谓的“关闭主机服务”。这种服务的声明几乎与宣布HCE服务相同。以下情况例外：

相应 apduservice.xml 文件注册两个AID 的示例：

该 android:requireDeviceUnlock 属性不适用于脱离主机服务，因为主机CPU不参与事务，因此无法阻止SE在设备锁定时执行事务。

该 android:apduServiceBanner 属性必须用于作为支付应用程序的关闭主机服务，以便作为默认支付应用程序进行选择。

Android本身永远不会启动或绑定到声明为“脱离主机”的服务。这是因为实际交易由SE执行，而不是由Android服务本身执行。服务声明仅允许应用程序注册安全元件(Secure Element)上存在的AID。

HCE体系结构本身提供了一个核心安全性：因为您的服务受到 BIND_NFC_SERVICE 系统权限的保护，所以只有 *** 作系统可以绑定到您的服务并与之通信。这可以确保您收到的任何APDU实际上都是OS从NFC控制器接收到的APDU，并且您发回的任何APDU只会发送到 *** 作系统，而 *** 作系统会直接将APDU转发给NFC控制器。

剩下的核心部分就是您获取应用程序发送给NFC读卡器的数据的位置。这在HCE设计中有意解耦：它不关心数据来自何处，它只是确保将其安全地传送到NFC控制器并传送到NFC读取器。

为了安全地存储和检索您希望从HCE服务发送的数据，例如，您可以依靠Android应用程序沙箱，将应用程序的数据与其他应用程序隔离。有关Android安全性的更多详细信息，请阅读 安全提示 。

这部分内容对于希望了解HCE设备在NFC协议的防冲突和激活阶段使用何种协议参数的开发人员很感兴趣。这允许构建与Android HCE设备兼容的读卡器基础结构。

作为Nfc-A协议激活的一部分，交换多个帧。

在交换的第一部分，HCE设备将呈现其UIDHCE设备应该被假定为具有随机的UID。这意味着在每个抽头中，呈现给读卡器的UID将是随机生成的UID。因此，NFC读卡器不应依赖HCE设备的UID作为身份验证或身份验证的一种形式。

NFC读取器可以随后通过发送SEL_REQ命令来选择HCE设备。HCE设备的SEL_RES响应将至少设置第6位（0x20），表示设备支持ISO-DEP。注意，SEL_RES中的其他位也可以被设置，表示例如对NFC-DEP（p2p）协议的支持。由于可以设置其他位，所以想要与HCE设备交互的读者应该明确检查第6位，并且<stront style="box-sizing: inherit">不要将完整的SEL_RES与值0x20进行比较。</stront>

Nfc-A协议激活后，NFC读取器启动ISO-DEP协议激活。它发送一个“RATS”（请求选择应答）命令。RATS响应（ATS）完全由NFC控制器生成，不能由HCE服务配置。然而，HCE实现需要满足NFC论坛对ATS响应的要求，因此NFC读卡器可以根据NFC论坛对任何HCE设备的要求设置这些参数。

以下部分提供了有关NFC控制器在HCE设备上提供的ATS响应的各个字节的更多详细信息：

请注意，许多HCE设备可能符合EMVCo联合的支付网络在其“非接触式通信协议”规范中指定的协议要求。尤其是：

如前所述，HCE实现仅支持单个逻辑通道。尝试在不同的逻辑通道上选择应用程序将不适用于HCE设备。

本文 翻译自 谷歌开发者文档，已由本人仔细校对。如有错误，请联系我，以便修改。

子小程序正式上线以来，微信的开发团队每周都会更新小程序，包括开发工具跟基础库的更新。可见腾讯对微信小程序的重视。看来腾讯立志要革新应用市场了。

今天要讲的是就在本月初，官方更新了小程序1.7.0基础库，这次一次就修复和更新了30个API，重要的是开放了今天要说的NFC功能。使用华为手机的应该都知道，可以使用自带的NFC刷地铁卡等。

NFC功能指近距离无线通信。在手机上使用NFC功能，可以实现以接触方式进行支付、连接、下载等功能。是由HCE技术实现的，所以小程序目前也仅支持HCE模式。

正在学习小程序的程序员不妨试试该功能，这绝对是小程序的一次重大革新，因为毕竟现在NFC技术使用的还不是太广泛，微信团队已经有了这方面的意识，不得不给这群技术人员一个大写的牛。

NFC是由RFID演变而来的一种近距离无线通信技术。它的最大优点是不需要麻烦的配对过程就能直接读取和交换数据，另外NFC的配对速度极快，平均速度远远小于0.1ms。NFC技术可以广泛应用于身份识别、打卡、门禁、支付、票据、数据传输等很多很多领域。

好了，知道了NFC的功能我们就知道小程序开放NFC我们能用小程序做哪些事情了（前提是用户手机有NFC功能，不过这越来越不是问题了）：

可以基于小程序实现无卡乘公交和地铁了！

打开两个有NFC功能的小程序可以互相传输文件了！

用户打开某小程序可以实现像Apply pay一样的近场支付了！

学习到原有门禁锁的信息后，用小程序可以开门禁和门锁了！

可以用触碰的方式直接免密连接WIFI了！

---