Does anyone know the UUID to connect an android 2.2 device to a WiiMote? The wiimote will not pair, as the wiimote does not require a PIN #.
Apologies for answer an old question, but to pair the Wiimote using legacy pairing, you reverse the bytes of the device address and use that as the pin.
As far as I know, you can only connect a Wiimote to a non-Wii device if you use a bluetooth stack/program that allows you to skip the PIN. This is possible a couple of different ways on laptops and such, but Android 2.2 requires the PIN for the first pairing.
However, depending on what kind of phone you have, you can try the WiimoteController app. It doesn't connect on HTC devices that are running the Sense UI, but if you have a Nexus One or you're running some kind of custom vanilla Android ROM on your phone, it should work.
Related
I am working with a firmware team that writes firmware on a QCC3056 Qualcomm chipset that supports earbuds and I develop an android application that supports the BLE earbud Bluetooth device. The earbuds also support google fast pair and this feature requires the BLE mac address to be rotated every 15 min.
So the issue I am seeing here is the android Bluetooth settings recognize two Bluetooth devices with the same name(one is classic and the other one is BLE). I can tell by the mac addresses that one belongs to classic and the other belongs to the BLE address. We are able to connect to the classic instance. However, we are unable to connect to the BLE instance. We would like just one name to show up and the user should be able to connect to it. The firmware team thinks this is expected behavior(two names showing up). As far as I know, from the android end, we don't have any control over the Bluetooth settings. So I wanted to understand if this behavior is expected. I have tested this scenario with SONY WF-1000XM3 which supports Google Fast Pair and I have noticed only one name showing up.
It would be great if anyone can suggest the best possible approach I can take here.
I'm doing some simple scanning + advertising testing on bluetooth LE feature for Android using this sample-code
I'm testing it using a Samsung 6 and a Nexus 9, and for some reason if I leave the app running on the Samsung and restart the app on the Nexus, the next time the Samsung devices finds the other device, it has a different address.
In code:
On the device:
The funny thing it doesn't happen the other way around. (Samsung always has the same address when discovered from the Nexus 9)
Is this a common behavior between devices?
Is there another way to identify a specific device besides it's mac address?
As CommonsWare mentioned, as of Android 6.0, Android has removed access to the hardware address programmatically, and made it so that the address appears to be randomly generated to scanning devices. The change log can be found here:
http://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-hardware-id
The fact that scanning devices see a random Bluetooth address rather than the actual one is a highly useful privacy feature. It was adopted by the Bluetooth specification as of BTv4.0 and is known as LE privacy:
"This feature causes the MAC address within the advertising packets to be replaced with a random value that changes at timing intervals determined by the manufacturer. Any malicious device(s), placed at intervals along your travel route, would not be able to determine that the series of different, randomly generated MAC addresses received from your device actually relates to the same physical device. It actually looks like a series of different devices, thus, it will not be possible to track you using the advertised MAC address"[1]
You can find a similar question here:-
Since marshmallow update Bluetooth discovery using BluetoothAdapter.getDefaultAdapter().startDiscovery(); is broken
[1] http://blog.bluetooth.com/bluetooth-technology-protecting-your-privacy/
I'm trying to use two phones in my car as a reversing camera: one being the camera and the other being the viewer. I have the software but the problem is I can't get it to work using two phones. I can get it to work using a third phone as the hotspot gateway. The problem seems to be I can't seem to communicate with any app running on the device running the hotspot yet they all have the same ip range. One machine is running a http server accessing the camera (similar to "IP webcam" app) and one is running software accessing the web server (in this case a web browser). There is no internet component. I assume this is being blocked because of some sort of security feature. I see no technical reason why it can't work.
I have tested this using HTC one, HTC DesireHD, Samsung galaxy camera and other various friend's phones so it seems to be consistent across android. Not an odd feature of some type of phone. Android 5 has not helped either. If it is a security feature do I need to root the device running the hotspot to overcome it? Any pointers to discussions on this subject would be very helpful.
I have searched many similar threads but most are discussing tethering issues or connecting through to the internet. Not sure what keywords to use. I have also tried "Hotspot control" app which did not work although I don't think it relates to this issue.
e.g How to make two android devices to communicate through TCP This has the right title but then goes on about NAT translation which is not related. Others go on about DNS. Just a simple DHCP server (which the hotspot has) and a router?
So in essence this is simply getting a local tcp/ip network set up between two android devices so apps can talk to each other. I would have thought this was quite straight forward. Hotspot is almost there as a solution.
I had a brainwave and solved my own problem at least on my HTC one (and I think before the 5.01 upgrade which would have been kitkat).
When in "settings" select "more" under "Wirelesss Networks".
Then under "Mobile network sharing"->"Portable Wifi Hotspot" click the menu button at the top and select "Advanced".
Then click LAN Settings:
Here we select the ip address of the host (i.e this mobile) and the "Starting IP" for the DHCP server for devices connecting in. It seems to choose zero (last in group of 4 numbers used for the ip address) for the mobile running the hotpsot and and then, presumably, 10 for the starting address of connecting machines. However, it seems only addresses from starting address onwards can see each other so the simple fix is to change the ip address of the host to a number greater than 10. I chose 200 and all worked. My camera can connect to the phone and the two can talk.
However, on my Galaxy camera (model EK-GC100) running 4.1.2 (Jelly Bean) these addresses can't be configured. It also doesn't allow a hotspot to start if a sim card isn't inserted. It seems to think there is no other reason to use a hot spot other than for tethering. Just another in the list short sighted design features that cost almost nothing to implement.
Unfortunately it would have been better if the camera device is running the hotspot. Oh well not a major issue as I wouldn't use a galaxy camera for a car reversing camera.
I'll explain the problem I'm trying to solve first. I have two Adobe AIR applications that can be deployed to Android (Receiver App and Broadcaster App). The Receiver App sits on one Android device and waits for any Android devices running the Broadcaster App (on the local network). This is all currently working and I can have the devices talking over a local WiFi connection with no problem.
The issue is I need to be able to do this without an external router/AP. I was able to setup a third Android device as a Wireless AP and have two other Android devices communicate over the WiFi connection just fine. However, the device setting up the Wireless AP connection is not able to join the network.
After searching google and stackoverflow I came up with a few solutions.
(1) Set up an Ad-Hoc network using a rooted Android device and running Barnacle. I was able to try this and set up an Ad-Hoc network successfully between two devices but they were not able to establish a connection in the Adobe AIR apps (using Adobe P2P support).
(2) If I can get my hands on the new Android 4.0 Galaxy Nexus I understand I'll have access to WiFi-Direct. I'm curious if this will solve my problem. Can I set up AND join a Wireless AP using the Galaxy Nexus, and connect to the Wireless AP from my older 2.X devices? Reading this makes me believe I can, but I wanted to know if anyone can confirm.
P.S. I am using NetConnection/NetGroup/NetStreams on the Adobe AIR side over a serverless rtmfp connection.
Thanks.
Sean, this may not answer your question, but I've used rtmfp for serverless p2p also (of the kind described in this blogpost by Tom Krcha) and have a couple data points for you:
Many HTC devices and other smartphones have a multicast issue that prevents them from communicating in this way. Google 'htc multicast' and read about it on this blog. Interestingly, these devices can work in such a group as long as there are non-impaired devices also, because they can transmit multicast, just not receive it. So the other devices initiate the group and all can participate. But the impaired devices can't initiate the group by themselves.
I had no trouble communicating between a range of devices, from Android to iOS to desktop, so I assume you should be fine across versions of Android.
I have a rooted phone that I run an app called 'wireless tether' to create a hotspot / wifi access point, and when two other devices connect to that hotspot, they can communicate with each other using this method, but they cannot communicate with the phone that is creating the hotspot network.
Does anyone know of a current Android cell phone that actually supports the Bluetooth SPP Profile? I have spent days online trying to find one, and nowhere do I see any cell phones that say they support the SPP profile. Furthermore, I have noticed all kinds of postings where people cant get their applications to work correctly because the phone they are using does not support the SPP profile, or it has been disabled on their phone. Am I missing something here? Before I commit to developing my Bluetooth application for Android, I want to make sure it can actually be done.
I am hoping that the answer is that we implement the SPP profile via the Bluetooth API, and therefore we can use RFCOMM on any Android OS level that supports it, i.e., 2.0 or above. Is this correct?
SPP is RFCOMM, from the docs:
The most common type of Bluetooth socket is RFCOMM, which is the type supported by the Android APIs. RFCOMM is a connection-oriented, streaming transport over Bluetooth. It is also known as the Serial Port Profile (SPP).
So yes, any device at API level 5 (2.0) or above will support BluetoothSocket and therefore SPP.
#GAZ This does not appear to be true. Take the Droid Incredible S, for example, running Android 2.3. Now install an app called Bluetooth Remote Control. The app displays a list of all BT devices it finds but remarkably does not find those that advertise only SPP. I can use that same app on my Nexus S and it finds the same devices that the Incredible misses. I can only assume that it is the carrier that disabled serial Bluetooth on their phones - as a way of preventing tethering.
Since I first posted this answer I have discovered the probable cause of the failure to discover some Bluetooth devices. It appears that when the major device class is BluetoothClass.Device.Major.MISC (0), many phones simply skip this device during discovery, although I can't imagine why. If anyone has thoughts on a workaround, I would love to hear them.
Turns out that there is a workaround for this bug (device class 0 being skipped). Find it here: http://zornsoftware.talsit.info/blog/pairing-spp-bluetooth-devices-with-android-phones.html