AID is the "name" that you assign to your smart card application (in the case of HCE: an Android application that emulates a card application). The reader application uses this "name" to access your card application (HCE) using the APDU SELECT (DF name / AID) command (see ISO / IEC 7816-4). You can use whatever value you want if it is in accordance with ISO / IEC 7816-4.
In your particular case, the application uses the AID application F0010203040506
private static final byte[] AID_ANDROID = { (byte)0xF0, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06 };
Therefore, to be compatible with this example, you need to register your HCE service for AID F0010203040506 .
How to assign and use AID?
Usually you first define a "name" for your HCE application:
<host-apdu-service ...> <aid-group ...> <aid-filter android:name="F0010203040506"/> </aid-group> </host-apdu-service>
Later, reader applications can use this name to select your HCE application and then contact it (in Java, for example, using Java Smart Card IO):
Card card = ...; CardChannel c = card.getBasicChannel(); // SELECT by AID (F0010203040506) ResponseAPDU resp = c.transmit(new CommandAPDU( 0x00, 0xA4, 0x04, 0x00, new byte[] { (byte)0xF0, (byte)0x01, (byte)0x02, (byte)0x03, (byte)0x04, (byte)0x05, (byte)0x06 })); assert resp.getSW() == 0x9000; // Send application-specific command (what such a command could look like depends on your application) resp = c.transmit(new CommandAPDU( 0x80, 0x10, 0x00, 0x00, new byte[] { (byte)0x12, (byte)0x34 }));
How do you get the value for AID?
It depends on your application script.
In your closed loop scenario, where you are under full control of both the HCE side and the reader side, you can choose an arbitrary (note that the rules for AIDs ) AID and assign it to your HCE application. You can later use this AID in your application to read HCE applications.
In real-world HCE scenarios, you often develop an HCE application to interact with your existing reader infrastructure. Therefore, your HCE application will comply with some of these specifications. In this case, such a specification will determine the AID (or AID) that your HCE application must use in order to be detected by the existing reader infrastructure. An example of such a specification is the EMV specification for contactless payment systems.
Why are some HCE applications registered for multiple AIDs?
Sometimes it becomes necessary that an application is addressed through several "names" (AIDs). The reasons may be:
- The application provides several different interfaces (i.e. which have a different set of commands or provide different data).
- There are existing readers who use (for some reason) different AIDs to access the same application.
How do you choose AID?
Rules for smart card application identifiers (AIDs) are defined in ISO / IEC 7816-4. An AID has at least 5 bytes and can contain up to 16 bytes (see this answer for AID size limits). Based on the first 4 bits, AIDs are divided into different groups. The most relevant groups defined in ISO / IEC 7816-4 are:
- AID starting with
'A' : internationally registered AIDs - AID starting with
'D' : nationally registered AIDs - AID starting with
'F' : branded AID (no registration)
For (inter) nationally registered AIDs, the AID is divided into two parts, a 5-byte mandatory RID (registered application provider identifier) and an optional PIX (extension of proprietary application identifier) up to 11 bytes long.
For proprietary AID ( F... ) you can use any arbitrary value.
Why did the AID F00000000A0101 work and the F0010203040506 not work?
I do not know, and you did not provide enough information to diagnose this. For example. where are the adb log messages when you tried to select F0010203040506 ?
In any case, both AIDs are valid and should work. One possibility might be that your device already has another HCE application registered for this AID. In this case, two applications would listen to the same name, which is impossible.