I have an ePad (Android 2.1) that mounts usb devices in the normal Linux way so that I can use libusb to access them, I have managed to control my usb robot arm using an NDK app. Before I move onto making it a proper app instead of a hack job I wanted to know if the usb device files are standard to Android or if it's specific to my system.
Put it this way, if I make a nice cuddly app is it going to fail on most devices or work on most devices? (ones with USB OTG interface)
Sorry, I understand this could be a 'how long is a piece of string' type of question.
Many thanks,
Richard e Collins.
After a few hours of routing about on the internet I found an article on an exploit on the init daemon, google "android-root-source-code-looking-at-the-c-skills". This gave enough insight for me to deduce that this functionality I am getting is present on at least anything running 2.1 and above and is not a customisation unique to my device.
I really want usb host capabilities on my phone.
Honeycomb 3.1 has this as does (if I understand correctly) Samsung Galaxy S2, where it is backported to gingerbread.
So first thing to do of course was to look at the galaxy s2 source code.
But there is nothing there. No UsbDevice.java, no additional drivers, nothing.
Do I miss anything? Isn't Samsung required by GPL to publish such modifications?
Thanks,
quietNaN
So far USB host mode doesn't work for Androids < 3.1
For 2.3.4 there's only an external library to support the USB accessory mode but it needs to be built into the OS. From latest news this is included in CyanogenMod 7.1 so as soon as this is released for your phone you can at least connect peripherals to S2.
See also this link for more details on Android USB support:
http://developer.android.com/guide/topics/usb/index.html
Thanks ramdroid77 for your answer.
I am aware that the feature I am asking for is not available before 3.1 .
And I am also aware of the "accessory mode".
However, there are two reasons why I am pretty sure that the S2 does not use the accessory mode.
1. From what I gathered around the internet (mostly from the exact link you mentioned) the handshake in accessory mode is quite different from the usual usb host mode. An android phone in accessory mode will for example not be able to provide an identifier for the client. The accessory is supposed to do this.
So (please correct me here, this point is halfway guessed) I think it will not be possible to plug an usb device into your phone and expect things to work. An "usb accessory" is something you actually have to develop to work with android. There are videos on youtube however that show people just plugging in a stick into their S2...
2. Usb accesory mode is introduced as an optional feature in 2.3.4 . The S2 runs 2.3.3 .
The README_platform.txt provided with the S2 source gives instructions how to build the code. It says to download 2.3.3(r1) and replace some files by the files provided by Samsung before make. The usb handling is not part of 2.3.3(r1) and (as far as I can see) not part of the modified files they offer for download.
The modifications were actually what I was looking for. I was hoping that Samsung backported the true usb host mode which is introduced with 3.1 (but not published yet by google) to 2.3.3 so that I can have a look and also backport it to the pre-CM7.1 (build from source) I am using on my legend. Well, at least try to figure out which informations I need to gather before I even can start to think about backporting it.
Since the S2 does not use accessory mode (I think) they either use a host mode and hold the code out on us (since my original question) or they use something completely different (neither the android accessory mode nor the android usb host mode) which then I must have missed in the kernel code. If I remember correctly the tiamat kernel for example has support for usb mass storage devices (which I cannot test on my legend).
I have some projects on my mind which (from what I gathered about the accessory mode) requires a real host mode.
So my question persists (or has to be reformulated): What does the S2 use to communicate with a usb device?
quietNaN
Hello *,
a customer asked me to develop an app for Android tablets that should use an external USB webcam (UVC). The app should target any consumer tablet that has a USB Host interface and MUST NOT require rooting.
According to API level 12 docs or Android 3.1, it is possible to use any external USB device.
Until here is theory. Is it actually possible, in practice, and how hard can it be to write java code that implements a UVC driver in user space? The UVC standard documents are hundreds pages long and I fail to understand how much of that specs need to be implemented on the host side, and how much is eventually already implemented in the Android Linux kernels.
Hi Folks.
With both a Zune HD and WP7 devices not supported via USB conenction to a Surface RT, I was thinking there had to be a way to tweak/re-write the ZuneHD / Zune driver files to allow them to be installed on the Surface RT...The ZuneHD is an ARM based device running Windows Embedded - and RT is an evolution of Windows CE you might say.
If so, the earlier regedit hack to allow the WP7 (or ZuneHD) to connect as a USB mass storage device would hopefully be possible, without the full ARM recompile of the Zune software (a near impossible task).
It's ridiculous that pre WP8 devices cannot even be connected via USB to facilitate file transfers "non-cloud" way.....
I tried manually updating drivers on the Surface RT with my ZuneHD connected - pointing at the Zune 4.7 drivers, and it confirmed that they were not ARM compatible.
Cheers,
Sheeds.
...
"tweak/re-write" an x86 kernel-mode driver into an ARM kernel mode driver for installation on a platform that doesn't (currently) permit unsigned drivers at all? You act like you have some idea what an instruction set architecture is, but you say this. If I ran this entire message through a translator to Finnish and then ROT-13'd it, you'd probably have a better chance of understanding the post than of managing to get the existing x86 Zune driver working on RT without a full re-write plus an additional hack to bypass driver signing. The Zune driver isn't exactly open-source... binary emulation *might* work at some point, but it's not practical for a kernel-mode driver (signature checks or not).
There is not, and never was, a hack to allow Zune-like devices to connect using UMS. The hack you're referring to merely un-hid the MTPZ (Media Transfer Protocol, Zune) devices from Windows Explorer. MTP(Z or not) and UMS are not at all the same thing, although they can sometimes be used for some of the same purposes.
We'd have a much better chance of getting Zune to run on RT, actually. That's "just" a matter of emulating an x64 machine for it to run on and passing its system calls through to the real OS and back again. Won't do any good for this use case without the driver, of course.
What does it matter that RT and CE run on the same ISA? The driver that we need is x86/x64 only.
There is basically nothing in common between CE and NT, aside from the fact that they're both portable operating systems from Microsoft and both implement some large portion of the Win32 API. Claiming that "RT is an evolution of Windows CE" is laughably wrong. They probably have less in common than Windows 95 (9x kernel, partially based on Win16 code) and Windows 8 (NT kernel, completely different project that contains no portions of DOS/Win16 except the re-implementation of the shell in NTVDM) - at least Win8 can run (many) Win95 apps. CE is at least as different from each of those as they are from eachother.
At this point, I'd guess that the most practical way to connect Zune on Windows RT would be the following:
a) Use a full x86-machine emulator (Bochs or QEMU, for example).
b) Use one that does JIT and/or dynamic recompilation, so the performance isn't abysmal (not sure what qualifies here...)
c) Install XP on it (no point targeting something newer).
d) Install Zune on the emulated XP.
e) Forward the tablet's USB port to the emulated machine's USB port (not sure if anybody has the ability to do this... currently, we can't even get networking in the emulated machine).
Good luck with that! I actually mean that quite seriously, I have a WP7 device myself and it annoys me that my Surface and it can't communicate except over Bluetooth (and I had to hack the phone to get that much).
GoodDayToDie said:
...
"tweak/re-write" an x86 kernel-mode driver into an ARM kernel mode driver for installation on a platform that doesn't (currently) permit unsigned drivers at all?QUOTE]
LOL - Thanks for the informative reply Luckily I have no delusions of grandeur over the fact that I am A) not a Developer and B) can't code past "hello world"
I was coming from the angle of the old registry hack for WP7 which allowed your phone to work as a USB mass storage file by a simple change via regedit to one of the registry strings associated to the Zune Driver....Certainly ignorant of the finer (and even the coarser) detail of your reply...so thanks for the explanation.
I added a MS Answers post asking why Microsoft cannot provide USB device connection for legacy WP7 and ZuneHD units with Windows RT. Be interesting to see what they or their MVP's reply to this, if at all.
Cheers.
Click to expand...
Click to collapse
Yeah.. asking MS to support the devices is definitely the best approach. We might manage to make a user-mode connection to them using some third-party software talking directly to the USB port on sufficiently hacked RT devices, but that's about the best we'll get.
Also, I really with people would stop calling it a "USB Mass Storage" hack. I've posted to that effect in the relevant forums that I can find, too. This is not now, never was, and (short of custom ROMs or special bootloader modes) never will be a UMS interface to Zune-like devices. The device literally doesn't support it. Please don't confuse Media Transfer Protocol for USB Mass Storage. They are *not* the same. For example, those nicely named music files you see when using the "UMS" hack for WP7/Zune? *THEY DO NOT EXIST* anywhere on the device's filesystem. True, there are files containing the same binary data, but they have names like "2D.mp3" and are stored in a filesystem structure designed to make referencing them in a database faster. MTP exposes a hierarchical storage system (which may, coincidentally, mirror the filesystem although it does not do so on Zune-like devices), but it does *NOT* expose the filesystem/storage (which is what UMS does).
Hi xda dev team !
I would like to write an android app which sends serial data (over USB as bridge) to a hobby
circuit. The app should work on my Motorola Defy+ (android 2.3.6) and look like
a text editor (with some exceptions) - the window content should be sent to my circuit.
The problem is that the only programming language I know is C and my Linux knowledge
is minimal, almost zero ! FTDI offers some "java drivers" on their site for USB to serial converter
chipsets, but those work only on android 3.1 and above (USB host capability on android device).
An alternative would be the use chipsets like FT 311/312 which act as usb hosts
and comunicate over AOA (Android Open Accessory) Protocols with android devices.
How do i know which AOA protocol version my phone has (i want to make my app upwards compatible
so it can be used by as much android devices as possible)? Also, which IDE should i use
taking into account that i'm a beginner in this matter ? Can somebody give me some tips
where to start from ?
thanks!