Develop Reference

USB-Webcam on Android 4.4+

I am into a new project which requires me to use a USBconnected "Webcam".
The whole fun should run on Android 4.4.
my little story was:
I try multiple apps which do this - all work on both my testing devices
adapting some NDK lib that directly uses /dev/video0. This didnt work due to read-permission that was not granted in a new File("dev/video0").canRead() check. Although my unix permissions are correct, this seems to not work due to some new check on Android 4.4. (the whole thing was suggested here: Connect Android phone to a USB Web camera )
next: discover the UsbAccessory API that supposedly easens a lot of the above.
´find no documentation or anything about how to correctly handle a webcam
I still try, but don't come further than finding no device via
usbManager.getAccessory();
I've also tried to discover devices by filtering for a USB_ATTACHED broadcast but nothing triggers.
So I am starting to ask myself how the hell do others find the devices & communicate with them to get the pictures?
Anyone has sources from which i could learn, or a tutorial or something?
Little update from my side:
- I've gotten access by using the Android USB Host API e.g. UsbDevice instead of UsbAccessory.
- I have the connection and everything setup fine, and can now send binary data to my webcam and supposedly receive.
I can now send controlCommands via connection.controlTransfer(...) or use a "UsbRequest" in order to receive data.
However, I couldn't find any documentation to "make the camera submit pictures" to me. My Endpoint is of type XFER_INT (=interrupts).
I am continuing to try sending out various commands (e.g. binary values) but haven't had any success so far.

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.

Android rtsp client compiled with NDK cannot receive any UDP packets

I recently compiled ffmpeg and live555 for android, and built my own media client wrapper. The whole system works perfectly in all other systems (windows and linux), but not in android, just no UDP packets could be ever received. The RTSP communication works fine, which uses TCP connection. The session starts successfully, and keeps running in server. After searching for the similar topics, I see it seems that I have to acquire a multicasting permission with wifi at first. So I did:
- put permissions in AndroidManifest.xml
<uses-permission android:name="android.permission.CHANGE_NETWORK_STATE""/>
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.CHANGE_WIFI_MULTICAST_STATE"/>
- put following java codes in android Activity::onCreate()
WifiManager wm = (WifiManager)getSystemService(Context.WIFI_SERVICE);
if( wm != null ) {
mMCLock = wm.createMulticastLock( TAG );
mMCLock.acquire();
}
But it still doesn't work, the results are all the same in Emulator, in Galaxy S2 Phone and
in Galaxy Tab 10.1. Even I deactivate the live555 module, and just use ffmpeg ( ffmpeg has also its build-in rtsp client, but not as stable as live555, therefor, I ported live555 into android). The results are the same, rtsp ok, rtp not, where rtp uses udp as underlying carrier.
In DDMS is an error registered:
Address Family not supported by protocol
I think, the problem is that the UDP port is still blocked. Maybe getting multicastlock in
java is not enough for native code running in user kernel of android.
Does anyone has idea?
Steven

The UDP Problem in meinem RTSP client has been solved, there is nothing to do with permission and multicast lock. It is the bug inside android stl library implementation, provided in android-ndk-r7 and android-ndk-r8 both. Anyone wants to use gnu-libstdc++.so has to keep in mind: don't use string, especially string::c_str(), it leaves danger pointer in your stack, and damages everything. After I threw out every thing to do with stl, everything works fine, tcp and udp. A little off-topic: Inside the live555, there are at least 20 bugs, and the most fatal errors are: they used unblocked rtp over tcp, therefore, most packets are get lost before they reach the network interface, and at rtsp client, the rtp/tcp socket will never get the packets which are lost in the network interface, and then a rtsp session enters into endless receiving loop, it hangs.

I faced the same problem.
I think, in your bind you are biding to an IP, use htonl(INADDRY_ANY) as s_addr.
not sure whether this helps your cause, but it seems to solve my problem.

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

Android Usb Host Problem with Samsung Galaxy 10.1 Tablet

I am attempting to leverage the USB host capability on the Samsung Galaxy Tablet. I purchased the attachment dongle from samsung (http://www.samsung.com/us/mobile/galaxy-tab-accessories/EPL-1PL0BEGSTA). When I first connected a usb device via this dongle, I had a high power error from the Galaxy Tablet -- FYI use an externally powered USB hub and you can bipass this.
Now that the device itself is acknowledging the existance of a USB peripheral when I attach it, I attempted to use Android's android.hardware.usb.UsbDevice;
import android.hardware.usb.UsbManager; library. I saw that there are two methods for recognizing a USB device, registering a broadcast receiver to listen for the intents via
IntentFilter usbIntentFilter = new IntentFilter();
usbIntentFilter.addAction("android.hardware.usb.action.USB_DEVICE_ATTACHED");
usbIntentFilter.addAction("android.hardware.usb.action.USB_DEVICE_DETACHED");
registerReceiver(mUsbReceiver,usbIntentFilter);
This is not firing any intents when I attach any devices, strange...ok. So I went on to try the next method: explicitly querying for a device list via the UsbManager -- this was accomplished as follows:
HashMap<String, UsbDevice> deviceList = manager.getDeviceList();
int count = deviceList.size();
Iterator<UsbDevice> iterator = deviceList.values().iterator();
if(iterator.hasNext()){
UsbDevice deviceVal = iterator.next();
testTxtView1.setText("set device " + deviceVal);
}
This would presumably grab the one (only one USB device currently supported per Google Documentation) USB device that is currently connected. To test this I would call the above code upon a button click and display the device results. For some reason, I am getting a device from the device list every time, whether a USB dongle is connected or not. Furthermore, the device is the same every time regardless of the USB dongle (or lack thereof). The output is as follows:
device usbDevice[mName=/dev/bus/usb/001/002,mVendorId=1256,mProductId=27033,mClass=0,mSubClass=0,mProtocol=0,mInterfaces=[Landroid.os.Parcelable;#406ff4d8]
^^ the #406ff4d8 value changes every time I query this code (I just put a single instance of it up)
I have searched everywhere and have not been able to find any similar problems or solutions that may apply to my situation. I have tried implementing google's USB examples (which is exactly what I have essentially, I ripped theirs) and am running into these problems.
I should also mention the makeup of my manifest:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="edu.mit.ll.drm4000"
android:versionCode="1"
android:versionName="1.0">
<uses-feature android:name="android.hardware.usb.host" />
<uses-sdk android:minSdkVersion="12" />
<application android:icon="#drawable/icon" android:label="#string/app_name">
<activity android:name=".DRM4000Activity"
android:label="#string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
<intent-filter>
<action android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED" />
</intent-filter>
<meta-data android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED"
android:resource="#xml/device_filter" />
</activity>
</application>
and device filter:
(I removed criteria on the device filter but have also tried inserting specific information about the device I am looking for...both to no avail.)
Any help regarding this problem would be much appreciated!
Another update: The device I complained about always being enumerated on the device list
device usbDevice[mName=/dev/bus/usb/001/002,mVendorId=1256,mProductId=27033,mClass=0,mSubClass=0,mProtocol=0,mInterfaces=[Landroid.os.Parcelable;#406ff4d8]
must be the android side usb port or something...because I started attaching a bunch of different devices to my code and found that (similar to this link:
USB_DEVICE_ATTACHED Intent not firing) HID devices, arduino devices..and sadly... my USB device do not appear to fire an intent or get enumerated by the USB hub. I tried with a USB flash drive and it DID enumerate it and worked...however it shows up as the SECOND device on the list, the first being the ever-present usbDevice listed above. Intents do fire with it though.
Does anyone know a workaround to making intents fire with HID devices and other USB devices except the select few android seems to do now?

SOO unfortunately it looks like the Samsung Galaxy Tablet just does not play nicely with the UsbManager and about half of the USB devices in the world. The kernel in Samsung seems to fire intents for storage devices and the like, but not for HID and other random devices (such as arduino, and my usb sensor, and HID devices as well.) It seems to be a bug in samsung kernel. Interestingly, the HID devices WORK on the tablet, but are not enumerated on the UsbManager. I have found several links of the same problem, and it seems like a kernel patch (or the acer tablet) are the only ways around this atm. hopefully samsung will fix in the future. Here is a link to a guy who did a kernel patch if rebuilding the kernel is your thing and you really need to get UsbManager working. I have not tested but plan to eventually, and will leave a comment on my thoughts.
http://forum.xda-developers.com/showthread.php?t=1233072

I am facing same problem but you can use one method deviceName(), after enumerating device you can store device name in a string using device.getdeviceName() method.
you will get exact device name appart from full information of device.

Samsung has removed the USB API from the Android Kernal

i think you should define the device you want to recognize in resource/xml/device_filter.xml.
you can referring the android api.

There may be another (nasty) reason why you can't see your HID device.
UsbHostManager.beginUsbDeviceAdded() "Called from JNI in monitorUsbHostBus() to report new USB devices". This method calls a private method isBlackListed() which will unconditionally filter out all HUB's, and HID's with subclass BOOT.
This may be the reason why you don't see HID devices when you do a getDeviceList()
If anyone has a workaround to this, I think that there are a fair amount of users out there who would appreciate see this.

I have had succesfully attached my Arduino Uno to my samsung galaxy tab 10 P7500.
If you have a problem connecting it, It is because the tablet deny permission for the usb devices that doesn't have external power.
Try to power your device externally using 5 or 3.3 Volt AC/DC Adaptor, for the first time, if you find your device attached and fire the intent, unplug the power adaptor, and your device would operate without external power, the tablet itself would give the power through USB OTG