PCI Watch

Tracking changes across the Payment Card Industry

EMV® Mobile Product Level 1 Type Approval – Level 1 Test Application Requirements

v2.0.2.r Test Cases & Test Environments
ContactlessMobile NFC Consumer Device

EMV® Mobile Product Level 1 Type Approval Level 1 Test Application Requirements Version 2.0.2.r September 2025

v2.0.2.r

Legal Notice

Page i This document summarizes EMVCo’s present plans for evaluation services and related policies and is subject to change by EMVCo at any time. This document does not create any binding obligations upon EMVCo or any third party regarding the subject matter of this document, which obligations will exist, if at all, only to the extent set forth in separate written agreements executed by EMVCo or such third parties. In the absence of such a written agreement, no product provider, test laboratory or any other third party should rely on this document, and EMVCo shall not be liable for any such reliance. No product provider, test laboratory or other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a product provider, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter, compliance certificate or similar document issued by EMVCo. All other references to EMVCo approval are strictly prohibited by EMVCo. Under no circumstances should EMVCo approvals, when granted, be construed to imply any endorsement or warranty regarding the security, functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received evaluations or approvals, and to the evaluation process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or noninfringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, AS TO THIS DOCUMENT. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to this document. EMVCo undertakes no responsibility to determine whether any implementation of this document may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of this document should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, this document may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement this document is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party's infringement of any intellectual property rights in connection with this document.

v2.0.2.r

Revision Log – Version 2.0.2.r The following changes have been made to the document since the publication of Version 2.0.2. Some of the numbering and cross references in this version have been updated to reflect changes introduced by the published bulletins. The numbering of existing requirements did not change, unless explicitly stated otherwise. Incorporated changes described in the following Specification Updates:

  • None Other editorial changes:
  • Editorial updates v2.0.2.r 1. 1. 1.2. 1. 3. 3.1.1 3.1.2 3.1. 3. 3.2. 3.2. 3.2. 3.2. 3.2. 3.2. 3.2. 3.2. 3.2. 3.2. 3. v2.0.2.r v2.0.2.r Page v v2.0.2.r 1 About this document / 31 1.1

Introduction

EMVCo Mobile Product Level 1 Type Approval Process currently requires that the execution environment under test (EEUT) of the Mobile Product under test contains a Test Application supporting the requirements described in this document in order to perform Level 1 Analogue and Digital testing. Also, as indicated in [EMV ADMIN], depending on the capabilities of the mobile product, the EEUT shall request contactless configurations as defined in this document (see section 2). The purpose of this document is to publish the Test Application requirements allowing third party implementations. To support the type approval process EMVCo makes available:

  • for UICC EEUT: a set of reference UICCs with an EMVCo Test Application and the Test Profiles defined in this document.
  • for GP compliant eSE EEUT: the Test Application CAP file (used in the reference UICC) as well as personalization scripts.
  • for Android HCE EEUT: An EMV HCE Level 1 Test Application (pre personalized). All above deliverables can be obtained by product provider and laboratories upon signature of a license agreement with EMVCo. The appendixes provide additional information on how to implement, instantiate, personalize and/or load the EMVCo Test Applications. For the other product architecture, the implementation, loading, instantiation and personalization of the Test Application shall be performed by the product provider. Note: EMVCo makes no guarantee that all EMVCo analogue and digital qualified tools are compatible with such third party implementations nor with all non-SWP/UICC architectures. Note: EMVCo will not qualify third party implementations and will not provide any support when test cases or test tool are used in conjunction with a third party implementation. v2.0.2.r / 31 1.2 Reference Documents EMV documents are available on the EMVCo web site: http://www.emvco.com/approvals.aspx and http://www.emvco.com/specifications.aspx 1.2.1 Specification Documents Reference Document [EMV ADMIN] [EMV CPS] EMV Mobile Product Level 1 Type Approval – Administrative Process EMV Card Personalization Specification Version Issue date Latest Version 2.0 [EMV CCD] [GP Card Spec] [GP Amend C] [RSA] EMV Card Type Approval – CCD Level 1 and Level 2 – Card Images Requirements GlobalPlatform Card Specification GlobalPlatform Card Contactless Services Card Specification v2.2 – Amendment C R. L. Rivest, A. Shamir, and L. Adleman, ‘A method for obtaining digital signatures and public key cryptosystems,’ Communications of the ACM, vol. 21, 1978, pp. 120-126 Latest Version 2.2.1 January 2011 Version 1.1 April 2013 1.3 Abbreviations The following abbreviations and notations are used in this document Abbreviation

Description

AC Application Cryptogram AFI Application Family Identifier AFL Application File Locator AID Application IDentifier APDU Application Protocol Data Unit App Data Application Data ATQA

Answer

To reQuest, Type A CID Card IDentifier (when L1 context) CID Cryptogram Information Data (when L2 context) CLA CLAss CRC Cyclic Redundancy Check error detection code

v2.0.2.r

/ 31 Abbreviation DF DGI EEUT ETSI FCI FWI GPO HCI ICC INS L1 L2 NFC PDOL PICC PUPI SAK SE SFGI SFI SW UID UICC Variable Parameter Description Dedicated File Data Group Identifier Execution Environment Under test European Telecommunications Standards Institute File Control Information Frame Waiting time Integer Get Processing Options Host Controller Interface Integrated Circuit Card INStruction Level 1 Level 2 Near Field Communication Processing Options Data Object List proximity integrated circuit card Pseudo-Unique PICC Identifier, Type B Select AcKnowledge, Type A Secure Element Start-up Frame Guard time Integer Short File Identifier Status Word Unique IDentifier, Type A Universal Integrated Circuit Card Contactless Parameter which can be set by the SE according to ETSI 102 622 (HCI)

v2.0.2.r

/ 31 2 Test Profiles EMVCo has defined Test Profiles that shall be used during mobile product level 1 type approval testing when applicable according to [EMV ADMIN]. For each Digital parameter that can be set by the execution environment under test, the multiple Test Profiles permit to test a range of values that are in line with [EMV CPS]. These profiles are defined in the two tables below: UID SAK ATQA UID size Anticollision Byte 2 FWI SFGI CID Values A1 A2 A3 A4 Dyn/ Size1/ Dynamic Size2/Size3 (Empty) Size 1 AA AA AA AAh Size 2 00 11 22 33 44 55 66h Size 3 FF EE DD CC BB AA 99 88 77 66h xx1x x0xxb 11111011b 00100000b 01101000b 10101010b 01 00h 10 0Ch 48 0Fh 82 05h 0-2 0 0 1 2 x xxxxb 0 0001b 1 x set to 0 1 0000b 0 1000b 0 0010b 0Xh 00h 0Ch 0Fh 05h 0h-7h 0 7 6 1 0h-8h 0 8 7 1 No/Yes No Yes No No Table 2-1: Type A Profiles Values B1 B2 AB UID Dyn/ Size1/ Size2/Size3 Dynamic (Empty) SAK xx1x x0xxb 00100000b ATQA UID size Anticollision 0-2 x xxxxb 1x set to 0 04 00h 0 0 0100b Byte 2 0Xh 00h FWI 0h-7h 3 SFGI 0h-8h 4 CID No/Yes No

v2.0.2.r PUPI FWI App Data AFI CRC_AID Number Apps CID, NAD Rand/stat 0h-7h No/Yes XXh XX XXh Random (Empty) 0h No 00h 00 00h Static 11 22 33 44h 7h Yes 2Dh AE DFh Random (Empty) 5h No 00h 00 00h XXh 00h 05h 00h No/Yes No Yes No Table 2-2: Type B and A+B Profiles

/ 31

v2.0.2.r 3 Description of the Test Application This section describes:

  • what data shall be defined in the application (generic);
  • the commands/responses that shall be supported;
  • information on personalization values. / 31 3.1 Data This section indicates what data shall be defined in an instance of the Test Application.

3.1.1 AID The AID of the application permits to select the application

Its value is set during the instantiation of the application. Note: several instances of one application can be activated simultaneously in a SE.

3.1.2 Data Grouping Identifiers (DGI) This section describes the DGIs to be used for the Personalization of the Test Application. DGI # Meaning Size in DGI Origin byte ‘5001’ ‘5002’ ‘5003’ ‘5004’ ‘5005’ ‘5006’ ‘5007’ Select response (including template) GPO response (including template) 1-255 1-255 Generate AC response (including template) INS Case 2 response (including template) INS Case 4 response (including template) Calibration value – UnitaryStep 1-247 1-255 1-255 2 This optional tag defines a 2 byte 14 waiting time per command type This document This document This document This document This document This document This document Presence (M=mandatory, O=optional) M M M M M M O (‘00000000000 000000000000 00000 by default if not personalized)

v2.0.2.r

/ 31 ‘5008’ ICC public key modulus 64 to This O 248 document ‘5009’ ICC public key exponent 01 or This O 03 document ‘8201’ ICC key CRT constant p-1 mod q 32-124 [EMV CPS] O ‘8202’ ICC key CRT constant d mod (p-1) 32-124 [EMV CPS] O ‘8203’ ICC key CRT constant d mod (q-1) 32-124 [EMV CPS] O ‘8204’ ICC key CRT constant prime factor 32-124 [EMV CPS] O P ‘8205’ ICC key CRT constant prime factor 32-124 [EMV CPS] O Q ‘XXYY’ Record ‘YY’ of SFI ‘XX’ Where ‘XX’ is in [01h;1Eh] Where ‘YY’ is in [01h;FFh] 1-255 [EMV CPS] O Table 3-1: DGIs 1. DGI=’5001’ to ‘5005’: For the DGI corresponding to the command response (range 5001-5005), the new data size (set during a second (or more) Personalization session) may be higher (or lower) than the existing ones. Note that if a template is expected in the command response (i.e. template 77 for generate AC response), it shall be included in the associated DGI; no check is done on the DGI value. 2. DGI=’5006’: The calibration value permits to calibrate the steps of the waiting time induced by the Test Application after all commands following the Get Processing Options command (i.e. UnitaryStep value). The Calibration Value (DGI 5006) shall be configured to define a step of 1ms. 3. DGI=’5007’: The waiting time value permits to define a specific waiting time for each supported command. It contains a 2-byte delay per command type as per the sequence: SELECT/GPO/ReadRecord/GENAC/CASE4/CASE2/OTHER. Refer to 3.2.2. 4. DGI=’5008’ and ‘5009’: When the ICC Public Key modulus and exponent are personalized (to execute the signature during Generate AC command), then the 2 DGIs must be present. The card verifies that the ICC Public Key modulus and exponent is completely initialized. Key modulus size until 248 bytes is supported. When ICC Public Key modulus and exponent are personalized, it is possible to update them (during a new Personalization session) but the key size cannot be updated. 5. DGI=’8201’ to ‘8205’: When the ICC Key is personalized (to execute 2 signatures during Generate AC command), then all the DGIs containing the CRT parameters must be present.

v2.0.2.r

/ 31 The card verifies that the ICC Private Key is completely initialized. Key modulus size until 248 bytes is supported. When a ICC key is personalized, it is possible to update it (during a new Personalization session) but the key size cannot be updated. When the ICC Key is not personalized, then none of the DGIs, containing the CRT parameters, must be present.

3.1.3 Records The records referenced in the AFL are stored in DGIs in an ‘XXYY’ format:

  • XX’ represents the SFI in which the record is stored and shall be in the range [1, 30] ([01h;1Eh]).
  • ‘YY’ represents the record number and shall be in the range [1, 255] ([01h; FFh]). The number of records is limited to 32 for one instance of the Test Application. The size of a record must be less than or equal to 255 bytes for the Personalization phase (during re-Personalization, it is possible to update the size of a record). During a second (or more) Personalization session:
  • a record may be updated (with a higher or lower size);
  • new records may be added (32 records may exist), but no record can be deleted. v2.0.2.r / 31 3.2 Commands and Responses The Test Application shall implement the following commands.

3.2.1 Select Command The Select command has to be sent to the mobile product in order to select the Test Application.

3.2.1.1 Code CLA INS P1 P2 Lc Data Command Value ‘00’ ‘A4’ Reference control parameter Selection Options parameter '05'–'10' File name – AID to select E.g. 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 (2PAY.SYS.DDF01) Le Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) P1 value, Reference control parameter: b8 b7 b6 b5 b4 b3 b2 b1 Value 0 0 0 0 0 1 Select by name P2 value, Selection Options parameter: 0 0 b8 b7 b6 b5 b4 b3 b2 b1 Value 0 0 First or only occurrence 1 0 Next occurrence 3.2.1.2 Code Data Response Value Data defined in DGI ‘5001’

v2.0.2.r SW ’90 00’ ‘67 00’ if Lc is erroneous

/ 31 3.2.2 Get Processing Options (GPO) Command 3.2.2.1 Code CLA INS P1 P2 Lc Data Le Command Value ‘80’ ‘A8’ Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) Any value (disregarded) E.g. ‘00’ Length of Data to be sent Byte 1-2: Any value (disregarded) Byte 3-4= ‘XX YY’ (Waiting Time) Other bytes: the other bytes may be set to any value (disregarded) E.g.: Processing Options Data Object List (PDOL) related data Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) All responses following the GPO Response (GPO Response included) will be sent with an extra processing time: (XX * 256 * UnitaryStep + YY * UnitaryStep). If Lc < 4 byte, ‘XX YY’ = ’00 00’ i.e. the waiting time is 0. The delay is always present except when the Status word ‘6300’ or ‘6400’ is returned. The delay is computed as follow:

  • If the GPO waiting time XXYY is different from ‘0000’, the same delay is used for all subsequent commands and is computed as follow: Delay = “waiting Time” * “Calibration” * unitary loop.
  • If the GPO waiting time XXYY is set to ‘0000’, a specific delay is used for each command type and is computed as follow: Delay for command Type X = “waiting Time for command Type X” * “Calibration” * unitary loop. Where:
  • “waiting Time for command Type X” is the value set in DGI ‘5007’;
  • “unitary loop” is the duration of a unitary loop implemented in the Test Application to create some delay and;
  • The “calibration” factor is a parameter used to fine tune an incremental step (UnitaryStep) independent from the device running the Test Application. The Test Application personalizer shall configure the “calibration” factor value in order to tune v2.0.2.r / 31 this incremental step to 1ms. The Test Application personalization script shall be modified accordingly. Note: Whenever possible the unitary loop should be replaced by a timer set to 1ms. In such a case the “calibration” factor shall be set to 1.

3.2.2.2 Code Data SW Response Value Data defined in DGI ‘5002’ ’90 00’ ‘67 00’ if Lc is erroneous or less than 4 bytes.

3.2.3 Generate Application Cryptogram (Generate AC) Command 3.2.3.1 Code CLA INS P1 P2 Lc Data Le Command Value ‘80’ ‘AE’ Any value (disregarded) E.g. Reference control parameter Any value (disregarded) E.g. ‘00’ Length of Data to be sent Any value E.g.: Transaction-related data ‘00’ The Test Application shall perform the following steps when receiving Generate AC command: 1. Check the presence of the ICC key CRT components. If the ICC key is not present the Test Application stops the processing and returns a SW ’69 82’. 2. Execute an encryption using the ICC key CRT components (as per guidance notes below). 3. Verify the encryption using the ICC key CRT components (as per guidance notes below): a. If the verification of the RSA encryption fails, the Test Application shall stop the processing and return a SW ’69 82’. b. If the verification of the encryption is OK, then the Test Application shall return the following data:

  • the content of DGI ‘5003' v2.0.2.r
  • the 8 least significant bytes of the encryption result
  • SW ’90 00’ / 31 v2.0.2.r / 31 Guidance notes on RSA Encryption and Verification The RSA Encryption uses a reversible asymmetric algorithm consisting of an encryption function Encrypt(SK)[ ] depending on a Private Key SK, and a decrypt function Decrypt(PK)[ ] depending on a Public Key PK. Both functions map N-byte numbers onto N-byte numbers and have the property that Decrypt(PK)[Encrypt(SK)[X]] = X. This reversible algorithm is the approved algorithm described in [RSA][RSA][RSA][RSA][RSA][RSA][RSA]. The RSA encryption calculated by the Test Application at Step 2 is performed using the following instructions:
  • The application extracts the data received in the incoming Generate AC command and builds M (the message to encrypt). a. If the incoming data length is less than the ICC public key modulus length, left pad it with ‘00’ bytes to the length of the ICC public key modulus to obtain M (If no data is received then M is only composed of padding bytes ‘00’). b. If the incoming data length is longer or equal to the ICC public key modulus length, right truncate it to the length of the ICC public key modulus minus 1 byte and left pad it with one byte ‘00’ to obtain M. Note: right truncation is made by removing bytes from the right of the incoming data.
  • The Test Application encrypts M by performing a RSA encryption using the ICC Private Key CRT components (SK). S= Encrypt(SK)[M].
  • The Test Application decrypt S by performing a RSA decryption using the ICC Public Key modulus and the exponent (PK). M’= Encrypt(PK)[S]. The Test Application verifies that M’=M during Step 3.

3.2.3.2 Code Data SW Response Value Data defined in DGI ‘5003’ 8 least significant bytes of the RSA encryption ’90 00’ ‘67 00’ if Lc is erroneous ’69 82’ if the verification of the signature is failing or if the ICC key is not personalized

v2.0.2.r 3.2.4 Read Record Command 3.2.4.1 Code CLA INS P1 P2 Lc Data Le Command Value ‘00’ ‘B2’ Record number Reference control parameter Not present Not present Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default)

/ 31 P2 value, Reference control parameter: b8 b7 b6 b5 b4 b3 b2 b1 Value x x x x x SFI 1 0 0 P1 is a record number 0 0 3.2.4.2 Code Data SW Response Value Le bytes of the record ’90 00’ ‘67 00’ if Lc is erroneous

v2.0.2.r 3.2.5 Command Instruction Code 0x36 3.2.5.1 Code CLA INS P1 P2 Lc Data Le Command Value ‘00’ ‘36’ Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) Length of Data to be sent Any value (disregarded) Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) 3.2.5.2 Code Data SW Response Value Not present ’63 00’ This Command Instruction Code cannot be updated by Personalization.

/ 31

v2.0.2.r

/ 31 3.2.6 Get Data Command The Get Data command permits to obtain information on the current version of the Test Application, the calibration value and the delays personalized in DGI ‘5007’.

3.2.6.1 Code CLA INS P1 P2 Lc Data Le Command Value ‘00’ ‘CA’ ‘DF’ ‘01’: request application version ‘02’: request calibration value as indicated in DGI ‘5006’ ‘03’: request delays as indicated in DGI ‘5007’ Not present Not present Maximum Length of data to be returned (‘00’ by default) 3.2.6.2 Code Data SW Response Value If P2=’01’: ‘76 32 2E 30 32 20 30 38 6A 75 6E 32 32’ If P2=’02’: Data defined in DGI ‘5006’ (Calibration value) If P3=’03’: Data defined in DGI ‘5007’ or array of null bytes ’90 00’ ‘6A 80’ P1-P2 is erroneous

v2.0.2.r 3.2.7 Command Instruction Code 0x46 3.2.7.1 Code CLA INS P1 P2 Lc Data Le Command Value ‘00’ ‘46’ Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) Length of Data to be sent Any value (disregarded) Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) 3.2.7.2 Code Data SW Response Value Not present ’64 00’ This Command Instruction Code cannot be updated by Personalization

/ 31

v2.0.2.r 3.2.8 INS case 2 3.2.8.1 Code CLA INS P1 P2 Lc Data Le Command Value ‘00’ xxxx x010b (except ‘AE’, ‘B2’, ‘CA’, ‘46’ or ‘36’) E.g. ‘02’ Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) Not present Not present Maximum Length of data to be returned (‘00’ by default) 3.2.8.2 Code Data SW Response Value Le bytes of Data defined in DGI ‘5004’ ’90 00’ ‘67 00’ if Lc is erroneous

/ 31

v2.0.2.r 3.2.9 INS case 4 3.2.9.1 Code CLA INS P1 P2 Lc Data Le Command Value ‘00’ xxxx x100b (except ‘A4’) E.g. ‘04’ Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) Length of Data to be sent Any value (disregarded) Maximum Length of data to be returned (‘00’ by default) 3.2.9.2 Code Data SW Response Value Le bytes of Data defined in DGI ‘5005’ ’90 00’ ‘67 00’ if Lc is erroneous

/ 31

v2.0.2.r 3.2.10 INS Case 3 or Case 1 3.2.10.1 Command Code CLA INS P1 P2 Lc Data Le Value ‘00’ All other INS values E.g. ‘01’ or ‘EE’ Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) Any value (disregarded) E.g. Maximum Length of data to be returned (‘00’ by default) Length of Data to be sent Lc=’00’ for INS case 1 ‘00’<Lc 80 E2 00 00 FA 02 01 FA 01 02 03 04 05 06 07 08 09 0A 0B 0C …EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7;

  • Second command containing the remaining data > 80 E2 00 00 03 F8 F9 FA. v2.0.2.r / 31 Annex B EMV HCE Level 1 Test Application This appendix describes how the HCE Android compliant EMVCo Test Application implementing the requirements described in this spec is installed and started as well as the minimum product requirements to support this Test Application. Note that the EMV HCE Level 1 Test Application is already pre personalized with the values described in section 3.3. B.1 Minimum Requirements: To install EMV HCE Level 1 Test Application the Minimum OS requirements with the product under test is Android operating system with version 9.0 or above. B.2 Installation There may be multiple methods of installing the application. The method below could be applicable for certain product implementations and is provided as an example. B.2.1 Enabling installation of applications from unknown sources Please note that, since this application is not distributed via the Google Play Store or any other App store, the installation of apps from unknown sources has to be allowed. This can be done via Settings > Security > Unknown sources. B.2.2 Installing the application 1. Copy apk file onto the device using a USB cable or using any other mean such as transferring via Bluetooth. To achieve this first the correct USB driver for the phone needs to be installed in the PC connected. 2. Copy the application to the product to be tested under a folder. Note the folder path. 3. On the handset, browse to the apk file, using the default file browsing application on the device. Note: Such file browsing application may be vary based on manufacturers. The most common one is the “My Files” under “Applications” tab. 4. Locate the EMV HCE Level 1 Test Application in the folder noted before in the handset and open it. The device will prompt to install the application. In some cases the handset may have proprietary methods of installing the application in the handset based on the manufacturer software. There may be a proprietary application installed in the PC connected to the handset to make installation easier. These methods are allowed to use as long as the application is correctly installed and in working condition. v2.0.2.r / 31 B.2.3 Running the application: Running the application may similarly have various ways. In some implementations as soon as the application is installed the operating system give option to open the application. In other cases the application can be found under “Applications” tab and opened there. B.2.4 Confirmation: Please note that normally, the application does not have to be explicitly opened for the HCE service to be active. Opening the application from the Application drawer will just show a dummy GUI. Once the Application is installed, the HCE service will always be running in the background when NFC is enabled and the EMV HCE Level 1 Test Application is selected from the Settings (if necessary). To select the HCE application from the settings the sequence below is applicable:
  • Once the application is installed correctly, the HCE service will appear in Settings > NFC > Tap & pay.
  • In some cases this sequence would be Settings > General > Tap & pay. B.2.5 Additional considerations: Screen Timeout
  • On some devices, the HCE service is disabled when the device’s screen is off. To prevent this from happening while testing, the ‘Screen Timeout’ value should be set as high as possible. This can be done via Settings > Display > Screen timeout.
  • It may also be possible to force the device to stay awake while charging in the Developer Options. If the ‘Developer Option’ button is not present in the Settings menu, it can be activated by going to ‘About Phone’ and tap the ‘Build Number’ 7 times. This will make the ‘Developer Options’ button appear where the option ‘Stay awake – screen will never sleep while charging’ can be enabled. B.3 Personalization Process The application supports a simplified proprietary personalization mode to update the DGI values. It is described hereafter. This mode is based on Common Personalization with the following differences:
  • No need for Initialize for Update, nor External Authenticate;
  • Store Data command use CLA=80 and all command data contain DGI values in plaintext;
  • No need to set P1 of the last Store Data to 0x80. The personalization of a DGI is effective immediately after the Store Data. Note 1: The personalization of DGI ‘5006’ is not supported since the HCE applet is using Android functionality to define a timer of 1ms. Consequently DGI ‘5006’ is useless. v2.0.2.r / 31 Note 2: The functionality associated to DGI ‘5007’ is not supported in this version of application. Note 3: The application supports Store Date Spanning over 2 Store Data in case the data is too long to fit into a single Store Data. The data field of the second store data command shall then only contain the remaining data that did not fit into the first store data command. It does not have to contain the DGI and DGI length anymore. For example:
  • First Store Data for spanning > 80 E2 00 00 FA 02 01 FA 01 02 03 04 05 06 07 08 09 0A 0B 0C …EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7;
  • Second command containing the remaining data > 80 E2 00 00 03 F8 F9 FA. v2.0.2.r / 31 *** END OF DOCUMENT *** © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.