Symbian3/PDK/Source/GUID-667C0481-2DEF-4618-9AA5-8DF528082061.dita
changeset 3 46218c8b8afa
parent 1 25a17d01db0c
child 5 f345bda72bc4
--- a/Symbian3/PDK/Source/GUID-667C0481-2DEF-4618-9AA5-8DF528082061.dita	Thu Mar 11 15:24:26 2010 +0000
+++ b/Symbian3/PDK/Source/GUID-667C0481-2DEF-4618-9AA5-8DF528082061.dita	Thu Mar 11 18:02:22 2010 +0000
@@ -1,119 +1,119 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License 
-"Eclipse Public License v1.0" which accompanies this distribution, 
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
-    Nokia Corporation - initial contribution.
-Contributors: 
--->
-<!DOCTYPE concept
-  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<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><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
-APIs for the addition of new Accessory Services plug-in components. </p></section>
-<section><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 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">
-<title>Accessory Services Architecture</title>
-<image href="GUID-5AE741A2-68C5-4219-8F2A-ECE0A819FCAA_d0e133491_href.jpg" scale="150" placement="inline"/>
-</fig></section>
-<section><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
-TV-out.</p> </li>
-<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>
-</ul><p/></section>
-<section><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.dita">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>
-</ul></section>
-<section><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>Retrieve accessory control and connection-related functionality.</p></li>
-<li><p>Request for a protocol-specific connection handle for accessory audio
-control.</p></li>
-<li><p>Handle accessory-related key events.</p></li>
-<li><p>Monitor accessories connected to a phone.</p></li>
-<li><p>Identify accessories connected based on its features, using Generic
-IDs.</p></li>
-<li><p>Configure accessory-related settings.</p></li>
-<li><p> Retrieve headset connection status.</p></li>
-<li><p>Create mappings between remote control clients.</p></li>
-<li><p>Configure TV-out settings.</p></li>
-</ul></section>
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License 
+"Eclipse Public License v1.0" which accompanies this distribution, 
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+    Nokia Corporation - initial contribution.
+Contributors: 
+-->
+<!DOCTYPE concept
+  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<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><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
+APIs for the addition of new Accessory Services plug-in components. </p></section>
+<section><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 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">
+<title>Accessory Services Architecture</title>
+<image href="GUID-5AE741A2-68C5-4219-8F2A-ECE0A819FCAA_d0e133491_href.jpg" scale="150" placement="inline"/>
+</fig></section>
+<section><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
+TV-out.</p> </li>
+<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>
+</ul><p/></section>
+<section><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.dita">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>
+</ul></section>
+<section><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>Retrieve accessory control and connection-related functionality.</p></li>
+<li><p>Request for a protocol-specific connection handle for accessory audio
+control.</p></li>
+<li><p>Handle accessory-related key events.</p></li>
+<li><p>Monitor accessories connected to a phone.</p></li>
+<li><p>Identify accessories connected based on its features, using Generic
+IDs.</p></li>
+<li><p>Configure accessory-related settings.</p></li>
+<li><p> Retrieve headset connection status.</p></li>
+<li><p>Create mappings between remote control clients.</p></li>
+<li><p>Configure TV-out settings.</p></li>
+</ul></section>
 </conbody></concept>
\ No newline at end of file