Simulator user guide

Great Events of the Twentieth Centuryi Contents Contents i Introduction Overview Audience How This Guide is Organised Document Conventions Getting Started Overview System Requirements Installation Procedure Verifying the Installation Using the Simulator 19 Overview 19 Device Maintenance 20 Running applications 30 Using The Simulation Console 31 Link Security 35 Event Logging 38 Device Discovery 43 Overview 43 Device Inquiry 43 Device Retrieval 47 Creating Services 49 Overview 49 Service Record Creation 49 Service Record Publication 50 Service Record Update 51 Update of Device Service Class 52 Great Events of the Twentieth Centuryi i Contents Accessing Services 53 Overview 53 Service Discovery 53 Client Retrieval of Service Attributes 59 Using RFCOMM 61 Overview 61 Server Side RFCOMM 62 Client Side RFCOMM 65 Using L2CAP 67 Overview 67 Server Side L2CAP 67 Client Side L2CAP 71 Connection Configuration 72 Using OBEX 74 Overview 74 OBEX Protocol Overview 75 Server Side OBEX 78 Client Side OBEX 82 OBEX Authentication 85 Impronto Specific Classes 90 Overview 90 Configuration classes 90 Utilities 91 Comparing the simulator and real devices 93 Connections 93 Applications and devices 93 Impronto System Properties 95 95 Overview ii Great Events of the Twentieth Centuryii Contents J2ME and the GCF 97 Overview 97 J2ME Configurations 97 J2ME Profiles 99 CLDC Connectivity 99 The Bluetooth Control Center 102 Overview 102 Security 102 Other BCC Functionality 105 The BCC Security Model 106 iii Great Events of the Twentieth Centuryiii Introduction Overview The Impronto Simulator provides a simulated Bluetooth environment that allows developers to build Bluetooth-enabled Java applications without deploying them on Bluetooth devices. The Impronto Simulator is 100% Java and supports the standard JABWT (Java APIs for Bluetooth Wireless Technologies) developed by the JSR-82 expert group. The following features are supported in the product: • Provides full support for L2CAP, RFCOMM, OBEX, SDP, HCI, BCC • Runs actual application code in simulated mode • Provides a management console for tracking and controlling the run-time behaviour of devices and networks • Allows users to create and configure virtual devices using the management console • Has full logging capability for Bluetooth events, and can capture events for specific devices with event filtering • Supports J2ME applications for Windows and Linux Audience This guide is intended for the following audience: • Experienced Java developers who wish to build Java-based Bluetooth applications. • Software test engineers who require a simulated test environment for Bluetooth enabled applications Great Events of the Twentieth Century1 CHAPTER 1: Introduction How This Guide is Organised This guide is organised into main sections • • • • Getting Started Using the Simulator JABWT Development Developing with the Impronto Simulator Getting Started - Chapter This section provides system requirements and installation instructions. It includes detailed instructions on how to run the Echo demo, a simple application that can be used to verify that the installation of the product was successful. Using the Simulator - Chapter This chapter describes how to use the Impronto Simulator. It introduces product features such as simulated device configuration and logging, and explains how to use them when running applications. JABWT Development - Chapters - This section of the guide provides an introduction to the major topics an application developer should be familiar with when developing JABWT applications. The topics covered are: • • • • • • Device Discovery Service Discovery Service Registration Using the L2CAP protocol Using the RFCOMM protocol Using the OBEX protocol Developing with the Impronto Simulator - Chapters 10 - 11 This section includes topics specific to developing with Impronto, including an overview of the useful Java libraries provided with Impronto, and a discussion of the differences between working with the simulator and using real Bluetooth devices. Great Events of the Twentieth Century2 CHAPTER 1: Introduction Java and Bluetooth Technology - Chapters 12 - 14 This section introduces important Java and Bluetooth concepts that relate to the Impronto Simulator. It provides an overview of J2ME technologies, including CLDC and MIDP. This section also includes a chapter introducing the Bluetooth Control Center (BCC) and JABWT security. Document Conventions The following conventions have been adopted in this document: All Java code in the text appears like this. All user input and menu selections referred to in the text appear like this this. The Impronto Simulator can run on both the Linux and Windows platforms. In this guide the character / has been used as a directory separator. Please replace this character with \ if you are running the product on a Windows platform. The string {simulator_home} represents the directory into which the Simulator was installed. Great Events of the Twentieth Century3 Getting Started Overview This chapter guides you through the installation of the Impronto Simulator and a simple verification of the installation. It includes the following topics • System Requirements • Installation Procedure • Building and Running the Echo Demo System Requirements Software Requirements The software requirements are as follows: • JDK 1.4 • Windows 2000 or Redhat Linux For J2ME development: • me4se, http://me4se.org Hardware Requirements • At least a Pentium processor with at least 64 MB of RAM • 70 MB of disk space Great Events of the Twentieth Century4 CHAPTER 2: Getting Started Installation Procedure Run the self-extracting installer as follows, java -jar simulator-installer.jar simulator-installer.jar, and follow the on-screen instructions. This will install the Impronto Simulator, example applications, and the ant build tool. Information about ant is available from http://ant.apache.org/. After the installation has completed, you will need to install your license file in order to use the simulator. The file must be copied into the simulator configuration directory, {simulator_home}/ config. Using J2ME applications with Impronto J2ME applications may be tested with Impronto Simulator using me4se, a J2ME emulation environment for J2SE, available for download from http://www.me4se.org.This version of Impronto has been tested against me4se version 2.1.2, which is shipped with the Simulator. The following section explains how to verify your installation using both J2ME and J2SE. Verifying the Installation Your Impronto installation includes a number of sample applications that you can use to verify that your installation has been successful and to practise using the simulator. The sample applications are Chat, and Echo. All examples run on J2SE and J2ME. This section steps through running the Echo demo, a very simple client-server application in which the client connects to and sends a message to the server, and the server replies with the same message. Both the client and server have a simple graphical interface, and the application has two preconfigured simulated devices that communicate using the L2CAP protocol. To verify your installation, you need to: • set up your development environment • build the demo applications • start the Bluetooth Simulation Console tool Great Events of the Twentieth Century5 CHAPTER 2: Getting Started • run the Echo demo and verify its output Set-up Environment To set up your environment to build the examples, the following: • On Windows, type set PATH=%PATH%;{simulator_home}\ant\bin • On Linux, type export PATH=$PATH:{simulator_home}/ant/bin Build the sample applications Now you need to build the sample applications: • Change to the {simulator_home}/examples directory • Type ant to build all applications Start the Bluetooth Simulation Console If you are using Windows and specified that you would like a desktop or Start menu shortcut added when installing the simulator, you can start the Bluetooth Simulation Console using this shortcut. Otherwise: • Change to the {simulator_home}/bin directory • On Windows, type manager • On Linux, type ./manager& The Bluetooth Simulation Console should display, as in the next figure: Great Events of the Twentieth Century6 J2ME and the GCF Overview Impronto applications use the Java Applications for Bluetooth Wireless Technology (JABWT) APIs to work with Bluetooth. The JABWT APIs are an optional package for the Java Platform, Micro Edition (J2ME) - a Java Platform specially designed for small devices. J2ME allows you to deploy and use Java technology in a wide range of devices, from pagers and phones to set-top boxes. Because such devices vary in terms of - for example - their memory capacity, user interface, and processing power, the J2ME specification allows you to choose an appropriate Java environment for each “family” of devices. You this by selecting from J2ME’s configurations and profiles. This chapter introduces you to some J2ME concepts, including • Configurations • Profiles • The Generic Connection Framework J2ME Configurations A J2ME configuration specifies Java language and virtual machine features and a core set of APIs. Each configuration is optimized for a particular set of devices that have similar capabilities. There are currently two possible J2ME configurations: • Connected Limited Device Configuration (CLDC CLDC), CLDC which is aimed at resource- constrained small devices such as phones and pagers. The JABWT API is designed to operate with this configuration. 97 Great Events of the Twentieth Century97 CHAPTER 13: J2ME and the GCF • Connected Device Configuration (CDC CDC), CDC which is aimed at larger, more capable devices such as set-top boxes You can download the complete specifications and API documentation for both of these configurations from Sun’s Java website at http://java.sun.com/j2me/docs/. CLDC features The CLDC specification was designed for very small devices that may have limited resources in terms of memory, power, and network bandwidth. A CLDC device typically has 128 - 512K of memory available for the Java environment and applications, limited power (CLDC devices are usually battery operated), and a 16- or 32-bit CPU. CLDC applications use the Java programming language as it is used in J2SE, with a few exceptions. Most notably, the CLDC does not support floating point numbers, as most CLDC devices not have hardware support for these. The reference Java virtual machine implementation for the CLDC is the K Virtual Machine (KVM), a small, highly-optimized virtual machine that was specially designed for use with resource-constrained devices.1 The CLDC also specifies a small core set of Java libraries that all CLDC applications can use. These include classes inherited from the J2SE packages java.lang.*, java.util.*, and java.io.*. A complete list of these classes is available in the CLDC specification. In addition, there is a set of I/O and networking classes that are specific to the CLDC - these are in the package javax.microedition.io. You can find out more about these classes later in this chapter. Unlike J2SE, the CLDC specifies only a simple sandbox security model, much like that used for untrusted applets in web browsers. Because of this, the CLDC does not support features such as user-defined class loaders or the Java Native Interface (JNI) API - JNI also requires more memory resources than are typically available on a CLDC device. An application that uses the CLDC will run on any device that implements the CLDC, provided that it uses only the set of Java classes defined by the configuration. A CLDC application will also run on a CDC device. 1. You can find more details about the KVM, including how it differs from larger virtual machines, in the KVM white paper at http://java.sun.com/products/cldc/wp/KVMwp.pdf 98 Great Events of the Twentieth Century98 CHAPTER 13: J2ME and the GCF CDC features The CDC specifies a Java environment for devices with greater resources than those targeted by the CLDC. CDC devices typically have more than 2.0MB of memory for use by the virtual machine and Java libraries, and a 32-bit processor. Unlike the CLDC, the CDC has full Java language and virtual machine support. It uses the CVM as its virtual machine, which has all the functionality of standard Java VMs but a smaller memory footprint. CDC applications can use a larger set of classes inherited from J2SE than CLDC applications. The CDC also supports the CLDC-specific javax.microedition.io classes. J2ME Profiles A J2ME profile adds further classes to a configuration to produce a complete Java environment for a particular set of devices. While configurations focus on a device’s capabilities and resources, profiles focus on how the device is used - for example, how will the user need to interact with it? J2ME profiles include • Mobile Information Device Profile (MIDP MIDP) MIDP • Foundation Profile The Foundation Profile is used with the CDC for consumer electronics and embedded devices. The MIDP is used with the CLDC for mobile phones and entry-level PDAs. It addresses phone-specific issues not dealt with by the CLDC, such as user interfaces and persistence. An application written to the MIDP specification is called a MIDlet. The JABWT API can be used to extend the functionality of this profile. You can find out more about MIDP and download the full specification from http:// java.sun.com/products/midp/ CLDC Connectivity As mentioned previously, a set of I/O and networking classes that are specific to the CLDC can be found in the javax.microedition.io package. These are known as the Generic Connection Framework (GCF). The GCF consists of a series of interfaces for different types of connection - such as StreamConnection - and a Connector class that can be used as a factory for creating connection objects. 99 Great Events of the Twentieth Century99 CHAPTER 13: J2ME and the GCF Why we need the GCF? J2SE provides a large number of useful classes relating to networking and I/O. Including all of these classes in the CLDC would be most impractical, as they would occupy a huge proportion of many small devices’ memories. However, small devices can vary widely in their networking and I/O needs, which would make choosing a subset of J2SE classes for the CLDC extremely difficult. In addition, many small devices use non-standard networking technology such as Bluetooth, which is not supported by J2SE. To address this problem, the expert group responsible for the CLDC created a new set of networking classes, the GCF. The GCF was designed to provide a set of related abstractions for different types of communication, without any dependence on specific device features or capabilities. Different implementations of the GCF are used for different types of device - however, the application developer needs only to understand the GCF API. Using the GCF The javax.microedition.io.Connector class is used to create GCF connections. You create a connection by passing a special URL to the Connector.open() method. The URL specifies the protocol you want to use (such as HTTP) and the “target” of the connection, as in the following example: Connection connection = Connector.open(“http://www.mytarget.com”); The open() method returns a Connection object that can be cast to an appropriate Connection type. The GCF provides interfaces for • • • • • • serial output connections (OutputConnection) serial input connections (InputConnection) circuit connections (StreamConnection) web server connections (ContentConnection) server-side socket connections (StreamConnectionNotifier) datagram connections (DatagramConnection) GCF and JABWT The JABWT specification allows you to use the GCF to create and use connections with Bluetooth protocols. You will find out how to this in the Using RFCOMM, Using OBEX, and Using L2CAP chapters of this guide. 100 Great Events of the Twentieth Century100 CHAPTER 13: J2ME and the GCF 101 Great Events of the Twentieth Century101 The Bluetooth Control Center Overview A Bluetooth device can have several applications running on it, each of which may have its own requirements in terms of security and other device configuration issues. To deal with this, each Bluetooth device has a Bluetooth Control Center (BCC). The BCC allows users or equipment manufacturers to configure device-wide settings, and resolves conflicting requests made by applications. Different Bluetooth devices may implement the BCC differently - for instance, on one device it may be an application with its own user GUI, on another it may be a series of settings that cannot be changed by the user. This chapter outlines some of the functionality that a BCC can offer, and explains how to use the JABWT APIs to make security requests in your applications. Security Bluetooth security is implemented using three different procedures: authentication, authentication encryption, encryption and authorization. authorization None of these can take place unless the two devices involved in attempting a connection have first been bonded. bonded Bonding is the process of linking two devices by means of a link key. This key is then used in authentication and to derive the keys used in encryption. Authentication is the process of verifying that a remote device is the device it claims to be. In Bluetooth authentication, the local device sends a challenge to the remote device. For authentication to be successful, the response must indicate that the remote device shares a link key with the local device. 102 Great Events of the Twentieth Century102 CHAPTER 14: The Bluetooth Control Center Encryption protects data by encoding it before it is transmitted over a connection. Encryption keys are derived from, but not the same as, the link key that is used in the bonding process. Authorization determines whether a client device should be allowed to access services, and only occurs once authentication has completed successfully. Only a service can request authorization. Device Security and Service Security There are three security levels available for imposing device security. These are 1. Never enforce security 2. Services enforce security 3. Always enforce security You select which of these options should apply to your device using the Console. These options refer only to how a device behaves in terms of initiating security procedures. A device using level security will respond to security requests from other devices but it will never initiate security. Security level means that a device will never establish a connection with another device without inititiating authentication and encryption. When security level is selected, the device defers security to the service level, and services on the device are free to impose the levels of security defined in the service code. Services can initiate authentication, encryption, and authorization. Authorization is only associated with service security as it relates to allowing a device access to particular services. The security options you implement in your service code can have implications in terms of the device security level selected in the Simulation Console. If the device security level states that security should never be enforced, a service on this device that requires any type of security will result in an error. Service Security using JABWT The JABWT API allows you to make security requests to the BCC in your code • when opening a connection • with an existing connection 103 Great Events of the Twentieth Century103 CHAPTER 14: The Bluetooth Control Center To make a security request when opening a connection in either your client or server code, you add optional security parameters to the connection URL that’s passed to Connector.open(). In a server, you create your protocol-specific URL as usual and include one or more of the following parameters: • authenticate • encrypt • authorize For instance, the URL in the following example specifies that client connections to the L2CAP server should be authenticated and encrypted: String url = "bt_l2cap:// 0050CD00321B:1003;authenticate=true;encrypt=true" Note that Bluetooth encryption requires authentication, so you can’t set the encrypt parameter to true and the authenticate parameter to false. If you use encrypt=true and not specify an authenticate parameter, authenticate is considered to be true. A URL that includes both encrypt=true and authenticate=false will result in Connector.open() throwing a BluetoothConnectionException. Authorization also requires authentication, and similar rules apply to the combination of these parameters. In a client, you can specify whether you require authentication or encryption when creating a connection URL from a ServiceRecord. You this by passing one of the following constants to ServiceRecord.getConnectionURL(): • ServiceRecord.AUTHENTICATE_ENCRYPT • ServiceRecord.AUTHENTICATE_NOENCRYPT • ServiceRecord.NOAUTHENTICATE_NOENCRYPT As authorization is only performed by servers, client applications cannot request authorization when opening a connection. If you make a security request that cannot be granted when calling Connector.open(), the method will throw a BluetoothConnectionException. This might occur, for instance, if you have used an invalid combination of parameters, or if you request functionality that your Bluetooth device can’t supply (not all devices support 104 Great Events of the Twentieth Century104 CHAPTER 14: The Bluetooth Control Center authentication), or if your request conflicts with the device’s security mode as set by the user in the BCC. Some BCCs may ask the user if they want to change the device settings if there is a conflict. To request additional security for a connection once it has already been opened, you use the following RemoteDevice methods: • authenticate()/ isAuthenticated() • authorize() / isAuthorized()- this will throw an IllegalArgumentException if called by a client • encrypt() / isEncrypted() RemoteDevice also has methods that allow you to check if the connection to the other device has already been authenticated, authorized, or encrypted. If you make a security request that cannot be granted when using a RemoteDevice, the relevant method returns false, otherwise it returns true. RemoteDevice.authenticate() and RemoteDevice.authorize() will also return false if the remote device could not be authenticated or authorized. Trusted Devices The BCC implementation allows you to permanently authorize certain client devices to use the services on your device. These client devices are known as trusted devices. You can check if a device is trusted by clicking the Peer button on the Simulation Console. A list of peer device will present and any trusted devices with have the Trusted checkbox checked. In a JABWT application, you can check if a remote device is trusted by calling RemoteDevice.isTrustedDevice(), which returns a boolean value. Other BCC Functionality Friendly Name The BCC allows you to set a user-friendly name that can be used to identify the device. Discovery Mode The BCC allows you to set the discovery mode of the device. A Bluetooth device can be in one of three discovery modes: 105 Great Events of the Twentieth Century105 CHAPTER 14: The Bluetooth Control Center • general discoverable • limited discoverable • not discoverable If a device is in “not discoverable” mode, it cannot be found by other devices during device discovery. If it is in “limited discoverable” mode, it will respond only to limited inquiries. If it is in “general discoverable” mode, it will respond to all device discovery inquiries. Other Modes The BCC allows you to specify whether a device is connectable - in other words, if other devices can connect to it. It may also allow you to specify whether the device is pairable. If a device is not pairable, it cannot authenticate other devices or be authenticated itself. Pre-known Devices The BCC maintains a list of pre-known devices that applications can consult instead of going through the process of device discovery. This BCC functionality is required by the JABWT specification. This is accessed through the JABWT API: DiscoveryAgent.retrieveDevices(DiscoveryAgent.PREKNOWN) The BCC Security Model There are a number of security procedures that may be performed. These are: a - A service that requires security (authentication, encryption or authorisation) may be started on a device. This is performed through the Connector.open() method, and an inability to fulfil this security procedure is signalled through a BluetoothConnectionException. b - A connection that requires security (authentication, encryption or authorisation) may be opened to another device. This is performed through the Connector.open() method, and an inability to fulfil this security procedure is signalled through a BluetoothConnectionException. c - An existing connection may be encrypted/decrypted, or used to authenticate or authorise another device. This is performed through the RemoteDevice security 106 Great Events of the Twentieth Century106 CHAPTER 14: The Bluetooth Control Center methods, and an inability to perform one of these security procedures is signalled through a 'false' return value. d - The security mode of the device may be changed. This is performed through the BCC, and an inability to perform this security procedure is signalled to the user through the GUI. The BCC security model is expressed below, in terms of what is permitted and forbidden with the above security procedures in the security modes of a device. If the device is in mode 1: a - security procedure a is forbidden and attempts to perform will result in an exception. b - security procedure b is forbidden and attempts to perform will result in an exception. c - security procedure c is permitted but will result in the following behaviour: • Authenticate (connection) will always return false; • Encrypt (connection, true) will always return false. This will be the case even if the Acl link is encrypted, and is used to signal that the device will not maintain the Acl link as encrypted on behalf of the application in mode 1. • Encrypt (connection, false) will return true if the ACL link is not encrypted OR if there are no other connections requiring the link to be encrypted, and the remote device allows it. This covers the situation where the security mode of the local device is changed from 2/3 to and where all connections that required encryption in mode 2/3 have revoked that requirement. Note that if it is just the remote device that is enforcing encryption then it is the remote device that will decrypt it eventually. • Authorize (connection) will always return false, except in the case where the connection is a 'client' side connection, in which case an exception is thrown. d - security procedure d will allow the security mode to be changed to or If the device is in mode 2: a - security procedure a is permitted without restraint and will not result in an exception, unless the security fails for valid reasons as given in the JABWT API specification. Most of these faults are faults in the security string. b - security procedure b is permitted without restraint and will not result in an exception, unless the security fails for valid reasons as given in the API specification. In addition to faults in the security string, the following is a summary of the exceptional cases: 107 Great Events of the Twentieth Century107 CHAPTER 14: The Bluetooth Control Center • If the service to which the connection is being opened requires authentication or encryption (note that authorisation requires authentication) and the baseband procedures for such procedures are executed and fail because of invalid link keys or invalid attempts to set up such a key then an exception is thrown. • If the service to which the connection is being opened requires authorisation, and the connecting device is refused access, an exception is thrown. • If the application requesting the connection requires authentication or encryption and the baseband procedures for such procedures are executed and fail because of invalid link key, or invalid attempts to set up such a key then an exception is thrown. c - security procedure c is permitted and will result in the following behaviour: • Authenticate (connection) will return true where the baseband procedure can be fulfilled, OR has already been fulfilled. • Encrypt (connection, true) will return true where the baseband procedure can be fulfilled OR where the ACL link is already encrypted. In the latter case the connection's requirement for encryption is simply noted. • Encrypt (connection, false) will return true if the link is not encrypted OR if there are no other connections requiring the link to be encrypted, and the remote device allows it. Note that the connection requirement for encryption is removed if the connection originally requested encryption. Note also that if it is just the remote device that is enforcing encryption then it is the remote device that will decrypt it eventually. • Authorize (connection) will return true when the remote device at the end of the connection can be authenticated (as in a above), and is authorised to use the service at the end of the connection. In the case where the connection is a 'client' side connection an exception is thrown. d - security procedure d will allow the mode to be changed to without restriction, or if there are no services running on this device that require baseband security procedures to be executed on their behalf when a client connection attempt is made. If the device is in mode 3: a - security procedure a is permitted without restraint and will not result in an exception, unless the security fails for valid reasons as given in the JABWT API specification. Most of these faults are faults in the security string. b - security procedure b is permitted without restraint and will not result in an exception, unless the security fails for valid reasons as given in the API specification. In addition to faults in the security string, the following is a notable exceptional case: 108 Great Events of the Twentieth Century108 CHAPTER 14: The Bluetooth Control Center • In mode the baseband procedures for authentication and encryption are performed automatically when the Acl Link is set up. If the SSE proceduress fail because of invalid link keys, or invalid attempts to set up such a key, then an exception is thrown. c - security procedure c is permitted and will result in the following behaviour: • Authenticate (connection) will return true where the baseband procedure can be fulfilled, OR has already been fulfilled. Note that although the device is in mode it may recently have been put in this mode from mode or 2, so it is possible that the baseband procedure may have to be executed for the given connection (in which case of course it could fail and 'false' will be returned). • Encrypt (connection, true) will return true where the baseband procedure can be fulfilled OR where the link is already encrypted. Note that although the device is in mode it may recently have been put in this mode from mode or 2, so it is possible that the baseband procedure may have to be executed for the given connection. In the case where the baseband procedure fails, 'false' will be returned. In the case where it succeeds or where it was already encrypted, the connection's requirement for encryption is simply noted. This information is subsequently used if the security mode is changed to or 2. • Encrypt (connection, false) will return true if the link is not encrypted. This would be the case where the device was recently put in mode from mode or 2, where it was not encrypted. In all other cases 'false' will be returned. Note that the connection requirement for encryption is removed if the connection originally requested encryption. • Authorize (connection) will return true when the remote device at the end of the connection can be authenticated (as in a above), and is authorised to use the service at the end of the connection. In the case where the connection is a 'client' side connection an exception is thrown. d - security procedure d will allow the mode to be changed to without restriction, or if there are no services running on this device that require baseband security procedures to be executed on their behalf when a client connection attempt is made. 109 Great Events of the Twentieth Century109 A authentication 102 authorization 102 B BCC 102 BCC functionality 105, 106 Bluetooth address 21 Buffer size 39 C Cancelling the device inquiry 47 Cancelling the service search 58 CDC 98 CDC features 99 CLDC 97 CLDC connectivity 99 CLDC features 98 Client retrieval of service attributes 59 Client-side L2CAP 70, 71 Client-side RFCOMM 65 Configuration classes 90 Connectable 21 Connecting to the service 58 Connection configurations 72 Connection URL connection 68 Creating the discovery listener 54 Creating the DiscoveryListener 44 D Device characteristics 21 Device classes 22 Device discover 43 Device Inquiry 46 General inquiry 46 Device inquiry 43 Limited inquiry 46 Device maintenance 20 Device retrieval 43, 47 Device security 35 Discovery mode 25, 105 E encryption 102 Establishing the client connection 65, 71 Event filter 39 Great Events of the Twentieth CenturyI Event logging 38 F Friendly name 21, 105 G GCF 100 GCF and JABWT 100 Getting started H Hardware requirements I Initiating the service search 56 Installation procedure Introduction J J2ME 97 J2ME configurations 97 J2ME profiles 99 K Known devices 106 L L2CAP 67 L2CAP Server Connection Creation 69 L2CAP Service record 70 L2CAP service record 70 Link security 35 Logging activation 40 M MIDP 99 Minor device 23 R Rendering 25 Retrieving the discovery agent 54 Retrieving the DiscoveryAgent 44 RFCOMM server connection creation 63 RFCOMM service record 64 Running applications 30 Running the Echo demo Great Events of the Twentieth CenturyII S Security with JABWT 103 Sending and receiving data 66 Server-side L2CAP 67 Server-side RFCOMM 62 Service class 25 Service discovery 53 Service record creation 49 Service record publication 50 Service record update 51 Service registration 49 Software Software requirements Starting the console System requirements T Trusted devices 105 U Update of device service class 52 Using the simulation console 31 Utilities 91 V Verifying the installation Great Events of the Twentieth CenturyIII [...]... Changes The simulator saves the device details in an xml file in {simulator_ home}/config using the friendly name you have supplied, for example the details of a device with the friendly name foo will be saved in foo.xml 29 Great Events of the Twentieth Century29 CHAPTER 3: Using the Simulator Running applications A Bluetooth Java application that conforms to the JABWT standard should run within the simulator. .. Great Events of the Twentieth Century18 # Using the Simulator Overview The Impronto Simulator allows you to run JABWT-compliant Bluetooth applications in a simulated environment This environment consists of: • Applications, running as clients or servers, each running in a separate Java Virtual Machine (VM) • A set of simulated devices, defined by the user using the Bluetooth Simulation Console Each device... Simulation Console allows you to create new devices and edit existing devices The characteristics of each device are stored in individual XML configuration files in the Simulator configuration directory This directory is located by default in {simulator_ home}/ config Device Maintenance Commands You can find the device maintenance commands in the Simulation Console’s File menu (Since we will not be using... by this device This is a user- friendly name mapped to the Bluetooth address that can be used to identify your device You check the box labelled Connectable if the device is to be connectable If this box is unchecked then no device will be able to connect to this device This flag should always be set for servers 21 Great Events of the Twentieth Century21 CHAPTER 3: Using the Simulator Device Classes... you have chosen The figure below shows the minor device Cellular option for major device class Phone 23 Great Events of the Twentieth Century23 CHAPTER 3: Using the Simulator 24 Great Events of the Twentieth Century24 CHAPTER 3: Using the Simulator Service Class You can provide Service Class information for your device by selecting checkboxes in the Service Class panel A service class indicates the type... classes in this guide s Device Discovery and Creating Services chapters, and in the Bluetooth Assigned Numbers document (http:// www.bluetooth.org/assigned-numbers/baseband.htm) Discovery Mode If you right-click on Not discoverable the options for Discovery Mode are displayed in a discoverable, drop-down menu The Device Discovery and Security and the Bluetooth Control Center chapters in this guide provide... provide more details about these options Most applications will use the General Discoverable option 25 Great Events of the Twentieth Century25 CHAPTER 3: Using the Simulator 26 Great Events of the Twentieth Century26 CHAPTER 3: Using the Simulator Security Mode A device can be in one of three security modes: • It will never initiate security procedures • It will always initiate security procedures •... deals with application security requests See the Bluetooth Control Centre chapter for more information 27 Great Events of the Twentieth Century27 CHAPTER 3: Using the Simulator 28 Great Events of the Twentieth Century28 CHAPTER 3: Using the Simulator Saving the details Before you save the details for your new device, you can specify other devices as preknown, such that your device can communicate with... Great Events of the Twentieth Century7 CHAPTER 2: Getting Started The following two sections guide you through running the Echo sample in J2SE and J2ME Run the Echo demo application - J2SE This section tells you how to run the Echo sample application and verify its output in a J2SE environment • Change to the {simulator_ home}/examples/echo/bin directory • On Windows, type start echo-server • On Linux,... Century30 CHAPTER 3: Using the Simulator System.setProperty("impronto.localdevice.friendlyname", "foo"); If you're writing a MIDlet, you can set these properties in its Java Application Descriptor (JAD file) For example the JAD file would contain the line: impronto.localdevice.friendlyname: foo You must also insert the following code into your MIDlet's constructor so that Impronto Simulator can read the JAD . self-extracting installer as follows, java -jar simulator- installer.jar java -jar simulator- installer.jarjava -jar simulator- installer.jar java -jar simulator- installer.jar, and follow the on-screen. type set PATH=%PATH%;{ set PATH=%PATH%;{set PATH=%PATH%;{ set PATH=%PATH%;{ simulator_ home simulator_ homesimulator_home simulator_ home }antin }antin}antin }antin • On Linux, type export. export PATH=$PATH:{ export PATH=$PATH:{export PATH=$PATH:{ export PATH=$PATH:{ simulator_ home simulator_ homesimulator_home simulator_ home }/ant/bin }/ant/bin}/ant/bin }/ant/bin Build the sample applications Now