android-ble | DeviceHive Bluetooth Low Energy bridge for Android | Networking library

First of all, if you are intending to distribute your app to Google Play Store, you need to be targeting minimum api level 29 if I'm not mistaken, hence you should be using either JobService along with JobScheduler or WorkManager, instead of Service. This is to support the background limitations from Oreo(26) onwards.

a) if you properly implement any of the two options I mentioned above, you can write a proper service that will not terminate unless you stop it. Here are some resources on JobService : (resource1, resource2, resource3)

b) You can re-register as you please upon the onStartJob() method of your JobService, which will recreate your app.

c) Each time you are done with the peripheral ble device, you need to close the gatt connection with it. Here is a snippet from the BluetoothGatt class

From the logs I see "found something 2" is logged in onBatchScanResults() method of ScanCallback. You should handle this event. Call the same connectGatt which is used in onScanResult() method.

When device connection successful in order to read messages from device you should subscribe to services and setCharacteristicNotification for PROPERTY_NOTIFY type characteristics.

For anyone who comes across this post also wondering why Android seems to return only 600 bytes for long GATT characteristics like this question is asking about, it all comes down to how Bluedroid (Android's Bluetooth stack) implements their GATT Client and how its out of spec. In my case, I was using an ESP32-based IoT device as my GATT Server and Android (SDK 24) for the GATT Client.

According the spec (Bluetooth Core 4.2; Vol 3, Part F: 3.2.9), the maximum size for a characteristic value (inherited from ATT's attribute value) is 512 bytes. However, for some reason, Bluedroid does not attempt to enforce this requirement, instead decided upon a maximum size of 600; which can be seen if you dive into the Bluedroid source and find the macro GATT_MAX_ATTR_LEN which is set to 600 (stack/include/gatt_api.h:125). Since in my case (and yours it seems) I was implementing the read request response code, I did not see to enforce the 512 byte limit on reads for characteristics either.

Now, its important to realize just how it seems Bluedroid reads characteristics and how that relates to both the MTU size, the maximum size of a read (should be 512, but is 600 for Bluedroid) and how to handle data longer than that maximum size. The MTU size is the largest packet size on the ATT level you can use. So, for each call to BluetoothGatt.readCharacteristic, you may be sending one or more read requests to the server depending on if Bluedroid thinks the characteristic size exceeds the MTU size. On a low level, Bluedroid will first send a ATT Read Request (0x0a) and if the packet is MTU bytes in length, it will follow up with a ATT Read Blob Request (0x0c) with the offset set to the MTU size. It will continue to send ATT Read Blob Requests until either the ATT Read Blob Response is less than MTU bytes in length or until the maximum characteristic size is reached (ie, 600 for Bluedroid). Its important to note that if the MTU size is not a perfect multiple of 600 for data longer than 600 bytes, the remaining bytes will be discarded (as Bluedroid never actually expects to read 600 bytes since it thinks the GATT Server will enforce the 512 byte limit on characteristic sizes). So, if your data exceeds the 600 byte limit (or 512 limit for safety), you should expect to call BluetoothGatt.readCharacteristic multiple times. Heres a simple example for reading lots of data on the Android side (sorry Im not using bleno so cannot give you the code to fix that side), it relies on first sending the length of the data as a unsigned 32-bit integer and then reading out the data with repeated calls to BluetoothGatt.readCharacteristic if the data is longer than 600 bytes:

After a great deal of investigation, I was able to determine the root cause of my issue: Spotify.

Having Spotify installed on the Android device was enough to manifest this aberrant behavior; the user need not have logged into or ever started the Spotify app. Uninstalling or force-stopping the app in all cases rectified the issue.

It appears that Spotify has a service that registers for disconnects from any bluetooth peripheral. When the system notifies Spotify, the service immediately connects to the just-disconnected peripheral --- I didn't bother to characterize the communication from Spotify. After ~5 seconds the connection is dropped; however, since Spotify is notified of bluetooth disconnection events, the service again tries to connect with the peripheral. This effectively is an infinite loop that can be aborted only by force-stopping Spotify or cycling bluetooth on the Android device.

To investigate, I developed a simple app that is notified of and reports bluetooth connection and disconnection (ACL_CONNECTED, ACL_DISCONNECTED) events. I used a BLE scanner on my Android device and connected / disconnected with a variety of bluetooth peripherals. My test app would show my initial interaction with the peripheral followed by an infinite stream of connect then disconnect events. Again, this would continue until Spotify was force-stopped.

Following is example logging...

In latest versions of Android they lowered the default timeout to 5 seconds, which is of course much better.

I guess most peripherals send their own Connection Update request where they can set a different timeout value, which solves that issue (except for the small time between connection setup and until the connection update has gone through).

So called "out of range" detector apps are according to me pretty useless and hard to make good because BLE devices will probably sometimes temporarily disconnect anyway, even though they are in range.

For your actual question if it's possible to "immediately" get notified on the loss of the connection, the basic answer is no, because the Bluetooth controller doesn't send anything to the main cpu that packets were lost (that's the whole purpose of having a timeout so you are allowed to have packet losses). But you can of course try to poll the rssi or set up a flow where the peripheral every constant interval sends a notification and then you can in your app detect if you don't get the notification after some amount of time. But in this case it's smarter to just set your own timeout (from the peripheral) using the connection parameter update procedure.