I'm trying to use WiFi Direct service discovery to connect two android phones. I'm only interested in one phone being able to send a connection request. I thought what I needed to do was register a local service on one phone, and discover the service on the other phone, and after discovering it I can connect to it. But it seems like I have to do the discovery stuff on both phones in order for it to work...so I'm just confused on what's happening. I'm using this tutorial. Can anyone help me understand what's necessary to have the two phones connect? I can't have one phone only registering and the other phone only discovering?
It really depends on what you are trying to do. You can actually discover other devices and perform a connection without having a Service Discovery layer on top. Peer Discovery and Service discovery are not the same thing. Peer discovery involves detecting all of the nearby devices that use Wifi Direct while Service Discovery involves only discovering devices that advertise a specific kind of service.
You should start with this other Tutorial before moving on to Service Discovery which is a more advanced topic.
You can detect other devices using peer discovery but there is no need for service discovery to exchange data or service. You can use socket connection also after connecting the devices ex - for exchanging of files .
It's worth to mention that using ServiceDiscovery you can sent some additional data, like running port or something else in record map (in DNS-SD at least).
Related
I want to use the BLE Current Time Service (0x1805) in conjunction with a BLE enabled device. My question is: Do I "need" to create an App to manage BLE connectivity and return results for the Current Time Service to my device, or does Android somehow implement a generic GATT server?
If so, how do I enable that?
So far, my BLE pairing attempts have simply errored out on the device side.
I'm not aware of a generic GATT Server on Android, but there are apps that can do the job for you. I would suggest starting with the nRF Connect app which is able to start a GATT server with a pre defined current time service.
I am writing an android app to connect with BLE heart rate monitor devices.
All works well until another application tries to connect to the same service on the BLE device.
Only one application seems to be able to connect at a time.
Is it possible to connect the same BLE service to multple apps at once?
I set up my Bluetooth service in accordance with Link :
You can use BluetoothManager.getConnectedDevices() to get a list of Bluetooth devices, even ones not connected by your app. Unfortunately, you don't also get the service information for those devices.
What you can do then, is connect to the ones not already connected by your app and perform service discovery on them (BluetoothDevice.connectGatt() / BluetoothGatt.discoverServices()), then disconnect those that you aren't interested in. It's a bit cumbersome, but it seems to work for us.
No you can not do that, this is something is not supported in BLE.
I have to implement bluetooth connectivity with multiple devices(4 devices) from my android java application. App will be continuously receiving data from 2 connected BT (bluetooth) devices, the other 2 BT devices can be connected on need basis & no need to maintain continuous connection. As per the requirements, app has to run continuously for 24 to 48 hours. The device with the app installed will be dedicatedly used for the app & the app will be continuously pushing the bluetooth received data to a remote server. The connected BT devices can be disconnected & reconnected any time from the app. Also if the BT connection is lost, automatic reconnect should happen. What is the best approach to implement this?
Hi i have developed a similar app for BLE Heart rate Belts (Polar H7)
what i did (may not be the best approach but it works smoothly for me as i am able to mangae 5-7 belts at a time) is i made a service to manage the connection with multiple BLE devices
in the service i keep record of all the GATT Callbacks.
so i am using one service in backgorund to keep and mange the connections and separate GATT callbacks for each device in a list or Hashmap .
If a device disconnects or new connection needs to be established i connect/disconnect accordingly and update my record of GATT callbacks .
take a look at the Android BLE sample something similar
There are several choice for making a WiFi program in android, most common methods are using NSD and WifiP2pManager.
What is different between these 2 choice?
Firstly, these are not two entities to be differentiated. Even if you use Wi-Fi P2p for NSD, you should use WifiP2pManager for connection initiation and negotiation. NSD is to be used for Discovery phase
I assume your question to be difference between Using Wi-Fi P2p Service Discovery(NSD) and Not using it (using normal scan WifiP2pManager.discoverPeers() ).
The answer is explicitly provided here under three sub-topics. However
The difference is actually in the initial phase: The peer discovery phase
When you don't use the Wi-Fi P2p Service discovery, you scan for all
devices that are active with WiFi direct. The scan result list may contain peers that are not of your interest. You can't help it, as you do not have a filter.
In the case where you need to discover only peers that are of your
interest, then Wi-Fi P2p Service discovery should be used. Here, the
filter condition is set in the name of Service.
For ex: your app "XYZ" needs
to form groups ONLY with other devices that also use the same app
"XYZ", then you can create a service and name it, say service_xyz,
and this service info will be broadcast along with the Wi-Fi Direct
device details. On the receiver end, you implement a service listener
that listens for the service "service_xyz". By doing so, only devices
with the desired service name are discovered and listed. Useful for
gaming apps, social networking apps.
However, after this phase, in both the methods, from the discovered list a particular device is selected and connect request is initiated. From here on, the following phases are the same - connection request, negotiation, group formation...
hope this helped you.
I have: 1) An embedded device with a Bluetooth connector that I use with BlueZ, and 2) I have an Android phone that I am writing an application on.
Goal: I want to make sure that when these two devices are near each other, they quickly detect each other and establish communication. Unfortunately, I'm running in to complications of what is feasible on Android and power efficient.
Initial Design: Originally, I've been thinking and implementing the following --
Embedded Device: Constantly in discoverable mode, creates a service with an RFCOMM server running to accept multiple connections.
Android Phone: Listen for Broadcast intents that would tell me when the embedded device (discoverable) is nearby, and then create an RFCOMM client socket to it.
The difficulty I am having with this design is that I do not get intents when I would expect them. Even if I turn the embedded device on and cycle the Android phone's Bluetooth adapter to off/on ... none of these Broadcast intents are received:
BluetoothDevice.ACTION_FOUND
BluetoothDevice.ACTION_ACL_CONNECTED
BluetoothDevice.ACTION_BOND_STATE_CHANGED
The only thing that seems to work is to periodically either have the phone try to connect to the Bluetooth device's RFCOMM socket, or to periodically trigger Bluetooth scans (both power inefficient). This will trigger ACTION_FOUND and ACTION_ACL_CONNECTED. If i shutdown the embedded device, I will receive ACTION_ACL_DISCONNECTED. The issue, again, is that none of these are received if I do not explicitly have the phone try to initiate a socket connection. This is bad for power efficiency on the phone.
Do I have this logic backwards? Should the embedded device keep track of Bluetooth MAC addresses that it has paired with and be the RFCOMM client, whereas the Android application creates a service and is the RFCOMM server just hanging around and waiting for a connection? This seems logically backwards, though... I wouldn't think the Android phone would create a service or be the server to make this happen.
If I go in to my car, it almost immediately manages to establish a connection with my phone. So, I know this is possible!
The concrete questions I have are two-fold: 1) Is there something I am doing wrong with my "initial design" to make it more effective, and 2) Is the 2nd logic I propose what things like cars use to establish quick communication and poll frequently? (since the battery power of the car is not a concern...)