I have with my delphi code found the device I want to connect to and display services available. When I do the DiscoverServices for the device I found the method returns false meaning it didn't started. I suspect that this is because the device is not connected.
Following the example in https://developer.android.com/guide/topics/connectivity/bluetooth-le.html#read I do the whole discover part but I have found no equal thing in delphi that does
device.connectGatt(this, false, mGattCallback)
How do I go about to connect the device to my android phone in Delphi?
Am currently doing like the following
FBLEDevice := FBluetoothManagerLE.LastDiscoveredDevices.First;
FBLEDevice.OnServicesDiscovered := GetServicesAndCharacteristics;
if FBLEDevice.DiscoverServices = False then
Memo1.Lines.Add('DiscServ could not start')
else
Memo1.Lines.Add('Discover Services started');
SOLUTION:
You apparently don't need to connect in some special way as I though, the problem that my method won't start was because there are currently no services to discover on the module I am using.
Related
Situation:
VS 2022, 17.0.4
Maui App,
net6.0-android
AndroidManifest.xml contains also:
android.permission.INTERNET
android.permission.CHANGE_NETWORK_STATE
android.permission.ACCESS_WIFI_STATE
android.permission.CHANGE_WIFI_MULTICAST_STATE
android.permission.CHANGE_WIFI_STATE
Connected mobile Phone:
Samsung SM-G960F (Android 10.0 - API 29)
OS: Windows 11, latest patch.
All firewalls are down (for testing purpose only!)
While debugging the develop computer is only connected to a Wifi network; computers ethernet card is disabled.
Mobile phone is connected to this dev computer via USB cable (to be able to debug) and to the same Wifi network as the computer.
App starts and works fine, app can be debugged. No issue at all - except:
After the application is fully initialized and ready to accept user interactions -> Click on button -> Desired method is called -> Code is worked out -> The code should make a simple UDP call but it does not (or the packet does not reach the UDP listener due to missing configuration?).
The UDP receiver works fine and is capable to receive UDP packets.
My mobile phone and the UDP receiver app are using the same port.
I read/found already that in the previous cross-platform framework, means “Xamarin (Android SDK 12)”, some permissions must be set (I did, see above) and that the multicastlock must be set over the WifiManager …
I tried this in my MAUI app. But could not find anything guiding me nor figured it out by myself.
My MAUI sending code:
var dataToBeSend = "What ever ...";
var data = Encoding.UTF8.GetBytes(dataToBeSend);
var UdpClient = new UdpClient();
// UdpClient.Client.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.Broadcast, true);
UdpClient.ExclusiveAddressUse = false;
UdpClient.EnableBroadcast = true;
// UdpClient.Client.Bind(new IPEndPoint(IPAddress.Parse("255.255.255.255"), BroadcastPort));
// UdpClient.Client.Bind(new IPEndPoint(IPAddress.Any, BroadcastPort));
UdpClient.Send(data, data.Length, "255.255.255.255", BroadcastPort);
As said: very easy and straight forward.
Notice that I also tried binding UDP code …
So please can someone be so kind to guide me or give me a hint?
Thank you very much in advance!
ANSWER:
After two days I found a solution - and would like to share it because may be it helps someone else.
The code to make the UDP call msut be placed in a THREAD (not task!)
codesnippet:
var communication = new Communication();
var udpThread = new Thread(new ThreadStart(communication.FireUDPCall));
udpThread.Start();
The firewalls can stay turned on / active!
I have an Android VPN application. When I fire the intent to start the VPN (via VPNService.prepare), it fails immediately if there's an always-on VPN already configured on the device. That seems reasonable, but I'd like to be able to easily detect that case, so I can show a helpful message to the user.
By 'always on' I mean the specific VPN always-on Android VPN flag: https://developer.android.com/guide/topics/connectivity/vpn#always-on
I can't seem to find a way to access that info, even though it is used internally in Android (e.g. here but that getAlwaysOnVpnPackage doesn't seem to be available publicly AFAICT).
The best option I've seen is Check if a VPN connection is active in Android?, which will tell you if any VPN connection is currently active, but that's not enough, because:
I don't want to know about temporary VPN connections: I'm only interested if it's an always-on VPN connection.
Sometimes 'always-on' connections aren't actually always on. If you have a disconnected connection and set it as 'always-on', it's configured as such, and blocks all other VPN installs, but there's no network connection created (Android shows a persistent warning instead, which takes you to the other app to activate the connection). Because there's no connection, the above technique doesn't work. I still need to detect this case, since it still blocks my VPN setup.
Is there any way to check whether the device currently has a VPN configured as 'always-on'?
You can use this method
private fun isVpnAlwaysOn(): Boolean {
return if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP_MR1) {
val alwaysOn = Settings.Secure.getString(contentResolver, "always_on_vpn_app")
return !alwaysOn.isNullOrEmpty()
} else false
}
'alwaysOn' contains the package name of the app for which always-on is configured.
In the end, it seems this isn't possible on a normal device any way that I can find. I think is possible if you're a device admin, but that requires managed enterprise devices etc.
For now, I've handled this by watching for near-instant (less than 200ms) VPN setup failures (between running startActivityForResult(vpnIntent) and receiving onActivityResult with RESULT_CANCELED) and then showing a helpful message in that case.
Full implementation is in https://github.com/httptoolkit/httptoolkit-android/commit/928fbf92a4f868042789471be0d42800a226194b in case you're trying to do the same.
I am trying to get an existing RhoMobile APK running on a TC52, Android 8.1.
The App is running fine on TC51, Android 6. On the TC52, when i start the app I get a toast message
DS8178 Bluetooth Scanner is not connected, therefor BTPairing Utility will be started.
The problem is that - ignoring the BTPairing Utility App (i also tried to disable it) - i cant use the build in scanner in my rho mobile app. When I try to use it I see the following message in the log
"The decodeSound barcode property can only be set once the scanner has finished initialising"
Looking at the underlying code, it looks like that the scanner has not initialised, probably due to not be able to pair the bluetooth scanner. But there is now such scanner and there never will be. Anybody know how to disable this behaviour?
Edit 1:
Here is my javascript code for enabling the scanner
Rho.Barcode.enable({ allDecoders: true }, this.onScan);
But, I think it happens before that javascript is accessed; the app is hosted on web server; even if i disable WIFI and starting the app, the toast is displayed. It seems like that RhoMobile is trying to setup all known scanners.
Edit 2:
When I enumerate all scanners, i get those in this order
Scanners found: '[
"Camera Scanner",
"2D Barcode Imager",
"Bluetooth Scanner",
"RS6000 Bluetooth Scanner",
"DS3678 Bluetooth Scanner",
"LI3678 Bluetooth Scanner",
"DS2278 Bluetooth Scanner",
"DS8178 Bluetooth Scanner"]'
Default scanner: '2D Barcode Imager'
Default scanner is determined by
Rho.Barcode.getProperty("friendlyName");
Edit 3:
Ok, as suggested in the comments, using the actual instance returned from the enumeration works; triggering scanner buttons works well.
What remains is the toast that asks to connect the DS8178 Bluetooth Scanner; is there a way to disable scanners from config.xml?
This error:
DS8178 Bluetooth Scanner is not connected, therefor BTPairing Utility will be started.
Is not coming from RhoMobile, it is being generated from the low level scanning framework. I checked on a more up to date device and I'm glad to say they fixed the spelling error. It is caused when something (either EMDK or DataWedge) tries to enable the DS8178 scanner. The DS scanner support was only added in a recent version of the mobile computing scanner framework so that probably explains the difference in behaviour you are seeing between TC51 and TC52.
RhoMobile (on Zebra Android devices) wraps the EMDK and exposes each supported scanner as a separate Barcode object and you can see all of these in the array returned from enumerate. What is strange is that, per your second edit, the default scanner is '2D Barcode Imager'.
There are a few options / possibilities:
There is a bug in the RhoMobile framework and for some reason the DS8178 scanner is being enabled. I checked https://github.com/rhomobile/rhodes/tree/master/lib/commonAPI/barcode/ext/platform/android/src/com/rho/barcode and cannot see any such bug. Rho is open source but supported by Tau-Technologies if you wanted to explore that route.
Something else on your device is enabling the DS8178 scanner, e.g. a DataWedge profile or other app using the EMDK. You could disable DataWedge (from the DataWedge app settings) and reboot your device to test this.
There is an issue with the TC52. I would say this is the least likely as I have never heard of a similar issue
There is no way to disable any of the scanners via XML
I have a problem with testing my application on Android platform. I have functional application on x86 architecture. This application can connect to Bluetooth LowEnergy device and communicate with it. BT device is HM-10 module - serial line.
But when I try the same application, but just compiled for Android, I'm not able to receive any data back. On the other hand I can see on remote device that all data from mobile terminal are sent.
What I suspect as a possible problem is that signal QLowEnergyService::characteristicChanged is not emitted. In the documentation http://doc.qt.io/qt-5/qlowenergyservice.html is written that you should register for changes, but at least on PC it is done automatically somehow.
Would anyone please help me ?
You have to do some magic
QLowEnergyDescriptor notification = _characteristic.descriptor(
QBluetoothUuid::ClientCharacteristicConfiguration);
if (!notification.isValid()) {
qDebug() >> "QLowEnergyDescriptor not valid";
}
connect(_service, &QLowEnergyService::characteristicChanged, this,
&Device::onCharacteristicChanged);
_service->writeDescriptor(notification, QByteArray::fromHex("0100"));
using the android 4.4 BLE APIs on my Nexus7, i'm able to successfully interact with a peripheral BLE device -- connect, disconnect, read, write....
if however an active connection breaks for whatever reason (in this case, the peripheral is reset), i observe the following behavior....
my peripheral (by design) begins advertising after any active connection is terminated (for whatever reason); i can see this via my bluetooth packet sniffer....
i receive the onConnectionStateChanged callback as expected in my android app, at which point i invoke close() on my active BluetoothGatt instance; this is the same procedure i follow during a "normal" disconnect initiated from the client...
shortly after this, the android BLE stack tries to re-connect to the same peripheral; through the packet sniffer i can see the BLE connection request going out over the air...
my app, however, did not initiate this re-connection; indeed, i see no information from any bluetooth log suggesting this even happened!!!!
is there some "mode" in the BLE stack where it attempts to re-establish busted connections automatically???
thanks....
This happens on various Android phones whether the autoConnect flag is set to false or true.
Couldn't yet find a complete solution, it seems as the android BLE stack is spontaneously re-initiating the connection once it is getting the advertising signal again, just ignoring that it was the app that disconnected on purpose...
A partial solution may involve not using the BluetoothGatt.connect() method as explained here:
https://stackoverflow.com/a/23749770/4144487
So, a sample connect method can look like:
void connect(Context context) {
if (mGatt != null) {
mGatt.close();
}
mGatt = mDevice.connectGatt(context, false, callback);
}
To explain the importance of this issue, when it happens the peripheral thinks it is connected and my "real" app can't find it any more. At some phones like Galaxy S3 and Redmi note 3 I found that closing the bluetooth switch from the notification bar is "releasing" the peripheral and allowing me to discover the device. At others like Nexus 5x only a phone reboot will do the trick.
I've observed this happening if you use autoConnect=true when calling BluetoothGatt#connectGatt(). Generally I've found that it is best to use autoConnect=false, but with some devices you simply cannot connect unless you use true, so I usually do both. I try false first and if that fails then use true and then the behavior you're describing is something you simply have to work around.