Optional APIs Porting Guide

This appendix discusses the design and porting of the Bluetooth optional package (JSR 82) for the Java ME platform. The Bluetooth Specification provides a standard set of Java programming language APIs that enables low-power, handheld devices such as cell phones, pagers, PDAs, and other small devices to share functionality over a peer-to-peer wireless connection. Bluetooth wireless technology allows for heterogeneous connections between different kinds of devices (for example, between a cell phone and a PDA).

For a complete description of Bluetooth functionality, see the Bluetooth Specification 1.1 at the following URL:

http://jcp.org/aboutJava/communityprocess/final/jsr082/index.html

---

Bluetooth Overview

Bluetooth technology (the Bluetooth stack) is built upon the Connected Limited Device Configuration and can be loosely divided into two components:

• Bluetooth controller.The baseband layer that enables the physical Radio Frequency (RF) link up between two Bluetooth-enabled devices, using the underlying Bluetooth Radio module.
• Bluetooth host.The higher level software stack that includes a number of Bluetooth profiles. A Bluetooth profile is a standardized way of defining a protocol and its features. Each profile enables a particular usage model between devices able to share that protocol.

Communication between the Bluetooth controller and the Bluetooth host is managed by the Host Controller Interface (HCI).

Bluetooth Profiles

Bluetooth technology supports a number of profiles, including the following generic profiles:

• Generic Access Profile (GAP) - An umbrella profile that includes the other three generic profiles.
• Bluetooth Serial Port Profile (BTSPP) - A profile used to establish RS-232 serial port connectivity between devices that support it (for example, a cell phone and a headset), using an Radio Frequency Communication (RFCOMM) or Logical Link and Control Application Protocol (L2CAP) transport.
• Service Discovery Application Profile (SDAP) - A profile used by client applications to discover services available through a Bluetooth server.
• Generic Object Exchange Profile (GOEP) - An underlying profile used for file transfer, synchronization, object push, and other object transactions.

The generic profiles shown here and other functionality available with Bluetooth technology are found in the javax.bluetooth package, which depends upon javax.microedition.io.

In addition, Bluetooth technology supports the Object Exchange Protocol (OBEX). which is a separate optional package outside the core Bluetooth APIs, it is also used to establish connectivity between Bluetooth clients and Bluetooth servers and can be used to "push" or "pull" objects from one to the other.

OBEX functionality is available in the javax.obex package and also depends upon javax.microedition.io.

Bluetooth Functionality

Bluetooth technology supports three categories of basic functionality, including the following:

• Discovery - The process of seeking and finding other Bluetooth-enabled objects, which can include the following:
• Devices, such as other cell phones, headsets, or PDAs
• Services, such as applications available from a Bluetooth server
• Registering services, for example, making Bluetooth-enabled applications available for discovery by other Bluetooth-enabled devices or applications

• Communication - The process of establishing connection with another Bluetooth-enabled device and using that connection to exchange data between the devices.
• Device management - The process of managing and controlling connectivity between Bluetooth-enabled devices.

Bluetooth Control Center

The Bluetooth Control Center (BCC) is a set of capabilities that allows a user, device manufacturer, or Bluetooth service provider to define specific values for configuration parameters in a Bluetooth stack. The Bluetooth Control Center also makes it possible to manage and resolve conflicting requests made by wireless applications to a Bluetooth implementation, for example, by setting a specific security policy or defining a list of trusted devices.

---

BluetoothStack Interface and the Bluetooth Control Center

The JSR 82 optimized implementation of Java Wireless Client software uses the BluetoothStack interface whenever communication with the underlying Bluetooth stack is required. The BluetoothStack interface provides an API for device management and security. Typical scenarios include the following:

• Device inquiry
• Retrieval of a remote device name
• Authentication
• Updating Service Discovery Database (SDDB) service records

The BCC interface is used to provide access to services implemented by a dedicated application, which serves as a central authority for local Bluetooth device settings. Those services include retrieval of cached and preknown devices, pairing, authorization, and so on. The BCC application is usually already available on the target platform and is implemented in native code.

Some functionality of the BluetoothStack interface and BCC interface is overlapping. For example, both interfaces have methods for doing the following things:

• Retrieving a local Bluetooth address and friendly name
• Setting and retrieving device and service classes and access codes
• Changing authentication and encryption

In most cases, the default implementation of the BCC interface forwards these requests to the corresponding BluetoothStack interface methods. The idea is that the BCC interface provides a higher level of operation, while the BluetoothStack interface is used for low-level communication. For example, the authenticate() method of the BCC interface might request the user to enter a PIN code before asking the BluetoothStack interface to perform an actual authentication. The overlapping of APIs is also required for the emulation build, where the BluetoothStack interface is not used at all.

Porting the BluetoothStack Interface

The BluetoothStack interface is presented by an abstract BluetoothStack Java programming language class and a corresponding abstract CBluetoothStack C++ class. The Java programming language class handles parameter checking, exception handling, synchronization and other higher-level tasks, while the native class takes care of communication with the underlying Bluetooth stack. During porting on the target platform, it may be required to subclass the Java programming language class, native class, or both.

Assumptions About the Implementation

The following assumptions have been made in regard to the underlying stack implementation:

• The Bluetooth stack API provides a non-blocking operation so that the virtual machine is allowed to run during prolonged operations, for example, a device inquiry.
• Certain Bluetooth events, such as an inquiry result or a remote name result, can be polled for, and when available, extracted from an event queue.
• Access to the local Service Discovery Database is provided.

Often, polling for and extraction of events is not directly supported by the Bluetooth stack API. Instead, a Bluetooth stack implementation can provide a callback mechanism for delivering notifications and events. However, it must also be possible to implement polling for a callback-oriented API (for example, a callback function can save event data, which can be retrieved later during a polling call).

For passing Bluetooth events from the native to the Java programming language side, a binary serialization of events is used. To minimize your porting effort, serialize event data in the format used for representing corresponding HCI events, as it enables you to reuse event construction code provided by the GenericBluetoothStack interface. However, any other serialization method is also acceptable.

Implementation Requirements

The underlying Bluetooth stack implementation must be able to do the following:

• Check if the Bluetooth radio is enabled, and turn it on if disabled.
• Retrieve local Bluetooth address and friendly name.
• Retrieve device class and set service classes.
• Get and set inquiry access code.
• Start an inquiry process (or report failure if the device is currently busy).
• Cancel an ongoing inquiry.
• Perform remote name retrieval (or enqueue the request if the device is busy).
• Perform asynchronous authentication.
• Request encryption change of all connections with a remote device.

The Bluetooth stack implementation must report the following events:

• Authentication completion, containing connection handle and a flag indicating whether the procedure succeeded
• Encryption change, containing a connection handle and a flag indicating whether the change succeeded

1. Determine whether your Bluetooth stack provides access to HCI.

For stacks providing primitives to access HCI layer, the GenericBluetoothStack implementation is the best starting point for the port. The HCI specifies a uniform command interface to the Bluetooth controller and covers all the functionality represented in the BluetoothStack porting interface. If the target Bluetooth stack provides an API for the HCI, it can be beneficial to use that API, so that the porting effort can be reduced to a minimum. When using this approach, it is often enough to just implement the HCI transport, as all higher-level methods are already provided by the GenericBluetoothStack interface implementation.

However, some stack implementations might lack a usable API to access the HCI layer, or provide other reasons to use a high-level API instead. In such cases, use the BluetoothStack as a base class for the implementation.

2. Subclass CGenericBluetoothStack C++ class.

Usually, the GenericBluetoothStack Java programming language class does not need to be subclassed or modified, as it already implements all abstract methods of the BluetoothStack accordingly. In the CGenericBluetoothStack C++ class, the following three HCI-related abstract methods are declared, which need to be implemented in a subclass:

• SendHCICommand() method sends an HCI command to the underlying stack implementation. See the JSR 82 specification for a description of the method arguments.
• WaitHCICommandComplete() and WaitHCICommandStatus() wait until CommandComplete or CommandStatus events are received. These methods block virtual machine execution, which does not present a problem because the time between issuing a command and receiving the corresponding event is negligible for the commands used with these methods.

Also, the following event-related methods declared in CBluetoothStack class need to be defined:

• CheckEvents()method checks HCI events are pending. Only the following HCI events are of interest:
• Command complete
• Command status
• Inquiry complete
• Inquiry result
• Remote name
• Request complete
• Authentication complete
• Encryption change

All other HCI events are filtered out.

• ReadData() method extracts a single pending event and writes event data into the buffer provided. HCI events are presented in binary format according to the Bluetooth Specification.

3. Subclass the BluetoothStack Java programming language class and the CBluetoothStack C++ class.

When using higher-level API provided by the Bluetooth stack, it is required to make appropriate API calls in the following C++ class methods:

• StartInquiry()
• CancelInquiry()
• AskFriendlyName()
• Authenticate()
• Encrypt()

All of these methods must not block and must perform asynchronously. Also, the two event-related methods declared in CBluetoothStack class need to be defined.

• CheckEvents() method checks if Bluetooth events are pending. The following events are of interest:
• Inquiry complete
• Inquiry result
• Remote name result
• Authentication complete
• Encryption change complete

• ReadData() method extracts a single pending event and writes event data into the buffer provided. The format of event data is arbitrary and can be stack specific.

Bluetooth events are usually provided using callback functions in the stack API. The usual practice is to store events when a callback function is invoked and access the events stored from CheckEvents() and ReadData() methods.

It is also required to subclass the BluetoothStack Java programming language class and override the retrieveEvent() method, which converts binary data of an event extracted with ReadData() into the corresponding Java programming language class. See the GenericBluetoothStack implementation for an example.

4. Implement other device management methods.

The following methods need to be implemented:

• IsEnabled()
• Enable()
• GetLocalAddress()
• GetLocalName()
• GetDeviceClass()
• SetServiceClasses()
• GetAccessCode()
• SetAccessCode()

See the Doxygen-generated documentation for details on these methods and their arguments.

All of these methods are also present in the BCC interface and the default BCC implementation forwards calls to the BluetoothStack interface. However, in some cases, the BCC itself is responsible for all or some of the functionality provided by these methods.

Even though all of the methods mentioned can be implemented using the HCI, the GenericBluetoothStack currently does not provide such an implementation. None of the methods access remote devices and all of them must perform synchronously, so a higher-level API usually can be used. Still, future versions of GenericBluetoothStack might include an HCI-based implementation, which reduces the porting efforts of an HCI-compatible API even further.

5. Implement SDDB functionality.

The Service Discovery Database functionality is contained in two methods:

• updateRecord()
• removeRecord()

Both methods take a record handle as their first parameter. These handle values are not related to the ServiceRecordHandle attributes associated with the service records. Instead, these handles are only used to uniquely identify service records in the upper-level code, and might or might not match the ServiceRecordHandle attribute values used by the SDDB internally.

The updateRecord() method replaces the existing SDDB entry identified by the given handle with a new one. The new record is passed in a byte array, containing attribute-value pairs in the format identical to the one used in the AttributeList parameter of the SDP_ServiceAttributeResponse protocol data unit (PDU). See the Bluetooth specification for details. This method returns the new handle value (or the same handle value, if it has not changed).

The removeRecord() method is permanently deletes an existing SDDB entry identified by the given handle. The handle value specified can then be reused by new SDDB entries.

Porting the BCC Interface

The BCC is an abstract Java programming language class. The class currently has two implementations, JavaBCC for use with the emulation build and NativeBCC for working with Bluetooth radio. Ensure the latter class is instantiated in the BCC.getInstance() method.

Following is a list of NativeBCC methods and possible actions you might need to perform when porting:

• native boolean confirmEnable()

Before enabling Bluetooth, the user must to be prompted. If the prompt dialog is to be displayed by the native BCC application, the native bt_bcc_confirm_enable() function needs to be implemented. If the Java programming language-based dialog is expected, the native modifier is dropped and the method is implemented using the Java programming language modifier.

• native boolean isConnectable()

This method is used to check if the local device is available for connection. The native bt_bcc_is_connectable() function returns the connectable status, according to the native BCC application policy.

• native boolean isPaired()

This method determines if the local and remote device can proceed with authentication without requesting a PIN from the user. The corresponding native bt_bcc_is_paired() function needs to be implemented accordingly.

• native boolean isAuthenticated()

This method determines if the remote device has previously been authenticated. The corresponding bt_bcc_is_authenticated() function needs to be implemented accordingly. If the authentication status is not known, this function returns false.

• native boolean isTrusted()

This method determines if the remote device is a trusted device. If the concept of trusted devices is supported by the native BCC application, the corresponding native bt_bcc_is_trusted() function needs to be implemented accordingly, otherwise this method always returns false.

• native boolean isEncrypted()

This method determines if all connections to the specified remote device are encrypted. The corresponding native bt_bcc_is_encrypted() function needs to be implemented accordingly.

• native String getPasskey()

This method retrieves the PIN code associated with a specified remote device. If the PIN code is not known, the user is prompted to enter one. The corresponding native bt_bcc_get_passkey() function needs to be implemented accordingly. In some cases, PIN code retrieval and bonding (pairing) cannot be separated. If this is the case, the getPasskey()method returns any non-null value. A separate method for PIN code retrieval is provided for convenience, or if the UI dialog is implemented in the Java programming language instead.

• native boolean bond()

This method performs bonding with the specified remote device using the given PIN code. The corresponding native bt_bcc_bond() function needs to be implemented accordingly.

• native boolean authorize()

This method asks the user whether to allow a connection from the specified remote device to the given service. The corresponding native bt_bcc_authorize() function needs to be implemented accordingly.

• native String getCachedDevices()and native String getPreknownDevices()

These two methods retrieve a list of Bluetooth addresses of cached and previously known devices from the native BCC application. Separate the addresses by a specific character (the default is a colon). The corresponding native bt_bcc_get_cached_devices() and bt_bcc_get_preknown_devices() functions need to be implemented accordingly.

• native int getHandle()

This method retrieves the default ACL connection handle for the specified remote device. This handle is used for authentication and encryption in the BluetoothStack interface. The corresponding native bt_bcc_get_handle() function needs to be implemented accordingly.

• native int getConnectionCount()

This method retrieves the number of connections to the specified remote device, including connections from native applications, if any. The corresponding native bt_bcc_get_connection_count() function needs to be implemented accordingly.

• native boolean setEncryption()

This method increases or decreases the counter of encrypted connection requests for the specified device, including connections from native applications, if any. Once the counter makes a transition from 0 to 1, indicating that the encryption mode needs to be changed, the method must return true. The corresponding native bt_bcc_set_encryption() function needs to be implemented accordingly.

Additionally, two native methods might need to be implemented:

• bt_bcc_add_connection() is called whenever a new logical connection is established between the local and a remote device. The handle argument of this method specifies the default ACL connection handle for the connection.
• bt_bcc_remove_connection() is called whenever an existing connection is closed.

---

L2CAP Protocol and BTSPP Profile

The descriptions of the Logical Link and Control Application Protocol (L2CAP) and the Bluetooth Serial Port Profile (BTSPP) and have much in common. The major difference is that L2CAP is a packet protocol while BTSPP is a stream protocol.

They differ in the following ways:

• L2CAP data is trimmed if it is outside the packet length. It's also possible to send empty packets (without data).
• The L2CAP getReceiveMTU() and getTransmitMTU() methods return the input and output Maximum Transmission Unit (MTU) sizes negotiated by the underlying stack while establishing connections. BTSPP has no such methods.
• The L2CAP protocol has the ready() method that determines whether a packet is in the input data queue. In the BTSPP protocol, the available method explicitly returns the number of bytes available for reading.

The set of Java programming language classes for each protocol consists of two major classes: One represents the Connection class and the other represents the Notifier class. Currently, the L2CAP and BTSPP protocols are implemented on the Linux platform using the BlueZ library, which provides a GNU socket-based interface.

BlueZ Library

Although the BlueZ library has been in development for many years and is in wide use, it has major bugs, especially in non-blocking mode. Comments in the bt*Connection.c files mark workarounds for bugs found in the BlueZ 2.19 library. To install the BlueZ library, you can either build it from the sources downloaded from the official site or get the binaries using the package manager for your version of Linux.

You must also build the Bluetooth kernel modules for your Linux kernel.

Although the library is undocumented, some information can be found in the various forums and mail lists.

The hcidump utility analyzes Bluetooth HCI packets and is very useful for debugging.

Making Connections in L2CAP and BTSPP

The typical name for the connection class is *ConnectionImpl, where (*) is the name of the protocol. *ConnectionImpl classes are inherited from the BluetoothConnectionImpl class. This is a base class for both protocols. It keeps the things associated with the connection, including the following items:

• URL
• I/O mode
• RemoteDevice class
• Security settings (encryption and authorization)

Each *ConnectionImpl contains the native methods initialize() and finalize(). The initialize() method retrieves fieldIDs used to access the Java platform class members from native code. The finalize() method releases native resources. That is, it closes the native connection handle if it is not closed explicitly.

Each connection implementation consists of three parts, where (*) represents L2CAP or BTSPP for the equivalent protocol:

• *ConnectionImpl.java

The mode-specific functionality is put in separate methods, whose names end with a "0".

Long-running native code is not suitable for protocol operation because it blocks the VM. Therefore, for asynchronous operations (for example, connect, accept, send, and receive) use the Java Wireless Client software midp_thread_wait and midp_thread_signal mechanism. This is a common mechanism utilized by all Java Wireless Client software network protocols.

The following differences exist between the JSR implementation of GNU sockets, QSockets and event-oriented (callback-oriented) stacks.

• If the GNU socket API is used and data is not available, the bt_na_register_for_write and bt_na_register_for_read functions add the socket into a special array. This array is accessed using GetRegisteredBtSocketHandles() declared in bt_generic.h. The sockets from the array are put into a common set of sockets checked on every VM time slice. For more information see the checkForSocketAndKeyboardSignal function in midp/src/events/mastermode_port/linux_fb/native/mastermode_check_signal.c.
• If the QT library is used and data is not available, calling bt_na_register_for_write and bt_na_register_for_read enables the read/write QSocket notifier. The notifier calls the Java Wireless Client software NotifySocketStatusChanged() function to make an up-call to unblock the thread.
• If an event-oriented (callback-oriented) stack is used (for example, Broadcomm) and data is not available, the stack must call the Java Wireless Client software bt_notify_protocol_event() callback function to unblock the thread.

• *ConnectionGlue.c, *NotifierGlue.c

*ConnectionGlue.c contains implementations for the native methods of *ConnectionImpl class. To avoid race conditions, native connection handles stored in the fields of the *ConnectionImpl and *NotifierImpl Java platform classes are accessed only from native code. All KNI oriented code is located in these two files and the porting layer is utilized to call native platform-specific connection methods.

There are no global native variables except jfieldID variables that are set once by static initializers and can be safely used by multiple tasks.

This information holds true for the *NotifierGlue.c as well, except for the *NotifierImpl class.

• *Connection.h, *Connection.c

*Connection.h is the porting interface declaration for the protocol, while *Connection.c contains an implementation for the specific platform (the OS plus the underlying bluetooth stack). This API has GNU style sockets but can also be used with other sockets underlying the Bluetooth stacks. The API contains the client connection and server connection. Some functions can be applied only for a dedicated entity, but other functions are common to all.

Be aware of the following issues when using the ROMizer to tune the jsr82_rom.config file:

• Renaming is disabled for the fields accessed using KNI_GetFieldID.
• Internal packages are made hidden. Non-ROMized code is prevented from accessing even public methods and fields of classes in these packages.
• Public JSR APIs are restricted. Non-ROMized code cannot load new classes into JSR API packages.

The Java Wireless Toolkit stores JSR public properties as well as internal properties in Java platform files.

The Java Wireless Client software has its own technology to manipulate properties. It uses the following XML configuration files for this purpose. The configuration files are share, emul, real, and linux.

In the following steps, platform is the name of the target OS (for example, Linux) and protocol is the name of the protocol being used (the possible values are btl2cap, btspp, and irdaobex).

The following steps describe how to port the Bluetooth optional package to your platform.

1. Create the jsr82/src/config/platform/properties_jsr82.xml file and fill it with valid property values.

Use jsr82/src/config/share/properties_jsr82.xml as a template.

2. Create the jsr82/src/protocol/protocol/native/platform/*Connection.c file that contains an implementation of the protocol's porting layer (*Connection.h) for your target platform.

3. Create a customized subsystem.gmk for the target platform, which is similar to the Linux subsystem.gmk.

4. Build your target platform executable using the newly-created subsystem.gmk file.

A common subsystem.gmk is available for emulation and real modes. Currently linux_qte and linux_fb are supported in real mode.

This customized subsystem.gmk file can include the following declarations:

• DOXYGEN_INPUT_LIST - Adds native headers in order to generate Doxygen documentation for them.
• JAVADOC_ALL_SOURCEPATH - Adds Java programming language headers to generate documentation using the Javadoc tool.
• vpath - Adds paths to new directories containing native source.c and .cpp files.
• SUBSYSTEM_JSR_82_NATIVE_FILES - Contains the names of native files to include them into the build process.
• SUBSYSTEM_JSR_82_EXTRA_INCLUDES - Contains paths to newly added header files.
• SUBSYSTEM_JSR_82_JAVA_FILES - Java platform source files to be included.
• SUBSYSTEM_CONFIGURATION_CONFIGURATOR_INPUT_FILES - Includes properties to the configurator tool.
• LIBS - Adds a native library (the key format is platform-specific).

The current release includes its own trace system for debugging. The trace system is located in btMacros.h. The following macros are declared: PRINT_INFO, PRINT_ERROR, and EXCEPTION_MSG.

You can independently switch each of the macros on and off. You can switch the EXCEPTION_MSG macro on during development in order to catch problems, and switch it off in the production release to reduce the code footprint.

TCK and Java Device Test Suite software can be used to test the implementation. Note that the following permissions must be enabled in the Java Device Test Suite software:

• Connector.http
• Connector.comm
• Connector.bluetooth.client
• Connector.bluetooth.server
• Connector.obex.client.tcp
• Connector.obex.server.tcp
• Connector.obex.client
• Connector.obex.server
• Connector.socket
• Connector.serversocket

---

Porting the OBEX Interface

OBEX is a protocol developed by the Infrared Data Association (IrDA) for pushing and pulling objects to or from clients and servers.

The irdaobex protocol is used for devices that make connections using only an infrared port and is implemented in two Java programming language classes: IrNativeConnection and IrNativeNotifier. The Native prefix is used to identify that these classes are mostly implemented in native code and are intended to be used with a non-emulation build. No corresponding implementation is available for an emulation build at the moment.

The porting interface is defined in the IrConnection.h header file. Most of the functions declared there must be implemented during the porting process.

In some cases, when the connection is known to be synchronous, ir_connect_complete is not required.

---

JavaCall Porting Layer

All JavaCall API Bluetooth functions and variable types have prefix javacall_bt_ or javanotify_bt_.

JavaCall API Bluetooth Variable Types and Values

Most JavaCall API Bluetooth functions return the result value. The type of it is the same as for other JSRs and it has name javacall_result. Most often values are as follows:

• JAVACALL_OK means an action has finished correctly.
• JAVACALL_FAIL indicates an error occurred during execution.
• JAVACALL_WOULD_BLOCK menas that the function starts an asynchronous operation and a function will be called on finishing this operation.

Some JavaCall API Bluetooth functions have boolean arguments or return a boolean value (i.e. isDeviceAuthenticated). The JavaCall API boolean type is javacall_bool and it can be JAVACALL_TRUE or JAVACALL_FALSE.

The most important type is javacall_bt_address which is a pointer to a six byte Bluetooth address. For more information on Bluetooth addresses, see the Bluetooth specification at http://www.bluetooth.org/spec.

Definition of JavaCall API Bluetooth Variable Types, Values and Functions

The file javacall_bt.h contains the definition of all variable types, values and function prototypes of the JavaCall API Bluetooth interface.

JavaCall API Bluetooth Function Groups

• Bluetooth Control Center (prefix javacall_bt_bcc_)
• Bluetooth Stack (prefix javacall_bt_stack_)
• Service Discovery Database (prefix javacall_bt_sddb_)
• L2CAP protocol (prefix javacall_bt_l2cap_)
• RFCOMM protocol (prefix javacall_bt_rfcomm_)
• Notification functions (prefix javanotify_bt_)

Memory Allocation

Buffers for all output parameters are allocated by the caller, unless specified otherwise.

In case of strings and arrays, a parameter represents the size of the buffer. If output data does not fit into the buffer of the given size, the JavaCall API function must return JAVACALL_FAIL.

Porting steps

This section explains how the JSR 82 code can be ported to a new platform using the JavaCall API .

1. All functions contain empty bodies. When a function returns javacall_result value it should return JAVACALL_FAIL. Boolean return value should be JAVACALL_FALSE. Be sure that the build contains no mistakes. Insert trace into each function for debugging.

2. Implement functions from the first three groups (Bluetooth Control Center, Bluetooth Stack, Service Discovery Database).

3. Implement L2CAP protocol functions and run available L2CAP tests.

4. Implement RFCOMM protocol functions and run available RFCOMM tests.

5. (Optional) Implement notification functions if needed.

Optional APIs Porting Guide

05-2007

Copyright © 2007, Sun Microsystems, Inc. All rights reserved. SUN PROPRIETARY/CONFIDENTIAL.