So I just wanted to get my concepts cleared. How exactly does BluetoothServerSocket.accept() exactly work? The Android documentation mentions that it returns a CONNECTED BluetoothSocket, but isn't there some kind of authorization before connecting?
Also, I am currently working on an application where one device acts as a host and holds a listening BluetoothServerSocket, but I want to first list down all the incoming client connections and let the user select which device to connect with. Is that possible? If yes, how can it be done?
Thanks in advance. :)
You would have to implement those things.
Bluetooth has its own security, including authorization, encryption, etc. If the security of Bluetooth is not sufficient for your purposes then you need to implement your own.
Bluetooth sockets is a simple abstraction for communicating over Bluetooth RFCOMM (or L2CAP on other platforms). It doesn't add any security, or any ability to select amongst clients.
If you want to let the user choose amongst possible clients to connect with then you will probably want to accept() connections from multiple clients (so that you have multiple independent Bluetooth socket connections). Have each client use the socket to identify itself and then list these for the user who can then select who to communicate with.
If you want something easier, but less secure, you could just show the user a list of paired devices, or do a scan and show them the list of devices found in the scan, and then let the user pick from this list. But be aware that other devices can mis-identify themselves.
Related
We found multiple ways to connect two device with a Peer-to-Peer connection using things like Bluetooth and Wifi direct. Problem is, each device need the user to accept or confirm the connection.
We would like to make a One to Many system where everyone can connect to one device. This device need to manage all the connections incoming without any user interaction (really independant) and then display in our activity some informations receive from all the connected device.
We're looking for some good examples on how we can do this. Thanks
Cant you just use basic TCP Server?
EDIT/Answer to comment:
Yes it is possible, here is one of my sample apps, tho servers can be created on ports above 1024
My application need to create multi-group wifi-direct communication.But after testing I find that none of the following scenarios are feasible in Android:
1) a device plays the role of P2P client in one group and GO in another.
2) a device behaves as client in two or more groups.
I want to ask does the google have the plan to update the android Wifi-Direct API for suppporting one of above, so that we could implement multi-group communication easily?
Or are there some ways for two wifi-direct group communication with each other in android?
Thanks!!!!!!!!!!!!!!!!
Simple answer for all questions would be: No. though the second question it would be that As far as I know, No.
Anyway, if your logic requires you to be able to be GO & Client same time, then you could work around this by creating normal access point, where clients would connect to, and you could connect to other devices access point.
For access point, you could for example use the CreateGroup function, which would create hidden access point. Then you could use the Wifi Direct service advertising for delivering the password & SSID alongside IP-Address to other devices, so they could discover access points and connect to them.
I am looking to implement a cloud application that allows one to save contacts and if the contact also has the app on, see on a map where the contact is (if in close proximity to you).
I've been looking around towards how to do so and the first step is to establish a connection.
For my purposes, a centralized server to which apps connect and fetch repeatedly updated database information about other users is unsatisfactory as this is too "centralized" for a cloud app.
I've some experience with Bluetooth but in my opinion and experience, bluetooth is not practical as the two devices must then be in very very close proximity with each other.
Thus my question is this, how do android phones connect p2p without the use of local wifi? If that is even possible?
Thank you for your time
Thus my question is this, how do android phones connect p2p without the use of local wifi? If that is even possible?
Yes, via Bluetooth where available, but it will probably not meet your needs. So, in practice, the answer to your question is no. You will need the local wifi.
That being said, you could attempt multicast on the LAN to detect other connected devices enabled with your application. If you want more than LAN, you will need a fully fledge solution including super peers and a P2P framework, like JXTA
Hi all I was wondering what options do we have to exchange data between two different android devices?
For example, User-A and User-B both installs my app. I would like User-A to send data (possibly just a simple message or user-A's location info) to User-B.
The functionality I would need is similar to the functionality that WhatsApp has. However unlike WhatsApp, I do not have a server and I was wondering if we could do data exchange between two different android devices without a server?
I was thinking we build it atop SMS or something.
Options for exchanging information between devices are the following:
Bluetooth - this would be between two devices in the near vicinity
TCP/UDP IP connection - this would be using TCP to open a socket directly to another server socket. That could be hosted on the phone or a shared server. There are pros and cons to both.
The pros of bluetooth would be no need for a central server. The big downside is this means you can only exchange data between two people standing within 20 meter range. The other downside is you have to pair the devices which not everyone finds easiest.
You can use TCP/IP connections to exchange data just like any client-server program you write on a traditional computer. This could be used no matter if your phone is using 3G/4G/WIFI/EDGE or future radio protocols. The problem is the IP address of the phone might not be globally reachable. The IP address of the phone might be a non-routable like a private IP. They might be behind a firewall or NAT address.
This is where a central server is probably needed to either exchange IP addresses for users, or serve as a common location for clients behind infrastructure that could block. This is where protocols like SWIFT come in handy for jumping firewalls. Even with things like P2P you still run into these types of issues with non-accessible devices, and tricks like this have to be used to crawl around them. Unfortunately, that means you probably need a central server even with the P2P model.
Without an external server to keep a list of all connected clients, you would need to implement communication in a P2P fashion. Depending on the needs of your app, you could have the user type in the IP address/email/phone number of the other user they want to exchange data with.
If you wish to use a server approach, you can sign up for Google's App Engine which has good Eclipse integration as well as a plugin to easily interface with an Android app. This would give you an infrastructure option without initially (or maybe never depending on how high you scale) having to put down any money.
Google gave a good IO talk showing an example of a web app that can easily communicate with an Android app. You could extend this to do what you are looking to do.
I am developing an application which connects devices over bluetooth and exchanges messages. It works fine for paired devices, but I would also like it to automatically pair devices that are not paired. Like for example it could store and use the same PIN for pairing requests, I just dont know how to manage this request programatically in my applciation, how to automatically set and send the PIN when you get a pairing request and how to initiate such a request with the predefined PIN code.
Any snippets or thoughts would be highly appreciated! :)
EDIT:
I know its risky, I am developing this app for emergency situations only where no other means but bluetooth is available. Also is there maybe a way of premature pairing with devices without even connecting to them? Like lets say there is a list of MAC Addresses of those devices and I can use them to generate a bond with that devices so that they appear paired on my device?
You can't do this. To do what you want to do would create a huge security risk. Think about it, my device just comes anywhere in bluetooth range of yours and now I can send you anything I want without you knowing? You can't really do this and I highly recommend not trying to subvert it.
Reflecting the setPin method allowed me to send the pin automatically to the other device. I had to implement it in a broadcast receiver that is listening for pairing requests. Although I cant get rid of the dialog it just stucks there on the screen and I dont know how to close it (programatically) and continue the bonding procedure since this dialog is called from inside connect() which is a blocking method. I am not giving up on it yet though :)
With Bluetooth version 2.1 and above there is a method of pairing called the 'just works' association model. This is the lowest security method of pairing and has no protection against man-in-the-middle attacks.
However, this will provide a secure, encrypted link without the need to exchange pin numbers or verify device ID.
The API on different platforms may differ but the underlying HCI messages require that you indicate that your device (or one of the devices) has the following IO capabilities:
No Keyboard, No Display.
As you might have guessed, this is a mode for very
simple devices that use Bluetooth, such as a speaker or headphones.
If you can find the API to configure that, then the 'just works' association mode of Secure Simple Pairing will be used for pairing.
The next step is to store the link keys e.g. bonding. Many devices e.g. mobile phones, will still create a dialogue box to the user to ask if they want to 'remember this device', as user authorisation is specified by the BT specifications... but that's another problem.