主機型卡片模擬總覽

許多搭載 NFC 功能的 Android 裝置都支援 NFC 卡模擬功能。在大多數情況下，卡片會由裝置中的另一個晶片模擬，稱為安全元件。許多無線電信業者提供的 SIM 卡也包含安全性元素。

Android 4.4 以上版本提供額外的卡片模擬方法，不涉及安全元素，稱為「主機型卡片模擬」。這可讓任何 Android 應用程式模擬卡片，並直接與 NFC 讀卡器通訊。本主題說明主機卡片模擬 (HCE) 在 Android 上的運作方式，以及如何使用這項技術開發可模擬 NFC 卡片的應用程式。

使用安全元件模擬卡片

使用安全元件提供 NFC 卡模擬功能時，系統會透過 Android 應用程式，將要模擬的卡片佈建至裝置上的安全元件。接著，當使用者將裝置放在 NFC 終端機上時，裝置中的 NFC 控制器會將讀取器的所有資料直接轉送至安全元素。圖 1 說明瞭這個概念：

圖1. 含有安全元件的 NFC 卡模擬功能。

安全元件本身會執行與 NFC 終端機的通訊作業，且交易過程中不會涉及任何 Android 應用程式。交易完成後，Android 應用程式可以直接查詢安全元件，取得交易狀態並通知使用者。

主機卡模擬

使用主機卡模擬功能模擬 NFC 卡時，資料會直接轉送至主機 CPU，而非轉送至安全元件。圖 2 說明主機卡模擬的運作方式：

圖2. 沒有安全元件的 NFC 卡模擬功能。

支援的 NFC 卡片和通訊協定

圖3.Android 的 HCE 通訊協定堆疊。

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 說明瞭所有這些規格的層級。

HCE 服務

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。ISO/IEC 7816-5 規範中定義了 AID 的註冊程序。如果您要部署 Android 適用的 HCE 應用程式，建議您依照 7816-5 註冊 AID，以免與其他應用程式發生衝突。

AID 群組

在某些情況下，HCE 服務可能需要註冊多個 AID，並將其設為所有 AID 的預設處理常式，才能實作特定應用程式。系統不支援將群組中的部分 AID 傳送至其他服務。

將 AID 保留在一起的清單稱為 AID 群組。對於 AID 群組中的所有 AID，Android 保證下列任一條件：

• 群組中的所有 AID 都會轉送至這項 HCE 服務。
• 群組中沒有任何 AID 會轉送至這個 HCE 服務 (例如，因為使用者偏好其他服務，而該服務也要求群組中的一或多個 AID)。

換句話說，沒有中間狀態，也就是群組中的部分 AID 可導向至一個 HCE 服務，而其他則導向至另一個服務。

AID 群組和類別

您可以將每個 AID 群組與類別建立關聯。這可讓 Android 依類別將 HCE 服務分組，進而讓使用者在類別層級 (而非 AID 層級) 設定預設值。請勿在應用程式中向使用者提及 AID，因為這對一般使用者來說毫無意義。

Android 4.4 以上版本支援兩種類別：

• CATEGORY_PAYMENT (涵蓋業界標準的付款應用程式)
• CATEGORY_OTHER (適用於所有其他 HCE 應用程式)

注意： 系統一次只能啟用 CATEGORY_PAYMENT 類別中的一個 AID 群組。通常，這類應用程式會瞭解主要信用卡付款通訊協定，並可在任何商家使用。

如果是只在單一商家 (例如儲值卡) 使用的封閉式付款應用程式，請使用 CATEGORY_OTHER。這個類別中的 AID 群組可以一律處於啟用狀態，並可在必要時由 NFC 讀取器在 AID 選取期間獲得優先順序。

實作 HCE 服務

如要使用主機卡片模擬功能模擬 NFC 卡片，您必須建立可處理 NFC 交易的 Service 元件。

檢查是否支援 HCE

應用程式可以檢查 FEATURE_NFC_HOST_CARD_EMULATION 功能，藉此確認裝置是否支援 HCE。請在應用程式資訊清單中使用 <uses-feature> 標記，宣告應用程式使用 HCE 功能，以及應用程式是否需要這項功能才能運作。

服務實作

Android 4.4 以上版本提供方便使用的 Service 類別，可做為實作 HCE 服務的基礎：HostApduService 類別。

第一步是擴充 HostApduService，如以下程式碼範例所示：

Kotlin

class MyHostApduService : HostApduService() {

    override fun processCommandApdu(commandApdu: ByteArray, extras: Bundle?): ByteArray {
       ...
    }

    override fun onDeactivated(reason: Int) {
       ...
    }
}

Java

public class MyHostApduService extends HostApduService {
    @Override
    public byte[] processCommandApdu(byte[] apdu, Bundle extras) {
       ...
    }
    @Override
    public void onDeactivated(int reason) {
       ...
    }
}

HostApduService 會宣告兩個您必須覆寫及實作的抽象方法。每當 NFC 讀取器將應用程式通訊協定資料單元 (APDU) 傳送至服務時，就會呼叫其中一個 processCommandApdu()。APDU 定義於 ISO/IEC 7816-4 規範。APDU 是 NFC 讀取器與 HCE 服務之間交換的應用程式層級封包。該應用程式層級通訊協定為半雙工：NFC 讀取器會傳送指令 APDU，並等待您傳送回應 APDU。

注意： ISO/IEC 7816-4 規格也定義了多個邏輯管道的概念，可讓您在個別邏輯管道中進行多個並行 APDU 交換。不過，Android 的 HCE 實作僅支援單一邏輯通道，因此只有單一執行緒的 APDU 交換。

如先前所述，Android 會使用 AID 判斷讀取器要與哪個 HCE 服務通訊。通常，NFC 讀取器傳送至裝置的第一個 APDU 是 SELECT AID APDU；這個 APDU 包含讀取器要與之通訊的 AID。Android 會從 APDU 中擷取 AID，將其解析為 HCE 服務，然後將 APDU 轉送至已解析的服務。

您可以透過 processCommandApdu() 傳回回應 APDU 的位元組，傳送回應 APDU。請注意，這個方法會在應用程式主執行緒上呼叫，因此請勿封鎖該執行緒。如果您無法立即計算並傳回回應 APDU，請傳回空值。接著，您可以在另一個執行緒上執行必要工作，並使用 HostApduService 類別中定義的 sendResponseApdu() 方法，在完成時傳送回應。

Android 會持續將讀取器的新 APDU 轉送至您的服務，直到發生下列任一情況為止：

• NFC 讀取器會傳送另一個 SELECT AID APDU，而作業系統會將該 APDU 解析為其他服務。
• NFC 讀卡機和裝置之間的 NFC 連結中斷。

在上述兩種情況下，系統會呼叫類別的 onDeactivated() 實作項目，並使用引數指出發生了哪一種情況。

如果您使用現有的讀取器基礎架構，則必須在 HCE 服務中實作讀取器預期的現有應用程式層級通訊協定。

如果您也要部署新的讀卡機基礎架構，並自行控管，則可以定義自己的通訊協定和 APDU 序列。請盡量限制 APDU 的數量和交換資料的大小：這樣可確保使用者只需將裝置靠近 NFC 讀卡機一段短時間。合理的上限約為 1 KB 的資料，通常可以在 300 毫秒內交換。

服務資訊清單宣告和 AID 註冊

您必須照常在資訊清單中宣告服務，但也必須在服務宣告中加入一些額外元素：

1. 如要告知平台這是實作 HostApduService 介面的 HCE 服務，請在服務宣告中為 SERVICE_INTERFACE 動作新增意圖篩選器。

2. 如要告知平台這項服務要求哪些 AID 群組，請在服務宣告中加入 SERVICE_META_DATA <meta-data> 標記，指向包含 HCE 服務其他資訊的 XML 資源。

3. 將 android:exported 屬性設為 true，並在服務宣告中要求 android.permission.BIND_NFC_SERVICE 權限。前者可確保服務可與外部應用程式繫結。後者則會強制規定，只有擁有 android.permission.BIND_NFC_SERVICE 權限的外部應用程式才能繫結至您的服務。由於 android.permission.BIND_NFC_SERVICE 是系統權限，因此這項權限可有效強制執行，確保只有 Android 作業系統能繫結至您的服務。

以下是 HostApduService 資訊清單宣告的範例：

<service android:name=".MyHostApduService" 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/apduservice"/>
</service>

這個中繼資料標記會指向 apduservice.xml 檔案。以下是這類檔案的範例，其中包含單一 AID 群組宣告，內含兩個專屬 AID：

<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
           android:description="@string/servicedesc"
           android:requireDeviceUnlock="false">
    <aid-group android:description="@string/aiddescription"
               android:category="other">
        <aid-filter android:name="F0010203040506"/>
        <aid-filter android:name="F0394148148100"/>
    </aid-group>
</host-apdu-service>

<host-apdu-service> 標記必須包含 <android:description> 屬性，其中包含服務的使用者友善說明，可在應用程式 UI 中顯示。您可以使用 requireDeviceUnlock 屬性，指定在喚用此服務處理 APDU 之前，必須先解鎖裝置。

<host-apdu-service> 必須包含一或多個 <aid-group> 標記。每個 <aid-group> 代碼都必須執行以下操作：

• 包含 android:description 屬性，其中包含 AID 群組的友善使用者說明，適合在 UI 中顯示。
• 將其 android:category 屬性設為指示 AID 群組所屬類別，例如 CATEGORY_PAYMENT 或 CATEGORY_OTHER 定義的字串常數。
• 包含一或多個 <aid-filter> 標記，每個標記各含有一個 AID。請以十六進位格式指定 AID，並確保 AID 包含偶數個字元。

應用程式也必須擁有 NFC 權限，才能註冊為 HCE 服務。

AID 衝突解決

單一裝置上可能安裝多個 HostApduService 元件，且同一個 AID 可由多個服務註冊。Android 會使用下列步驟決定要叫用哪項服務：

1. 如果使用者選取的預設錢包應用程式已註冊 AID，系統就會叫用該應用程式。
2. 如果預設錢包應用程式未註冊 AID，系統會叫用已註冊 AID 的服務。
3. 如果有多項服務已註冊 AID，Android 會詢問使用者要叫用哪項服務。

前景服務偏好設定

前景中的應用程式可以叫用 setPreferredService，指定在特定活動處於前景時，應優先使用哪種卡片模擬服務。這個前景應用程式偏好設定會覆寫 AID 衝突解決方案。當應用程式預期使用者可能會使用 NFC 卡模擬功能時，建議採用此做法。

Android 13 以上版本

為讓橫幅廣告的顯示效果更符合「設定」UI 中的預設付款方式選單，請將橫幅廣告的顯示要求調整為方形圖示。理想情況下，應與應用程式啟動器圖示設計相同。這項調整可讓畫面更一致，並呈現更清晰的視覺效果。

Android 12 以下版本

將服務橫幅的大小設為 260x96 dp，然後在中繼資料 XML 檔案中設定服務橫幅的大小，方法是將 android:apduServiceBanner 屬性新增至指向可繪資源的 <host-apdu-service> 標記。以下是範例：

<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
        android:description="@string/servicedesc"
        android:requireDeviceUnlock="false"
        android:apduServiceBanner="@drawable/my_banner">
    <aid-group android:description="@string/aiddescription"
               android:category="payment">
        <aid-filter android:name="F0010203040506"/>
        <aid-filter android:name="F0394148148100"/>
    </aid-group>
</host-apdu-service>

錢包應用程式

Android 15 以上版本包含預設錢包應用程式角色，使用者可以依序前往「設定」>「應用程式」>「預設應用程式」來選取該角色。此屬性會定義在輕觸付款終端機時要叫用的預設錢包應用程式。Android 會將宣告支付類別的 AID 群組視為錢包應用程式。

確認您的應用程式是否為預設錢包應用程式

應用程式可以將 RoleManager.ROLE_WALLET 傳遞至 RoleManager.isRoleHeld()，藉此檢查是否為預設錢包應用程式。

如果您的應用程式不是預設應用程式，您可以將 RoleManager.ROLE_WALLET 傳遞至 RoleManager.createRequestRoleIntent()，以便要求預設錢包角色。

錢包應用程式所需的素材資源

為了提供更具視覺吸引力的使用者體驗，HCE 錢包應用程式必須提供服務橫幅。

觀察模式

Android 15 推出了「觀察模式」功能。啟用後，觀察模式可讓裝置觀察 NFC 輪詢迴圈，並將相關通知傳送至適當的 HostApduService 元件，以便準備與特定 NFC 終端機互動。HostApduService 可以將 true 傳遞至 setObserveModeEnabled()，將裝置設為觀察模式。這會指示 NFC 堆疊不允許 NFC 交易，而是被動地觀察輪詢迴圈。

輪詢迴圈篩選器

您可以使用下列任一方法，為 HostApduService 註冊輪詢迴圈篩選器：

• registerPollingLoopFilterForService()：適用於必須完全符合輪詢時間間隔的篩選器。
• registerPollingLoopPatternFilterForService()：用於篩選器，以規則運算式比對輪詢影格。

當輪詢迴圈篩選器與非標準輪詢影格相符時，NFC 堆疊會呼叫其 processPollingFrames() 方法，將這些輪詢影格轉送至對應的 HostApduService。這可讓服務採取必要步驟，確保使用者已準備好進行交易，且有意進行交易，例如驗證使用者。如果 NFC 讀取器在輪詢迴圈中只使用標準影格，NFC 堆疊會將這些輪詢影格路由至所需的前景服務 (如果該服務位於前景)，或預設錢包角色持有者 (如果該服務位於背景)。

輪詢影格通知也包含供應商特定的場強度量測值，您可以呼叫 getVendorSpecificGain() 擷取這項資料。只要廠商提供的評估結果可容納在單一位元組內，即可使用自訂比例提供評估結果。

回應輪詢迴圈並退出觀察模式

當服務準備好進行交易時，可以將 false 傳遞至 setObserveModeEnabled()，藉此退出觀察模式。接著，NFC 堆疊會允許交易繼續進行。

HostApduService 元件可在資訊清單中將 shouldDefaultToObserveMode 設為 true，或呼叫 CardEmulation.setShouldDefaultToObserveModeForService()，指出在偏好的付款服務為 HostApduService 元件時，應啟用觀察模式。

HostApduService 和 OffHostApduService 元件也可以指出，如果檢查輪詢迴圈篩選器與收到的檢查輪詢迴圈影格相符，則應自動停用觀察模式，並在資訊清單的 PollingLoopFilter 宣告中將 autoTransact 設為 true，以便允許交易繼續進行。

前景服務偏好設定

前景中的應用程式可以叫用 setPreferredService，指定在特定活動處於前景時，應優先使用哪種卡片模擬服務。這個前景應用程式偏好設定會覆寫裝置的觀察模式狀態，對應至特定服務的 shouldDefaultToObserveMode 值，可透過下列任一方式設定：

• 在該服務的資訊清單中設定 shouldDefaultToObserveMode 的狀態。
• 使用對應的服務和狀態叫用 CardEmulation.setShouldDefaultToObserveModeForService()。

螢幕關閉和鎖定螢幕的行為

HCE 服務的行為會因裝置上執行的 Android 版本而異。

Android 15 以上版本

如果預設錢包應用程式在支援的裝置上開啟觀察模式，則該應用程式會覆寫解鎖和關閉螢幕的行為，因為它會控制交易何時可以進行。如果觀察模式未偵測到可辨識的輪詢迴圈模式，某些錢包應用程式可能會要求解鎖裝置才能繼續交易。

建議開發人員與讀取器裝置合作，發出可辨識的輪詢迴圈模式，並註冊以處理這些模式。

Android 12 以上版本

在指定 Android 12 (API 級別 31) 以上版本的應用程式中，您可以將 requireDeviceScreenOn 設為 false，在裝置螢幕未開啟的情況下啟用 NFC 付款功能。

Android 10 以上版本

搭載 Android 10 (API 級別 29) 以上版本的裝置支援安全 NFC。當安全 NFC 開啟時，所有卡片模擬器 (主機應用程式和非主機應用程式) 在裝置螢幕關閉時無法使用。當安全 NFC 關閉時，非主機應用程式在裝置螢幕關閉時可供使用。您可以使用 isSecureNfcSupported() 檢查是否支援安全 NFC。

在搭載 Android 10 以上版本的裝置上，將 android:requireDeviceUnlock 設為 true 的功能與搭載 Android 9 以下版本的裝置相同，但僅適用於關閉安全 NFC 的情況。也就是說，如果啟用安全 NFC，無論 android:requireDeviceUnlock 的設定為何，HCE 服務都無法在鎖定畫面上運作。

Android 9 以下版本

在搭載 Android 9 (API 級別 28) 以下版本的裝置上，裝置螢幕關閉時，NFC 控制器和應用程式處理器會完全關閉，因此螢幕關閉時，HCE 服務就無法運作。

在 Android 9 以下版本中，HCE 服務也可以在螢幕鎖定時運作。不過，這項設定是由 HCE 服務的 <host-apdu-service> 標記中的 android:requireDeviceUnlock 屬性控制。根據預設，系統不需要解鎖裝置，即使裝置處於鎖定狀態，服務也會叫用。

如果您為 HCE 服務將 android:requireDeviceUnlock 屬性設為 true，當發生下列情況時，Android 會提示使用者解鎖裝置：

• 使用者輕觸 NFC 讀卡機。
• NFC 讀取器會選取可解析至服務的 AID。

解鎖後，Android 會顯示對話方塊，提示使用者再次輕觸即可完成交易。這是必要的，因為使用者可能會將裝置移離 NFC 讀卡機，以便解鎖。

與安全元件卡片共存

這個部分適用於部署了需要安全元素進行卡片模擬的應用程式。Android 的 HCE 實作方式與其他實作卡片模擬的其他方法 (包括使用安全元素) 並行運作。

注意： Android 不會提供 API，用於直接與安全元素本身進行通訊。

這項共存機制以「AID 路由」原則為基礎。NFC 控制器會保留路徑資料表，其中包含有限的路徑規則清單。每個轉送規則都包含 AID 和目的地。目的地可以是主機 CPU (執行 Android 應用程式的位置)，或是已連線的安全元素。

當 NFC 讀取器傳送含有 SELECT AID 的 APDU 時，NFC 控制器會解析該 APDU，並檢查 AID 是否與其路由表中的任何 AID 相符。如果相符，系統會將該 APDU 和後續的所有 APDU 傳送至與 AID 相關聯的目的地，直到收到另一個 SELECT AID APDU 或 NFC 連結中斷為止。

注意： 雖然 ISO/IEC 7816-4 也定義了部分比對的概念，但 Android HCE 裝置不支援這項功能。

圖 4 說明這個架構：

圖4. Android 同時支援安全元件和主機卡模擬。

NFC 控制器通常也會包含 APDU 的預設路徑。如果轉送表格中找不到 AID，系統會使用預設路徑。雖然這項設定可能因裝置而異，但 Android 裝置必須確保應用程式註冊的 AID 能正確路由至主機。

實作 HCE 服務或使用安全元件的 Android 應用程式，不必擔心設定路由表，因為這項作業會由 Android 自動處理。Android 只需要知道哪些 AID 可由 HCE 服務處理，哪些 AID 可由安全元件處理。系統會根據安裝的服務和使用者偏好的服務，自動設定路由表。

以下章節說明如何為使用安全元素進行卡片模擬的應用程式宣告 AID。

安全元件 AID 註冊

使用安全元素進行卡片模擬的應用程式可以在資訊清單中宣告主機外服務。這類服務的宣告幾乎與 HCE 服務的宣告相同。例外狀況如下：

• 意圖篩選器中使用的動作必須設為 SERVICE_INTERFACE。
• 中繼資料名稱屬性必須設為 SERVICE_META_DATA。

• 中繼資料 XML 檔案必須使用 <offhost-apdu-service> 根標記。

  <service android:name=".MyOffHostApduService" android:exported="true"
         android:permission="android.permission.BIND_NFC_SERVICE">
    <intent-filter>
        <action android:name="android.nfc.cardemulation.action.OFF_HOST_APDU_SERVICE"/>
    </intent-filter>
    <meta-data android:name="android.nfc.cardemulation.off_host_apdu_service"
               android:resource="@xml/apduservice"/>
  </service>

以下是註冊兩個 AID 的對應 apduservice.xml 檔案範例：

<offhost-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
           android:description="@string/servicedesc">
    <aid-group android:description="@string/subscription" android:category="other">
        <aid-filter android:name="F0010203040506"/>
        <aid-filter android:name="F0394148148100"/>
    </aid-group>
</offhost-apdu-service>

android:requireDeviceUnlock 屬性不適用於主機外服務，因為主機 CPU 不會參與交易，因此無法在裝置鎖定時防止安全元件執行交易。

如為付款應用程式，且可選做預設付款應用程式的主機外服務，則必須使用 android:apduServiceBanner 屬性。

主機外服務叫用

Android 不會啟動或繫結至宣告為「主機外」的服務，因為實際交易是由安全元素執行，而非由 Android 服務執行。服務宣告僅允許應用程式註冊安全元件上的 AID。

HCE 和安全性

HCE 架構提供一項核心安全機制：由於您的服務受到 BIND_NFC_SERVICE 系統權限保護，因此只有作業系統可以繫結至您的服務並與其通訊。這可確保您收到的任何 APDU 實際上是作業系統從 NFC 控制器收到的 APDU，且您傳回的任何 APDU 只會傳送至作業系統，而作業系統會直接將 APDU 轉送至 NFC 控制器。

最後，您需要考量應用程式傳送至 NFC 讀取器的資料來源。這項功能在 HCE 設計中是刻意分離的；它不會在意資料來源，只會確保資料安全地傳送至 NFC 控制器，並傳送至 NFC 讀取器。

如要安全地儲存及擷取您想透過 HCE 服務傳送的資料，您可以使用 Android 應用程式沙箱，將應用程式資料與其他應用程式隔離開來。如要進一步瞭解 Android 安全性，請參閱「安全性提示」。

通訊協定參數和詳細資料

開發人員如想瞭解 HCE 裝置在 NFC 協定抗衝突和啟用階段中使用的協定參數，請參閱本節。這樣一來，您就能建構可與 Android HCE 裝置相容的讀取器基礎架構。

Nfc-A (ISO/IEC 14443 type A) 通訊協定防衝突和啟用

在 Nfc-A 通訊協定啟用期間，系統會交換多個影格。

在交換過程的第一部分，HCE 裝置會提供其 UID；HCE 裝置應假設具有隨機 UID。也就是說，每次點選時，讀者看到的 UID 都是隨機產生的 UID。因此，NFC 讀取器不應依賴 HCE 裝置的 UID 做為驗證或識別的形式。

接著，NFC 讀取器可以傳送 SEL_REQ 指令，選取 HCE 裝置。HCE 裝置的 SEL_RES 回應至少會設定第 6 位元 (0x20)，表示裝置支援 ISO-DEP。請注意，SEL_RES 中的其他位元也可能會設定，例如表示支援 NFC-DEP (p2p) 協定。由於其他位元可能已設為 1，因此想要與 HCE 裝置互動的讀取器應明確檢查第 6 位元，且不將完整的 SEL_RES 與 0x20 的值進行比較。

ISO-DEP 啟用

Nfc-A 通訊協定啟用後，NFC 讀取器會啟動 ISO-DEP 通訊協定。它會傳送 RATS (Request for Answer To Select) 指令。NFC 控制器會產生 RATS 回應 (ATS)；ATS 無法透過 HCE 服務設定。不過，HCE 實作必須符合 NFC 論壇的 ATS 回應規定，因此 NFC 讀取器可以依據 NFC 論壇的規定，為任何 HCE 裝置設定這些參數。

以下章節將詳細說明 HCE 裝置上 NFC 控制器提供的 ATS 回應的個別位元組：

• TL：ATS 回應的長度。不得指出長度超過 20 個位元組。
• T0：所有 HCE 裝置都必須設定位元 5、6 和 7，表示 ATS 回應中包含 TA(1)、TB(1) 和 TC(1)。位元 1 到 4 表示 FSCI，用於編碼影格大小上限。在 HCE 裝置上，FSCI 的值必須介於 0 和 8 小時之間。
• T(A)1：定義讀取器和模擬器之間的比特率，以及是否可以不對稱。對於 HCE 裝置，我們沒有比特率要求或保證。
• T(B)1：位元 1 到 4 表示啟動畫面保護時間整數 (SFGI)。在 HCE 裝置上，SFGI 必須小於或等於 8 小時。位元 5 到 8 表示影格等待時間整數 (FWI)，並編碼影格等待時間 (FWT)。在 HCE 裝置上，FWI 必須小於或等於 8 小時。
• T(C)1：位元 5 表示支援「進階通訊協定功能」。HCE 裝置可能會支援「進階通訊協定功能」，也可能不會支援。位元 2 表示支援 DID。HCE 裝置可能支援或不支援 DID。位元 1 表示支援 NAD。HCE 裝置不得支援 NAD，並將位元 1 設為零。
• 歷來位元組：HCE 裝置最多可傳回 15 個歷來位元組。願意與 HCE 服務互動的 NFC 讀取器，不應對歷來位元組的內容或存在狀態做出任何假設。

請注意，許多 HCE 裝置可能會符合 EMVCo 聯合支付網路在「感應式通訊協定」規格中指定的通訊協定規定。請特別注意以下幾點：

• T0 中的 FSCI 必須介於 2 小時和 8 小時之間。
• T(A)1 必須設為 0x80，表示只支援 106 kbit/s 位元率，且不支援讀取器和模擬器之間的不對稱位元率。
• T(B)1 中的 FWI 必須小於或等於 7 小時。

APDU 資料交換

如先前所述，HCE 實作僅支援單一邏輯管道。嘗試在不同邏輯管道上選取應用程式，在 HCE 裝置上無法運作。