我们正在开发一款基于Android HCE的应用程序。我们发现 HCE 使用基于 AID 的机制将通信路由到特定应用程序。这意味着如果我想触发我的应用程序，第一个命令必须是按名称选择命令。
这对于传输域来说是一个非常大的限制。在传输中，许多 POS 不会发送 SELECT by name 命令作为第一个命令。相反，他们会发送 SELECT MF (
00A40000023F00有计划增加默认选择功能吗？或者我们有其他解决方案来支持这个用例吗？
Android 使用基于 AID 的路由机制将卡模拟模式下的通信调度到特定应用程序（HCE 应用程序或 SE 小程序）。这也是 NFC 论坛设计的在单个 NFC 设备上支持多个独立卡模拟应用程序的主要手段。
基于 AID 的路由要求第一个命令是 SELECT（按 DF 名称/AID）命令：
00 A4 0400[ ]
为了区分不同的应用程序，这是必要的。否则，Android 将无法将通信分派到正确的 HCE 服务。
但是，这也会阻止在成功选择应用程序之前模拟任何内容（例如使用 SELECT（按文件名等）命令选择主文件）。如果允许这样做，Android 将无法知道哪个 HCE 应用程序负责处理该命令。因此，不可能在一台设备上托管所有都需要主文件的多个 HCE 应用程序。因此，我预计不会很快得到支持。
在其他多应用平台上也存在同样的问题。例如，典型的 Java Card 智能卡也没有主文件。在这些平台上，通常通过允许一个默认选择的应用程序在第一个 SELECT（通过 DF 名称/AID）命令之前处理所有通信来解决该问题。人们只能推测这样的机制是否会出现在未来的 Android 版本中……我不会指望它。
如果可以选择已取得 root 权限的设备，您也许可以使用 Xposed 之类的框架来调整 NFC 系统服务，以将通信调度到某些默认的 HCE 服务。
我也遇到过和你描述的情况一样的情况。不幸的是，经过几个小时的挖掘，我发现官方文档显示：
NFC 控制器通常还包含 APDU 的默认路由。 当路由表中没有找到AID时，默认路由为 使用过。
当 NFC 控制器收到代表“00A40000023F00”的 APDU 时，会将 Lc（即“3F00”）之后的部分视为 AID。但是，您不能为 HCE 服务设置短于 5 个字节的 AID 过滤器，否则 Android 将引发异常。因此，NFC 控制器发现“3F00”没有路由目标，然后将 APDU 引导至所谓的“默认路由”。
在图 4 中，正如您所看到的，每个 APDU 都通过 NFC 控制器进行处理，无论它来自内部还是外部。当存在“未知 AID”APDU 时，由 NFC 控制器决定路由规则，这是默认路由。我想说，NFC 控制器如何路由 APDU 已集成到硬件中，否则可能无法在 Android 开发中进行编程。
对于交通，Visa 使用其应用 qVSDC 应用程序作为离线解决方案。它为离线数据认证提供特定的公钥，以限制运输上的交易。因此，Visa 的默认选择是 A0000000031010，而不是特定的交通 AID。但Visa提供多种AID支持，这意味着您可以开发2.应用程序用于交通。 您必须个性化您的应用程序以响应特定的“选择 AID”命令。