ETSI TS 103 544-22 V1.3.1 (2019-10)

TECHNICAL SPECIFICATION
Publicly Available Specification (PAS);
Intelligent Transport Systems (ITS); ®
MirrorLink ;
Part 22: Android Specific Specifications enabling ®
AIDL-based MirrorLink Applications
CAUTION
The present document has been submitted to ETSI as a PAS produced by CCC and
approved by the ETSI Technical Committee Intelligent Transport Systems (ITS).
CCC is owner of the copyright of the document CCC-TS-056 and CCC-TS-065 and/or had all relevant rights and had assigned
said rights to ETSI on an "as is basis". Consequently, to the fullest extent permitted by law, ETSI disclaims all warranties
whether express, implied, statutory or otherwise including but not limited to merchantability, non-infringement of any
intellectual property rights of third parties. No warranty is given about the accuracy and the completeness of
the content of the present document.

2 ETSI TS 103 544-22 V1.3.1 (2019-10)

Reference
RTS/ITS-98-22
Keywords
interface, ITS, PAS, smartphone

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm
except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
©ETSI 2019.
© Car Connectivity Consortium 2011-2019.
All rights reserved.
ETSI logo is a Trade Mark of ETSI registered for the benefit of its Members.
MirrorLink® is a registered trademark of Car Connectivity Consortium LLC.
RFB® and VNC® are registered trademarks of RealVNC Ltd.
UPnP® is a registered trademark of Open Connectivity Foundation, Inc.
Other names or abbreviations used in the present document may be trademarks of their respective owners.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 544-22 V1.3.1 (2019-10)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Platform-Specific Specification Concept Overview . 8
5 Application Identifier . 8
5.1 General . 8
5.2 Format . 8
5.3 Calculation . 9
5.3.1 General . 9
5.3.2 Shared UIDs. 10
5.3.3 ROM applications . 11
5.4 APK Validation . 11
6 Application Information . 11
6.1 General . 11
6.2 Self-Signed Application Certificates . 11
6.2.1 General . 11
6.2.2 Application Certificate Self-Signing Process. 12
6.2.3 Self-Signed Application Certificate Installation . 12
6.3 Particulars of Android Application Certificates . 12
6.3.1 General . 12
6.3.2 Platform version . 12
6.3.3 Icon URLs . 12
6.4 Localized strings for the entries in the application certificate . 12
7 Development Certificates . 13
7.1 General . 13
7.2 Device ID . 13
7.3 Application Development Certificates . 13
7.4 Developer ID Entry . 13
7.5 Manual Developer ID Certificate Revocation Checks . 14
8 MirrorLink API Implementation . 14
8.1 General . 14
8.2 API Overview . 14
8.2.1 General . 14
8.2.2 Android MirrorLink Server Requirements . 14
8.2.3 Application Requirements . 16
8.3 MirrorLink API Library Definition . 17
8.3.1 Data Type Definitions . 17
8.3.2 Data Structure Definitions . 17
8.3.3 MirrorLink API Elements accessible from the Service . 18
8.3.4 MirrorLink API Elements accessible from the Content Provider . 19
8.3.4.1 General . 19
8.3.4.2 0xF0xx ' MirrorLink API Information mapping . 19
8.3.4.3 0x02xx ' Certification Information mapping . 19
8.3.4.4 0x03xx ' Connection Information mapping . 20
ETSI
4 ETSI TS 103 544-22 V1.3.1 (2019-10)
8.3.4.5 0x0Cxx ' Actions mapping . 20
8.3.5 Modules dependencies . 20
8.3.5.1 General . 20
8.3.5.2 General Android MirrorLink Service access . 20
8.3.5.3 General Android Content Provider Service access . 21
8.3.5.4 Actions Module write access. 21
8.3.5.5 DataService Module Source Service Access . 21
8.3.5.6 Launch of Actions . 21
8.3.5.7 MirrorLink Actions . 21
8.3.6 Context Information Lifetime . 22
8.3.7 Return values outside of a MirrorLink session . 22
9 MirrorLink Events . 23
9.1 General . 23
9.2 Touch Events Injections . 23
9.3 Key Events Injections . 23
9.4 Key Event Mapping. 23
9.5 Virtual Keyboard . 24
10 Platform Limitations. 25
10.1 CCC-TS-010-VNC Based Display and Control (ETSI TS 103 544-2) . 25
10.1.1 Server Event Configuration Message . 25
10.1.2 Handling of Overlays . 25
10.1.3 Handling of Applications Seeking Foreground Status . 25
10.1.4 Removal of audio from non-certified applications . 25
Annex A (informative): App ID Generation Code . 26
Annex B (informative): Authors and Contributors . 30
History . 31

ETSI
5 ETSI TS 103 544-22 V1.3.1 (2019-10)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Intelligent Transport Systems
(ITS).
The present document is part 22 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.1].
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI TS 103 544-22 V1.3.1 (2019-10)
1 Scope ®
The present document is part of the MirrorLink specification which specifies an interface for enabling remote user
interaction of a mobile device via another device. The present document is written having a vehicle head-unit to interact
with the mobile device in mind, but it will similarly apply for other devices, which provide a colour display, audio
input/output and user input mechanisms.
The present document provides the elements of the MirrorLink specification that apply only to Android MirrorLink
Server devices.
The API javadoc files contained in the archive CCC-TS-065_Mirrorlink_API-Level2-AIDL-files__v138.zip, contained
in ts_10354422v010301p0.zip, are an integral part of the present document.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 103 544-14 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 14: Application Certificates".
[2] ETSI TS 103 544-15 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink® ; Part 15: Application Programming Interface (API) Level 1 & 2".
[3] ETSI TS 103 544-16 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 16: Application Developer Certificates".
[4] IETF RFC 4648: "The Base16, Base32, and Base64 Data Encodings", October 2006.
NOTE: Available at http://www.ietf.org/rfc/rfc4648.txt.
[5] ETSI TS 103 544-9 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 9: UPnP Application Server Service".
[6] ETSI TS 103 544-2 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 2: Virtual Network Computing (VNC) based Display and
Control".
ETSI
7 ETSI TS 103 544-22 V1.3.1 (2019-10)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 103 544-1 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 1: Connectivity".
[i.2] Android package documentation.
NOTE: Available at http://developer.android.com/guide/topics/manifest/manifest-element.html#package.
[i.3] Android android:versionCode documentation.
NOTE: Available at http://developer.android.com/guide/topics/manifest/manifest-element.html#vcode.
[i.4] JAR File Specification.
NOTE: Available at http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html.
[i.5] Signing Your Applications.
NOTE: Available at http://developer.android.com/tools/publishing/app-signing.html.
[i.6] Car Connectivity Consortium: "Android Application ID Generator".
[i.7] Common Intents.
NOTE: Available at https://developer.android.com/guide/components/intents-common.html.
[i.8] Managing audio focus.
NOTE: Available at https://developer.android.com/guide/topics/media-apps/audio-focus.html.
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACMS Application Certification Management System
AIDL Android Interface Definition Language
API Application Programming Interface
APK Android PacKage
CDB Common Data Bus
ETSI
8 ETSI TS 103 544-22 V1.3.1 (2019-10)
CDMA Code-Division Multiple Access
HTTP HyperText Transfer Protocol
IMEI International Mobile Equipment Identity
IPC Inter-Process Communication
JAR Java ARchive
ML MirrorLink
OCSP Online Certificate Status Protocol
OS Operating System
ROM Read-Only Memory
RSA Rivest–Shamir–Adleman
SBP Service Binary Protocol
SDK Software Development Kit
UID Unique IDentifier
UPnP Universal Plug and Play
URL Uniform Resource Locator
UUID Universally Unique IDentifier
VNC Virtual Network Computing
4 Platform-Specific Specification Concept Overview
In order to support third-party applications within a MirrorLink session, the MirrorLink protocols require certain
information be provided to the MirrorLink Server's software (the MirrorLink "Stack") and to the Application
Certification Management System (ACMS), and that certain functionality be exposed to those applications (the
MirrorLink API). In order to prevent fragmentation of the application ecosystem, simplify implementation for
MirrorLink Server Device developers, and to increase the number of devices that a given application can be run on,
these systems should be common to a given mobile device platform. The goal being that a MirrorLink application
written for Android, for example, should be able to run on all MirrorLink-certified Android devices. It is understood
that differences of versions and hardware capabilities limit the ability to ensure cross-device compatibility however the
intent is that MirrorLink should not create additional barriers to such cross-compatibility.
The present document contains the requirements for MirrorLink Server devices that utilize the Android OS. MirrorLink
Server devices that use the Android Operating System shall comply with the requirements listed in the present
document.
5 Application Identifier
5.1 General
As described in the Application Certificate Handling specification [1], each application shall have a unique application
identifier (App ID) that is provided to the Application Certification Management System (ACMS) via the HTTP GET
and OCSP requests sent to it by the MirrorLink Server device. This AppID needs to be unique for that application, and
change whenever the application is modified. For Android devices, the App ID is generated using the below method.
Source code that implements the below algorithm is provided in Annex A.
5.2 Format
The application ID for an Android application shall be a URL-safe base-64 encoding [4] of a SHA-256 digest. As the
digest of SHA-256 is 32 bytes long the application ID will therefore be a string of 43 URL-safe base-64 characters.
The application ID shall not place any padding characters at the beginning or end of the encoding. This ensures all
implementations will generate an identical application ID and prevents the need to escape any characters when querying
the Application Certificate Management System (ACMS).
ETSI
9 ETSI TS 103 544-22 V1.3.1 (2019-10)
5.3 Calculation
5.3.1 General
The data to be hashed shall be the concatenation of the following in the order specified:
1) String encoding of Android package name provided in AndroidManifest.xml [i.2].
2) Big endian 8-byte integer representing the version code provided in AndroidManifest.xml [i.3].
3) The string "startManifestMain".
4) For each attribute in the main section of the APK manifest (META-INF/MANIFEST.MF), sorted
lexicographically by unicode code point of the attribute name:
a) String encoding of the full attribute name.
b) String encoding of the attribute value.
5) The string "endManifestMain".
6) For each file named in the main section of the APK manifest (META-INF/MANIFEST.MF), sorted
lexicographically by unicode code point of the file path:
a) The string "startFile".
b) Skip this file if the path is "assets/self-signed.ccc.crt".
c) String encoding of the file path.
d) For each attribute in the file section of the APK manifest, sorted lexicographically by unicode code point
of the attribute name:
i) String encoding of the full attribute name.
ii) String encoding of the attribute value.
e) The string "endFile".
The encoding of strings shall be a big-endian 8-byte integer specifying the length in bytes followed by the UTF-8
encoding of the string.
Example: The string "Hi Σ" would be encoded as the following bytes:
0x00 0x00 0x00 0x05 (Length of UTF-8 string, 5 bytes)
0x48 0x69 0x20 0xCE 0xA3 (UTF-8 encoding of string)
Therefore, an example APK for an application with the following properties:
• Package name of "com.example.a".
• Version code of 124.
• Containing the following files:
- assets/image.png.
- assets/self-signed.ccc.crt.
- META-INF/CERT.RSA.
- META-INF/CERT.SF.
- META-INF/MANIFEST.MF.
- AndroidManifest.xml.
ETSI
10 ETSI TS 103 544-22 V1.3.1 (2019-10)
- classes.dex.
- resources.arsc.
• A META-INF/MANIFEST.MF containing the following:
Manifest-Version: 1.0
Created-By: 1.0 (Android)
Name: classes.dex
SHA1-Digest: eEcd5Q6I3GDCkZ7gAAsC0dB8KxU=

Name: resources.arsc
SHA1-Digest: IEBCJEW4Ws8uS/ML7RgEqwGYvtU=

Name: assets/image.png
SHA1-Digest: gHoXviEAT+JdNMqsvo/vERe231Y=

Name: assets/self-signed.ccc.crt
SHA1-Digest: r/HlpR8FRHOKcsF4o5PFSeV32yk=

Name: AndroidManifest.xml
SHA1-Digest: /czwhhK4YJmcwq9E/qHoB26/K90=

Would have an application ID which is the SHA-256 digest of the concatenation of the following data where the strings
are encoded using the method described above:
"com.example.a"
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7C
"startManifestMain"
"Created-By"
"1.0 (Android)"
"Manifest-Version"
"1.0"
"endManifestMain"
"startFile"
"AndroidManifest.xml"
"SHA1-Digest"
"/czwhhK4YJmcwq9E/qHoB26/K90="
"endFile"
"startFile"
"assets/image.png"
"SHA1-Digest"
"gHoXviEAT+JdNMqsvo/vERe231Y="
"endFile"
"startFile"
"classes.dex"
"SHA1-Digest"
"eEcd5Q6I3GDCkZ7gAAsC0dB8KxU="
"endFile"
"startFile"
"resources.arsc"
"SHA1-Digest"
"IEBCJEW4Ws8uS/ML7RgEqwGYvtU="
"endFile"
The quotation marks are not included in the calculation, they are here just to indicate the exact string which is going to
be hashed.
To see a working example for calculating the AppID please check the Android Application ID Generator [i.6], which
contains a sample APK. The README file provided contains the expected application ID.
The Mirror Link Server should reject any APK which contains the same filename twice. An APK with the same
filename multiple times could be used to mask some unwanted data, therefore the Server shall treat it as untrusted.
5.3.2 Shared UIDs
In Android APKs are allowed to share UIDs. Each APK shall be treated as an application as a whole and if two or more
APK use the same shared UID, each of them will be considered an application in its own right. Each of those APKs
shall be certified independently and each of them will have a unique application ID.
ETSI
11 ETSI TS 103 544-22 V1.3.1 (2019-10)
When an application connects to a service of the MirrorLink Server it shall provide the package name of the APK it
lives in. The server then shall validate that the package name has the UID of the process making the request. This is
because when an IPC request is being made, in Android, there is no way to tell the package from which the request
came, only the UID can be retrieved.
5.3.3 ROM applications
Application identifiers of apps built-into the device firmware (aka ROM) may be extracted by the MirrorLink Server
from the self-signed certificate instead of being dynamically generated at runtime. This may be necessary due to
firmware optimizations, which change the structure of an APK thus making it difficult to maintain a unique application
identifier for the same application across different firmware variations. The application identifier of the optimized
application within the self-signed certificate shall match the application identifier of the same, un-optimized application.
The application shall contain a self-signed certificate, following the requirements in clause 6.2. The MirrorLink Server
shall have an integrity check method for build-in ROM applications to verify the integrity of such build-in applications,
before granting the exemption. Integrity check may be done by validating that the ROM application was signed with the
same ROM signature key (platform private key).
If an updated version of a ROM-based application is installed as a standard APK, the MirrorLink Server shall treat it as
an updated version of the ROM application, shall cease making OCSP requests in relation to the ROM-based version,
and shall not list the ROM-based version in the UPnP Application Listings. Updated versions of built-in applications
installed as a standard APK shall be treated like normal MirrorLink applications.
5.4 APK Validation
An APK which contains files outside of the 'META-INF' directory with no MANIFEST.MF entries will be rejected by
the Android platform. If a file is present in the MANIFEST.MF but does not a have a *-Digest entry then this will also
be rejected by the Android platform. This is because both of these are requirements for a valid JAR signature [i.4].
An application ID shall not be generated by an ID generation tool, for an APK with files outside of the 'META-INF'
directory with no MANIFEST.MF entry. An application ID also shall not be generated for an APK containing files
without a '*-Digest' entry in the MANIFEST.MF.
An application ID shall not be generated also when the same filename is present more than once in the APK. This is to
avoid any attempts to hide files within the APK. The MirrorLink Server is responsible itself for rejecting such
applications.
A MirrorLink server may validate the signature of the APK in addition to the APK signature being validated by the
Android platform.
6 Application Information
6.1 General
As described in clause 6.1 of the Handling of Application Certificates specification [1], an application should come with
a MirrorLink developer self-signed certificate Application Certificate for the purposes of providing the information
needed by the MirrorLink Server to list the application in the A_ARG_TYPE_AppList as described in Table 4.3 of [5],
and to control interaction with the ACMS as described in [1]. This clause describes how the Application Certificate is
generated and included with the application for Android MirrorLink Server devices, as well as any alternate methods
for providing that information.
6.2 Self-Signed Application Certificates
6.2.1 General
The MirrorLink servers running on an Android platform shall allow for Self-Signed Application Certificates as
described in clause 6.1 of [1].
ETSI
12 ETSI TS 103 544-22 V1.3.1 (2019-10)
6.2.2 Application Certificate Self-Signing Process
To create a MirrorLink aware application a Self-Signed X.509 Certificate shall be created. The certificate shall include
the MirrorLink Extension Headers as described in clause 5.2.1 of [1]. The key used shall be a 2048-RSA key and the
hashing shall be done using SHA-256 or SHA-512 signature algorithms.
The self-signed certificate shall be signed with a key pair generated by the developer. The Jarsigner utility included in
the SDK, as described in [i.5], should be used to sign the Self-Signed Application Certificate.
6.2.3 Self-Signed Application Certificate Installation
The Self-Signed Certificate shall be placed in a file called "self-signed.ccc.crt". The certificate file shall be placed in the
assets folder of the APK containing the application.
The MirrorLink server shall use the "self-signed.ccc.crt" file as the self-signed Application Certificate as described in
clause 6.1 of [1].
6.3 Particulars of Android Application Certificates
6.3.1 General
The following clauses 6.3.2 and 6.3.3 describe any items which are in the Application Certificates that need to be
adapted to the Android OS.
6.3.2 Platform version
The platform version in the certificates shall match the constants defined in Build.VERSION_CODES. So for example
if an application is available for Ice Cream Sandwich devices, the constant value of
Build.VERSION_CODES.ICE_CREAM_SANDWICH should be used, which is the integer 14. The string
representation shall be decimal, signed and without any leading 0, or white spaces.
6.3.3 Icon URLs
The Icon URL field shall be left empty; therefore, the iconList element shall be omitted from the Application
Certificate. The MirrorLink Server shall use the icon provided with the Activity which accepts the LAUNCH and
TERMINATE MirrorLink-specific Intents (see clause 8.2.2) or the icon provided through the Actions module when
applications are making use of variants.
Having the URL field empty means that in future versions this can be used without a break in compatibility.
The omission of the iconList element is allowed, since it is platform specific. In [1], clause 7.3.2,
A_ARG_TYPE_AppList, the Server is mandated to copy all the entries from the Application Certificate into the
matching A_ARG_TYPE_AppList entries, while leaving the missing entries to the default values. This does not apply to
the iconList for the Android Servers, as it is easiest to provide the icon data through the Android specific means.
6.4 Localized strings for the entries in the application certificate
The application certificate provides various strings without any localization information. In order to support localized
versions of the strings, the application will provide them as string resources as follows.
Table 1
Certificate element Resource name
Name "com.mirrorlink.app.certificate.name"
providerName "com.mirrorlink.app.certificate.providerName"
providerURL "com.mirrorlink.app.certificate.providerURL"
ETSI
13 ETSI TS 103 544-22 V1.3.1 (2019-10)
Certificate element Resource name
description "com.mirrorlink.app.certificate.description"

Each resource may contain localized versions. The Server will retrieve the resource string for the locale of the device.
7 Development Certificates
7.1 General
Android MirrorLink Server devices will support the development of MirrorLink Applications. Clause 7 of the present
document covers those aspects of the MirrorLink specification that address development of applications as described in
the Handling of Application Development Certificates specification [3].
7.2 Device ID
Device IDs are the IMEI/IMEISV number or version 5 UUID derived from an equivalent unique identifier of the
MirrorLink Server devices on which development applications can be used.
All Android MirrorLink Servers should use the IMEI (or MEID/ESB for CDMA devices) as provided by the
TelephonyManager's getDeviceId method or the ANDROID_ID as provided by the Settings.Secure.getString( resolver>, Settings.Secure.ANDROID_ID) method as seed of the Device ID. If an IMEI (or MEID/ESB) or
ANDROID_ID is not available, the Android MirrorLink Server shall use the serial number as reported by the
android.os.SystemProperties ro.serialno property or any other read-only secure property uniquely identifying a device.
See clause 5.2.3.2 of the Handling of Application Developer Certificates Document [3] for more information on the
Device ID.
7.3 Application Development Certificates
The Android platform uses Application Development Certificates as described in clauses 5.1 and 7 of the Handling of
Application Developer Certificates Document [3]. These certificates differ from the Self-Signed Application Certificate
by the inclusion of an additional extension containing the Developer ID, which can be obtained from the ACMS. If the
Android MirrorLink Server determines that the self-signed application certificate contains a developer ID extension, it
will be treated as an Application Development Certificate.
Application Development Certificates follow the same signing and installation requirements for Self-Signed
Application Certificates, as described above.
7.4 Developer ID Entry
The Android MirrorLink server may provide a mechanism for the user of the device to enter one or more developer IDs
into the server, as part of functionality available as part of the "developer mode" menu. (In Android 4.2, this can be
reached by tapping on the Build Number entry 7 times in the About Phone screen.) The Android MirrorLink server
shall attempt to retrieve the Developer ID certificate for all entered Developer IDs using the Device ID as described
above.
If the MirrorLink server does not provide a mechanism for entering the Developer IDs, the Android MirrorLink server
shall attempt to retrieve the Developer ID certificate for all Developer IDs reported in all Application Development
Certificates available on the device.
A MirrorLink server only implementing API Level 1, shall allow developers having entered their Developer ID in the
device to consult its DEVICE ID for inclusion in their Application Developer Certificates.
See clause 6 of the Handling of Application Developer Certificates Document [3] for more information on requesting
Developer ID certificates.
ETSI
14 ETSI TS 103 544-22 V1.3.1 (2019-10)
7.5 Manual Developer ID Certificate Revocation Checks
The Android MirrorLink server shall allow for the user of the phone to immediately request the Developer ID
Certificate associated with the Developer ID. This capability should be provided as part of the "developer mode" menu
as described above.
8 MirrorLink API Implementation
8.1 General
All MirrorLink Servers using the Android platform shall implement the MirrorLink API as described below.
8.2 API Overview
8.2.1 General
Before defining the actual API an overview of the mechanisms used in it should be considered:
• The API is based on the "Android Interface Definition Language" (AIDL) and on the concept of content
provider Contract classes. This should provide the necessary flexibility and extensibility of the API. Also, it
means that there is no need to maintain and distribute binaries to the application developers.
• Applications access the MirrorLink server by communicating with an Android Service and an Android
Content Provider. The package name for the service and content provider should be unique across all Android
MirrorLink servers. The recommended name used for the packages are: "com.mirrorlink.android.service" and
"com.mirrorlink.android.provider".
• Constants used when interacting either with the MirrorLink Service, ContentProvider, Intents or specific
Bundle will be regrouped in a single java source file with one distinct class per module, or structure, being
supported.
• Whenever possible, android.os.Bundle objects will be used to exchange complex data structures between the
MirrorLink Service and the Application.
8.2.2 Android MirrorLink Server Requirements
• MirrorLink Servers shall allow access to the MirrorLink Service for all applications that bind using the
"com.mirrorlink.android.service.BIND" family of Intents, and that have the
"com.mirrorlink.android.service.ACCESS_PERMISSION" permission. This permission should be user-
grantable on the MirrorLink Server. If more than 3 seconds elapse from the launch of the application to receipt
of the bind request, then the MirrorLink server should mark the application as not MirrorLink aware and
remove it from the application list. If the application responds later on, the server should add it back to the list.
• MirrorLink servers shall allow access to the MirrorLink ContentProvider for all applications listing the
"com.mirrorlink.android.provider" in their certificate xml , using the
"com.mirrorlink.android.provider" authority and using the "com.mirrorlink.android.provider.
MIRRORLINK_PROVIDER_ACCESS_PERMISSION" permission. This permission should be user-
grantable on the MirrorLink Server.
• MirrorLink servers shall support the use of android.database.ContentObserver by MirrorLink aware
applications to monitor underlying changes made to the MirrorLink ContentProvider datasets.
• Application can use the appropriate "com.mirrorlink.android.service.BIND" action to specify the MirrorLink
API level they wish to bind to. If a MirrorLink Server does not support a particular API level, it shall fail the
bind operation.
ETSI
15 ETSI TS 103 544-22 V1.3.1 (2019-10)
• In response to the default "com.mirrorlink.android.service.BIND" Intent, MirrorLink servers shall return the
Android MirrorLink API Service Level 1 binder from the bind request.
• In response to a "com.mirrorlink.android.service.BIND." Intent, MirrorLink Servers shall return
the corresponding MirrorLink API Service Level binder from the bind request or null if the requested API
Level is not supported.
• MirrorLink servers shall allow access to the Android MirrorLink Service and Android MirrorLink
ContentProvider at all times, inside and outside of a MirrorLink Connection.
• MirrorLink servers shall keep the Android MirrorLink Service alive as long as there is at least one MirrorLink
Aware application bound to it.
• The MirrorLink server shall respond to the Launch request successfully if the application has been found and
the intent has been sent to it. If the application responds back through the MirrorLink Service API, then the
server shall send an Application Status Update notifying the client that the application is now in Foreground.
• The MirrorLink server shall consider an application that unregistered from all the Services as terminated. It
may consider it as terminated as soon as it unregisters from the Connec
...