简介面向Android开发者的NFC身份证读取项目源码包解决在安卓平台上通过NFC近场通信读取二代身份证信息并借助云端完成解码的实战需求适合有Android基础、正在研究身份证识别或NFC应用的开发者参考。压缩包共458个文件体积15.41MB内含Java源码与Gradle构建脚本如build.gradle、gradlew、Android Studio工程配置.xml、.iml、.properties以及编解码相关的.aar、.jar库文件另有大量构建缓存和二进制资源结构完整可直接导入工程分析。目前已有3609人学习浏览具备不错的参考热度。该工程展示NfcAdapter、Tag等API调用并包含云解码服务、网络请求封装、身份证信息格式化与安全处理等模块可帮助读者理解从NFC标签读取到云端解析的完整链路掌握项目集成与安全加固思路适合用于酒店入住、会议签到等身份验证场景的二次开发。1. 安卓NFC读身份证源码先认清能读到的到底是哪一层数据做移动端几年几乎每隔一段时间就有人问“能不能直接用安卓手机NFC读身份证把姓名和照片读出来做自动登记”。我的第一反应通常是可以读但普通App能拿到的只有卡片的物理ID而不是身份证里的明文信息。第二代身份证用的是ISO 14443 Type B协议卡内文件系统受到安全状态和密钥保护直接刷手机App只能读到类似“PUPI”的物理序列号。这个物理ID可以用于防伪比对、门禁判断、设备绑定但读不出“张三身份证号110……”那部分。本文给你一套能直接跑的安卓NFC读身份证源码思路同时把边界、参数和踩坑点讲清楚适合正在评估门禁App、访客登记或者需要判断“这卡是不是真的身份证”的开发者。如果你只是想要一个能稳定读明文信息的方案坦白说普通商用手机做不到。必须外接触摸读卡器或依赖系统级安全单元。但如果你需要的是“识别出这是一张身份证并且拿到一个稳定的卡片唯一码”那下面这套代码已经够用。2. 从 ISO 14443 Type B 到安卓 NFC API读身份证前的理论课与准备动作2.1 身份证为什么采用 Type B 而不是 Type A日常见到的门禁卡、公交卡大多是ISO 14443 Type A像Mifare Classic、Mifare DESFire都走Type A。而第二代身份证走的是Type B两者在物理层上的调制和防冲突机制不一样。简单说Type A用100%ASK调制抗冲突逻辑用比特帧Type B用10%ASK调制抗冲突用的是时隙ALOHA方式。Type B在多卡同时靠近的场景下碰撞概率更低也更容易控制信号功率所以被选中做高安全性的身份证件。对安卓开发者而言最关键的区别是系统区分NfcA和NfcB两类Tag技术。身份证不会被识别成Mifare而是NfcB或者更高层的IsoDep。你如果按NfcA的方式去读大概率得到一堆乱码或Tag Lost。我这里有个习惯拿到Tag对象后第一步先打印所有TechList看看有没有NfcB、IsoDep再决定后续指令。另一个概念是PUPIPseudo-Unique PICC Identifier可以理解为卡片在Type B协议层里的物理序列号长度一般是4字节。有些文档也叫它Card ID或CID但要注意它跟PC读卡器读出来的8字节“身份证UID”往往是不同的字段。我们后面做代码解析时会区分这一点避免拿两个ID比兑半天对不上。2.2 支持哪些设备与系统版本能够顺利跑通读身份证物理ID并不是所有安卓手机都能顺利做。首先硬件必须有NFC且系统没有把NFC功能裁剪掉。国产定制系统里有的ROM对NfcB支持不完整导致某个型号手机永远连不上身份证。我一般建议准备两台以上的手机做交叉测试一台原生系统更接近的Pixel一台国产主力机。系统版本方面Android 4.4就有NfcB和IsoDep API但实际推荐Android 8.0及以上。Android 12开始NFC权限和ReaderMode行为有变化后面避坑章节会单独说。芯片厂商方面恩智浦方案兼容性最好部分使用其他NFC芯片的手机会出现“能发现标签但连不上IsoDep”的情况别急着骂代码先换台手机验证。开发阶段建议把NFC默认支付设置为“不启用”或者不要安装会抢占NFC读卡的应用否则系统钱包很可能在贴卡瞬间弹出支付界面你的App根本收不到Tag事件。2.3 Manifest 权限与前台调度配置在AndroidManifest.xml里至少要声明uses-permission android:nameandroid.permission.NFC / uses-feature android:nameandroid.hardware.nfc android:requiredtrue / uses-permission android:nameandroid.permission.READ_PHONE_STATE /READ_PHONE_STATE只是部分机型在读取某些卡信息时需要不是必须。如果你的App只需要NFC可以不申请。更重要的其实是android:launchMode和前台调度很多开发者把Activity设置成singleTop然后忘掉onNewIntent导致每次贴卡都新开页面。NFC标签发现有两种方式一种是系统通过NDEF回调拉起Activity另一种是调用NfcAdapter.enableReaderMode自己做回调。读身份证物理ID建议用后者因为ReaderMode可以绕过NDEF解析直接拿到Raw Tag对象延迟更低。Manifest里的uses-feature写requiredtrue后不支持NFC的设备会直接被应用商店过滤。如果你还要让应用在平板上跑又要兼容没有NFC的设备可以改成requiredfalse代码里再判断NfcAdapter是否为空。3. 用 enableReaderMode 读取身份证物理 ID可直接复制的 Kotlin 代码3.1 注册 ReaderMode 并监听 Tag 发现这一节给出一套最小可用代码。先拿到NfcAdapter然后注册ReaderMode回调里拿到Tag对象。建议在onResume里开启在onPause里关闭避免页面不可见时还占用NFC资源。private lateinit var nfcAdapter: NfcAdapter override fun onResume() { super.onResume() nfcAdapter NfcAdapter.getDefaultAdapter(this) ?: run { Log.e(NfcReader, 设备不支持 NFC) finish() return } if (!nfcAdapter.isEnabled) { Log.w(NfcReader, NFC 未打开) // 跳系统设置让用户手动开启 startActivity(Intent(Settings.ACTION_NFC_SETTINGS)) return } val options Bundle().apply { putInt(NfcAdapter.EXTRA_READER_PRESENCE_CHECK_DELAY, 100) } nfcAdapter.enableReaderMode( this, object : NfcAdapter.ReaderCallback { override fun onTagDiscovered(tag: Tag) { handleTag(tag) } }, NfcAdapter.FLAG_READER_NFC_B or NfcAdapter.FLAG_READER_SKIP_NDEF_CHECK or NfcAdapter.FLAG_READER_NO_PLATFORM_SOUNDS, options ) } override fun onPause() { super.onPause() nfcAdapter.disableReaderMode(this) }上面的Flags里FLAG_READER_NFC_B是必须的因为身份证走Type B。FLAG_READER_SKIP_NDEF_CHECK用来跳过NDEF标签的NDEF检查减少贴卡后的响应时延。FLAG_READER_NO_PLATFORM_SOUNDS可以关掉系统默认提示音防止门禁场景里“哔”一声吵到别人。EXTRA_READER_PRESENCE_CHECK_DELAY表示检测卡片离开的轮询间隔单位毫秒这里的100表示每100ms检查一次。3.2 从 Tag 提取 Type B 芯片 ID 并解析十六进制在handleTag里先打印tag.techList然后通过IsoDep.get(tag)获取一个ISO-DEP通道。身份证本身实现了ISO 14443-4所以IsoDep是首选而不是直接用NfcB。连接成功后tag.id就是系统NFC控制器对这张卡片的标识字节数组不同手机可能返回不同长度但大多数情况下是4到8字节。private fun handleTag(tag: Tag) { val techList tag.techList Log.d(NfcReader, techList: ${techList.joinToString()}) val isoDep IsoDep.get(tag) if (isoDep null) { Log.e(NfcReader, 该标签不是 ISO-DEP 卡片) return } try { isoDep.connect() val rawId tag.id ?: ByteArray(0) val hexId rawId.joinToString() { byte - String.format(%02X, byte) } Log.d(NfcReader, 物理ID(hex): $hexId 长度: ${rawId.size}) // 把 hexId 交给业务层做后续判断 isoDep.close() } catch (e: IOException) { Log.e(NfcReader, 连接/通信失败: ${e.message}) } }这里有一个很多人会踩的误区tag.id不是从APDU指令里读出来的而是NFC控制器在防冲突阶段缓存的。它是给操作系统和应用层做标识用的并不保证等价于卡内的固定证件编号。你需要先在台架测试里确认某款手机的tag.id是否稳定。我试过某款手机会在每次贴近后返回相同ID但另一款手机在卡片移开再贴近后返回不同ID这个情况后面避坑章节会展开。3.3 把 PUPI 转成语义信息区分厂商与卡片类型拿到hexId之后很多业务只需要判断“是不是身份证”。身份证芯片的类型代码往往带有较明显的字节特征但这里不能给出具体码值因为不同批次芯片可能存在差异。我一般做法是拿一张已知真卡做标定记录它返回的物理ID长度和首字节范围然后写一个白名单规则。fun isLikelyIdCard(hexId: String): Boolean { return hexId.length 8 hexId.startsWith(A0) // 示例前缀需替换为你实测到的真卡前缀 }注意上面的前缀只是示例。真正的判断逻辑要基于你自己的样本集。大量应用只关心“能不能识别出身份证”这时可以结合Type B返回的ATQA特征来做。Android没有直接暴露ATQA的API但tag.id的字节分布可以在一定程度上反映芯片厂商信息。如果你需要更高精度的卡型识别就需要走NfcB的transceive发送指令进入协议层探测这个我们下一章细说。这里血的教训是不要把判断逻辑写死成“长度等于4字节就是真卡”。我遇到过一个翻车案例某开发者的应用用长度判断身份证结果一个门禁卡也返回了4字节ID导致门禁系统把门禁卡当身份证放行了虽然只是Demo但后续改判断逻辑花了半天。4. 从物理 ID 到明文身份信息APDU 实验与安全边界解读4.1 ISO 7816-4 APDU 在身份证上的真实行为物理ID只能证明“存在这么一张Type B卡片”但要读取姓名、照片这类应用数据必须向卡片发送APDU指令。身份证的传输层遵循ISO 7816-4所以常规的SELECT、READ BINARY指令在命令格式上是标准的。Android里的IsoDep可以直接做APDU收发不像读Mifare那样要自己做块寻址。一个常见的尝试是选择某个文件标识符然后读取内容。这里我写一个尽可能通用的APDU封装方便你试验fun transceiveApdu(isoDep: IsoDep, apdu: ByteArray): ByteArray { val raw isoDep.transceive(apdu) // 解析响应最后两个字节是槽码 SW1 SW2 val sw1 raw[raw.size - 2].toInt() and 0xFF val sw2 raw[raw.size - 1].toInt() and 0xFF val data raw.copyOfRange(0, raw.size - 2) Log.d(NfcReader, SW%02X%02X 数据长度%d, sw1, sw2, data.size) if (sw1 0x90 sw2 0x00) { return data } throw IOException(命令失败: $sw1$sw2) } val selectFile byteArrayOf( 0x00, 0xA4.toByte(), 0x04, 0x00, 0x02, 0x00.toByte(), 0x01.toByte() )上面这条00 A4 04 00 02 00 01是选择文件标识符的思路具体文件ID因卡种而异。身份证的目录结构不是公开字段App在没有密钥的情况下发送这类命令大概率返回6982安全状态不满足或6D00指令不支持。这不是代码问题而是卡片的安全策略生效了。你要做的是记录这些返回码用来判断当前卡片是否需要额外的安全认证。4.2 为什么必须依赖读卡器或安全单元安全模块与密钥身份证里的明文数据存储在受控文件系统中门禁要读身份信息通常要调用一个独立的安全模块这个模块内部有运算密钥并且模块本身经过认证。普通安卓手机里没有这个安全模块所以无论你怎么改APDU都无法绕过卡片安全机制。市面上所谓“安卓NFC读身份证源码”绝大多数是指读取物理ID的演示Demo。如果某个项目宣传“直接刷手机自动读取姓名和身份证号”你要提高警惕要么它用的是外接读卡器要么它就是读取eID后者也需要系统级协同。业务真的需要明文信息时常见做法是配一个符合行业规范的蓝牙读写器手机App与读写器通信由读写器内的安全模块完成鉴权。我做项目时的选择标准是门禁只需要“这张卡是不是合法身份证”时读物理ID就够了。需要姓名和照片做实名制时直接上认证读卡器不要试图用手机NFC去碰明文数据既不现实也不合规。这里不展开政策评价单从工程可行性讲手机里的普通NFC通道拿不到那些字段。4.3 通过卡外行为判断“读身份证”方案的可行性如果你的产品已经过了概念验证但还在选型可以画一张决策表确认是否存在稳定的物理ID、是否支持区分身份证与普通Type B门禁卡、是否对响应时间有要求。这三个点如果都满足读物理ID方案可以上线。如果其中有一点不满足就需要调整预期。我遇到过的真实案例是某访客系统最初想用手机NFC读身份证自动登记评估后发现访客用的是第一代身份证根本没有非接芯片方案直接废掉。后来改成外接读卡器才把识别率做到99%。所以做方案评估时别只盯着源码看要先问清楚“要读哪一代卡”“卡里有没有芯片”“是否允许贴卡”这三个问题的答案决定了技术路线。另外很多人在这个阶段拿到的“源码废案”其实不是源码本身有问题而是业务场景不匹配。比如做一个健身房的会员卡识别用它来识别身份证入场结果用户把身份证套在厚卡套里NFC信号衰减严重导致大量失败。这种情况不用改代码改卡套就行。5. 安卓 NFC 读身份证的 5 个典型踩坑与现场排查5.1 贴卡后手机无响应 / 不停振动现象手机贴卡片后有系统提示音也振动但你的App毫无反应或者系统弹出了钱包界面。原因系统把身份证当成了一个“可交互卡片”优先弹出了NFC支付或系统标签应用。另一个常见原因是开启了enableReaderMode但Flags里没加FLAG_READER_NFC_B系统完全不委派回调。解决在enableReaderMode的第一个参数传入Activity实例而不是ApplicationContextFlags组合里加上FLAG_READER_SKIP_NDEF_CHECK。同时进系统设置把NFC默认应用改为“读取标签”或“关闭安全模块”。在代码侧可以加一个日志确认onTagDiscovered有没有被回调如果回调都没进优先排查系统NFC拦截。注意部分手机锁屏状态下ReaderMode不可用贴卡只会唤醒支付。测试时最好是保持屏幕常亮并且解锁。5.2 IsoDep.connect() 抛异常“Tag Lost”现象tag.getId()有时候能拿到但isoDep.connect()直接抛TagLostException或者连接成功后第一次transceive就断。原因身份证卡片面积大内部线圈分布不均匀贴卡位置偏移会造成射频场不稳定。另外如果手机开启了NFC检测音每次按键音会触发场控暂停导致协议层超时。解决把摄像头区域对准身份证的不规则边缘位置而不是贴着卡片正中心一般能改善。同时把EXTRA_READER_PRESENCE_CHECK_DELAY调大一点比如200让系统更“宽容”。还有就是不要用手捏住卡片边缘手指会吸收一部分射频能量这属于玄学但实测有效。还有一种情况是手机壳内含有金属部件河南米等品牌的磁吸指环会严重干扰NFC场。排查时先取掉手机壳。5.3 读出的 CID 和 PC 读卡器不一致现象App打印的物理ID是8字节而专用读卡器读出来的是4字节字符串两边对不上怀疑身份证被换。原因安卓上层报告的tag.id取决于NFC控制器驱动的缓存策略并不等同于PC/SC读卡器通过.GetUID返回的CID。两者在字段定义和数据来源上就不一样。身份证在PC读卡器上看到的UID通常来自卡内文件系统的卡号而tag.id来自PICC层的PUPI这两者是由芯片不同模块生成的。解决统一标准。如果你要跟PC读卡器比对就不要用tag.id做唯一键而是自己发送APDU读取卡内卡号只要它能通过安全认证。硬件读卡器读出的卡号有固定格式你需要在安卓端解析APDU响应而不是读tag.id。我自己的习惯是在App里同时保留tag.id和连接成功的状态但业务主键一律用读卡器返回的卡号字段。对纯移动端场景则把tag.id在服务端做哈希登记不与PC端数据混用。5.4 Android 12 以上 NFC 权限行为变更现象App在Android 12设备上第一次贴卡没反应打开日志发现NfcAdapter实例正常但isEnabled返回false用户设置里NFC又是开着的。原因Android 12开始部分系统服务的NFC状态读取受限应用如果没做运行时权限判断会误判NFC未开启。另外Android 12以上的ReaderMode回调如果在后台会被系统限制。解决在读写NFC前不要依赖isEnabled的返回值直接尝试开启ReaderMode回调永远走系统分发。如果打开失败再引导到系统设置页确认。onTagDiscovered里一定不要在子线程里做UI操作但IsoDep的connect和transceive要放到子线程或协程中避免阻塞主线程。这里还有一个坑有些App在Android 12上申请了ACCESS_FINE_LOCATION用于蓝牙扫描结果也会被关联到NFC状态判断权限弹窗频繁用户拒绝后NFC初始化失败。排查时关注一下权限关联不是NFC自身问题。5.5 某些手机能读另一些手机始终读不出来现象用A手机测试半小时没问题换B手机之后贴卡无反应或者反应极慢。原因B手机使用了不同的NFC天线设计和底层协议栈。身份证这种大面积卡容易产生负载调制信号幅度不够导致低灵敏度机型直接忽略。解决搭建一张测试矩阵记录“手机型号、系统版本、是否成功、成功耗时、物理ID长度”。在代码里做Type B列表轮询和IsoDep切换有些机型用IsoDep不稳定改用NfcB.transceive反而能出数据。可以在onTagDiscovered里判断IsoDep.get(tag)是否匹配不匹配时再尝试NfcB.get(tag)。最实际的兜底方案是给用户提供“贴卡位置提示”类似在页面中间画一个圆并显示“请将卡片上部靠近手机NFC区域”这能缓解硬件层级差异。不要指望所有安卓手机表现一致你必须在正式上线前确定最低支持机型。if (IsoDep.get(tag) ! null) { // 走 ISO-DEP } else if (NfcB.get(tag) ! null) { // 走 NfcB 通道 } else { // 不支持提示用户换一个贴卡位置 }很多人觉得这段逻辑多余但它在Stable的ROM上可能不会进入在某个定制ROM上就救你一次。我都习惯把这个分支写进去成本低回报率很高。6. 把物理 ID 变成可用的业务验证白名单与二次比对读物理ID只是第一步真正让设备“认清身份证”需要对读到的ID做封装。最简单的封装是维护一个服务端白名单把之前登记过的物理ID和用户手机号绑定下次贴卡时直接校验。但物理ID并不是绝对隐私它可以被NFC嗅探器截获所以不能把它当密钥。正确做法是把物理ID作为查询键在服务端生成一次性挑战值下发到AppApp通过其他安全通道比如蓝牙或网络请求把挑战值签名后返回服务端验签通过才放行。这样一来即使有人复制了物理ID没有签名密钥也无法通过校验。我经常用的签名方案是HMAC-SHA256利用物理ID加时间戳生成动态码。这里给出一个最小示意不涉及服务器地址fun generateDynamicCode(physicalId: String): String { val timestamp System.currentTimeMillis() / 1000 val msg $physicalId-$timestamp return hmacSha256(msg, secretKey) }具体HMAC的实现在Android SDK里有javax.crypto.Mac标准接口不需要额外引包。这里的意义在于把“贴卡识别”升级为“贴卡认证”而不是简单读ID。如果你做的系统需要和PC读卡器数据互通建议在服务端保留两种ID映射表移动端物理ID和读卡器卡号各一列用业务行为建立关联。不要试图从ID字节上反推两种字段的一致性那会陷入无底洞。最后说一个个人习惯每做一个NFC项目都会在样机上跑一遍“连续贴卡50次”的稳定测试记录失败次数和错误类型。很多项目在功能验证时都正常就是没有做疲劳测试结果上线第一天被贴卡频繁错乱打爆。NFC这个东西真不是“能通就行”天线位置、贴卡角度、手机壳厚度都能让结果抖三抖。希望这篇笔记能帮你绕开那些我踩过的坑祝你的身份证NFC识别项目一次跑通。本文还有配套的精品资源点击获取
