このページは Cloud Translation API によって翻訳されました。

ホストベースのカードエミュレーションの概要

NFC 機能を提供する Android デバイスの多くは、すでに NFC をサポートしていますカードエミュレーション。ほとんどの場合、カードは別のチップによってエミュレートされます。セキュアエレメントと呼ばれるデバイスです。携帯通信会社が提供する多くの SIM カードセキュアエレメントも含まれます。

Android 4.4 以降では、カードエミュレーションのための追加の方法が提供されます。 ホストベースのカードエミュレーションと呼ばれるセキュアエレメントを使用しない。この任意の Android アプリでカードをエミュレートして NFC と直接通信可能読み取りますこのトピックでは、ホストベースのカードエミュレーション（HCE）の動作について説明します。使用して NFC カードをエミュレートするアプリの開発方法についても手法です。

セキュアエレメントを使用したカードエミュレーション

セキュアエレメントを使用して NFC カードエミュレーションを提供する場合、エミュレートされた ID が、Android デバイスを介してデバイス上のセキュアエレメントにプロビジョニングされます。説明します。ユーザーがデバイスを NFC 端末にかざすと、コントローラにより、すべてのデータがリーダーから安全な要素です。図 1 に、このコンセプトを示します。

NFC コントローラを介してセキュアエレメントから情報を取得する NFC リーダーの図
図 1. セキュアエレメントを使用した NFC カードエミュレーション

セキュアエレメント自体が NFC 端末と通信するトランザクションに Android アプリは関与しません。取引の完了後完了すると、Android アプリはセキュアエレメントに対して直接、取引ステータスを表示し、ユーザーに通知します。

ホストベースのカードエミュレーション

ホストベースのカードエミュレーションを使用して NFC カードをエミュレートすると、データはセキュアエレメントにルーティングされることなく直接ホスト CPU にルーティングされます。図 2 ホストベースのカードエミュレーションの仕組みを示しています。

NFC コントローラを介して CPU から情報を取得する NFC リーダーの図
図 2. セキュアエレメントを使用しない NFC カードエミュレーション

サポートされている NFC カードとプロトコル

HCE プロトコルスタックを示す図
図 3. Android の HCE プロトコルスタック

NFC 規格はさまざまなプロトコルをサポートしています。さまざまなタイプのカードがエミュレートできます。

Android 4.4 以降では、市場で一般的に使用されている複数のプロトコルをサポートしています。今すぐ始めましょう。既存の非接触型カードの多くは、すでにこれらのプロトコルに基づいています。キャッシュレスの決済カードなども含まれますこれらのプロトコルは、現在市場で販売されている NFC リーダー（（IsoDep を参照）クラス）。これにより、エンドツーエンドの NFC ソリューションを構築してデプロイできます。 Android 搭載デバイスのみを使用する HCE。

具体的には、Android 4.4 以降では、以下をベースとするカードのエミュレートがサポートされています。 NFC-Forum ISO-DEP 仕様（ISO/IEC 14443-4 に基づく）とプロセス ISO/IEC 7816-4 で定義されている Application Protocol Data Unit（APDU）仕様。Android では、NFC-A 上でのみ ISO-DEP をエミュレートすることが義務付けられています（ISO/IEC 14443-3 Type A）の規格に準拠しています。Nfc-B（ISO/IEC 14443-4 Type B）をサポートオプションです。図 3 では、これらすべてのレイヤが階層化されています。仕様。

HCE サービス

Android の HCE アーキテクチャは Android をベースとしている Service コンポーネント（HCE） サービス）。サービスの主なメリットの 1 つは、バックグラウンドで実行することもできます。これは、多くの HCE に無理なく適合します。ポイントカードや交通機関のカードなどのアプリで利用できますが、ユーザーが使用するアプリを起動します。デバイスを NFC リーダーにかざすと、正しいサービス（まだ実行されていない場合、トランザクションを実行する場合）確認できます。もちろん、追加の UI（ユーザー通知など）を適宜配信する必要があります。

サービスの選択

ユーザーがデバイスを NFC リーダーにタップしたとき、Android システムは NFC リーダーが通信する HCE サービスを指定します。ISO/IEC 7816-4 仕様では、アプリケーションの選択方法が定義されています。アプリケーション ID（AID）。AID は最大 16 バイトで構成されます。エミュレートしている場合、既存の NFC リーダーインフラストラクチャのカード、それらのリーダーが使用している AID 一般的に、よく知られていて公的に登録されているもの（例: Visa や MasterCard などの決済ネットワークの AID）。

独自のアプリケーション用に新しいリーダーインフラストラクチャをデプロイする場合は、独自の AID を登録する必要があります。AID の登録手順は、 ISO/IEC 7816-5 仕様に準拠しています7816-5 に従って AID を登録することをおすすめします。 Android 向け HCE アプリをデプロイすると、競合を回避できる統合できます

AID グループ

場合によっては、HCE サービスは複数の AID を登録し、特定の AID を実装するために、すべての AID のデフォルトハンドラを説明します。グループ内の一部の AID が他のサービスに送信されることはサポートされていません。

まとめて管理される AID のリストは、AID グループと呼ばれます。1 つのモードのすべての AID は、 AID グループの場合、Android は次のいずれかを保証します。

グループ内のすべての AID は、この HCE サービスにルーティングされます。
グループ内の AID はこの HCE サービスにルーティングされません（たとえば、ユーザーが別のサービスを選択したため、グループ内の 1 つ以上の AID がリクエストされましたできます）。

つまり、グループ内の一部の AID にそれぞれ別の HCE サービスにルーティングできます。

AID グループとカテゴリ

各 AID グループはカテゴリに関連付けることができます。これにより、Android は HCE をカテゴリ別に分類することで、ユーザーがデフォルトで AID レベルではなくカテゴリレベルで設定されます。AID に言及しないアプリケーションのユーザー向け部分で使用しても、平均的なユーザーはそれほど多くありません

Android 4.4 以降では、次の 2 つのカテゴリがサポートされています。

CATEGORY_PAYMENT （業界標準の決済アプリをカバー）
CATEGORY_OTHER （他のすべての HCE アプリの場合）

で確認できます。

HCE サービスを実装する

ホストベースのカードエミュレーションを使用して NFC カードをエミュレートするには、 NFC トランザクションを処理する Service コンポーネント。

HCE のサポートを確認する

アプリは、デバイスが HCE をサポートしているかどうかを確認するには、 FEATURE_NFC_HOST_CARD_EMULATION 機能。<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 は、オーバーライドする必要がある 2 つの抽象メソッドを宣言し、説明します。そのうちの 1 つは processCommandApdu() NFC リーダーがアプリケーションプロトコルデータユニット（APDU）を送信するたびに呼び出される追加できますAPDU は、ISO/IEC 7816-4 仕様で定義されています。APDU NFC リーダーと NFC の間で送受信されるアプリレベルのパケット必要があります。そのアプリケーションレベルのプロトコルは半二重通信です。NFC リーダーはコマンド APDU を送信し、ユーザーが応答 APDU を送信するのを戻ります。

前述のように、Android は AID を使用して、リクエストする HCE サービスを答える必要があります。通常、NFC リーダーがデバイスは SELECT AID APDU である。この APDU には読者が希望する AID が含まれているあります。Android が APDU からその AID を抽出し、HCE に解決するその APDU を解決済みサービスに転送します。

レスポンスの APDU を送信するには、レスポンスの APDU のバイトを processCommandApdu()。このメソッドはメインスレッドで呼び出されます。ブロックできません。計算ができない場合に返す場合は null を返します。その後、必要な作業を別のスレッドに移動し、 sendResponseApdu() HostApduService クラスで定義されているメソッドを使用して、レスポンスをできます。

Android は、次のいずれかの状態になるまで、リーダーからサービスに新しい APDU を転送し続けます。次の処理が行われます。

NFC リーダーが別の SELECT AID APDU を送信し、OS がそれをあります。
NFC リーダーとデバイスとの間の NFC リンクが切断される。

どちらの場合も、クラスの onDeactivated() どちらが発生したかを示す引数を指定して実装が呼び出されます。

既存のリーダーインフラストラクチャを使用する場合は、既存のアプリケーションレベルのプロトコルを HCE サービスで読み込む必要があります。

自社が管理する新しいリーダーインフラストラクチャをデプロイする場合は、独自のプロトコルと APDU シーケンスを定義できます。APDU の数を制限してみるやり取りするデータのサイズを指定します。これにより、デバイスを NFC リーダーに短時間かざします。データの妥当な上限は約 1 KB です。これは通常、 300 ミリ秒以内に交換されます。

マニフェストでのサービスの宣言と AID の登録

通常どおりマニフェストでサービスを宣言する必要がありますが、いくつかの点を次の要素を追加します。

HCE サービスであることをプラットフォームに伝えるために、 HostApduService インターフェースを使用するには、次のインテントのインテントフィルタを SERVICE_INTERFACE アクションを追加します。
このサービスからどの AID グループがリクエストされるかをプラットフォームに伝えるには、 SERVICE_META_DATA サービスの宣言の <meta-data> タグ（XML を指す）リソースで HCE サービスに関する追加情報を確認してください。
android:exported 属性を true に設定し、 android.permission.BIND_NFC_SERVICE 権限をサービスの宣言で追加してください。前者は、外部アプリケーションがそのサービスにバインドできるようにするためのものです。後者では、IP アドレスを保持する外部アプリケーションのみが android.permission.BIND_NFC_SERVICE 権限をサービスにバインドできます。 android.permission.BIND_NFC_SERVICE はシステム権限であるため、 Android OS のみがサービスにバインドできる設定を効果的に強制適用できます。

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>

この meta-data タグでは apduservice.xml ファイルを指定します。以下は、 2 つの AID グループ宣言を含む 1 つの 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> 属性を含める必要がありますサービスにわかりやすい説明を表示できます。requireDeviceUnlock 属性を使用して、 APDU を処理するためにこのサービスを呼び出す前にデバイスのロックが解除されていること。

<host-apdu-service> には <aid-group> タグを含める必要があります。各次の操作を行うには、<aid-group> タグが必要です。

ユーザーフレンドリーな属性の android:description 属性が含まれている AID グループの説明。UI での表示に適しています。
AID のカテゴリを示す android:category 属性を設定するグループ（CATEGORY_PAYMENT で定義された文字列定数など）または CATEGORY_OTHER。
それぞれ 1 つの AID を含む <aid-filter> タグを 1 つ以上含めます。 AID を 16 進数形式で指定し、必ず偶数が含まれるようにします。あります。

また、アプリケーションは NFC 権限（以下として登録する） HCE サービス。

AID の競合の解決

1 台のデバイスに複数の HostApduService コンポーネントをインストールできます。同じ AID を複数のサービスに登録できます。Android が AID を解決 AID がどのカテゴリに属するかによって、競合は異なります。各競合解決ポリシーが異なる場合があります。

支払いなどの一部のカテゴリでは、ユーザーがデフォルトの Android の設定 UI で確認できます。その他のカテゴリの場合、ポリシーは競合が発生した場合に呼び出すサービスを常にユーザーに確認します。詳細情報特定のカテゴリの競合解決ポリシーをクエリする方法については、 getSelectionModeForCategory()。

サービスがデフォルトかどうかを確認する

アプリケーションは、その HCE サービスがサービスのデフォルトサービスとして特定のカテゴリを選択して isDefaultServiceForCategory() API

サービスがデフォルトでない場合は、デフォルトに設定するようリクエストできます ACTION_CHANGE_DEFAULT。

決済アプリ

Android では、 payment カテゴリを支払いアプリケーションとして指定します。Android 4.4 以降には、最上位の設定メニューエントリである「タップ &」payという決済アプリなどですこの設定メニューで決済デバイスがタップされたときに呼び出すデフォルトの決済アプリケーション。

決済アプリに必要なアセット

より視覚に訴えるユーザーエクスペリエンスを提供するため、HCE 決済アプリケーションはサービスバナーを表示する必要があります

Android 13 以降

設定 UI のデフォルトの支払い選択リストに合うように、正方形のアイコンに変更する必要があります。理想的には、アプリケーションランチャーアイコンのデザイン。この調整により整合性が高まり、見た目もすっきりします

Android 12 以前

サービスバナーのサイズを 260x96 dp に設定し、サービスバナーのサイズを設定する android:apduServiceBanner 属性をメタデータ XML ファイルに追加することで、ドローアブルリソースを指す <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>

画面オフとロック画面の動作

HCE サービスの動作は、搭載されている Android のバージョンによって異なります。クリックします。

Android 12 以降

Android 12（API レベル 31）以降をターゲットとするアプリでは、NFC を有効にできます。設定することで、デバイスの画面がオンにならなくても requireDeviceScreenOn～ false。

Android 10 以降

Android 10（API レベル 29）以降を搭載しているデバイスは安全性 NFC。セキュリティを確保 NFC がオンになっており、すべてのカードエミュレータ（ホストアプリケーションとオフホストアプリケーション）が使用できません。セキュア NFC が OFF のとき、オフホストデバイスの画面がオフのときにも使用できます。以下を確認できます: セキュア NFC サポート: isSecureNfcSupported()。

Android 10 以降を搭載したデバイスでは、デバイスと同様に、android:requireDeviceUnlock～trueが適用されます Android 9 以前を搭載している Android デバイス（セキュア NFC がオフになっている場合のみ）つまりセキュア NFC がオンになっています。HCE サービスはロック画面から機能しません android:requireDeviceUnlock の設定に関係なく適用されます。

Android 9 以前

Android 9（API レベル 28）以前を搭載しているデバイスでは、NFC コントローラと画面の表示が消えたとき、アプリケーションプロセッサはデバイスの電源がオフになっています。そのため、画面がオフのときは HCE サービスが機能しません。

また、Android 9 以前では、ロック画面から HCE サービスを機能させることができます。ただし、これは android:requireDeviceUnlock 属性によって制御されます。 HCE サービスの <host-apdu-service> タグ。デフォルトでは、デバイスのロック解除は不要で、デバイスがロックされていてもサービスが呼び出されます。

HCE で android:requireDeviceUnlock 属性を true に設定する場合サービスでは、次のような場合に、デバイスのロックを解除するよう求めるメッセージがユーザーに表示されます。目的:

ユーザーが NFC リーダーをタップしたとき。
NFC リーダーが、サービスに解決される AID を選択します。

ロックを解除すると、再度タップしてトランザクションを完了します。これは、ユーザーが NFC リーダーから離して、ロックを解除します。

セキュアエレメントカードとの共存

このセクションは、アプリケーションをデプロイしているデベロッパーを対象としていますカードエミュレーションにセキュアエレメントを使用するアプリの場合です。Android の HCE 実装は、カードを実装する他のメソッドと並行して動作するように設計されています。エミュレーションによって保護されています。

この併用は、AID ルーティングと呼ばれる原則に基づいています。NFC コントローラが、ルーティングテーブルを保持します。このテーブルは、有限のできます。各ルーティングルールには AID と宛先が含まれます。宛先は Android アプリが実行されているホスト CPU、または要素です。

NFC リーダーが SELECT AID を含む APDU を送信すると、NFC コントローラはその AID がルーティングテーブル内のいずれかの AID と一致するかどうかを確認します。もし一致した場合は、その APDU とそれに続くすべての APDU が宛先（別の SELECT AID APDU を受信するか、NFC が応答するまで）リンクが機能しない。

図 4 に、このアーキテクチャを示します。

セキュアエレメントと CPU の両方と通信する NFC リーダーの図
図 4. セキュアエレメントとホストカードエミュレーションの両方で動作する Android。

通常、NFC コントローラは APDU のデフォルトルートも含んでいます。特定の AID がルーティングテーブルに見つからない場合は、デフォルトルートが使用されます。このデバイスによって異なる場合があります。Android デバイスが必要です。アプリが登録されている AID がホストします。

HCE サービスを実装する Android アプリ、またはセキュアエレメントを使用する Android アプリルーティングテーブルの構成について気にする必要はありません処理 Android 搭載。Android 側で必要なのは、処理可能な AID を認識することだけですセキュアエレメントで処理できるものを指定します。ルーティングインストールされているサービスに基づいて自動的に構成され、ユーザーが優先として設定した広告です

次のセクションでは、カードエミュレーション用のセキュアエレメントです。

セキュアエレメントの AID の登録

カードエミュレーションにセキュアエレメントを使用するアプリは、 オフホストサービスをマニフェストで指定する必要があります。このようなサービスの宣言は、これは HCE サービスの宣言とほぼ同じです。例外は次のとおりです。次のようになります。

インテントフィルタで使用するアクションは、 SERVICE_INTERFACE。
meta-data の name 属性を 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>

対応する apduservice.xml ファイルの例を次に示します。 2 つの AID を登録する:

<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 は、「オフホスト」と宣言されたサービスを開始したり、バインドしたりすることはありません。実際のトランザクションはセキュアエレメントによって実行され、呼び出すことができます。Service の宣言では、アプリがセキュアエレメントに存在する AID を登録します。

HCE とセキュリティ

HCE アーキテクチャは、セキュリティのコア部分の 1 つを提供します。保護されているとは限りません。 BIND_NFC_SERVICE サービスにバインドして通信できるのは OS のみです。これにより、受信する APDU が実際には APDU を NFC コントローラからそして OS が APDU を NFC コントローラに直接転送します。

最後の懸念事項は、アプリが送信するデータをどこで取得するかです。渡します。HCE の設計では、これは意図的に分離されています。はいデータの出所は気にせずデータが安全に NFC コントローラに送られ、NFC リーダーに送出されます。

HCE から送信するデータを安全に保存、取得するためたとえば、Android Application Sandbox を使用することができます。アプリのデータを他のアプリから分離します。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）プロトコルで暗号化されます。他のビットが設定されている可能性があるため、 HCE デバイスは 6 番目のビットのみを明示的にチェックし、比較は行わない 値が 0x20 の完全な SEL_RES。

ISO-DEP の有効化

Nfc-A プロトコルが有効になったら、NFC リーダーが ISO-DEP を開始します。プロトコルアクティベーション。RATS（Request for Answer To Select）を送信します。使用できます。NFC コントローラが、RATS 応答である ATS を生成します。ATS は HCE サービスで構成できます。ただし、HCE の実装は NFC フォーラムを満たしている必要があります必要があります。これにより、NFC リーダーはこれらのパラメータを信頼できます。すべての HCE デバイスに関する NFC フォーラムの要件に従って設定されている。

以下のセクションでは、ATS の個々のバイトについて詳しく説明します。 HCE デバイス上の NFC コントローラから返されるレスポンスは次のようになります。

TL: ATS 応答の長さ。20 を超える長さを指定することはできませんあります。
T0: すべての HCE デバイスでビット 5、6、7 を設定する必要がある。これは、TA(1)、TB(1) であることを示すおよび TC(1) が ATS 応答に含まれる。ビット 1 ～ 4 は FSCI、渡します。HCE デバイスでは、FSCI の値を 0h ～ 8h の間で指定します
T(A)1: リーダーとエミュレータ間のビットレート、およびそれらのビットレートが非対称ですHCE デバイスに対するビットレートの要件または保証はありません。
T（B）1: ビット 1～4 は、開始フレーム保護時間整数値（SFGI）を示します。オン HCE デバイスでは、SFGI は 8 時間以下である必要があります。ビット 5 ～ 8 はフレーム待機中を示す time 整数（FWI）で、フレーム待機時間（FWT）をコード化します。HCE デバイスでは、FWI 8h 以下であることが必要です。
T（C）1: ビット 5 は、「高度なプロトコル機能」のサポート状況を示します。HCE デバイス「高度なプロトコル機能」に対応している場合とできない場合があります。ビット 2 はサポートを示しますあります。HCE デバイスでは DID をサポートしている場合と、サポートしていない場合とがあります。ビット 1 は、 NAD。HCE デバイスでは NAD をサポートしてはならないため、ビット 1 はゼロに設定してください。
ヒストリカルバイト: HCE デバイスは、最大 15 バイトのヒストリカルバイトを返すことがあります。NFC HCE サービスを利用する場合は、履歴バイトの内容やその存在を検出できます。

多くの HCE デバイスは、プロトコル要件に準拠している可能性があります。 EMVCo に統合されている決済ネットワークが「非接触型決済通信プロトコル」仕様。具体的には、次のとおりです。

T0 の FSCI は 2h～8h の間でなければならない。
T(A)1 は、106 kbit/s のビットレートのみを示す 0x80 に設定する必要があります。非対称ビットレートはサポート対象外です。サポートされません。
T（B）1 の FWI は 7h 以下である必要がある。

APDU データの交換

前述のように、HCE 実装は単一の論理チャンネルのみをサポートします。異なる論理チャネルでアプリケーションを選択しようとしても動作しない HCE デバイスが必要です