I know that the latest versions of Android (Honeycomb and ICS) have support for joysticks and gamepads.
Guitar Hero (and Garage Band) controllers are essentially USB HID devices, right?
So my question:
Is that possible to receive data (button clicks) from the Guitar Hero (or Rock Band) controllers on Android device?
Would the Android understand it as a gamepad input?
P.S. all I need is to detect in my game the input from those five buttons on the plastic guitar fret.
A good starting point would be to review the linux source code for Frets On Fire, which supports some of the Guitar Hero controllers.
Frets on Fire: SourceForge
SVN: https://fretsonfire.svn.sourceforge.net/svnroot/fretsonfire
It looks like it would be difficult to universally support all controllers, from different platforms. Each console has it's own protocol, but it does look like JoyStick to keyboard emulation is possible on the PC with the PS3 controller. There is a config file for the PS3 controller on the second link that may be helpful, it's for JoyToKey (which isn't open source), but some of the values in the config may help you.
Hey this is a really cool idea. start here:
http://developer.android.com/guide/topics/usb/host.html
Then, check out this sample:
http://developer.android.com/resources/samples/USB/MissileLauncher/index.html
in that sample, there is a method named setDevice(UsbDevice device)
If I were implementing this, I would start with a duplicate of the MissileLauncher project, and modify this setDevice method. I would log everything I could possible find about the UsbDevice device and try experimenting with these conditionals in the setDevice method:
if (ep.getType() != UsbConstants.USB_ENDPOINT_XFER_INT) {
...
if (intf.getEndpointCount() != 1) {
While the MissileLauncher uses this type and this endpointCount, it is very likely the garageband controller will have different values
ALSO
check out the run method to see an example of back and forth communication
DISCLAIMER: I have no idea if this will work. I've also seen blogs stating this cannot be done.
My guess is it should detect data. This is even possible on existing Android devices - but it is not Android Market friendly.
To accomplish this on non-4.0 devices you must provide an alternative power source to the usb port. Usually this can be done with a cheap usb hub that leaks power. The device also must be rooted. Once this is complete you need to create an interface to the device shell to launch a native language like C outside of your Dalvik VM. Use your C to bind to the appropriate socket and you should be able to bus data back and forth. You may also need to compile a kernel module to give driver support.
Like I said this is a complete hack for device below 4.0. But it is possible.
Related
Is it possible to simulate a USB or Bluetooth device connected to Android?
I would like to make an app which is able to simulate an HID device locally. What I mean by this is: the app should make Android believe that an USB/Bluetooth HID device is connected. This would allow my app to inject touch events globally, I hope. Is there anyway to simulate a (virtual) device? Note that I don't really care about the device, I just want to use the built-in support for HID input.
I know a lot of people already asked about touch event injections but this approach seems to be a little bit different. I do not want to use this for testing purpose, so InstrumentationTestCase and the like won't help.
Rooting the device might be an option, although I can also imagine to ask my endusers to install a specifically signed app manually (according to https://stackoverflow.com/a/16737083/2923406 and https://stackoverflow.com/a/22902808/2923406 this works, but it would be device specific).
I am aware of:
Simulate a mouse input on android - This guy seems to do it in his own app, although his questions wasn't answered ;)
http://www.pocketmagic.net/2013/01/programmatically-injecting-events-on-android-part-2/#.U58SqfldVHV - Needs Root. Did anyone succeeded in using this? Also, the solution seems very device-specific again.
Bluetooth + simulating mouse - That's not what I want. The phone itself should not be an HID device, but use the (virtually created) one itself. Same for this:
https://stackoverflow.com/a/8174973/2923406
Note that I do not want to turn my phone into an HID device of any kind.
Simulating is a broad term. When I created my Bluetooth app I "simulated" a Bluetooth connection in two ways.
Way 1: Use a serial port UART converter and hook it up to a Bluetooth module transmitter.
Then you can use a terminal program like CoolTerm, to send your data.
Like so. In this case I coded in a string to send on successful connection with the device however you can make a infinite loop for testing purposes effectively not requiring your phone to be turned into a HID device.
Way 2 (not easy): Use your computers bluetooth in a server/client relashionship model.
This is harder to do. What you can do is convert your pc/mac into a server and the Android phone into a client or vice-versa. For this you will need to write external code which will need to be compiled separately on a jvm(java virtual machine). The procedure to do this can be found here. If you are using a Linux machine you have to separately download the Bluez module. I have not tried this on any other operating sytem other than Ubuntu, and it was a pain to get functional.
Hopefully that helped.
Yes, it's quite easy using the AOA2 protocol check this & this links for details ( you'll need to switch your device to the Accessory mode )
This may be possible (or at least be easier) using the Robolectric library, which simulates a full Android device locally. Although it is intended primarily for testing, the fact that it simulates a whole device locally - including Bluetooth and USB - means adding to it may be an easier approach.
In other words, you may be able to modify the classes it uses to simulate these abilities locally (i.e. in the IDE itself without an emulator or device) in order to simulate them on the device itself. After all, it does provide full simulations of these functions. You could simply change these Bluetooth and USB simulating classes to load onto the device itself rather than onto the local Robolectric test "device."
This is just an idea though - I can't confirm this will work - it just might be a good place for you to start.
I would like to communicate with another Bluetooth device using the AVRCP vendor dependent or pass through command. From the API available, there does not seem to be any way to make such calls from an android application. Can anyone advise on whether this is possible and how this can be done if it is possible?
What you should do is to go directly and speak with the HCI layer of the BlueZ Bluetooth stack. You could do this through D-Buss daemon which you can do it from Userspace. Next you take the ARVCP specs for example 1.0, but you can find on Bluetooth SIG AVRCP 1.3 or 1.4 specs too, and start parsing the commands. This presentation should be helpful: Android Bluetooth Introduction and this stackoverflow question.
Refer the below link:
Adding AVRCP Plugin in Android GB
It seems like you confront the most common problem between Bluetooth devices, the Bluetooth compatible problem. Because the Bluetooth profiles do not strictly defined the audio related behaviors, the different behaviors implemented by different manufacturer would lead this problem. That's why every Bluetooth device should pass the Bluetooth Compatible Test of Bluetooth organization, however, it can not eliminate all problems.
As an open source implementation of Bluetooth Protocol Stack, Blue Z is not the best one in my mind and abnormal behavior of Bluetooth device also making trouble. If you have some test tool like PTS (profile tuning suite), try to use it to find out which side lead the problem. If everything is ok in profile side, that's good news for you, the problem may lead by some bugs of the related application. And if something wrong in the profile communication, it means you can not modified in API level, you may need some dirty work in profile stack and if you are phone manufacturer it can solve you problem, if you are not you can not slove the problem neither.
Is it possible in the Android framework to duplicate what is displayed on the main display (UI)?
I have a situation where I need to demonstrate my app to many people, and it would be easier to do if I can duplicate the screen contents to an external monitor/TV. I am not married to the idea of using the HDMI port, I would be happy doing this through Wi-Fi or Bluetooth or USB if need be. What I am looking for is to see if I can do something similar to what Windows does by default when a second monitor is connected.
I have been through the developer's documentation and haven't been able to find anything that would allow me to do this, but it would not be the first time I've missed something. Specifically I need to do this with an HTC Evo.
Your options are limited, mostly by your choice of device. The HTC EVO's HDMI port will only play back apps via the built-in Gallery application (videos and still photos).
You will need to use a "software projector" like Droid#Screen -- attach your EVO to a Android SDK-equipped notebook that is connected to a projector. Droid#Screen will display the EVO's screen on the notebook (and, from there, on the projector). However, the frame rate is limited to about 5-6 fps, due to limitations in the SDK tools that Droid#Screen leverages.
Or, get your hands on an HTC Droid Incredible, which supports composite output to TVs of anything on the main display via a special cable. The Samsung Galaxy Tab also supports this for anything that does not involve a SurfaceView, based on my experimentation to date. Some versions of the Samsung Galaxy S also support this, at least to some extent.
Or, use a webcam.
Or, use an ELMO (basically a webcam designed for document or device projection).
You can write a UiCloningService in jni that exposes a JNI method to clone the display. Usually, as Android is based on Linux, it will use the Linux framebuffer technology to represent display devices as dev nodes under /dev/fb* or /dev/graphics/fb*, where '*' can be 0,1,2,... depending on number of display connected.
As your device already has an HDMI port, it would be exposed via /dev/graphics/fb1, considering fb0 to be your default LCD display.
In the cloning service, you can then write to device attribute files created for the HDMI port under sysfs and, if the display driver of your device has implemented those features (which most probably would have, otherwise what point to have an external HDMI display), these features/functions in the driver will be responsible for cloning the Ui on your primary display to the secondary display.
But you would have to write the Ui cloning service in JNI.(usually device manufacturers provide such methods, if at all an Android SDK is provided by them for development on that particular device).
For eg., I have attached a UiCloningService.cpp that has a cloning JNI function for Android GingerBread on an OMAP3 platform below:
UiCloningService.cpp
I have a Symbian based phone with a ARM Cortex-A8 processor (SonyEricsson Vivaz) and was thinking on how hard would it be to try and port the Android OS for it. Obviously Android runs on a myriad of devices with different hardware so I imagine it shouldn't be too hard to adapt it to SE hardware. Could some one give me a clue where to start or if this is even undertakable...
How much information do you have about the hardware in the phone ? Are you starting completely from scratch ?
Porting Android is not simple task. First thing is to have Linux running (preferably 2.6.32 for more compatibility with the latest releases of AOSP.
If you can find a kernel that can run on your phone, that's one big step. After that, you want make sure that the peripherals you want to use also have the right drivers : touch interface, LCD display, SD card, audio, video. The ones that are probably most difficult will be wifi, radio (GSM) and power management module.
If you get that far, you don't have that much to go anymore, a few more changes in the kernel needed for Android, be able to compile Android correctly file system, hook up a few things like buttons and correctly interface with the drivers mentioned above...
But overall, definitely not an easy task (IMHO).
I have been tasked with sourcing an off the shelf touch pad device that can be used as a dedicated industrial instrument controller.
Is it possible to run a dedicated application and prevent user access to all other functions/applications within Android.
Also is it possible write your own USB device driver which would allow you to connect an USB serial class device?
Of course you can. Like already stated Android is open source. You can take the sources and recode them to your desire so that the device behaves like you want.
In the end the default android launcher and all other applications are all just standard Java applications (mainly). You can recode it so that instead of loading the launcher app it loads up your app.
I think you can use this OS to make your own custom gadgets same as you can use linux in embedded systems.
Its open source so you can go down into the OS code and disable what you like. So i would say it is indeed possible. Windows does also do windows embedded like windows CE/WM range, these have touch screens and come in rugged form factors too, M3,PSION and others.
You can recode the OS visual display, i.e. HTC sense on all their phones. So you could recode it to show nothing.
As to the driver, well a driver is a driver this will also be possible.