I have developed an application on an on-board device which allows a smartphone to be able to connect in secure BLE.
Everything works fine but I notice that every time I do a "pairing" via an Android smartphone, that the smartphone "bonds" the device even though I specified in the request that I did not want bondage. I don't have this problem on IOS.
Here are the requests that are sent by my on-board device to the smartphone:
Security request
Pairing response
Is it possible that Android does not support "pairing only"? If it is paired, it does a "boding" automatically even if it has received a request asking it not to do a bond?
Thank you
"Non-bondable mode" is mandatory to support in the Bluetooth Core specification. If Android makes a permanent bond, even though you say to not bond in the "Pairing response", it's a bug in Android. Please file a bug report to Android Open Source Project (AOSP).
Related
I have a Bluetooth Low Energy (BLE) device and want to access it from a web page using the Web Bluetooth API.
This works perfectly fine in Chrome on Windows (at least with current versions of Chrome and Windows) and even with the WebBLE App on iPadOS (since Safari won't support WebBluetooth).
But I have multiple Android devices running the current versions of Android (12) and Chrome (97), where in the browser device chooser, the device won't show up. Some other unknown devices show up, but my device does not.
What could be the reason just this one device does not show up and how could I gather more information about this situation?
It happens in the native browser dialog so my usual debugging steps don't work.
Update:
I have already checked with chrome://bluetooth-internals, and the result is the same. The device shows up on Chrome/Windows but not on Chrome/Android.
Now I also used chrome://device-log which on both Windows and Android shows only
Bluetooth Internals Page initiating Bluetooth discovery session
nRF Connect for Mobile shows the device instantly, and it also shows up in the Android Bluetooth settings. Only Chrome Web Bluetooth doesn't show it.
Update2:
The adb logcat reveals the following line during Chrome Bluetooth discovery:
V/BtGatt.GattService(19403): Skipping data matching denylist
What's that? Has Chrome its own denylist for bluetooth devices?
Update3:
Android has a denylist for BLE devices, which should not be applied if the App (Chrome) has ACCESS_FINE_LOCATION permissions. But Samsung seems to apply the denylist nonetheless, even if Chrome has all necessary permissions.
https://www.chromium.org/developers/how-tos/file-web-bluetooth-bugs/ lists tools and log viewing approaches thay may help, including:
chrome://bluetooth-internals
nRF Connect for Android
chrome://device-log
Try requestDevice with "acceptAllDevices":true as well if you haven't yet.
It is unfortunate that this device is getting filtered out even though it isn't a location beacon (iBeacon, eddyStone) but this behavior is currently working as intended according to https://bugs.chromium.org/p/chromium/issues/detail?id=1296054.
The reason the device is not showing up is that Android has a denylist which matches Eddystone and iBeacon payloads using the advertising data.
My device seems to have something in its advertising data which matches Eddystone or iBeacon and thus is ignored, even though it is a digital tape measure.
Sources:
https://android.googlesource.com/platform/packages/apps/Bluetooth/+/master/src/com/android/bluetooth/gatt/GattService.java#255
https://android.googlesource.com/platform/packages/apps/Bluetooth/+/master/src/com/android/bluetooth/btservice/AdapterService.java#3939
Target:
Sending a file to connected peers. The connected peers should recieve the File without a preinstalled app.
Situation - Question:
I'm writing an app that opens WiFi-direct or a WiFi-Hotspot for other devices. The other devices connect to the device (Main-Device) where the App is installed on. Now the Main-Device should broadcast a file and every device connected to the Main-Device should get a notification, that it could receive a file. But, the other devices should not need an App to receive the file!
Is this possible? Cause all I found till now describes how you can send something from one to an other device if both installed the same app. Using sockets and one device becomes server and the other client.
Reason:
I try to create a game, which just is installed on a Main-Device. Other devices can join the game by connecting over WiFi, then they'll receive a HTML5-file from the Main-Device which they can open in their browser. As soon as they have the HTML5-file they'll be able to interact with the game on the Main-Device.
But I don't want to force everybody who likes to join the game to download the app. Another Point is, if this is possible, I don't need to rewrite the app for other systems. Cause every Smartphone/Tablet has a Browser.
But, the other devices should not need an App to receive the file! Is this possible?
No, it isn't.
I try to create a game, which just is installed on a Main-Device. Other devices can join the game by connecting over WiFi
That, is possible. What you need to do is build a captive portal.
Basically, all DNS names resolve to your server's IP address, and all traffic that would be routed elsewhere is not routed to the internet. How you do this depends on your network setup. There is a lot of software available. I've used Untangle before with decent results: https://www.untangle.com/store/captive-portal.html
I'm trying to realize an Android-Beam-like behaviour between an Android Smartphone and a Linux Host. The Android Smartphone (Galaxy Note 3, Android 4.4.2) touches an NFC Dongle connected to the Linux Host and exchanges Bluetooth carrier data via NFC so it then can connect to a Bluetooth Dongle, also connected to the Linux host.
Now the problem is, that the Android Smartphone always asks the User (me) if I really want to pair with the Bluetooth Dongle. In Android Beam between two Android mobiles, this user confirmation doesn't show up, the user only has to click the content (i.e. the picture) to send it (and this is the behaviour I'm trying to get to). I'm using the "nfctool" to sniff the incoming Handshake Request message by the Android mobile (see http://pastebin.com/Dr0D0nqn ). According to the "Bluetooth Secure Simple Pairing Using NFC" document by the NFC Forum (see http://members.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf page 19) this Handshake Request should contain a Simple Pairing Hash and a Simple Pairing Randomizer, which are both missing in the Handshake Request by Android.
So my questions are:
First of all, is Android Beam using Secure Simple Pairing with OOB at all, or another mechanism? Why is the Android Beam between two Android devices working without confirmation of the pairing?
If it is using SSP, why are the SSP Hash and Randomizer missing in the HR message? Could this be the reason, why my pairing needs user confirmation?
If Android is using another mechanism, how do the HR messages roughly look like? Do they use a special type name (other than "application/vnd.bluetooth.ep.oob") or anything else in their Handshake Request, which circumvents the user confirmation of the BT pairing?
Are there any technical documentations (I couldn't find any so far) of Android Beam available? The NFC guide on android developers ( http://developer.android.com/guide/topics/connectivity/nfc/nfc.html ) isn't of much help concerning Android Beam.
Any help is much appreciated :)
I finally found the solution for this problem, and answers to most of my questions:
Yes, Android is using SSP, but Hash and Randimizer are not mandatory, so it's no must that they are included in the NDEF HR/HS messages.
Android is using HR messages with type name "application/vnd.bluetooth.ep.oob", this is correct.
It seems to be sufficient for SSP, if one device confirms the pairing process. So the solution for my problem is, to set the IO capabilities of the Linux Host to "DisplayYesNo" and then autoconfirm the authorization request. This way the Linux host fakes User input and the Android mobile wont ask the User for his confirmation anymore. A quick (and a bit dirty) way to realize this is to change BlueZs "simple-agent" script to confirm every authorization request.
I am currently working on the creation of an application for mobile devices with Android which should be capable of sending and receiving messages through local means like wifi and bluetooth. After making a research about it I found out that Android doesn't have a native wifi ad hoc functionality and that the only way to achieve that is through rooting your device and patching the wpa_suplicant and some other similiar methods which are not generic for every device.
Synopsis of what I am trying to achieve:
An application for Android that scans for devices nearby and tries to connect to them automatically. If the other device also got this application isntalled then it automatically accepts any connection request it receives and when the connection is established it sends back a message which ensures that it has this app installed so that both can start exchanging messages automatically and the users don't have to allow/deny any of the sending/receiving in real time.
My questions are:
Is there any way of sending messages through wifi between 2 android
devices without the use of internet?
Since Ad Hoc is not supported, is there any alternative?
In case the answer to 2 is no , then is it possible to make one of
the devices to be an access point so the other can connect to it and
vice versa.
As for bluetooth, is it possible to skip or automate the allow/deny
pop up of an incoming connection and the pairing procedure?
I'll be glad if you could give me an answer to those and/or any suggestions.
You'll be able to communicate between two devices over wifi without a router/access point using Wifi Direct (P2P) in Android 4.0.
Otherwise, I don't believe you can achieve this over Wifi (bluetooth would be the next best alternative). Since 2.2 you can set your phone up to be a Wifi Access Point (for tethering your device's network connection), but during this time, the Wifi hardware is unavailable for normal use. If you had 3 devices it could work (1 AP, 2 connecting to it).
Is this for a constant connection, or a one-off small delivery? You could use NFC if you want to transmit a URL for example (Android Beam integrates this type of sharing in Android 4.0, but could implement it in 2.3).
I want to initiate a pairing request (not connection at this point of time) to a non android device. This can be found working on Settings Application > Network > Bluetooth Settings > Click on a device after scan. A pop up appears on both the devices with a 6 digit pin.
As per Android's documentation this should have popped up in my application as well, if I do something like this
device.createRfcommSocketToServiceRecord(MY_UUID);
As per Android's API documentation
"Once a connection is made with a
remote device for the first time, a
pairing request is automatically
presented to the user."
And it is also mentioned that
"The current Android Bluetooth API's
require devices to be paired before an
RFCOMM connection can be established.
(Pairing is automatically performed
when you initiate an encrypted
connection with the Bluetooth APIs.)"
Even when I used the sample Bluetooth Chat application (only to test if it initiates a pairing on first connection) it didn't worked.
I also tried using a generic UDID like "00001101-0000-1000-8000-00805F9B34FB" but to no avail.
Couldn't find the source code of Settings Application (Android OS 2.1) to figure out myself. The sources available in Android GIT were for Android 2.3
Even if you cannot answer the question, only pointing out to Android Packages Settings App sources for Android 2.1 might do the trick for me.
It works for me with this UUID : "00001101-0000-1000-8000-00805F9B34FB".
The intent for pairing request is launched when you call socket.connect() if I remember correctly.