<concept id="GUID-667C0481-2DEF-4618-9AA5-8DF528082061" xml:lang="en"><title>Accessory Services Overview</title><shortdesc>Accessory Services abstract accessory-related services

for platform and SDK clients and provides accessory-related APIs for

adaptation (audio and display) and accessory plug-ins.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<section id="GUID-6C29F2CD-6FBE-4805-957A-CB08163DFC00"><title>Purpose</title><p>Accessory Services is a group of components that support APIs

for platform clients to retrieve accessory connection status information,

and device and services type information. It also provides adaptation

<section id="GUID-9236506F-077D-4AB1-AE4C-9CE391F42F98"><title>Architecture</title><p>The architecture of Accessory Services revolves around the Accessory

and the Remote Control Framework. Accessory Framework provides platform

clients with access to the accessory functionality on the device,

while abstracting away accessory, hardware, bearer and protocol-specific

details from the software layers. Accessory Framework also provides

accessory policy and adaptation APIs for the addition of new Accessory

Framework plug-in components (if required). The Remote Control Framework

provides APIs required to send and receive remote control commands

to/from an accessory connected to a phone.</p><p>The core of the Accessory

Framework is the Accessory Server. Accessory Server has a central

role in accessory-related connection/disconnection handling on the

Symbian platform. The Accessory Framework depends on the concepts,

such as Generic ID, Accessory Policy, Accessory Handlers and Accessory

Mode. These concepts are described in the following section.</p><p>Remote Control Framework exposes the Remote Control Server using

the Remote Control Core APIs. The remote control commands are understood

by the Key Event Converter and passed on to the Target Selector Plug-in

(TSP) Controller by the Remote Control Framework. Then TSP decides

which application must handle this request and passes that information

to the Remote Control Server. Finally, the request is handled by that

application. For more information about Remote Control concepts, see

the <b>Remote Control Framework</b> section.</p><p>The following figure

illustrates the architecture of Accessory Services:</p><fig id="GUID-EF39A7CD-BA15-4F2D-96C6-C54672226E98">

<image href="GUID-5AE741A2-68C5-4219-8F2A-ECE0A819FCAA_d0e159843_href.jpg" scale="150" placement="inline">

</image>

<section id="GUID-7AB78BEA-315A-4CC0-B5B6-A7A28568F2B2"><title>Description</title><p>This section describes the key concepts associated with Accessory

Services.</p><ul>

<li><p><b>Generic ID</b>: Generic ID provides the means to describe,

detect, connect, and control an enhancement without a need to use

hardware or provider-specific definitions. Thus Generic ID must be

a native concept for any accessory-related platform software. For

the platform purposes, Generic ID must be defined so that it covers

all the enhancement device types, bearers, protocols, and accessory

feature profiles that the platform supports and for which information

is needed.</p> </li>

<li><p><b>Accessory Policy:</b> Accessory Policy provides the Generic

ID data type for identifying an accessory on the basis of its features,

instead of an accessory-specific ID. Accessory Server uses Accessory

Policy through the Accessory Policy API to get information about the

connected accessories. A connected accessory is identified using an

assigned Generic ID, which is a data structure that describes the

relevant physical and logical features of the accessory.</p> </li>

<li><p><b>Accessory Mode:</b> Accessory Mode describes the accessory

connection status of the devices connected to a phone and indicates

whether the audio is routed into the accessory or not. Accessory Mode

typically affects the vibra state, lights state, texts, some UI icons

and menu items. </p><p><b>Note:</b> Accessory Mode is a single-valued

state, unlike the accessory connection status. Some supported Accessory

Modes include hand portable, wired headset, wireless headset, wired

car kit, wireless car kit, headphones, text device, music stand and

<li><p><b>Accessory Handlers:</b> Accessory Handlers (ASYs) form the

Accessory Framework adaptation layer. Accessory Server hosts multiple

ASYs. For example, wired ASY, bluetooth ASY, plugged display ASY and

so on. ASYs can be understood as an accessory adaptation layer between

the Accessory Framework and any other Symbian platform or hardware-related

software on the phone. Typical task of an ASY is accessory detection

(registering for hardware indications) and providing the capabilities

of the accessories to the Accessory framework.</p> </li>

<li><p><b>Controller:</b> Controller is a device that sends a control

message or command to a target device and is ready to capture responses.</p> </li>

<li><p><b>Target:</b> Target is a device that accepts the control

message or command from the controller, invokes necessary procedures

and sends out responses to controller. </p> </li>

<li><p><b>Bearer:</b> The bearer is a carrier that acts like a vehicle

of transmission for remote control messages. The bearer here is an

ECom plug-in to the Remote Control Server.</p> </li>

<section id="GUID-93D60E05-F086-46F4-A0A6-2B8227BBABED"><title>Components</title><p>Accessory Services consists of the following components: </p><ul>

<li><p><b>Accessory Monitor:</b> Provides APIs to retrieve information

about the connected accessories, such as a headset and car kit. </p></li>

<li><p><b>Accessory Remote Control:</b> Provides APIs for clients

to communicate with remote targets in a terminal and remote targets

outside a terminal.</p> </li>

<li><p><b>Accessory Server:</b> This is a core component that exposes

accessory-related client and adaptation APIs through the Accessory

Framework. The Accessory Framework provides APIs to query accessory-related

information, adjust accessory-related user settings and to request

control for accessory-related functions. </p> </li>

<li><p><b>Headset Status API:</b> Provides APIs for checking the headset

status. For example, headset status change notifications.</p> </li>

<li><p><b>Target Selector Plug-in (TSP) Client Mapper:</b> Provides

APIs to create mappings between remote control clients.</p> </li>

<li><p><b>Plugged Display:</b> Plugged Display component is an ASY

that enables High-Definition Multimedia Interface (HDMI) and TV-out

support. For more information about HDMI, see <xref href="http://en.wikipedia.org/wiki/HDMI" scope="external">Wikipedia</xref>.</p> </li>

<li><p><b>Remote Control Framework:</b> Provides APIs needed to send

and receive remote control commands to/from a Bluetooth enabled device.</p> </li>

<section id="GUID-18563CE6-A880-48E4-96BA-3B50CA8A373F"><title>Using

Accessory Services</title><p>You can use features provided by Accessory

Services to perform the following tasks:</p><ul>

<li><p>Retrieve accessory mode, connection status, accessory device

and service type information.</p></li>

<li><p>Request for a protocol-specific connection handle for accessory

audio control.</p></li>

<li><p>Identify accessories connected based on its features, using

Generic IDs.</p></li>