views:

115

answers:

7

Hi there.

I am trying to remake a java application into an android application, but I cannot make it work. The application is meant to talk to a device that uses OBEX Push. The device cannot take any incoming connections and it has no user interface but some LEDs.

The java code snippet I am trying to remake is following:

LocalDevice local;
local = LocalDevice.getLocalDevice();
local.setDiscoverable(DiscoveryAgent.LIAC);
String sConnectionURL = "btspp://localhost:" + myUUID + ";name=" + obexName;
this.server = (StreamConnectionNotifier) Connector.open(sConnectionURL);

I am no java expert, but as far as I know, this snippet should register an SPP service with the name obexName and start to listen for incoming connections via the UUID myUUID. This works as intended.

When the device is pairing to the phone running the java midlet, it will set a bit to send to an SPP with the UUID on the phone or not send at all. If it cannot find any SPP with the UUID during the pairing, it will try to connect to the phone using normal OBEX instead.

This is the technique I cannot make work on an android phone, neither an HTC Hero, nor an HTC Desire, both with version 2.1-update1. No matter how I try, the phone is only connecting to the phone, and not to the application as desired.

I created a class much like the example on developer.android.com:

private class AcceptThread extends Thread
{
    private final BluetoothServerSocket __serverSocket;

    public AcceptThread()
    {
        BluetoothServerSocket tmpSocket = null;

        trace("Creating AcceptThread");
        try 
        {
            trace("Starting to listen");
            tmpSocket = _bluetoothAdapter.listenUsingRfcommWithServiceRecord(obexName, myUUID);
            trace("Listening successful");
        } 
        catch (Exception e) 
        {
            trace("Listening NOT successful");
            // TODO: handle exception
        }
        __serverSocket = tmpSocket;
        trace("AcceptThread created");
    }

    public void run()
    {
        BluetoothSocket socket = null;
        trace("AcceptThread started");
        while(true)
        {
            try 
            {
                trace("Waiting for socket acceptance");
                socket = __serverSocket.accept();
                trace( "Socket accepted");
            } 
            catch (Exception e) 
            {
                trace("Error when accepting socket: " + e.getLocalizedMessage());
                break;
                // TODO: handle exception
            }
            if (socket != null)
            {
                synchronized (BTTransfer.this)
                {
                    trace("Socket exists");
                    try
                    {
                        __serverSocket.close();
                        trace("Socket successfully closed");
                    }
                    catch (Exception e) {}
                    break;
                }
            }
            trace("Socket does not exist");
        }
    }

    public void cancel()
    {
        try
        {
            __serverSocket.close();
        }
        catch (Exception e) {}
        trace("AcceptThread cancelled and Socket successfully closed");
    }
}

Comments about the code:
The trace function is a synchronized function feeding text to the Handler object, giving the UI information.
The application is knowingly not doing anything but closing the connection after a successful connection.
The application reaches "Waiting for socket acceptance" but never the trace after that.

I have a PC .NET application that can disguise itself as the device, and by using correct UUID it works flawlessly, but then the PC is already paired to the phone, and do not have the bit saying it should send over normal OBEX if it cannot find the specified one.

I have been working with this for several days, and can not come up with a solution. Does anyone out there have any ideas?

Thanks in advance,
/Trygg

A: 

Just to be sure, did you set the right permissions in the Android manifest?

Jelmer
Yes I did, or at least I think so. I figure that if it works with the PC, it should be correct?
Niklas Trygg
A: 

Hi Trygg,

Did you got this working? I am trying to get the same code working but insane. Just for thought what UUID you are using? I have tried a bunch of uuid but is not working the accept mehtod never returns.

Thansk in advance for sharing.

arsi
A: 

I did not get this working, but made sort of a workaround. I registerad a BroadcastReceiver on the event BluetoothDevice.ACTION_ACL_DISCONNECTED and then checked for what device was disconnected. If it was "mine" I searched for the files in the bluetooth inbox.

I got a message from the manufacturer of the device saying that it will not work yet, but they are working on a new firmware. This is why I haven't been active here nor worked for a better solution.

Niklas Trygg
A: 

Thanks for sharing mate. Good solution.

This is what I have workaround as well. But everytime there is a file sent over obex there is a notification coming up even if the device is set to authorized which is a pain if you are developing an app that requires frequent sending of files to your android app.

Any ideas of getting workaround for this notification i.e. suppressing them via code?

arsi
A: 

Sadly, I know about the problem. My "solution" is instructing the users about it, to just delete the second message. It's annoying, but I have found of no way to delete them in code.

Further, I have problems with HTC Hero and HTC Legend, but it works flawlessly (with the workarounds) in HTC Desire. Anyone know what the differencies are? Do they have different versions of firmware, or are there any differencies in the hardware as well?

/Trygg

Niklas Trygg
A: 

Deleting the second message? didnt really get this point. So if you delete the second message, then notification will not come up again? I working on htc legend right now may be that is the fact that i dont understand very clearly.

arsi
A: 

With the second message I mean following:

When the device contacts the phone, there is a notification in the drop down menu telling a device is contacting. A few seconds later (depending on the file size) the file is transferred, and there is a second notification telling the file is transmitted. This is the second "message".

Since I listen for the disconnection from the device, and the customer then through my program already knows that the file is transmitted, this second notification is utterly useless. Still, it will come up every time the device sends files to the phone.

In our tests on Legend and Hero, we never come to the second notification, though. This is where those phones fail. The first notification comes, then nothing, and the device returns an error after a few seconds.

Hope this helps to clarify what I meant.

/Trygg

Niklas Trygg