Anwendungsprogrammierung mit Bluetooth und JSR Februar 2006

Transkript

1 Anwendungsprogrammierung mit Bluetooth und JSR-82 Andreas Pinhammer Stefan Lindenlaub 20. Februar

2 Inhaltsverzeichnis 1 Motivation 3 2 Bluetooth Funktionsweise Netzwerktopologie Der Bluetooth Protocol Stack JSR-82 API Anforderungen Bluetooth Control Center Einführung in die API Geräteverwaltung Dienst registrieren Discovery Kommunikation Sicherheit Konklusion und Ausblick 10 A Glossar 12 B Beispiel (Server) 13 C Beispiel (Client) 14 2

3 1 Motivation Bluetooth verbreitet sich zunehmend. Immer mehr Hersteller bringen Endgeräte auf den Markt, die via Bluetooth drahtlos Kontakt zur Außenwelt aufnehmen können; mit jeder neuen Gerätegeneration werden zudem höhere Übertragungsgeschwindigkeiten erreicht. Fast alle Mobiltelefone auf dem Markt unterstützen mittlerweile die kabellose Funktechnologie. Gleichzeitig verlangen die Telekommunikationsanbieter hohe Gebühren für den mobilen Datenverkehr mittels GPRS oder UMTS. Die Übertragung mit Bluetooth dagegen ist kostenlos und mit bis zu 100m Reichweite für viele Anwendungsszenarien ausreichend. Das haben auch die Telefonhersteller erkannt und mit JSR-82 eine Erweiterung für Java geschaffen, die den Zugriff auf die Bluetoothschnittstelle ermöglicht. Im Kapitel 2 geben wir einen kurzen Überblick über die Technik und Funktionsweise von Bluetooth. Kapitel 3 erklärt dann die Verwendung der API anhand eines kleinen Beispiels. Zum Schluß werden wir kurz darauf eingehen, welche Sicherheitsfunktionen Bluetooth mitbringt und wie diese genutzt werden können. 2 Bluetooth Die Bluetooth Verbindungstechologie wurde ursprünglich 1994, zur kabellosen Kommunikation zweier mobiler Geräte, vom schwedischen Telefonhersteller Ericsson für kurze Entfernungen von ca. 10 Metern entwickelt gründeten Ericson, IBM, Intel, Nokia, und Toshiba eine Vereinigung Bluetooth Special Interest Group (SIG), um eine lizenzfreie, offene und weltweit verfügbare Spezifikation zu entwickeln[3]. Seit dem haben sich mehr als 2000 Unternehmen dem Bluetooth SIG angeschlossen. Bluetooth unterstützt einen asynchronen Datenkanal oder bis zu 3 gleichzeitige Sprachkanäle oder einen Kanal mit gleichzeitiger asynchroner Daten- und synchroner Sprachübertragung. Daten können annähernd mit einer Geschwindigkeit von 720 Kbits/sec übertragen werden. Die Standart Wellenlänge reicht von 10 cm bis ca. 10 m und kann durch eine Verstärkung der Sendeleistung bis auf 100 m erweitert werden. 2.1 Funktionsweise Bluetooth arbeitet im 2,4-GHz-ISM-Band. ISM steht hierbei für Industrial, Scientific, Medical und bietet den Vorteil, dass es weltweit überall ohne Lizenz genutzt werden kann[4]. Obwohl es global verfügbar ist, kann sich die genaue Lage und Bandbreite in den Ländern unterscheiden. Europa und die vereinigten Staaten haben eine Bandbreite von B= 83,5 MHz, wobei 79 Radiofrequenz (RF)-Kanäle mit einem Abstand von 1 MHZ definiert sind. In Frankreich, Japan und Spanien wird ein schmaleres Band, mit 23 RF- Kanälen und einem Abstand von 1 MHz, genutzt. 3

4 Um Störungen mit anderen Geräten die auf dem ISM Band kommunizieren zu vermeiden, basiert die Modulation auf schnellen Frequenzsprüngen, wobei die 79 und 23 RF-Kanäle bis zu 1600 mal in der Sekunde gewechselt werden. Die Sprungfolge ist für jedes Netz einzigartig, weil sie durch die Bluetooth-Geräteadresse des Masters bestimmt wird. Der Kanal wird in Time-Slots geteilt, wobei jeder Slot mit einer RF-Sprung-Frequenz übereinstimmt. Ein Paket kann auf bis zu fünf Slots verteilt werden. Zur Unterstützung der doppelgerichteten (vollduplex) Kommunikation, benutzt Bluetooth ein Zeitmultiplexverfahren time-division multiplexing (TDM). Alle Bluetooth-Einheiten innerhalb eines Netzes sind kanal-, zeit- und sprungsynchron. 2.2 Netzwerktopologie Bluetooth Geräte nutzen eine eindeutige IEEE bit Adresse. Wenn zwei oder mehrere Bluetooth Geräte miteinander verbunden sind, wird dies auch als Piconet bezeichnet. Es handelt sich hierbei um ein eigens für diesem Zweck geschaffenes Netzwerk, in dem ein Gerät als Master agiert, während alle anderen Geräte Slaves genannt werden. Ein Master und ein Slave nutzen eine point-to-point Kommunikation. Gibt es mehrere Slaves, wird eine point-to-multippoint Kommunikation verwendet. Ein Master ist ein Gerät, das die Kommunikation einleitet. In- Abb. 1: Piconet/Scatternet nerhalb eines Piconet können bis zu 7 Slaves aktiv sein[3]. Kommen noch weitere Slaves hinzu, so können sie beim Master in einem sogenannten Parked-State angemeldet sein. Die geparkten Slaves sind zwar nicht aktiv, bleiben aber dennoch mit dem Master synchron. Für aktive und geparkte Slaves wird der Kanalzugang durch den Master gesteuert. Existieren mehrere Piconets die sich überlappen, kann, wie in Abbildung 1 zu sehen, ein Scatternet entstehen. Slaves können so in unterschiedlichen Piconets auf einer timedivision-multiplex-basis teilnehmen. Hierbei ist zu beachten, dass der Master eines Piconet, ein Slave eines anderen Piconet sein kann. Die Piconets sind nicht zeit- oder frequenzsynchron. Jedes Piconet besitzt seine eigene RF-Sprung-Frequenz. 2.3 Der Bluetooth Protocol Stack Um die Zusammenarbeit der Entwickler zu erleichtern und eine universell anwendbare Funkschnittstelle zu schaffen, hat die SIG einen offenen Standard geschaffen, welcher in 4

5 der Bluetooth Specification Version 1.0[1] festgehalten ist. Der Bluetooth Stack ist in zwei Bereiche unterteilt: Der Kontroller, welcher üblicherweise in Hardware umgesetzt ist und der Bluetooth Software Protokoll Stack, mit dem Applikationen und Dienste interagieren. Die Abbildung 2 zeigt den Protokoll Stack. Das Basisband realisiert die physikalische Verbindung zwischen den einzelnen Stationen in einem Piconet. Die Übertragung findet paketvermittelt statt, wobei in definierten Zeitschlitzen Daten gesendet werden. Es existieren zwei Übertragungsvarianten, synchron verbindungsorientiert (SCO) und asynchron verbindungslos (ACL) Das Link Manager Protocol (LMP) ist verantwortlich für den Verbindungsaufbau und die Sicherheit von Bluetooth-Links. Es wird eine Authentifizierung und Verschlüsselung mittels Sicherheitscodes durchgeführt. Ebenso ist der Link Manager verantwortlich für die Kontrolle und Aushandlung der Basisband-Paketgröße. Weiterhin regelt das LMP die benötigte Sendeleistung und verwaltet die angemeldeten Stationen eines Piconet. Das Logical Link Control and Adaptation Protocol (L2CAP) verbindet die höherliegenden Schichten des Stacks mit dem darunter liegenden Basisband. Dabei ist ein paralleles Arbeiten zum LMP möglich, mit dem Unterschied, dass L2CAP Dienste für die oberen Schichten zur Verfügung stellt, wenn die Nutzdaten nicht als LMP Nachricht geschickt werden können. L2CAP bietet verbindungsorientierte und verbindungslose Dienste an. Dabei ist eine Protokollverschachtelung, -aufteilung und - zusammensetzung möglich. Das Service Discovery Protocol (SDP) stellt die Grundlage aller Bluetooth- Anwendungen dar und ist der wichtigste Teil des gesamten Protokoll- Rahmens. Über SDP werden alle für die Abbildung 2: Bluetooth-Stack Datenübertragung nötigen Informationen ausgetauscht, um dann eine Verbindung zwischen zwei oder mehreren Bluetooth-Projekten einzurichten. Das Cable Replacement Protocol (RFCOMM) dient zur Emulation einer seriellen RS-232 Kabelverbindung über Luftschnittstelle. RFCOMM wird von höherliegenden Protokollschichten genutzt, die Transportkapazität über eine serielle Leitung benötigen. Über den Schnittstellen RFCOMM und L2CAP sitzen dann Protokolle wie IP oder WAP, 5

6 um Daten über die Funkschnittstelle auszutauschen. Dabei laufen die Anwendungen über eine oder mehrere vertikale Kanäle des Protokoll-Stacks. Der Grund-Stack bis RFCOMM wurde so konzipiert, dass bereits vorhandene und bewährte Protokolle darauf aufsetzen können. Beim Host Controller Interface (HCI) handelt es sich um ein Kommando-Interface, welches dem Basisband Controller, dem Link Manager und der anderen Hardware, Statusinformationen und Steuerbefehle vermittelt. Die Protokolle Baseband, LMP, L2CAP und SDP zählen zu den sogenannten Bluetooth Core Protocols, welche von der Bluetooth SIG veröffentlicht wurden. 3 JSR-82 API JSR-82 wurde innerhalb des Java Community Process spezifiziert und erweitert die MIDP2.0 Platform um Bluetooth- und OBEX-Unterstützung. Die API[2] ist eng mit dem im Package javax.microedition.io enthaltenen Generic Connection Framework (GCF) verbunden und verwendet mehrere seiner Klassen und Schnittstellen. 3.1 Anforderungen Die API benötigt 512KB Arbeitsspeicher sowie volle Unterstützung für CLDC1.0. Das Gerät muss Bluetooth unterstützen und grundlegende Funktionen wie Authorisierung im Rahmen des Bluetooth Control Centers bereitstellen. Bluetooth und Java allein sind kein Garant dafür, dass auch JSR-82 im Mobiltelefon integriert ist. Hier bleibt einem vorläufig nichts anderes übrig, als die Datenblätter der Geräte genau zu studieren. 3.2 Bluetooth Control Center Das Bluetooth Control Center (BCC) regelt den Zugriff auf die Bluetoothhardware und die unteren Protokollschichten. Zu den Aufgaben des BCCs gehören die Bereitstellung von grundlegenden Sicherheitsfunktionen (Autorisierung, Authentifizierung und Verschlüsselung), sowie die Verwaltung des Gerätenamens, der bereits bekannten Geräte und der Sichtbarkeit des Gerätes. Das BCC ist ein Bestandteil Betriebssystems des mobilen Gerätes der API und kein Teil der API. 3.3 Einführung in die API Die API besteht aus zwei Paketen: javax.bluetooth und javax.obex. Beide können unabhängig voneinander genutzt werden. Zum Beispiel lässt sich die OBEX Implemen- 6

7 tierung auch zusammen mit IrDA verwenden. OBEX wird nicht im Rahmen dieses Textes behandelt. Die API bietet nur Zugriff auf die Datenkommunikation mit Bluetooth, Sprachkommunikation wurde nicht integriert. Im weiteren Verlauf demonstrieten wir den Umgang anhand zweier Beispielprogramme, je eins für Server und Client. Ziel ist es, den String Hallo Welt vom Server zum Client zu schicken. Dazu muss der Server den Dienst registrieren, und der Client eine Verbindung zu diesem Dienst herstellen. Den kompletten Quelltext des Beispiels finden Sie im Anhang Geräteverwaltung Für die Geräteverwaltung stellt die API im wesentlichen zwei Klassen zur Verfügung: für entfernte Geräte ist die Klasse RemoteDevice zuständig, das lokale Gerät wird über die Klasse LocalDevice verwaltet. LocalDevice ermöglicht es mittels LocalDevice l o c a l = LocalDevice. getlocaldevice ( ) ; int maxconnections = I n t e g e r. p a r s e I n t ( l o c a l. getproperty ( bluetooth. connected. d e v i c e s. max ) ) ; Dienst registrieren Serverseitig müssen wir zunächst den Dienst registrieren. Dazu muss ein neuer ServiceRecord der Service Discovery DataBase (SDDB) hinzugefügt werden. Dies geschieht mittels der Connector Klasse des GCFs: 7

8 StreamConnectionNotifier s e r v i c e = ( StreamConnectionNotifier ) Connector. open ( btl2cap : / / l o c a l h o s t :42249 B70A08911DAA C9A66 ) ; In der URI ist als Protokoll btl2cap für L2CAP angegeben. Hinter localhost wird die UUID angegeben, eine möglichst weltweit eindeutige 128-Bit Zahl. Über sie kann der Dienst später identifiziert werden. Als Ergebnis erhalten wir eine StreamConnectionNotifier Instanz, über die nun mittels ihrer Methode acceptandopen() neue L2CAPConnection Verbindungen geöffnet werden können Discovery Nachdem der Dienst registriert wurde, möchten wir von unserem Client darauf zugreifen. Um den eigentlichen Verbindungsaufbau starten zu können, muss unser Client das Gerät finden, auf dem der Dienst registriert wurde. Geräte suchen Zuerst müssen wir nach vorhanden Geräten in der Nähe suchen. JSR-82 stellt dafür die Klasse DiscoveryAgent bereit. Eine Instanz des DiscoveryAgent kann mittels DiscoveryAgend agent = LocalDevice. getdiscoveryagent ( ) ; erstellt werden. Der Discovery Agent unterscheidet zwischen der Suche nach Geräten (Inquiry), und der Suche nach Diensten. Die Suche nach Geräten kann mittels agent. s t a r t I n q u i r y ( d i s c o v e r y L i s t e n e r ) ; gestartet werden. Der übergebene DiscoveryListener implementiert einige Callback- Methoden, die während der Suche aufgerufen werden. In unserem Beispiel wird die Methode devicediscovered aufgerufen, wenn ein neues Gerät gefunden wurde. Nach Beenden der Suche wird abschließend inquirycompleted aufgerufen. Ein Inquiry dauert einige Sekunden, daher kann über den DiscoveryAgent ebenfalls eine Liste bekannter Geräte sowie eine Liste zuletzt gefundener Geräte über die Funktion retreivedevices abgerufen werden. Dienste suchen Nachdem wir nun hoffentlich eines oder mehrere Geräte gefunden haben, möchten wir auf diesen nach dem von uns beim Server registrierten Dienst suchen. DiscoveryAgent 8

9 stellt dafür die Methode searchdevices() zur Verfügung. Die Anzahl der Geräte, auf denen gleichzeitig nach Diensten gesucht werden kann, ist beschränkt und kann über die Property bluetooth.sd.trans.max abgefragt werden. UUID [ ] s e a r c h L i s t = new UUID [ 1 ] ; s e a r c h L i s t [ 0 ] = new UUID( 42249B70A08911DAA C9A66, f a l s e ) ; int t r a n s i d = agent. s e a r c h D e v i c e s ( null, s e a r c h L i s t, device, d i s c o v e r y L i s t e n e r ) ; Der Methode wird eine Liste mit UUIDs mitgegeben, die in unserem Beispiel nur die beim Registrieren des Servers angegebene UUID enthält. Wie schon bei startinquiry wird eine Implementation des DiscoveryListeners übergeben. Wurde ein Dienst gefunden, wird die servicesdiscovered Methode des Discovery Listeners aufgerufen. Nach Beenden der Suche wird die Methode servicesearchcompleted aufgerufen. Mittels eines ServiceRecords kann nun über L2CAPConnection connection = ( L2CAPConnection ) Connector. open ( s e r v i c e R e c o r d. getconnectionurl ( ServiceRecord.NOAUTHENTICATE NOENCRYPT, f a l s e ) ) ; eine L2CAP-Verbindung erstellt werden Kommunikation Wir haben jetzt eine Verbindung zwischen beiden Geräten hergestellt und möchten nun Daten zwischen diesen übertragen. Bei L2CAP-Verbindungen trägt die Anwendung selbst die Verantwortung, die Daten in Bytes zu konvertieren und auf einzelne Pakete zu verteilen. Die maximale Größe eines Paketes ist begrenzt, in der Bluetooth Spezifikation werden lediglich 48 Bytes als garantierte Größe genannt. Die genaue Größe ist geräteabhängig und kann über die Property bluetooth.l2cap.receivemtu.max abgefragt werden. Für unser Beispiel sollten 48 Bytes aber mehr als genügen. Wir möchten nun den String Hallo Welt vom Server zum Client übertragen. Strings besitzen idealerweise schon die Methode getbytes() zum Konvertieren in Byte Arrays. S t r i n g s t r = Hallo Welt! ; try { connection. send ( s t r. getbytes ( ) ) ; catch ( IOException e ) { e. printstacktrace ( ) ; 9

10 Auf der Empfängerseite wird das gesendete Paket empfangen und der Text auf der Konsole ausgegeben. int length = connection. getreceivemtu ( ) ; byte [ ] data = new byte [ length ] ; length = connection. r e c e i v e ( data ) ; System. out. p r i n t l n (new S t r i n g ( data ) ) ; 3.4 Sicherheit Mit der steigenden Verbreitung von Bluetoothgeräten im Alltag geraten diese zunehmend in den Fokus potentieller Angreifer. Um ein Mindestmaß an Sicherheit zu gewährleisten bringt JSR-82 dafür die grundlegenden Funktionen Authentifizierung, Autorisierung und Verschlüsselung mit. Autorisierung und Verschlüsselung können nur nach vorheriger Authentifizierung genutzt werden. Clients können nicht autorisieren. Die Authentifizierung basiert auf der manuellen Eingabe eines identischen Codes bei Server und Client. Dieser muss von den Benutzern vereinbart werden. Geräte ohne Eingabemöglichkeit, wie zum Beispiel Headsets, besitzen in der Regel einen fest eingebauten Code, der nicht verändert werden kann. Die genaue Realisierung der Authentifizierung ist geräteabhängig und wird vom BCC übernommen. Bereits beim Verbindungsaufbau können die Sicherheitsfunktionen aktiviert werden. Dazu kann die Verbindungs-URI mit folgenden Parametern erweitert werden: authenticate=true, authorize=true bzw. encrypt=true Für den Client stellt die Methode getconnectionurl der ServiceRecord Schnittstelle bereits Parameter dafür zur Verfügung. Manchmal ist es aber auch notwendig, eine bereits bestehende Verbindung nachträglich authentifizieren und verschlüsseln. Dies ist über eine RemoteDevice Instanz möglich: boolean r e s u l t = remotedevice. a u t h e n t i c a t e ( ) ; i f ( r e s u l t ) remotedevice. encrypt ( connection, true ) ; 4 Konklusion und Ausblick JSR-82 ist eine konsequente Erweiterung des GCFs. Die API stellt alles nötige zur Verfügung, um selbst anspruchsvolle Bluetoothanwendungen zu entwickeln. Bedauerlicherweise wurde jedoch zugunsten der Einfachheit der API auf einige nützliche Funktionen verzichtet. Multicast wurde ebenso wie unsichere L2CAP-Verbindung nicht integriert, 10

11 obwohl gerade Spiele davon hätten profitieren können. Eine Überarbeitung der API in diesen Punkten vor einer eventuellen Integration in den Nachfolger von MIDP2.0 wäre daher wünschenswert. Literatur [1] Dan Sönnerstam et al, Bluetooth Specification, Bluetooth SIG, Inc., 2003 [2] Motorola, Java APIs for Bluetooth Wireless Technology (JSR-82), Motorola, 2002 [3] Qusay H. Mahmoud, Wireless Application Programming with J2ME and Bluetooth, Sun Microsystems, Februar 2003 [4] Qusay H. Mahmoud, The Java APIs for Bluetooth Wireless Technology, Sun Microsystems, April 2003 [5] C. Enrique Ortiz, Using the Java APIs for Bluetooth Wireless Technology, Sun Microsystems, December 2004 [6] Nittin Mittal, Technical Overview of Java MIDP, Nokia,

12 A Glossar ACL Asynchronous Connectionless, asynchron verbindungslos API Application Programming Interface, Programmierschnittstelle BCC Bluetooth Control Center, verwaltet die Bluetoothhardware und ist Teil der Gerätesoftware CLDC Connected Limited Device Configuration GCF Generic Connection Framework, Teil von MIDP zum Erstellen von Low-Level- Netzwerkverbindungen (javax.microedition.io) HCI Host Controller Interface IrDA Infrared Data Association, Zusammenschluß von Unternehmen zur Förderung von Infrarotkommunikation ISM Industrial Scientific Medical, lizensloses Frequenzband JCP Java Community Process JSR Java Specification Request, Vorschlag für die Erweiterung der Java-Spezifikation L2CAP Logical Link Control and Adaptation Protocol LMP Link Manager Protocol, verantwortlich für Verbindungsaufbau und Sicherheit von Bluetooth-Links MIDP Mobile Information Device Profile, zur Zeit in der zweiten Version, Teil der Java Laufzeitumgebung für Mobile Geräte MTU Maxium Transfer Unit, maximale Übertragungsgröße OBEX OBject EXchange, Protokoll zur Übermittlung von Objekten wie Visitenkarten, ursprünglich von der IrDA für Infrarotkommunikation entwickelt RF Radio-Frequenz RFCOMM Cable Replacement Protocoll, emuliert eine serielle Schnittstelle SCO Synchronous Connection-Oriented, synchron verbindungsorientiert SDP Service Discovery Protocol SIG Bluetooth Special Interest Group, Vereinigung von Unternehmen, die Bluetooth entwickeln SPP Serial Port Profile, Implementation von RFCOMM TDM Time-Division Multiplexing, Zeitmultiplexverfahren UUID Universally Unique IDentifier, weltweit eindeutige 128-Bit Nummer 12

13 B Beispiel (Server) package HelloBluetooth ; import javax. bluetooth. ; import javax. m i c r o e d i t i o n. i o. ; import javax. m i c r o e d i t i o n. midlet. MIDlet ; import javax. m i c r o e d i t i o n. midlet. MIDletStateChangeException ; public class Server extends MIDlet { protected void startapp ( ) throws MIDletStateChangeException { try { LocalDevice l o c a l = LocalDevice. getlocaldevice ( ) ; // ServiceRecord erzeugen l o c a l. s e t D i s c o v e r a b l e ( DiscoveryAgent.GIAC) ; L2CAPConnectionNotifier s e r v i c e = ( L2CAPConnectionNotifier ) Connector. open ( btl2cap : / / l o c a l h o s t :42249 B70A08911DAA C9A66 ) ; ServiceRecord s r = l o c a l. getrecord ( s e r v i c e ) ; // Verbindungsanfrage annehmen L2CAPConnection connection = ( L2CAPConnection ) s e r v i c e. acceptandopen ( ) ; // S t r i n g senden S t r i n g s t r = Hallo Welt! ; connection. send ( s t r. getbytes ( ) ) ; // Dienst entfernen, Verbindungen b l e i b e n o f f e n s e r v i c e. c l o s e ( ) ; l o c a l. s e t D i s c o v e r a b l e ( DiscoveryAgent.NOT DISCOVERABLE) ; catch ( Exception e ) { // keine Fehlerbehandlung e. printstacktrace ( ) ; protected void pauseapp ( ) { protected void destroyapp ( boolean a r g 0 ) throws MIDletStateChangeException { 13

14 C Beispiel (Client) package HelloBluetooth ; import java. u t i l. Enumeration ; import java. u t i l. Vector ; import javax. bluetooth. ; import javax. m i c r o e d i t i o n. i o. Connector ; import javax. m i c r o e d i t i o n. midlet. MIDlet ; import javax. m i c r o e d i t i o n. midlet. MIDletStateChangeException ; public class C l i e n t extends MIDlet implements D i s c o v e r y L i s t e n e r { private Vector d e v i c e s = new Vector ( ) ; private Vector s e r v i c e s = new Vector ( ) ; private DiscoveryAgent agent ; protected void startapp ( ) throws MIDletStateChangeException { try { LocalDevice l o c a l = LocalDevice. getlocaldevice ( ) ; agent = l o c a l. getdiscoveryagent ( ) ; // Gerätesuche s t a r t e n agent. s t a r t I n q u i r y ( DiscoveryAgent.GIAC, this ) ; catch ( Exception e ) { e. printstacktrace ( ) ; public void d e v i c e D i s c o v e r e d ( RemoteDevice d, DeviceClass cod ) { d e v i c e s. addelement ( d ) ; public void s e r v i c e s D i s c o v e r e d ( int transid, ServiceRecord [ ] s r ) { s e r v i c e s. addelement ( s r [ 0 ] ) ; public void servicesearchcompleted ( int transid, int arg1 ) { Enumeration enum = s e r v i c e s. elements ( ) ; while (enum. hasmoreelements ( ) ) { ServiceRecord s r = ( ServiceRecord ) enum. nextelement ( ) ; try { // Verbinden 14

15 L2CAPConnection connection = ( L2CAPConnection ) Connector. open ( s r. getconnectionurl ( ServiceRecord.NOAUTHENTICATE NOENCRYPT, f a l s e ) ) ; // MTU abfragen int length = connection. getreceivemtu ( ) ; byte [ ] data = new byte [ length ] ; // S t r i n g ausgeben length = connection. r e c e i v e ( data ) ; System. out. p r i n t l n (new S t r i n g ( data, 0, length ) ) ; catch ( Exception e ) { e. printstacktrace ( ) ; public void inquirycompleted ( int arg0 ) { Enumeration enum = d e v i c e s. elements ( ) ; try { // auf a l l e n gefundenen Geräten nach Dienst suchen while (enum. hasmoreelements ( ) ) { synchronized ( this ) { RemoteDevice d e v i c e = ( RemoteDevice ) enum. nextelement ( ) ; UUID [ ] u u i d L i s t = new UUID [ 1 ] ; u u i d L i s t [ 0 ] = new UUID( B70A08911DAA C9A66, f a l s e ) ; agent. s e a r c h S e r v i c e s ( null, uuidlist, device, this ) ; catch ( BluetoothStateException e ) { e. printstacktrace ( ) ; protected void pauseapp ( ) { protected void destroyapp ( boolean a r g 0 ) throws MIDletStateChangeException { 15