JSR-82 Initialization : LocalDevice

LocalDevice class can be considered as the basic entry point to the JSR-82 API. It is used to initialize the JSR-82 stack, and to control the local bluetooth settings. If you are new to JSR-82, check out the JSR-82 Basics tutorial before reading this. JSR 82 API can be broadly classified into the following sections.

  • a. LocalDevice Settings Manipulation
  • Device Discovery
  • Service Discovery
  • Service Registration
  • L2CAP
  • SPP
  • GOEP
  • BCC

Out of these sections ,the LocalDevice class provides the lowest level of access to the bluetooth stack. There is also another part that can more or less be counted among the lowest layers of JSR82 : the Bluetooth Control Center or the BCC. This part is implementation specific and has no standard APIs. Each vendor can expose their own required APIs which they think is appropriate for their JSR82 implementation. In this article we will look in to LocalDevice and how it can be used to manipulate the Local Bluetooth Device settings.

The class LocalDevice represents the local bluetooth device. The actual bluetooth device could be a built-in bluetooth chip in the case of latest bluetooth enabled laptops and mobiles or it could be a USB or UART interface attached to a PC. No matter whatever shape or form the device takes it can be manipulated using the methods of class LocalDevice.

Local Device Methods

public static LocalDevice getLocalDevice()

The LocalDevice class produces a singleton object. i.e. At any instance there’s only one instance of the class in the VM. Hence applications cannot directly instantiate this class. To obtain an instance of this class application has to invoke the method getLocalDevice(). Multiple calls to this method will return the same object. This object can be used to invoke other methods of this class. In effect, this method is the entry point to a JSR-82 API, and initializes the underlying JSR-82 bluetooth stack.

public java.lang.String getBluetoothAddress()

This method returns the unique address of the local bluetooth device as a String.

Each bluetooth device has a 48-bit or 6-byte value which is termed as the device’s bluetooth address. This is the unique value that differentiates one bluetooth device from the other. So if you and your friend each have a bluetooth enabled mobile, then the device addresses of these 2 mobiles will be different. The address will look somewhat like this. 00:55:34:A6:56:89

The ‘:’ used to separate each byte, and is not part of the address. This is usually used to present the address in a readable form.

public java.lang.String getFriendlyName()

This method returns the friendly name of the local bluetooth device.

Though the bluetooth address can be used to identify a bluetooth device it’s not always so easy to remember the 6 byte addresses. Unlike computers human users are not so good with numbers, especially big ones. So to make the task of recognizing a device easier to a human user, each device can be assigned a user friendly name. This is a String and can be set to any value.

public DeviceClass getDeviceClass()

This method returns the class of the local bluetooth device as an Object of DeviceClass. The class DeviceClass has methods to retrieve the major device class, minor device class and service classes of the device.

Each bluetooth device has a device class or (Class of Device, CoD as specified by the bluetooth spec). This field stores information about the type of device and which types of service are supported by the device. For example if the bluetooth deviec is a mobile then in the device class field the particular bit representing mobile should be set. Likewise for services like Imaging or Rendering the respective bits should be set in the CoD field.


Bluetooth devices usually have some way to discover all other neighbouring bluetooth devices within range. But in some cases the device user might wish to hide his device from other searching devices. This is just like logging in to an instance messenger and making ourselves invisible. The hidden device itself can see all other bluetooth devices (that are not hidden) and can perform bluetooth operations but the only difference is that, it will be invisible in the bluetooth network. Later on when the device user wishes to make it visible he can make the device discoverable so that it again becomes visible in the bluetooth network.

Related Methods:

public boolean setDiscoverable(int mode)

This method can be used to make the device visible/invisible. Infact this method sets the discoverable mode of the device. Valid modes are DiscoveryAgent.GIAC, DiscoveryAgent.LIAC, DiscoveryAgent.NOT_DISCOVERABLE.

public int getDiscoverable()

This method returns the current mode of the bluetooth device.

Device Properties

public static java.lang.String getProperty(java.lang.String property)

The local bluetooth device is associated with some properties which specifies the features the device supports and also some specific values related to the features. All these can be retreived by the application running above jsr82.

Device Search

public DiscoveryAgent getDiscoveryAgent()

It has been mentioned earlier that bluetooth devices can search for other bluetooth devices in it’s neighbourhood. Once a device is found, it can be searched for specific services. All this is made possible by the class DiscoveryAgent. This class exports methods to search for both bluetooth devices and services. A localdevice can have only one instance of discovery agent and this is retreived using the above method.

Local Service Database

Each bluetooth device has a service database in which it can register services so as to allow other bluetooth devices to use them. The details of each registered service is kept as an object of class ServiceRecord. The process of creating and registering services will be discussed in a later article. For the time being we’ll examine the ways in which local device’s service records can be manipulated.

Each service record is associated with a Notifier object that registers it. In JSR82 there are notifiers for L2CAP, SPP and GOEP. To retrieve a service record corresponding to a service, the notifier that registered the record is necessary. Once the service record is fetched from the local service database it can be updated with the new values and the modified record can be added to the service database.

Related Methods:

a. public ServiceRecord getRecord(javax.microedition.io.Connection notifier)

This method gets the service record corresponding to a btspp, btl2cap, or btgoep notifier.

b. public void updateRecord(ServiceRecord srvRecord) throws ServiceRegistrationException

Updates the service record in the local SDDB that corresponds to the ServiceRecord parameter. Updating is possible only if srvRecord was obtained using the getRecord() method.

These are the operations that can be performed using the LocalDevice.

AddThis Social Bookmark Button AddThis Feed Button

6 Responses to “JSR-82 Initialization : LocalDevice”

  1. pethum Says:

    Hi all!
    Im interested to know wether is it possible for a device to get the basic RFCOMM service of another device which has not a done any service registration and doesnt accept any client connections

    if any advice mail to pethum85@yahoo.com

  2. Mark Says:

    If the service is not yet registered, then how does the question of using that service arise?

    You may find it more useful to use the JSR82 Discussion Forum to get your doubts clarified

  3. Anas Says:

    can we have more than one local device in same application using JSR-82

    for any advice mail me at anas.koara@yahoo.com

  4. Linda Says:

    Hello Mark,

    I’m doing a project of Bluetooth Scatternet Formation, I’m interested to know,inside a piconet, how can a Bluetooth enabled device change its states, such as active, sniff,hold, park and unpark. Does JSR-82 implement it? Can I access the device manager and LMP via HCI to do it from my java applications? Thank you very much.

  5. Ehsan Says:

    is it possible to find all of local devices that is embedded in a pc.
    i want to do this and order to every local device with its position and remote devices that it was found.

  6. Paddy Says:

    Hi there,

    The MIDlet is used to track the headset and ensure it is in reach at all times to the phone (bluetooth range (ie. 10 metres)) Its purpose is a proximity device – ie the headset is placed on the childs person,if the headset is out of reach of the phone the MIDlet will alert the mobile phone that its out of range ie. the child is more than 10 metres away!

    I’m developing a MIDlet that will search for a bluetooth headset, When it finds the headset It should connect to it.If the headset goes out of range the MIDlet should alert the user. I’m wondering if this is possible? Do I have to open a connection and continually stream data to the headset then catch an error if its lost. Or is there at a very low level a method to ensure both devices are in range?

    Thanks in advance,

    Please comment or email

Leave a Comment