从你描述的现象和提供的日志来看，这确实是Android底层NFC栈（具体是Broadcom方案的NFC驱动，日志里的BrcmNfcJni和libnfc_nci能佐证）在处理ISO15693多标签碰撞时的逻辑缺陷，和应用代码无关，属于系统级bug。

关键日志拆解 #

先梳理核心错误点：

E/BrcmNfcJni: nfaDeviceManagementCallback: chr_sub_error_no:7
E/libnfc_nci: [ERROR:nfa_dm_act.cc(888)] invalid protocol, mode or state
E/libnfc_nci: [ERROR:gki_ulinux.cc(693)] GKI TASK_DEAD received. exit thread 3...

• chr_sub_error_no:7 对应Broadcom NFC芯片的标签碰撞处理异常
• invalid protocol, mode or state 说明NFC设备管理模块在多标签扫描时进入了非法状态，状态机逻辑出现漏洞
• GKI TASK_DEAD 表示NFC核心任务线程直接终止，导致整个NFC服务瘫痪，必须重启才能恢复

你提到ISO14443-4标签无此问题，是因为两种标准的防碰撞机制完全不同：ISO15693采用时隙防碰撞，而ISO14443-4采用比特帧防碰撞，底层栈对前者的多标签场景处理没有做好边界覆盖。

可行的解决方向 #

• 优先向设备厂商提交bug反馈
  这是最根本的解决途径，因为底层NFC栈属于系统固件/驱动的一部分，普通开发者无法修改。提交时需要包含：

  • 设备型号（Honor 9、Samsung A51）及系统版本
  • 完整的Logcat日志（你提供的扫描+关闭NFC时的日志）
  • 精确的复现步骤：将两个ISO15693标签堆叠，用系统自带NFC扫描功能触发崩溃

• 应用层应急规避（针对自有NFC应用）
  虽然主屏幕扫描也会崩溃，但如果你的应用需要处理NFC场景，可以做以下尝试：

  1. 监测NFC服务状态：通过NfcAdapter的回调判断NFC是否异常，若检测到服务无响应，引导用户手动重启NFC（Android无公开API直接重启NFC，只能引导到系统设置操作）
  2. 限制扫描标签类型：如果业务不需要同时处理多个ISO15693标签，可以在应用中指定只扫描ISO14443-4标签，避免触发该bug

• 尝试系统更新
  检查设备是否有未安装的系统更新，厂商可能在后续固件版本中修复了这个NFC碰撞处理的bug。比如Samsung A51的One UI更新、Honor 9的EMUI更新，优先升级到最新稳定版再测试。

• 临时替代方案
  暂时避免堆叠ISO15693标签进行扫描，或者更换其他品牌的Android设备测试，确认是否是Broadcom方案NFC芯片的普遍问题，还是仅这两款设备的特定bug。

内容的提问来源于stack exchange，提问作者LostSoul