I know that connection between two Bluetooth devices can be made without pairing and maybe exchange files. My question is how can I extract accelerometer data from a smartphone without pairing? I already have a device that can locate the smartphone using Bluetooth signals only without connection or pairing. So, I don't have control or access over the smartphone, I only sense its location with a sensor.
You might want to use Bluetooth BLE (low energy), which doesn’t need pairing, but I’m not sure if you can access accelerometer data without using classic Bluetooth and pairing.
Related
I am developing a device that needs to communicate securely to an Android app via Bluetooth. I need that only a predefined phone to be able to communicate with my device for security reason. And I also need to assure that this is not an intruder device that is trying to communicate falsified data to the app.
Looking at Bluetooth specs, I had the impression the only way to do that is with out of band (OOB) authentication with a pre-provisioning temporary key (TK). This looked very promising but after trying to find how to use OOB on an Android app, it seems like it is not supported.
Is it still possible to use OOB authentification on Android ?
If no, is there another alternative to solve my issue ?
This is doable but it depends on the BLE peripheral that you are developing and the features that it supports. Namely, your device needs to support Whitelisting and bonding. This is how it should work.
Upon first connection to the BLE device, the BLE device should accept the connection regardless.
Once the connection is made, the central device (Android phone) needs to initiate bonding. This doesn't need to be Out of Band (OOB) bonding, and the standard Just Works bonding should do.
Once bonding is succesful, the BLE peripheral should add the Android device's IRK to the list of whitelisted devices.
From this point onwards, the BLE peripheral will activate the whitelist, and therefore only devices in the whitelist will be able to connect to your BLE peripheral, and in your case it will be the Android phone that you used to make the very first connection.
It is not straight-forward and requires an initial secure-less connection with the target phone, but if that is not an issue then this should work.
You can find more information about this in the links below:-
Set and activate whitelist with Android phone
Android BLE server - allow only previously connected device to connect
Whitelisting with resolvable random addresses
My treadmill has a bluetooth chipset that it allows it to communicate with an app on my phone called iFit. In the communications, the phone receives information such as my distance traveled and speed, and the phone can set the treadmill's incline.
Instead of using iFit, I'd like to make my own script running on something like raspberry pi.
Is it possible to emulate the iFit bluetooth communications?
You can capture the bluetooth communication using bluetooth snoop logs. I think you will still need to write something to initiate the initial bluetooth connection. Once that is done you can possibly replay the traffic that captured in the bluetooth snoop logs. You can use Android Things on a raspberry pi if you are comfortable with working on the Android platform.
Is it possible to connect BLE sensor device to android watch if the watch has BLE inside, without a phone nearby in the same manner like with a handheld device, i‘ve seen some questions on stackoverflow like this, for example
Is it possible to connect Android Wear device with another BLE device directly without interaction of phone device?
but they weren‘t answered, or the answers weren‘t clear.
Thanks in advance
BLE protocol only allows communication between a central and a peripheral device. The sensor surely is a peripheral device that advertises BLE packets and expose some services (for example the heart rate).
You need to figure out if the android watch support BLE in central mode.
In that case you will be able to scan for advertisement packets coming from peripheral devices (sensors), and connect to them.
Im wondering if there's a way of bridging or using a 'pass-thru' to send data from a bluetooth connected device over wifi to another android device.
The real world scenario is;
I have a bluetooth OBD device (for reading your car specs in real-time)
This connects fine over bluetooth to my android phone running any OBD software.
But i also have an android based in car unit (gps, reversing cam, etc) but oddly enough it doesn't have a bluetooth radio/chip in it, only wifi.
So im wondering if it would be possible to run an app on the car unit and my phone to 'in essence' pass on the bluetooth data. Emulating a bluetooth radio on the car unit.
I know it can be done in reverse for tethering a data connection over bluetooth, but why not the other way around?
Other situations could be sharing a bluetooth device connected to one phone over wifi to many different phones???
Sounds plausible to me, but you guys are the experts!
What say you?
My applications connects my Android phone to a health device. The health device is capable of connecting using either Bluetooth SPP or HDP profile while my app can only support SPP.
The health device's documentation states that I have to send a special command to the it during the pairing process to make sure that Bluetooth communication uses SPP profile instead of HDP.
Note that I'm not concerned about connection after pairing at all. I need to:
Separate the pairing process from the connections after pairing - I don't mind if users have to authorise pairing through a popup
Be able to send some data to the health device during the pairing process (so that following connections will actually happen)
The Android documentation seems to imply that pairing is implicitly handled as an integrated part of the Bluetooth connections as you call connect() or accept(). However, this and this gives me some hope.
I'd like to support as many devices as possible but 4.0 and above are more important. The health device I'm using supports Bluetooth 2.1 so no worries about PIN.