As a respected member of the community, I greatly appreciate you taking the time to comment. The backup feature is another in a long list of clever workarounds that we’ve all implemented in apps; and that certainly does work. However it is still a workaround. The same is true with Romain’s release of ViewServer. I just hope for a day when we don’t have to invent such things to jump over the hurdles. Especially since Google was so helpful in the early day providing these tools.

Cheers,
Dave

Your application needs to implement a backup-to-external-storage feature. Expecting your users to root their devices to back up your data is unrealistic. And, as a side benefit, this eliminates the need for you to root the device to access those same files.

“Using the HierarchyViewer tool to debug issues with layouts”

As you noted, this can be resolved with ViewServer.

‘Running ADB in TCP/IP mode”

While important for you, your use cases represent maybe 1-2% of the developer audience. Most people are developing pure-software apps for ordinary devices, where availability of the USB port is not an issue.

I’m not saying that rooting is bad, nor that your dream of userdebug builds of Nexus devices is bad, nor that the pain you went through somehow didn’t exist. However:

“they are all a necessary part of developing applications”

is over-stating the case IMHO. None are a necessary part of developing applications in general. Some, such as ADB over TCP/IP, may be necessary for developing certain applications, as is your case. All are certainly handy, but “handy” is short of “necessary” by a fairly wide margin.

My suggestion to you, if you’ve decided you must use ImageButton, would be to clear its focusable flag; as this is the root of the issue. You could do this with either setFocusable(false) in Java or android:focusable=”false” in XML.

But i need to fix it with imageButton itself … Can we have any options … Let us find…

Any way Its really useful for me… Thanks

Thanks for the great information here, I appreciate you sharing it.

I’ve been trying to find a way to initiate the low level ACL connection with a device that is “paired, but not connected” and within range. I was hopeful that if I could identify the UUID and connect to it, that it would re-attempt the ACL, but alas it didn’t.

Thanks again!

My first mention will be that throughout this process, Logcat is your friend. The OS will log out when it fires the UUID broadcast, so you can see if it is really firing or if the application just isn’t catching it.

I have noticed when trying to force the intent callback by calling BluetoothSocket.connect() with a fake UUID, the timing is a bit unruly on certain devices. On the HTC Evo, for instance, it can sometimes take up to one minute after the OS logged the broadcast redirect before the BroadcastReceiver in the app picks it up.

I’m going to assume though, based on your comment about null returns, that you are trying to access the hidden methods using reflection. Here is some sample code to do this that I have tested on a handful of 2.2 devices, so perhaps the answer to your issues lies within there. The first is using fetchUuidsWithSdp, which WILL force the system to fire the misspelled UUID broadcast intent that you can catch using the receiver code in the post (you may also try defining a BroadcastReceiver in your manifest, instead of inside an Activity class like I did):

Class cl = Class.forName("android.bluetooth.BluetoothDevice");
Class[] par = {};
Method method = cl.getMethod("fetchUuidsWithSdp", par);
Object[] args = {};
method.invoke(device, args);


Notice we don’t pay attention to the return value from the invoked method, because the interesting information will come back when the intent is fired. The next example is using getUuids, which WILL NOT fire said system intent. The UUID data is returned as an array from this method call:

Class cl = Class.forName("android.bluetooth.BluetoothDevice");
Class[] par = {};
Method method = cl.getMethod("getUuids", par);
Object[] args = {};
ParcelUuid[] retval = (ParcelUuid[])method.invoke(device, args);


Hope some of that is useful!

I tried using your method to get the UUID of a bluetooth enabled weightscale but no luck. It all returns null. In fact the filter “android.bleutooth.device.action.UUID” is never called. I added another filter BluetoothDevice.ACTION_ACL_CONNECTED to be sure i get a connection and that works. But still the UUID is null. I am testing this on a HTC Desire Android 2.2.

I agree that is it very hard to deal with incoming bluetooth connections in Android. It was so much easier in Windows Mobile 6.5!