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.
Related
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.
First up, I tried to post this in "Android Software Development" but unfortunately don't have the minimum 10 posts required to do so and didn't really feel like spamming the forums to make the count. If a moderator could move this post for me it would be greatly appreciated.
On an Android 4.0+ device (ie, contains the USB Host APIs), you can write applications that interface with USB devices that don't require root. Unfortunately I'm working with a codebase that is in C using libusb and while I've gotten a prototype working in a terminal emulator, at this stage it seems to require root to actually talk to the devices (enumerating devices seems ok though).
I had a look at the Android NDK API list but didn't see any reference to USB Host APIs leading me to believe that the only ones that exist are the underlying Linux APIs. Is there a way (without bouncing all calls to the USB Host APIs through JNI, or rewriting the entire thing in Java) to access USB devices when in USB OTG mode without root from Android NDK code?
I am quite interested in usage USB host ability on my china no-name tablet based on Allwinner A13 CPU. I'd like to use it as GUI front-end for my embedded project with STM32F4 ARM microcotroller. So far I use laptop as the GUI for this device. STM32F4 is connected via USB as a vendor-specified device. I use WinUSB library on laptop to enumerate connected device and to open endpoints.
I'd like to use tablet instead of PC. So I looked to the USB host API on Android and tried to enumerate devices. However I couldn't enumerate any device - includes mouse or flash drive, which works perfectly in the system, but getDeviceList from UsbManager returns emtpy list.
I installed USB Host Diagnostics application and run a test. All results are yes, only items "Claims support" and "Device detected" in Android API shows no. But there's an item "Device detected" in Rooted API, which is yes.
I'm quite new to Andoroid developing. What is Rooted USB host API? How can I use it? Thank you for your answer.
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,
is there a displayLink Software for the RT?? I have an Dockingstation with an extern SCreen and i really would like to use it, but this will only work with DisplayLink Software. So is there a solution for the RT??
Thanks a lot
HandyBesitzer said:
Hi,
is there a displayLink Software for the RT?? I have an Dockingstation with an extern SCreen and i really would like to use it, but this will only work with DisplayLink Software. So is there a solution for the RT??
Thanks a lot
Click to expand...
Click to collapse
Nope- no DDK for WinRT, so no one can make third-party hardware that doesn't fit the preloaded driver set:
http://www.displaylink.com/support/ticket.php?id=335
Well, no public DDK. There's (quite obviously) an internal one, and it has apparently been shared with certain partners, and a copy of it has leaked onto the Internet and been found (and occasionally used) in various places. That said, even if a commercial outfit were willing to entertain the use of such a thing, they would need to get the resulting driver signed by Microsoft for it to be installable on non-"jailbroken" RT devices.
this signing thing is really terrible. is there a chace to get such a driver in future??
GoodDayToDie said:
Well, no public DDK. There's (quite obviously) an internal one, and it has apparently been shared with certain partners, and a copy of it has leaked onto the Internet and been found (and occasionally used) in various places. That said, even if a commercial outfit were willing to entertain the use of such a thing, they would need to get the resulting driver signed by Microsoft for it to be installable on non-"jailbroken" RT devices.
Click to expand...
Click to collapse
Right, so effectively no DDK for general peripheral manufacturers to use unless MS decides otherwise for that device-- hence the situation with USB Ethernet adapters (and the driver that Plugable released then had to pull).
I'm a bit puzzled by the situation-- if MS' concern is that poor drivers would affect the WinRT user experience, then presumably they could enforce a testing process (as they already have w/ WHQL) and only allow driver delivery through Windows Update.
As it stands, WinRT devices, running full-blown Windows, are ironically far less useful in custom applications than iPads, which have all sorts of accessories available. Why wouldn't MS want WinRT to be usable in, say, medical settings? (even iPhones, let alone iPads, can connect to hardware accessories like medical sensors).
Android's also catching up quickly in the accessories space, and it's only a matter of time before iOS/Android destroy any advantage MS had w/ hardware manufacturers, as happened so dramatically in the software space (there are now so many more devs who've worked with iOS and Android than have with modern MS platforms).
Well, for accessories that just need "traditional" data I/O - things like what you might have done over a serial port in days of yore - you can easily use either BlueTooth or the audio jack (although the latter is a real hack, usually used only for very small dongles powered by the audio signal). The iPad is definitely less extensible with third-party hardware (note, accessorizable != extensible) than RT, but I fully agree with you that Microsoft's stance on RT drivers is just plain weird. Keep the pool smallish and/or WHQL-test the crap out of them, but make them available! Those USB ports can and should be a killer feature.
The audio channels available on many consumer devices are often perfect for bit banging various communications protocols. UART "emulation" has often been done on the headset jack with a level shifter and some trickery, often on android devices much less powerful than the surface RT (seen a demo on an 800MHz single core ARMv6 handset). If your willing to sacrifice audio output from your application on the RT (as it is being used for bit banging the UART) then you essentially have a plug and play serial port without any special drivers needed, your application just needs to be able to generate an audio signal and analyse an input. the peripheral will need an external power supply but this is common on many legacy RS232 applications too.
There is the bluetooth serial port profile. Thats often used as a replacement for RS232 or UART. I dont know if windows RT supports it though (someone would have to check).
Another trick I have seen involves a microcontroller with USB capabilities. I have seen examples of people setting a microcontroller to appear as USB mass storage and having a small file system with 1 plain text file. Writing into this text file from windows or linux etc would then cause the microcontroller to perform a particular operation in response. Sensors can also be read by the microcontroller causing it to update the text file too. You essentially have file based GPIO without.
Its all rather hacky but it works technically.
There is also an i2c bus on the RT keyboard connector.