Use android device as remote for the WII

Quote
Axel
Maybe it is time to move this thread to a more appropriate forum such as Coding.

This definitely does not belong to Getting Started anymore :)

Ha! Agreed. :)

Quote
Axel
Maybe it is time to move this thread to a more appropriate forum such as Coding.

This definitely does not belong to Getting Started anymore :)

Second

Quote
Greg

Quote
rikmer
As far as I know you can change the DeviceID which consists of the VID and PID in the main.conf of the bluetooth settings under /system/etc/bluetooth .

Oh man, that would be horrible if you had to do that to make it work. It would kill any chances of your app being successful in the Android Market. Who would want to do that to their phone? Requiring root is bad enough...but needing to edit system config files...

Quote
rikmer
Could you provide your experimental code?

Sure. I might not have a lot of time during the week, but I'll try to get to it.

Quote
rikmer
I also managed to add the service but when I compare the wiimote services to the phone services ...

Service RecHandle: 0x0
Service Class ID List:
"SDP Server" (0x1000)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 1
"SDP" (0x0001)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"" (0x0100)
Version: 0x0100

... is missing.

I think this is just the entry for the SDP server. Can't imagine this block would be required by the Wii. Actually, this entry is there, you just have to ask for it specifically:

sdptool get 0

When you queried the phone, were you doing so locally or from another device? Maybe when you're querying locally it doesn't show you the SDP server? But you will see it when querying from another device?

Another thing I didn't try, when I added the WIIMOTE service, it added it as 0x10007. Maybe I should have forced it to match the remote's handle for the same service.

And if that doesn't work, I'll remove all the other services 0x10001 - 0x10006. They show back up again after you turn off/on bluetooth.

Messing with systems config is a pain in the ass but if it works it would be great. It really could be the issue. Regarding the configurability of this config file it would be possible to realise it like AdFree Android. They do a symlink at boot time to /data/data .

I am looking forward to experiment with your code.

Did a local sdptool browse so that explains it.



Edited 1 time(s). Last edit at 09/20/2010 05:23PM by rikmer.

I have hacked a method from nachtschicht of xda developers to symlink main.conf to /data/data . You have to flash it through clockworkrecovery or something equal. I would advise backing up your system beforehand. Here is the link http://db.tt/p2VxwaK.
I will try to connect to the wii this evening and will post my results.

EDIT: Tested it with the modified main.conf and added WIIMOTE sdp service but regretfully again no connection. Damn.



Edited 1 time(s). Last edit at 09/21/2010 07:02PM by rikmer.

Quote
rikmer
Tested it with the modified main.conf and added WIIMOTE sdp service but regretfully again no connection. Damn.

How did you test it? Are you opening up an L2CAP server socket and waiting for an incoming connection?

I had another setback last night. I was looking through the Android source code again to make sure I wasn't missing something and I found something pretty significant. Let me explain by backing up a bit.

The public Android API currently does not support L2CAP sockets, which is what is going to be required to pull this whole thing off. There is currently an open issue, [code.google.com], but it is not scheduled yet. However if you look at the source code you will see there is a private API with plenty of support for L2CAP.

So I wrote my own API that accesses this private API via reflection. It works great for connecting to other L2CAP devices. But when I try to open up a server socket to listen for incoming connections, I forgot to call a key method...bindListen(). Since I wasn't calling this method, my server sockets were never really listening to anything. So I put the call to bindListen() in last night and the return code I kept getting back was 13, which is the unix errno for "Permission Denied". If I use my same API for RFCOMM (which isn't practical since the public API already supports RFCOMM, but this was just to prove a point), the return code is 0 (success). So there is something about requesting to bind an L2CAP socket to the system, that is not allowed. I traced this down through the Android source code, even into the native C code. The support appears to be there at all levels. The problem is someting really low level is not allowing it. Perhaps something in bluez is disabling L2CAP?? But like I said...connecting to other L2CAP devices works fine.

Quote
Greg
How did you test it? Are you opening up an L2CAP server socket and waiting for an incoming connection?

No I didnt open anything. Only modified the main.conf and added the service then switched the phone into detectable mode. My Laptop is connecting to it and accepts it as an input device. Is there a way to open L2CAP without coding it (if it is possible at all as you stated in the next post)?

One other interesting thing is that the pin for the wiimotes is the reversed mac address as stated here http://wiibrew.org/wiki/Wiimote under Bluetooth Communication. I never was asked for a pin when connecting to my phone.

A next attempt was to change the device class in the main.conf to the class of the wiimote (from 0x40020C which is phone to 0x002504 which is peripheral/joystick) but it doesnt seem to accept the change as when I scan for devices utilising btscanner my phone has a different class (0x58020C). I dont know where this ID is stored.

EDIT: Managed to change device class by using "hciconfig hci0 class 0x002504". A good thing is that this is reverted if you reboot the phone.



Edited 1 time(s). Last edit at 09/21/2010 08:25PM by rikmer.

Quote
Greg
I had another setback last night. I was looking through the Android source code again to make sure I wasn't missing something and I found something pretty significant. Let me explain by backing up a bit.

The public Android API currently does not support L2CAP sockets, which is what is going to be required to pull this whole thing off. There is currently an open issue, [code.google.com], but it is not scheduled yet. However if you look at the source code you will see there is a private API with plenty of support for L2CAP.

So I wrote my own API that accesses this private API via reflection. It works great for connecting to other L2CAP devices. But when I try to open up a server socket to listen for incoming connections, I forgot to call a key method...bindListen(). Since I wasn't calling this method, my server sockets were never really listening to anything. So I put the call to bindListen() in last night and the return code I kept getting back was 13, which is the unix errno for "Permission Denied". If I use my same API for RFCOMM (which isn't practical since the public API already supports RFCOMM, but this was just to prove a point), the return code is 0 (success). So there is something about requesting to bind an L2CAP socket to the system, that is not allowed. I traced this down through the Android source code, even into the native C code. The support appears to be there at all levels. The problem is someting really low level is not allowing it. Perhaps something in bluez is disabling L2CAP?? But like I said...connecting to other L2CAP devices works fine.

I understand. I remember another guy who programmed SleepTimer (available int the market) which was working perfectly under android 2.1 but then stopped to work under 2.2 because they changed some API so that it isnt possible to stop music from an app. He managed to gain back full functionality by using root access. Is it perhaps again possible to open up L2CAP sockets by using root tricks?

EDIT: if I remember correctly he also tried to access the private API via reflection but it didnt work without root.



Edited 2 time(s). Last edit at 09/21/2010 08:15PM by rikmer.

Quote
rikmer
Managed to change device class by using "hciconfig hci0 class 0x002504". A good thing is that this is reverted if you reboot the phone.

That's cool. Wonder if you can change VID and PID that way too? Are you sure you had to reboot? Can you just power down bluetooth and power it back up? That seemed to do the trick to revert the SD database.

Quote
rikmer
Is there a way to open L2CAP without coding it

Not that I know of.

Quote
rikmer
One other interesting thing is that the pin for the wiimotes is the reversed mac address as stated here [wiibrew.org] under Bluetooth Communication. I never was asked for a pin when connecting to my phone.

This worries me too. But when connecting to a remote from my phone I didn't need a pin. So I'm hoping this is a non issue.

Quote
rikmer
I remember another guy who programmed SleepTimer (available int the market) which was working perfectly under android 2.1 but then stopped to work under 2.2 because they changed some API so that it isnt possible to stop music from an app. He managed to gain back full functionality by using root access. Is it perhaps again possible to open up L2CAP sockets by using root tricks?

The only thing I have been able to figure out so far with using root is how to run privileged commands with su. Even if there were a command you could execute to open an L2CAP socket, how could I make use of it from my Java app? Unless a handle was given back to me that could be passed into the constructor for BluetoothSocket?

I don't believe there is a way to grant your app unconditional root access while it's running because each app runs under its own user. That's why you have to use "su" to obtain root and then run commands. I could be way off on this.

I was hoping you knew of a flag in some config file that looked like this:

allow.l2cap.bind=0

Then we just switch it to a 1 and we're good to go! :)

I will have a deeper look in configurability through config files and native commands. I will share my findings as soon as poossible.

So far I found a statement in an issues tracker (http://code.google.com/p/android/issues/detail?id=719):

L2CAP support is reachable on Android over the Java Native Interface without rooting your device. You can talk directly to bluez and create applications which natively bind to L2CAP or RFCOMM.

Dont know if that helps.

Really looking forward to what you find.

The Android API (the private stuff) is already using JNI to talk to bluez and hits the permission denied error. I'm going to assume their native code is correct (I couldn't do any better!). Afterall, it works for RFCOMM. And if there was a problem with their code, you would think it would throw a different error. Permission denied seems to me like the syntax was correct, but something in bluez just didn't allow it.

I found another guy who wrote an article on Android and JNI and he also talks about L2CAP. I posted a comment to see if he has any ideas.

One question. When you tried to bind the L2CAP socket did you do it as root? As far as I understand you didnt ... or am I wrong. I think it is possible to grant the function which binds the socket su rights. Perhaps this helps => http://www.stealthcopter.com/blog/2010/01/android-requesting-root-access-in-your-app/ .

Regarding possibilities to force allow bind to L2CAP I didnt find anything. Also bccmd is missing on android. Would have been a possibility to gain more access on how bluetooth is working. I fear hciconfig, hcitools and sdptool are the best command options we get.

I will look into anything which comes to my mind. Hopefully something is coming to my mind.

Quote
rikmer
One question. When you tried to bind the L2CAP socket did you do it as root? As far as I understand you didnt ... or am I wrong. I think it is possible to grant the function which binds the socket su rights.

No, I was not root when calling the bindListenNative() function. The problem is, you request root by executing "su" as an external process. But you only have root access within the context of that external process and only while it is running. So you can't request root and then expect that your app will be running as root from them on. From everything I've read, including the article that you posted, it doesn't work that way. I would love to be proved wrong about this!

The only possible way I can think of to grant the entire app root access would be to leverage the fact that each app runs under a unique user id. Then somehow run a command that grants root to that unique user account. I tried usermod, but that doesn't appear to be present.

But in the end I don't know if obtaining root will help. Because if, supposedly, you don't need root to use JNI and since RFCOMM works fine without root...maybe it's just a limitation of the platform and we might have to wait until Android 2.3 or 3.0? :(

Was really occupied the last weeks.
I am looking into patching the kernel to get l2cap socket bind ability now. Will tell my results as soon I have some new information.

You just don't give up do you? :) I've been over on this forum, [www.pocketmagic.net], trying to get some answers. But it seems that L2CAP server sockets stopped working around Android 1.5. Still waiting for more info...

Android 2.3 may be just what we have been waiting for. According to [www.androidcentral.com], Gingerbread has a new BlueZ stack. Unfortunately bluetooth is not supported on the emulator, but I'll be trying this as soon as I can get my hands on a 2.3 device!

Just found this topic as I searched for the features of the new bluez stack in 2.3.
I had the same idea as you some time ago in February, but this project was way to big for me. I didn't even clear the first hurdle, returning the right VID and PID, as you can see here:
[forum.xda-developers.com]

I also contacted Ryan Frawley, who connected the Wiimote to some android devices as an IME, you propably know his app, it's quite famous. But he was neither interested nor had some hints.
If I can help somehow I would be quite proud!

By the way, do you have a clue what to do next when you have successfully connected? I thought you need HID as a device, or is it possible to send everything you need via l2cap? Also, couldn't you just attach a small filter in front of the camera so only IR-light gets through? Some image processing afterwards to find the two brightest points and you could return them just like the wiimote does. Okay, forget the last part until there is a stable connection :D

Hey Felix, unfortunately right now we're stuck until we get better low level support for L2CAP, which will hopfeully come with 2.3. I was able to duplicate (rather crudely) the functionality of Ryan's app. So I am able to connect to a Wiimote from an Android phone and I can track buttons states, manipulate the lights, make it rumble, etc. I was hoping that using an Android device as a Wiimote would be as simple as reversing the process. But it's not, due to the fact that I can not open up L2CAP server sockets without getting permission denied errors coming from low level JNI, even on a rooted phone and even after making some modifications to various system files. But even if we successfully got the sockets open and listening, there is still the issue of VID and PID. rikmer has a potential fix for this earlier in this thread. Then we have to duplicate the SDP record(s) for a Wiimote. I think I found a way to do this, also documented earlier in this thread. But all of these fixes are probably going to require a rooted device and this is all dependent on 2.3 actually having what we need. We have a long way to go! :)

I have an idea of what to do once the connection is established. WiiBrew has great documentation on the Wiimote bluetooth spec. My goal was to start out getting just the D-pad and standard buttons working. Then work on the accelerometer. The IR camera was the last thing on my list, but I have verified that my device's camera can see the IR lights in the sensor bar. Although I think using the backside of a phone to point at the sensor bar is just going to be really awkward. Of course I don't know how practical this whole idea even is to begin with! :) I don't see an Android device being a very good substitute for a Wiimote when precise button presses are critical in a game. This was more just a fun project to gain experience with Android development. But who knows.....it might work really well...

Just keep following this topic and as soon as a custom 2.3 ROM comes out for my Droid, I'm going to dust this whole project off and try again. Not getting my hopes up though...

Quote
Greg
WiiBrew has great documentation on the Wiimote bluetooth spec.

Yeah, because of this site I thought you need HID with android in the role of a device.

I think if you get the first button working it will take under a day to get everything else ;)
Which devices are you using, only the droid or anything else? I had an HTC Hero, and HTC totally screwed bluetooth. Even Ryans app didn't work on official 2.1 -.-

So, if you need any help or want to share something, just tell, I will try everything I can.



Edited 1 time(s). Last edit at 12/07/2010 09:33PM by FelixL.