Empty notification string

[mic92]

Empty notification string

[GoogleCodeExporter]

Hmmm this is strange - are you listening as RFCOMM? How are you describing your 
service to SDP?

Original comment by [email protected] on 26 Aug 2010 at 4:32

• Added labels: Component-Communication, OpSys-Android

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi, 
I use both androdi-notifier-desktop 
(http://code.google.com/p/android-notifier-desktop/) and a little sharp project 
to see data. The result is the same. No data is transfert.

Here the code of my little program. The statement reads = 
sc.Receive(buffer,buffer.Length,0); alwayes return empty string.

/*
 * Created by SharpDevelop.
 * User: emmanuele
 * Date: 25/08/2010
 * Time: 16.33
 * 
 * To change this template use Tools | Options | Coding | Edit Standard Headers.
 */
using System;
using System.Collections;
using System.ComponentModel;
using System.IO;
using InTheHand.Net;
using InTheHand.Net.Sockets;
using InTheHand.Net.Bluetooth;
using System.Net.Sockets;

namespace BlueToothLineListener
{
    class Program
    {
        public static void Main(string[] args)
        {
            Console.WriteLine("Start Server....\n");

            // TODO: Implement Functionality Here

            byte[] buffer = new byte[255];

            Guid service = new Guid("{7674047E-6E47-4BF0-831F-209E3F9DD23F}"); // Notification

            Console.Write("Get Bluetooth and set it as discovery\n");
            BluetoothRadio br = BluetoothRadio.PrimaryRadio;
            br.Mode = RadioMode.Discoverable;

            Console.Write("Get Listner\n");
            BluetoothListener bl = new BluetoothListener(service);
            bl.Stop();
            bl.Start();

            Console.Write("Accept Client\n");
            //BluetoothClient bc = bl.AcceptBluetoothClient();          
            Socket sc = bl.AcceptSocket();
            Console.WriteLine("Connection accepted.");

            int reads;
            reads = sc.Receive(buffer,buffer.Length,0);
            String msg = "";
            if ( reads > 0 )
                msg = " -> [" + buffer.ToString() + "]";
            else
                msg = "no data";

            Console.Write( msg +"\n");

            bl.Stop();

            Console.Write("Press any key to continue . . . ");
            Console.ReadKey(true);
        }
    }
}

Original comment by [email protected] on 29 Aug 2010 at 8:47

[GoogleCodeExporter]

Hi! I finaly foudn more detail on this issue.

On my HTC Hero (2.1) i have 2 paried device: My computer and a earphone. I have 
disabled the earphone and now get data over bluetooth. Unfotunatly, about one 
notification every 2 will be lost (lost 30% of test) with and have the same 
issue (empty notification string).

With both device paried the notification is missed in 90% of test. 

Using Wifi this the notification string is always filled.

this info can be usefull?
Thanks
Emmanuele

Original comment by [email protected] on 29 Aug 2010 at 9:16

[GoogleCodeExporter]

Maybe it's a device specific issue. I'm not able to reproduce this sending ping 
notifications with a Nexus One running froyo.

Original comment by [email protected] on 29 Aug 2010 at 9:27

[GoogleCodeExporter]

I'm getting this issue with a Galaxy S running 2.1, sending pings to a Win7 
32bit PC with Java 1.6.0_21-b06 running AND. Here's the AND log:

2010-09-13 13:14:52,205 ERROR [BluetoothNotificationReceiver] - Error handling 
bluetooth notification
java.lang.IllegalStateException: Protocol version [] is not supported
    at com.google.code.notifier.desktop.parsing.StringNotificationParser.parse(StringNotificationParser.java:36)
    at com.google.code.notifier.desktop.parsing.StringNotificationParser.parse(StringNotificationParser.java:25)
    at com.google.code.notifier.desktop.notification.bluetooth.BluetoothNotificationReceiver$1.run(BluetoothNotificationReceiver.java:80)
    at java.lang.Thread.run(Unknown Source)
2010-09-13 13:14:52,206 INFO [NotificationManagerImpl] - Notification received: 
deviceId=null, notificationId=e5e2548c-6280-4101-b870-e900b4b6d37e, type=ERROR
2010-09-13 13:14:52,206 DEBUG [bluetooth] - closing RFCOMM Connection 1352
2010-09-13 13:14:52,206 DEBUG [bluetooth] - connection closed, open now 0
2010-09-13 13:14:52,206 DEBUG [bluetooth] - socket[1352] close
2010-09-13 13:14:52,207 DEBUG [bluetooth] - socket[860] accept

Original comment by [email protected] on 13 Sep 2010 at 5:18

[GoogleCodeExporter]

I think it would be safer if android-notifier called flush() on the socket 
output stream and close() it before closing the socket. Some bluetooth stacks 
on desktop don't like it if I don't call these methods.

Original comment by [email protected] on 13 Sep 2010 at 2:28

[GoogleCodeExporter]

@mark The guy in this link said it was solved after updating to samsung's 
latest firmware, could you try that?

http://stackoverflow.com/questions/2661932/problem-with-bluetooth-on-android-2-1
-samsung-spica-i5700-where-pairing-works-b

Original comment by [email protected] on 16 Sep 2010 at 1:14

[GoogleCodeExporter]

I too am having this issue. My specs are as follows:
HTC Droid Incredible running 2.2 (SkyRaider 2.5.2 Sense build)
MacBook Pro running 10.6.4, 64-bit
Java on the MBP version 1.6.0_20-b02-279-10M3065.

I receive notifications, and reliably so, despite having two devices paired 
(the other being a headset). But, they are all errors and all have a similar 
report to the following in the log file. I can reproduce this reliably using 
the test notification. This log was thrown by a received SMS.

2010-09-19 00:34:56,084 DEBUG [bluetooth] - will throw exception 
javax/bluetooth/BluetoothConnectionException(Failed to open connection(2) 
[0xe00002cd])
2010-09-19 00:34:56,185 ERROR [BluetoothNotificationReceiver] - Error handling 
bluetooth notification
javax.bluetooth.BluetoothConnectionException: Failed to open connection(2) 
[0xe00002cd]
    at com.intel.bluetooth.BluetoothStackOSX.rfServerAcceptAndOpenRfServerConnection(Native Method)
    at com.intel.bluetooth.BluetoothRFCommConnectionNotifier.acceptAndOpen(BluetoothRFCommConnectionNotifier.java:74)
    at com.google.code.notifier.desktop.notification.bluetooth.BluetoothNotificationReceiver$1.run(BluetoothNotificationReceiver.java:76)
    at java.lang.Thread.run(Thread.java:637)
2010-09-19 00:34:56,187 INFO [NotificationManagerImpl] - Notification received: 
deviceId=null, notificationId=ee2651c1-a37c-49bf-994c-b3ec652af2b0, type=ERROR
2010-09-19 00:34:56,187 DEBUG [bluetooth] - create ChannelController to accept 
incoming connection

Original comment by [email protected] on 19 Sep 2010 at 5:43

[GoogleCodeExporter]

devmage - that's definitely not the same issue - you probably want to report 
this at the multiplatform client here: 
http://code.google.com/p/android-notifier-desktop/

Original comment by [email protected] on 19 Sep 2010 at 6:15

[GoogleCodeExporter]

I've updated AN, AND - am now successfully receiving messages. Occasionally 
getting exact same error as #6 but haven't been able to reliably replicate it. 
Haven't touched Galaxy S firmware yet. Thanks so far!

Original comment by [email protected] on 20 Sep 2010 at 8:30

[GoogleCodeExporter]

Issue 201 has been merged into this issue.

Original comment by [email protected] on 4 Oct 2010 at 5:07

[GoogleCodeExporter]

FWIW, I am also running with two bluetooth connections on my phone (the other 
to a headphone) and on the laptop (the other to a mouse) when I get this problem

Original comment by [email protected] on 5 Oct 2010 at 9:32

[GoogleCodeExporter]

Hi, the new version of MultiDroidNotifier has the same problem. 

Here the log of application (if is usefull).

Thanks for your job.

Ps. Using encripted notification is very usefull since I work in a lan with 3 
other android device...:-)

Original comment by [email protected] on 9 Oct 2010 at 9:11

Attachments:

• android-notifier-desktop.log

[GoogleCodeExporter]

Yes, this error is caused by empty notifications, I changed the code to log a 
message saying an empty notification was received instead of this error, it 
will be in next release.

Original comment by [email protected] on 10 Oct 2010 at 1:59