企业官网建设流程全解析

不用买NFC空卡贴，也不用盯着各种“模拟门禁卡”App里那一大堆收费功能，Android手机本身就能做不少事。很多朋友一上来就搜“Android NFC模拟门禁卡”，结果要么被教程绕晕，要么跟着别人的App刷半天还是提示“不支持”，最后不了了之。这篇文章把我自己做NFC调试的真实流程和完整代码整理出来，从原理到环境搭建，从读卡号到HCE模拟，尽量把每一步为什么这么做讲清楚，代码可以直接抄。

这期内容适合三类人：刚接触Android NFC开发、想做个读卡小工具的移动开发者；不想折腾第三方破解工具、只想用手机和系统能力解决门禁问题的普通玩家；以及准备做门禁对接、考勤系统原型验证的产品同学。读完你至少能跑通一条完整链路：手机识别门禁卡 → 读取并解析卡号 → 用代码方式模拟近场交互。

1. 先弄清NFC和门禁卡的本质，再谈模拟

1.1 RFID与NFC的关系：一张卡片的身份从哪来

门禁卡本质是一张RFID（射频识别）卡片，里面有一块芯片和一组线圈。读卡器在刷卡瞬间给线圈供能，芯片被唤醒后把身份信息通过电磁波回传。RFID按频率分好几类，门禁行业最常见的是125kHz低频卡和13.56MHz高频卡。手机NFC的工作频率固定在13.56MHz，所以很多老式低频门禁卡没法直接用手机刷，这是硬件频率决定的，和软件无关。

NFC可以理解为RFID在13.56MHz频段上的一个增强版本，它继承了“读卡”能力，还额外支持双向通信。也就是说，手机既能当读卡器去读别人，也能模拟成一张卡让别人读。Android里把这两种行为分别称为Reader Mode和Card Emulation Mode，后面要做的“模拟门禁卡”就属于后者。

判断手里的卡能不能进入“手机模拟”的流程，先看卡面上有没有标着13.56MHz，再看读卡时App反馈的技术类型。现在办公楼和小区用的IC卡，大部分是NXP的Mifare Classic（S50/S70）或者兼容卡，频率就是13.56MHz，这类卡和手机NFC在频率上是能对上话的。而EM4100这类125kHz的ID卡，手机根本读不出UID，直接放弃，老老实实继续用实体卡。

1.2 手机NFC的三种工作模式，为什么读卡容易、模拟难

Android手机里的NFC硬件通常包含NFC控制器和安全单元（SE），系统在上面抽象出三种工作模式：

• 读卡器模式（Reader/Writer）：手机主动靠近标签，读取或写入数据，日常的NFC标签读写都走这个模式。
• 点对点模式（P2P）：两台设备之间交换数据，主要用于文件传输和数据交换，现在用得越来越少。
• 卡模拟模式（Card Emulation）：手机把自己当成一张卡，让外部读卡器读取。这个模式又分两种实现方式，一种依赖硬件SE，另一种叫HCE（Host Card Emulation，主机卡模拟），完全依靠手机CPU和应用代码处理。

读卡之所以简单，是因为Android把读卡器模式封装得很成熟，系统帮你处理了RFID协议细节。但模拟难是因为手机里的NFC控制器在默认情况下不会把“读卡器发来的底层命令”直接透传给App，尤其是Mifare Classic这类使用私有协议（MIFARE Classic protocol，基于ISO/IEC 14443-3）的卡片，驱动层和SE层通常不开放，普通Java/Kotlin代码根本没有机会介入。很多网上说的“用手机模拟门禁卡”，最终只能靠手机厂商在系统层开放模拟接口才能实现，这也是为什么刷门禁时经常出现“只有某品牌手机能模拟成功”的原因。

1.3 你的门禁卡到底能不能模拟？先判断卡型

做技术方案前先给卡分个类。常见门禁卡可以粗略分成以下几种：

最核心的判断依据有三个：频率、技术协议、加密情况。频率决定物理层是否兼容，协议决定Android能不能识别，加密情况决定你就算读到了数据，也无法在手机里产出一个能通过验证的响应。我见过不少人折腾半天，最后发现那张卡是滚动码卡，读到的卡号每次都不同，那就是没有意义的方向。

此处加一句非常必要的提醒：整个NFC调试过程请只针对你自己名下、有权限使用的门禁卡和测试设备。复制他人门禁卡属于你所在地区可能涉及民事责任甚至更严重后果的行为，本文只讨论技术教学和自有设备调试。

2. 开发环境准备：Android Studio、真机与工程配置

2.1 需要的工具和硬件

做NFC开发先准备一套像样的环境。软件方面需要Android Studio（建议用较新的稳定版本，下载地址直接在官网拿，旧版也没问题，核心API没有太大变化），以及一台Android真机。NFC模拟器在PC上跑不了，Android模拟器也不支持NFC硬件穿透，所以“必须真机”这条没有商量余地。

真机选择上有几个经验可以参考：优先选NFC能力完整的手机，不要用那种“只支持NFC支付，不开放读写”的阉割版本；系统版本尽量在Android 8.0以上，对HCE和动态前台分发的支持更稳定；如果手头是国产定制ROM，还要注意权限管理是否默认拦截了NFC相关的后台扫描。我自己测试时比较偏爱一加和Pixel系列，因为它们更接近原生Android行为，调试时少踩系统定制的坑。

电脑端建议装一个NFC Reader Tool或者系统自带的卡调试工具，也可以在Play商店里装一些免费的标签读取App来辅助判断。不过它们是辅助定位问题的，真正常用的是自己写的日志，后面会说到。

2.2 AndroidManifest配置：权限、intent-filter与features

新建一个空项目后，先在AndroidManifest.xml里声明NFC权限和硬件特性。

<uses-permission android:name="android.permission.NFC" /> <uses-feature android:name="android.hardware.nfc" android:required="true" />

uses-feature加required=true的意思是，没有NFC硬件的设备在应用市场里搜不到这个App，避免装到不支持的设备上。如果是做工具类应用，也建议加上，用户体验会好很多。

接下来配置Activity的intent-filter。NFC读卡分发有三种Action：ACTION_NDEF_DISCOVERED、ACTION_TECH_DISCOVERED、ACTION_TAG_DISCOVERED。门禁卡通常没有NDEF消息，所以核心是TECH_DISCOVERED。我们让入口Activity监听这几种事件，同时把tech过滤文件挂上去。

<activity android:name=".MainActivity" android:launchMode="singleTop"> <intent-filter> <action android:name="android.nfc.action.TECH_DISCOVERED" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> <intent-filter> <action android:name="android.nfc.action.NDEF_DISCOVERED" /> <action android:name="android.nfc.action.TAG_DISCOVERED" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> <meta-data android:name="android.nfc.action.TECH_DISCOVERED" android:resource="@xml/nfc_tech_filter" /> </activity>

在res/xml目录下创建nfc_tech_filter.xml，把可能用到的技术类型全部列进去。

<resources> <tech-list> <tech>android.nfc.tech.NfcA</tech> <tech>android.nfc.tech.NfcB</tech> <tech>android.nfc.tech.NfcF</tech> <tech>android.nfc.tech.NfcV</tech> <tech>android.nfc.tech.IsoDep</tech> <tech>android.nfc.tech.MifareClassic</tech> <tech>android.nfc.tech.MifareUltralight</tech> <tech>android.nfc.tech.Ndef</tech> </tech-list> </resources>

2.3 前台分发与Activity配置

只配置Manifest还不够。当手机贴卡时，系统会选一个最匹配的Activity把它带到前台，但如果你的App已经打开，并且系统认为当前界面不能处理这个标签，很可能事件就被后台吞掉或者直接弹出一个无响应。解决办法是用前台分发（Foreground Dispatch），让App在处于前台且无遮挡时优先拿到NFC事件。

前台分发需要在onStart里注册，onStop里注销。核心代码如下：

class MainActivity : AppCompatActivity() { private lateinit var nfcAdapter: NfcAdapter private var pendingIntent: PendingIntent? = null override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) nfcAdapter = NfcAdapter.getDefaultAdapter(this) if (nfcAdapter == null) { Log.e("NFCDemo", "设备不支持NFC") return } val intent = Intent(this, javaClass) pendingIntent = PendingIntent.getActivity( this, 0, intent, if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) PendingIntent.FLAG_IMMUTABLE or PendingIntent.FLAG_UPDATE_CURRENT else PendingIntent.FLAG_UPDATE_CURRENT ) } override fun onStart() { super.onStart() startForegroundDispatch() } override fun onStop() { super.onStop() stopForegroundDispatch() } private fun startForegroundDispatch() { val filters = arrayOf( IntentFilter(NfcAdapter.ACTION_TECH_DISCOVERED), IntentFilter(NfcAdapter.ACTION_NDEF_DISCOVERED), IntentFilter(NfcAdapter.ACTION_TAG_DISCOVERED) ) val techLists = arrayOf( arrayOf("android.nfc.tech.NfcA"), arrayOf("android.nfc.tech.NfcB"), arrayOf("android.nfc.tech.IsoDep"), arrayOf("android.nfc.tech.MifareClassic") ) nfcAdapter?.enableForegroundDispatch(this, pendingIntent, filters, techLists) } private fun stopForegroundDispatch() { nfcAdapter?.disableForegroundDispatch(this) } }

这段代码里最关键的是pendingIntent的Flag。低版本Android用FLAG_UPDATE_CURRENT，Android 12开始必须显式声明FLAG_IMMUTABLE，否则在部分机型上PendingIntent创建直接抛异常。这类兼容问题在NFC开发里很常见，遇到“一开App就崩溃但日志又没有明显报错”时，优先检查这里的Flag。

3. 核心代码：做一个能读取门禁卡信息的小工具

3.1 读取卡号（UID）的完整实现

拿到Tag对象后，第一个要读的就是UID，也就是卡号。门禁系统在授权时通常把这个串作为设备的唯一标识，很多纯不加密的门禁，刷卡的瞬间就是读卡号比对的过程。

在Activity中增加一个方法：

private fun handleTag(tag: Tag) { val uid = tag.id val uidHex = uid.joinToString("") { byte -> String.format("%02X", byte) } Log.i("NFCDemo", "UID: $uidHex") val sb = StringBuilder() tag.techList.forEach { tech -> sb.append(tech).append("\n") } Log.i("NFCDemo", "TechList:\n$sb") }

handleTag在onNewIntent和onResume两个地方调用。用singleTop启动模式后，Activity在栈顶收到NFC Intent时会回调onNewIntent，而不是重新onCreate，所以这里必须把intent更新到当前Activity，防止界面状态不一致。

另外，有一些国产ROM存在“息屏状态贴卡直接唤醒到桌面而不是进入App”的问题，这种情况通常出现在没有启用前台分发的场景。解决办法是再加一个前台通知栏或保持屏幕常亮，更优雅的方案是在onResume里检测到Intent后，立即处理并恢复前台。

3.2 读取卡型与技术细节：MifareClassic、IsoDep、NfcA

UID只是最表层的信息，真正决定能不能做深度操作的是卡片的技术类型。通过tag.getTechList()可以看到这张卡对外暴露了哪些技术接口。

常见组合大约是这样的：

• 普通IC门禁卡：NfcA、MifareClassic。卡内扇区可能加密，需要用密钥验证后才能读数据。
• 银行卡、公交卡：IsoDep、NfcA、NfcB。这类卡往往支持ISO-DEP协议，能通过APDU指令通信。
• 电子标签：NfcA、Ndef。贴上就有响应，一般用来存网址或文本。

读取MifareClassic卡的时候，还要拿到扇区数量、块数量、容量这些基础属性，方便后续判断卡内有没有可用数据区。

private fun inspectMifareClassic(tag: Tag) { val mfc = MifareClassic.get(tag) ?: return try { mfc.connect() Log.i("NFCDemo", "Sector Count: ${mfc.sectorCount}") Log.i("NFCDemo", "Block Count: ${mfc.blockCount}") Log.i("NFCDemo", "Type: ${mfc.type}") Log.i("NFCDemo", "Size: ${mfc.size}") mfc.close() } catch (e: IOException) { Log.e("NFCDemo", "读取MifareClassic失败: ${e.message}") } }

这里要解释一个关键点：connect成功不代表能读全部内容。Mifare Classic的每个扇区有独立密钥，默认出厂密钥可能是全FF，但很多门禁厂商已经改过密钥。如果没有密钥，读扇区数据会抛出权限异常。所以不要指望靠读扇区就能“复制”一张卡，在这类卡上，UID能不能模拟才是关键，而恰恰在Android原生层，UID模拟几乎是禁区。

有读者会问：那App怎么判断能不能模拟？简单回答是：不能单纯靠代码判断，只能实机测试。因为Android没有提供一个“查询本机NFC控制器是否支持UID模拟”的公共API，只有厂商SDK或系统签名应用才能碰底层。

3.3 记录与展示卡信息

在实际开发中，读卡号通常只是第一步。为了后面排查方便，建议把最近刷过的卡记录本地保存下来，便于对比测试。下面给一个简单版本，用SharedPreferences存储，够用且不引入额外依赖。

private fun saveCardRecord(uidHex: String, techList: String) { val prefs = getSharedPreferences("nfc_records", Context.MODE_PRIVATE) val timestamp = SimpleDateFormat("yyyy-MM-dd HH:mm:ss", Locale.getDefault()).format(Date()) val records = prefs.getString("records", "") val newRecord = "$timestamp | UID=$uidHex | Tech=$techList\n" prefs.edit().putString("records", newRecord + records).apply() }

有精力的话可以换Room数据库，把每次刷卡的时间、位置、UID、协议类型存成表，后面做门禁使用频率分析或者自动提醒会方便很多。但这个Demo阶段没必要过度设计，SharedPreferences够用。

4. 实现“模拟”：系统方案与HCE方案全解读

4.1 为什么系统自带的“模拟门禁卡”经常刷不上

先聊聊很多人的经历：手机钱包App里有“模拟门禁卡”功能，但试了十几次，系统提示“复制失败”或“不支持该卡片”。原因要从手机钱包App实现模拟的方式说起。手机钱包App（尤其是国产手机厂商自带的NFC服务）主要依赖手机里的安全单元SE，也就是一颗独立的安全芯片。模拟操作实际是把卡的信息写入SE里的某个安全域，再由SE直接和读卡器完成交互。

问题在于，门禁卡里的数据涉及扇区密钥、UID只读属性，SE为了安全不会允许普通用户随便读改写这些敏感信息。厂商提供的“模拟门禁卡”能力如果遇到非标准卡、加密卡、UID卡，往往直接拒绝；就算模拟成功，也经常碰上读卡器认UID的场合，因为很多门禁读卡器校验的不只是数据显示的卡号，还包含卡片在耦合阶段的硬件特性。这不是开发能力问题，而是芯片与协议边界问题。

还有一点容易混淆：一些第三方App声称自己能直接模拟门禁卡，但背后用的往往是手机厂商的系统模拟接口或者老版本系统的漏洞，一旦手机升级系统或者换设备，马上失效。正经做技术方案，不建议把希望全部寄托在这些App上。

4.2 HCE（主机卡模拟）的工作原理

HCE是Android 4.4开始引入的系统级卡模拟框架，它允许开发者在没有SE参与的情况下，让NFC控制器把收到的APDU指令转发给手机CPU，由App自己处理应答。这在门禁开发里是一个可用的技术方向，但它有明确边界。

手机在卡模拟模式下工作时，NFC控制器会先读取一张AID（Application ID，应用标识符）路由表。当外部读卡器发起SELECT AID指令时，控制器会根据路由表判断这个AID是本机SE的、SIM卡的还是某个App的。HCE做的就是注册自己的AID列表，让控制器命中后把后续指令全部交给App。

HCE真正能模拟的是遵循ISO 7816-4 APDU规范的智能卡协议，也就是读卡器侧通常走ISO-DEP（ISO/IEC 14443-4）通道。很多CPU卡门禁系统就是这种模式，读卡器发APDU，卡片回APDU，非常适合用HCE接住。

但跑Mifare Classic私有协议的门禁读卡器，在物理层用的是ISO/IEC 14443-3的MIFARE Classic协议，不通过ISO-DEP发APDU，也不走AID选择流程，HCE在这种情况下是无能为力的。所以如果门禁系统只是读一个固定UID的Mifare卡，HCE很难做成直接替代品；如果是自建门禁系统、实验室项目或者需要兼容标准智能卡协议的场景，HCE是完全可行的方案。

4.3 HCE完整代码：注册AID并响应门禁读卡器

先注册AID路由表。在res/xml目录创建aid_list.xml：

<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android" android:description="@string/hce_description" android:requireDeviceUnlock="false"> <aid-group android:description="@string/hce_aid_group" android:category="other"> <aid-filter android:name="F000000001" /> <aid-filter android:name="F000000002" /> </aid-group> </host-apdu-service>

AID的格式是16进制字符串，全局唯一，团队内部可以自行约定，但注意不要和别家的应用冲突。接下来写HCE服务：

import android.nfc.cardemulation.HostApduService import android.os.Bundle import android.util.Log class GateCardService : HostApduService() { override fun processCommandApdu(commandApdu: ByteArray, extras: Bundle?): ByteArray { Log.d("HCE", "收到APDU: ${bytesToHex(commandApdu)}") if (isSelectAidApdu(commandApdu)) { return byteArrayOf(0x90.toByte(), 0x00) } // 根据实际门禁读卡器的协议定义处理逻辑 // 这里演示一个最简单的场景：读卡器请求卡号，我们返回固定卡号 val cardNumber = "A0B1C2D3E4" val response = hexToByteArray(cardNumber) + byteArrayOf(0x90.toByte(), 0x00) return response } override fun onDeactivated(reason: Int) { Log.d("HCE", "卡模拟通道关闭，reason=$reason") } private fun isSelectAidApdu(apdu: ByteArray): Boolean { return apdu.size >= 7 && apdu[0] == 0x00.toByte() && apdu[1] == (0xA4).toByte() && apdu[2] == 0x04.toByte() } private fun bytesToHex(bytes: ByteArray): String { return bytes.joinToString("") { String.format("%02X", it) } } private fun hexToByteArray(hex: String): ByteArray { val result = ByteArray(hex.length / 2) for (i in result.indices) { val index = i * 2 result[i] = hex.substring(index, index + 2).toInt(16).toByte() } return result } }

最后在AndroidManifest.xml里注册服务：

<service android:name=".GateCardService" android:exported="true" android:permission="android.permission.BIND_NFC_SERVICE"> <intent-filter> <action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE" /> </intent-filter> <meta-data android:name="android.nfc.cardemulation.host.apdu.service" android:resource="@xml/aid_list" /> </service>

exported设置为true是因为NFC系统服务需要绑定这个Service，permission必须写成BIND_NFC_SERVICE，这是系统绑定HCE服务时的强制权限，写错了服务起不来。isSelectAidApdu的判断用了一个简化逻辑，真机上如果读卡器发来的SELECT指令带不同参数，可能需要更精确的判断，最好把收到的APDU完整打日志，再根据读卡器协议调整。

4.4 不同模拟方案的对比与选型建议

如果你真的想把日常门禁刷到手机上，最省心的路径其实是手机钱包里的“模拟门禁卡”功能；如果那张卡做不了，再考虑HCE方案去对接自建门禁系统。千万不要先买一堆NFC卡贴去“破解”加密数据，那既是市场乱象，也容易把你带进坑。

5. 实测踩坑实录：NFC调试中的常见问题与排查方法

5.1 App收不到NFC标签的Intent怎么办

这是NFC开发最常见的起步问题。代码照着写了，贴卡却没有任何反应。排查顺序一般是：

先确认手机NFC开关确实打开，部分手机还能区分“NFC”和“NFC读卡”两个开关，都要打开；确认系统没把NFC扫描权限关到后台；确认Activity用了singleTop并且前台分发注册成功；确认nfc_tech_filter.xml里技术的包名没有拼写错误，比如MifareClassic多写个r、NfcA写成NfcA，这类低级错误直接导致TECH_DISCOVERED不触发；最后用“NFC TagInfo”之类的第三方工具读一遍卡，如果第三方工具能读出UID而你的App收不到Intent，那问题基本出在filter或者前台上。

有一种很隐蔽的情况：Android系统在同一个Intent里可能同时匹配到多个Activity，如果你的手机装了多个NFC相关应用，系统可能会弹选择框或者把事件分给别的应用。处理方式是不要光靠intent-filter，而是用前台分发“抢”事件，同时把App设成某个NFC标签的默认应用，这样系统就不会乱分了。

5.2 HCE服务已经启动，读卡器没反应怎么办

写完HCE服务，把手机靠近自己的NFC读卡器（或者另一台手机的读卡App），结果没有响应。这里有个前提要先说清楚：HCE能否触发，取决于读卡器是否发起SELECT AID。读卡器如果连AID都不选，只是不断地感应卡片的UID，那HCE根本不会启动。这是协议层面的不匹配，不是代码问题。

排错步骤是先看日志。把手机连上Android Studio，过滤“HCE”关键字，确认processCommandApdu有没有被调用。日志里完全没有“收到APDU”，说明AID路由没走到App，检查aid_list.xml里的AID是否被其他App抢占；有些系统自带钱包会占用默认路由，需要把本App设为前台优先或者关闭系统钱包的卡模拟。日志里有“收到APDU”但返回值没有效果，说明读卡器收到了响应但不认可，需要核对APDU指令格式。

还要提一个细节：HCE需要屏幕解锁和NFC开启，部分机型还要求“NFC支付默认应用”设置为自己的App。路径一般在设置-连接与共享-NFC-默认付款应用，不一定每个品牌都一样，但功能是存在的。

5.3 常见问题速查表

5.4 我的安全建议与合规提醒

网上有“NFC中继攻击”的说法，原理是把读卡器的信号通过无线方式转发到远端的卡片，不是真的复制卡，而是“延长刷卡距离”。这种技术在安防领域通常被用来测试门禁系统的防中继能力，但从门禁用户的角度看，它绕过了授权验证，属于对门禁系统的未授权操作，我不建议技术爱好者在这上面试水。做开发调试时，请务必使用自己可控的读卡器和自己名下的测试卡。

还有一个合规细节：HCE服务的AID如果有人恶意模仿，有可能被其他应用拦截。商用项目中最好对自己的AID做申请和管理，在服务端校验卡号和会话随机数，而不是像Demo这样返回固定卡号。固定卡号适合验证链路，不适合上线。

6. 后续还能怎么扩展：从读卡到门禁联动

跑通上面的读卡和HCE流程之后，这个项目已经具备一个NFC工具的基础形态。你可以继续加以下几类功能。

第一类是门禁使用记录分析。把每次刷卡的UID、时间、地点记录下来，配合地图或考勤系统，能做出员工到岗统计、访客进出报表，这些在企业场景里可以直接对接后台API。第二类是自动化联动，比如读到某张卡后自动触发HomeAssistant的开门动作，或者联动智能家居场景，让手机贴近NFC标签时完成一个操作。第三类是协议适配层，把HCE部分抽象成服务，支持多套AID和不同APDU指令集，这样以后换门禁系统，只要改配置不用重写代码。

如果你打算继续深入，建议把官方文档里的NFC基础知识册翻一遍，尤其是关于IsoDep和APDU那部分。做NFC开发，需求真正难的不是写代码，而是理解协议背后的物理世界。

我自己的体会是：这类项目第一次做完最大的收获，不是“能让手机刷开门”那一刻的成就感，而是终于搞懂了平时那些门禁卡、电梯卡、饭卡在系统视角里到底是什么样的存在。而且一旦有了读卡和HCE这条链路，后面接考勤、接访客系统、接实验环境都是水到渠成的事。

最后再分享一个小技巧：调试HCE时，准备一台支持ISO-DEP的桌面读卡器，能大幅提升效率。很多门禁读卡器是单向输出，你根本不知道它往卡里发了什么指令，而桌面读卡器可以把APDU收发日志完整dump出来，对照着调整你的HCE返回逻辑，比盲调省太多时间。希望这篇能帮你在NFC这条路上少走弯路。