I'm using QBluetoothDeviceDiscoveryAgent to search BLE devices on an Android phone.
I request device search to be started by calling QBluetoothDeviceDiscoveryAgent::start(). After a few seconds, QBluetoothDeviceDiscoveryAgent::finished() is emitted, but I did not call QBluetoothDeviceDiscoveryAgent::stop().
At this point, my BLE device was not found yet (it's slow...I know), and it won't as the system decided on its own to stop the search....so I need to restart the search manually.
Why is the system stopping the search? Qt doc says about QBluetoothDeviceDiscoveryAgent::finished():
This signal is emitted when Bluetooth device discovery completes.
What does that mean? How could anyone decide that discovery completes? Does it come from BLE standard? As a end user, I'm the only one who knows when it's completed, i.e. when the device I'm looking for was found....
As commented by Frank Osterfeld, the android implementation of QBluetoothDeviceDiscoveryAgent (see line 273) silently creates a 10 seconds timeout that stops the search automatically.
It's a pain for users who want to search for longer than 10sec...
Filled a bug report here: https://bugreports.qt.io/browse/QTBUG-53012
Related
In my application i start a single scan which can last from some second to minutes.
In the onBatchResult i get all the devices which advertise during this period, but if one of them turn off the bluetooth i'd like to have it removed from the onBatchResult Results list.
I tryed to find a way to clear the bluetooth cache every time i on BatchResult is triggered but i wasn't able to solve the problem.
How can i remove the device which are no longer advertising?
Thanks fot the help.
Instead of BatchScanResult try using onScanResult.in onScanResult callback, check for the callbackType parameter. If it is CALLBACK_TYPE_MATCH_LOST then get the device from the results and remove it from your cache.
I'm developing an android application that has to get traffic statistics once a week. The problem is that if user reboots his device, the statistics will be reloaded and the app will not be able to get statistics just by subtraction current value with an previous one. I was wondering if there exists some kind of listener for that purpose.
There is unfortunately no such way to find out (in a foolproof manner) that the device is rebooting.
Compunded by the fact that reboot can take place in many ways (from the UI - which is a procedural shutdown of the Android runtime, or from the shell using the "reboot" command which is Linux userland level call) you probably won't have enough time to do anything in your app once the reboot sequence has started.
Architecturally, you should always be in a situation where in a random reboot should not make your app lose critical data - i.e. always periodically saving your analytics data to file in internal storage etc.
I am trying to write a Bluetooth LE app that accesses a Zephyr HxM Smart heart monitor. This monitor has several Bluetooth services, but I am interested in the Battery Service, Heart Rate Service, and a Custom Service that has Activity and Peak Acceleration. There is one characteristic for each, Battery Level, (BAT), Heart Rate Measurement (HR), and Custom Measurement (CUS). The HxM updates about once per sec.
I am doing this with a Galaxy S4 with Android 4.4.
It is not working as expected from the documentation.
My initial approach was to do:
Read BAT
Set notification for HR
Set notification for CUS.
Then wait for the callbacks. Setting notification means calling
BluetoothGatt.setCharacteristicNotification(Characteristic char , boolean enabled)
(One could also do notification for BAT, however, the spec does not require this to be supported. The HxM, however, does support it.)
This didn't work. I got BAT and notifications for HR, but not CUS. If I eliminated the second step, I got notifications for CUS. I couldn't get both. (This indicates I am reading the characteristics correctly, so that is [probably] not the problem.)
I found some indications there were problems with the Bluetooth stack for Android being synchronous, but no hard documentation. I then tried the following:
Read BAT.
Wait for the BAT reading, then set notification for HR,
Get HR, then disable notification for HR, and start notification for CUS.
Get CUS, then disable notification for CUS, and start notification for HR.
And continue to loop.
I got BAT and that is all.
By trial and error, I discovered the following works:
Read BAT.
Wait for the BAT reading, then set notification for HR,
Get HR, then start notification for CUS.
Get CUS, then start notification for HR.
And continue to loop.
(Same as above but without disabling notifications.) Typically, I get a HR reading, then the CUS one within 200 ms. One can assume they are from the same update. (There are no timestamps in the data, which have to be kept short to be LE.) In reality the logic is more complicated, as timers are necessary in case expected readings don't come in. This logic is FAR more complicated (and more prone to error) than my first try, which is what the documentation seems to say is what is appropriate.
I have contacted Zephyr, and they say the HxM Smart has been extensively tested on Windows, and will do simultaneous notifications as it should. There are also indications it works as it should on iOS.
There is a further problem that I do not understand. In order to get notifications, you have to enable the Characteristics locally for notification with something like:
BluetoothGattDescriptor descriptor = characteristic
.getDescriptor(UUID_CLIENT_CHARACTERISTIC_CONFIG);
resSet = descriptor.setValue(BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE);
resWrite = mBluetoothGatt.writeDescriptor(descriptor);
This is a per characteristic setting, and should only need to be done once, when the characteristic is first received. Instead, I find I have to do it every time I set the notifications. It is possible this just causes a sufficient time delay for things to work. I don't know. This trial and error is taking a lot of my time. It would be nice to have a definitive statement of how it works.
I should note that for all calls that return a result, the result is true (success).
I apologize for the long statement. My question is:
I find no documentation that I have to do the things described. All indications are that you set up notifications and wait for the callbacks. Is there documentation, or is this a bug, or just a bad implementation? (Or is it my error?) I would especially like to know where is the documentation for what I have had to do.
Second, there is a further complication. I have tried to debug into the routines to see what the code is actually doing. When I get to BluetoothGatt.class, the source lines don't match what the debug stack says. I thus assume that the S4 is not using standard Android. I don't know where to go from there. It has been frustrating, and while I have something that appears to work, it is kludgy and almost certainly less robust.
Thanks for any help.
I had the same problem with writing multiple values in sequence, putting a Thread.sleep(200) in between them solved the problem (alas i should say). Maybe this helps as well with getting notifications.
Tested this on android 4.4.2 on Nexus 5. And no, 4.4 does not solve all problems...
Im probably very late to this but you should implement a queuing architecture for setting up your characteristics to send notifications. I used a similar technique to miznick in the post https://stackoverflow.com/a/18207869/3314615 and ended up just writing wrapper code for the native BLE stack since there are several apps i use BLE for. Ever since then I have had no issues receiving notifications. I agree with you that the Android BLE documentation should have some sort of information or warning about the BLE Stack not being synchronous. Frankly, i believe it should be re-written to handle synchronous write calls and just queue them.
First, you set Notification(i.e. setCharacteristicNotification and set Descriptor) for first characteristic.
And, Set notification for second characteristic in onDescriptorWrite callback function.
Let me summarize my problem and what I would like to achieve.
I have a SonyEricsson X10i phone with Android 2.3.3. I realized that sometimes my phone not receiving calls even if it indicating full coverage. I checked myself in the MSC/VLR and it indicates that I registered and my phone is currently active (and also there is no IMSI DETACH flag), so it should working correctly (only the last Activate Date is a little bit old ~couple of hours, which can be good as well, without SMS/Call/Location Update), as I mentioned before the phone indicates full coverage and it seems it’s on the network. But when I tried to call it I only reached the Voice Mail.
In the MSC/VLR I see No Paging Response Cause for the call, but the phone does nothing. I tried with other SW version (4.0.3 ICS), but the same result. But I not noticed similar behaviour with a different handset (same type).
Sorry for the long summary.
So because what I described above, I ‘m trying to write an application/service which will perform GSM/UMTS location update in 15-20 minutes, but I couldn’t find any kind of procedure in android.telephony.gsm.GsmCellLocation, android.telephony.TelephonyManager which will do this for me.
My other concern is the
getState()/setStateOutOfService()/ setState() procedures from ServiceState class…
It seems they not really working. For example, when I first call the getState() I always get back STATE_OUT_OF_SERVICE, which is not true…
When I’m set the state to STATE_POWER_OFF or STATE_IN_SERVICE, at least I get back that state from getState() afterwards, but the phone does nothing for that . (Not even indicate out of coverage,etc…)
Every suggestion/comment are welcome.
I have also seen this problem many times (2 phones from the same manufacturer as yours). From your question, I understand that you want to force the phone to send an MM periodic location update (which it should be sending anyway).
This is too low level, and there's nowhere you can force this directly in the programming interface. The mobility management procedure is part of the phone stack, and is specified in detail in 3GPP TS 24.008, available from www.3gpp.org. Paragraph 4.2.2 defines when the phone is supposed to send these location updates.
The only other thing would be to try by indirect means to force the phone into a condition where it would send a location update. You might be able to do that by trying to select another network manually. If it's successful, and you then manually re-select your home network, then you would trigger a location update. If it's rejected and falls back to its home network, then I think a location update would be triggered as well.
But there would also be small costs to this - battery use while it does a networks scan, and time lost while it scans and does manual network selection.
(My personal experience is that the lost calls don't happen often enough to justify this.)
I'm writing software which requires cell location updates to be received or checked constantly. The problem I'm having is that when the screen is off: a) notifications stop (using PhonestateListener); b) when a timer is used to check the cell info of the current cell, old cell info is returned.
I've spent a lot of time searching the reason for this and found a couple of posts on this subject. However I never found an answer or a workaround to the problem, accept for having the phone turn the screen on constantly to get a new cell location.
I've check the android RIL source code and it seems as soon as the screen is turned off, a broadcast receiver in the RIL sets the screen state to off and stops URC messages from the modem. I decided to try and call these internal functions to, say, reset the screen state (bad solution!), but I kept getting permission errors due to system intents being created as a result of my actions (I even tried by getting su permission).
Finally, I tried to communicate directly with the modem to send a +CSQ command (using 'invokeOemRilRequestStrings' function in the RIL). However, that part failed as I kept getting errors about object type not being same as expected class type...
So... I would like to know if anyone can point me to a solution to get this thing done. Or is it an impossible thing to do on android without modifying the ROM?
Thanks in advance for your help.
Did you try registering for location updates in a separate Android service having FOREGROUND priority?