Develop Reference

connection resets when using set_configuration in PyUSB

I've recently updated my android phone to Marshmallow. Unfortunately for me, that broke my python code.
using PyUSB, I can get the device to enter accessory mode. Unfortunately, I can no longer read/write to the device, as now using set_configuration() resets the connection, causing the device to exit accessory mode and re-enter MTP mode.
dev = list(usb.core.find(find_all=True))[0]
dev.ctrl_transfer(0xc0,51,data_or_wLength=2)
dev.ctrl_transfer(0x40,52,wIndex=0,data_or_wLength='SAMSUNG')
dev.ctrl_transfer(0x40,52,wIndex=1,data_or_wLength='SAMSUNG_Android')
dev.ctrl_transfer(0x40,52,wIndex=2,data_or_wLength='16DIGITSERIALNUM')
dev.ctrl_transfer(0x40,52,wIndex=3,data_or_wLength='AOA')
dev.ctrl_transfer(0x40,52,wIndex=4,data_or_wLength='Whatever')
dev.ctrl_transfer(0x40,52,wIndex=5,data_or_wLength='4')
dev.ctrl_transfer(0x40,53)
time.sleep(5)
dev = list(usb.core.find(find_all=True))[0]
dev.set_configuration() ## Aaaaaand we're back to MTP...
I can't find any way around this; no references to this problem. Only solution I can some up with is to learn C and use libusb directly, assuming the PyUSB module is to blame...

Well, this isn't a good solution, but just in case anyone else just happens to come across this problem and find this:
The problem is with the specific backend (libusb0), which sends a message to reset configuration or something like that if an interface is already claimed. In some devices (mine, for example), this causes a programmatic reset of the connection.
My workaround involves using thelibusb1 backend when re-acquiring the device in accessory mode, since it doesn't cause a reset. But since libusb1 won't let me do control transfers, I need to switch between backends.
from usb.backend import libusb0, libusb1, and then be0,be1 = libusb0.get_backend(),libusb1.get_backend().
Then just specify the backend as a parameter to usb.core.find

Android Open Accessory Protocol using javax.usb

I'm working on getting any existing device communicating with Android devices. The device uses javax.usb (which is built on top of libusb) for usb communication and I am attempting to implement the Android Open Accessory Protocol using it. The device currently recognizes the android device and registers the android device with my application. However when I try to:
Attempt to Start in Accessory Mode - Send a 51 control request ("Get Protocol") to figure out if the device supports the Android accessory protocol.
I get a UsbStallException and my app dies. I know very little when it comes to usb from what I have been reading this should work.
Here's the relevant code:
byte req = (byte) (0x80 | 0x40);
UsbControlIrp irp = usbDev.createUsbControlIrp(req, (byte)51, (short)0, (short)0);
usbDev.syncSubmit(irp);
Any insights as to what I'm doing wrong would be appreciated.
PS: the device I'm running this on uses a 1.4 JVM so any solutions will be constrained by that

Android Bluetooth IOException:connection refused

Alright here's the deal. I got two Galaxy Nexus phones both with bluetooth enabled.
I've written a bluetooth connection management app that I use for device discovery and connectivity. It also outputs all the available UUIDs the devices can support.
Looking from http://www.bluetooth.org/Technical/AssignedNumbers/service_discovery.htm the following standard UUIDs are exposed from Galaxy Nexus devices.
0x1116 - NAP
0x112f - PBAP (Phonebook Access Profile)
0x111f - HFP (Hands free)
0x1105 - OPP (Object Push Profile)
0x1112 - HSP (Headset Profile)
0x110c - AVRCP
0x110a - A2DP
I am trying to connect via the OPP profile (UUID 00001105-0000-1000-8000-00805F9B34FB) and push objects (files) between the devices. I've gone though the entire Android API documentation on how to discover, pair/bond (threading etc.) and manage all bluetooth connections. I've managed to successfully connect and talk to a legacy board device via the SPP (0x1101) profile.
However, when I try to use socket.connect() between the two galaxy nexus phones, the pairing dialog shows up and I click Pair button on both devices. After that, I immediately get a Connection Refused IOException. Note that after pairing has occurred once I never get asked again which makes sense since the secure link is cached.
If I can't connect to these standard profiles using these standard UUIDs why are they exposed? How can I connect from my app to any of these profiles and interact with them? Is it because my app is not somehow trusted? What's weird is that even the Share functionality on Android does not work at all either. Is this something completely broken on Android?
Please avoid giving me hints to use the "well known UUID SPP one 0x1101" like the docs say. This is not what I want. I have a fairly good understanding of how this stuff works and I am looking for a real solution or explanation of the problem.
I've seen the typical "reflection" solution but I do not understand why is this still a problem on Android? Why do people use reflection to make this work? Can we file a bug on Android to fix this?
If those UUIDs are standard any app should be able to connect and interact with them. Why is this an issue and why do I get this exception?
Thanks in advance.
UPDATE
So for some reason the object push in the Android system started working. I actually attempted to connect via my app and it was not working. Then, I went to the Contacts app and tried to share a contact which magically worked. Then, I went back to my app and it now it works...wow. That is very weird and there must be an explanation to this.

I ran into this same issue and managed to find a solution that worked for me.
In my case I using three different test devices (Nexus 5, Galaxy S4, Note 2) and for some reason, the Note 2 wouldn't connect to my Bluetooth module yet the other two would.
The reasoning I've found is that Bluetooth drivers vary, and slightly different connection methods are needed to create a connection between different devices.
The three methods I use are called 'Secure', 'Insecure' and 'Reflection method'/'hax'.
switch(connType)
{
case Secure:
tmpSocket = device.createRfcommSocketToServiceRecord(_uuid);
break;
case Insecure:
tmpSocket = device.createInsecureRfcommSocketToServiceRecord(_uuid);
break;
case Hax:
Method createSocket = device.getClass().getMethod("createRfcommSocket", new Class[] {int.class});
tmpSocket = (BluetoothSocket)createSocket.invoke(device, Integer.valueOf(1));
break;
}
In my case, the Secure mode worked for both the Nexus 5 and Galaxy S4 however it didn't work for the Note 2.
After some testing I discovered the Note 2 only works using 'Insecure' mode, so to cater to this, I basically attempt a connection and cycle through the different modes if necessary. When attempting a different connection mode I simply prompt 'retrying connection'. So, if the connection fails using secure, then I will attempt using Insecure and then using the reflection method.
I haven't run into the case where one of these three methods haven't worked.

Have you tried using a nonstandard profile? i.e. a custom UUID just for your app. This will also help you know your are (most likely) only connecting to your own app rather than some other app that is registered with the same profile.
From my experience, Bluetooth pairing is very buggy for the first pair attempt. However, using a custom UUID helps this somewhat.
The reflection method (I think) was originally an attempt to fix a bug with a specific device, however I think some people found success in using it elsewhere as well. The device was called the Spica or something similar.
As one of the comments also posted, I would also try connecting again after failing.
Basically write code that plans to fail the first attempt, but then the code tries to connect again in 5 seconds if there was a failure.
These are imperfect solutions but Bluetooth implementation on Android is also imperfect (IMHO). Hope that helps
EDIT
Based on the question update and comments:
I agree something is definitely buggy. Part of the problem I think is the BT drivers vary and each has a different BT stack with different quirks. I also found a question that makes use of both the reflection method AND custom UUID, AND other standard methods. This seems extreme to me but it does cover the most ground. Unfortunately as app developers we have no control over the low level stack/code/drivers.
I have found with my two Bluetooth sharing apps that the first pairing is always tricky.
I'm glad to know it's not just me.

Connect cp2102 or FTDI to Android 4.x

I want to connect a custom device with cp2102 to Android powered tablet. I connect it in VCP mode (using PID EA60) and use JavaComm to find it,
#SuppressWarnings("unchecked")
Enumeration <CommPortIdentifier> ports = CommPortIdentifier.getPortIdentifiers();
while (ports.hasMoreElements())
{
final CommPortIdentifier port = ports.nextElement();
Log.d(null, port.toString());
}
but I never enter the loop.
I have an option to use FTDI instead of silabs. They have a variant of using their D2xx dll through JNI. I followed their guide but I have a memory crash (signal something and heap corrupted message in LogCat), when I connect ft232r and try to determine the number of connected devices. When I unplug the device from the tablet, the same code (their sample code) works just fine, returning zero, which is true.
When I use JavaComm with FTDI the result is the same as with cp2102: the loop is not entered.
I guess I miss something or do something wrong.
If I'm to use, say, usb-mode instead of VCP, I'm ready to start searching, I just need a hint.
Any help would be greatly appreciated.

The issue here is that the CP210x driver is not enabled in the Android kernel by default. So you will either need to build this driver in to your kernel to get the tty access and ability to use JavaComm.
The other option is to use the USB Host functionality and access your CP210x directly with it's API.

Android WiFi Direct Demo Issues

im testing the new technology wifi direct and im having some issues using
the wifi direct demo from the samples that come with the android-sdk.
So, I have two devices A and B, both with android 4.0.3.
First, from device A, I send a file to B. Nothing wrong here, B
receives the file.
Then A disconnects from B.
Now, from device B I try to send a file to A.
But the device that receives the file is B, instead of A.
To fix, i need to turn off and on both devices...
Also, sometimes when i click disconnect and try to
connect again, connection fails and i have to disable and
enable wifi direct...
Anyone else experiencing this?
Is it because the new technology is not mature yet or maybe
something wrong with my build/driver/etc or maybe this demoapp
doesnt support two-way sharing.
Any ideas and/or explanations would be apreciated.

When providing a WifiP2pConfig instance to the connect() function, you can set the groupOwnerIntent property of this configuration object as follows:
WifiP2pConfig config = new WifiP2pConfig();
config.deviceAddress = "..."; // insert ip here
config.groupOwnerIntent = 0;
config.wps.setup = WpsInfo.PBC;
manager.connect(..., config, ...);
From the android reference:
This (the groupOwnerIntent) is an integer value between 0 and 15 where
0 indicates the least inclination to be a group owner and 15 indicates
the highest inclination to be a group owner.
Furthermore, the demo probably repeatedly sends the file to the same device because there is always made a socket connection to the ip-address obtained from:
WifiP2pInfo.groupOwnerAddress
If you would like to support bidirectional communication, the first step in setting this up would be sending the ip-address of the non group owner to the group owner.
As far as the disconnect/reconnect problem goes, I seem to have the same inconsistencies with Android 4.0.2 devices.

I have been trying for a while to transfer files between two devices using wifi direct. I have use the Android SDK WifiDirectDemo as base. My experience:
GO address is always the same (at least in Samsung Nexus), but this is not really a problem, because you can use this to know who is the server (or client).
Another strange thing was that MAC address of devices were different when you got it from Android WifiManager and when you read it from "/proc/net/arp" file.
At the end I did it, and you can see the code here.
I hope it helps you!

I have been struggling with the same problem lately. I suppose this is an OS issue. To give you a brief background, I have installed Wi-Fi Direct application to both devices with different OS versions, one with OS 4.0.1 and one with OS 4.0.2. The connection fails from time to time when I disconnect and reconnect the devices. It goes same while searching for devices too. But the thing is, this only happens on the device with OS 4.0.2. Other device does not crash or disconnect.
While searching for that problem, I have found the links below. People discussed about that and they share the same idea. Apparently this is an OS 4.0.2 issue. I am not sure if it is the same for OS 4.0.3 but there is no problem with the previous version OS 4.0.1 for sure.
Here are the links:
http://code.google.com/p/android/issues/detail?id=24402
http://osdir.com/ml/android-platform/2012-01/msg00226.html