Fixed
Status Update
No update yet.
Comments
al...@android.com
ch...@google.com
re...@gmail.com
We have the same problem.
ru...@gmail.com
I have the same bug on LG Nexus 4
ru...@gmail.com
Do you know, how this error can raise?
It would be interesting if it comes from the BLE device or from the Android stack.
It would be interesting if it comes from the BLE device or from the Android stack.
ch...@google.com
I am working on an app that connects to many devices and was getting the callback exception - it is because the Gatt connection is closed before the disconnect event has fired. So either you need to wait for the disconnect event, or what I do now is just call close. It seems to tidy away the connection without generating a disconnect event.
However, I am also sometimes getting BLE into a state where on connection, I immediately get a disconnect event and have to restart BLE to resolve. In my case I am getting status 133 not 22
However, I am also sometimes getting BLE into a state where on connection, I immediately get a disconnect event and have to restart BLE to resolve. In my case I am getting status 133 not 22
ka...@gmail.com
Ok. I have changed my implementation so that I am closing only after a disconnect which works for me now.
But I still get the status code 22. I remember that I also got a status 133 or 8 which are both not documented. I was not able to reproduce them so I do not exactly know when these status come up.
Another thing I found out is that after getting a successful disconnect from the callback the device is sometimes not disconnected and then I am not able to disconnect it anymore. It is then possible to connect it again and retry another disconnect which sometimes works.
I also observed that I got successfully disconnected but the callback did not fire. This leads to the problem that close won't be called, so a loose a BLE slot for connection which is a problem on devices where you only have 5.
But I still get the status code 22. I remember that I also got a status 133 or 8 which are both not documented. I was not able to reproduce them so I do not exactly know when these status come up.
Another thing I found out is that after getting a successful disconnect from the callback the device is sometimes not disconnected and then I am not able to disconnect it anymore. It is then possible to connect it again and retry another disconnect which sometimes works.
I also observed that I got successfully disconnected but the callback did not fire. This leads to the problem that close won't be called, so a loose a BLE slot for connection which is a problem on devices where you only have 5.
ch...@google.com
FYI: On the LG Nexus 4 with Android 5.1.1 I get disconnection with status 22 almost every time after connection to BLE device. Device is in the connected state about 30 seconds. And after that I get disconnection. That happens if BLE device is NOT paired with phone. Pairing helps to avoid such behaviour
ka...@gmail.com
Ok, but BLE devices should not need to be paired, only bonding should be needed.
So you pair a BLE device inside your app?
I try to avoid pairing, as this is not a standard BLE approach.
So you pair a BLE device inside your app?
I try to avoid pairing, as this is not a standard BLE approach.
ch...@google.com
I pair manually at the moment. I know that pairing is not standard approach. Do you think that bonding can help in this situation?
cu...@gmail.com
I am not sure. But I think that this might help. I am unable to use the createBond() function as I am stuck with API-Level 18 (createBond() requires at least 19).
When I am pairing manually, my app is unable to discover the devices that are paired. So this option does not work for me.
When I am pairing manually, my app is unable to discover the devices that are paired. So this option does not work for me.
ch...@google.com
Greetings.
I’ve developed mesh networking library for Android that uses Bluetooth in such way that it doesn’t need Discoverable confirmation from the user each 5 minutes. It also allows background connection between devices thus allowing true seamless mesh networking.
You can try it here:http://underdark.io
I’ve developed mesh networking library for Android that uses Bluetooth in such way that it doesn’t need Discoverable confirmation from the user each 5 minutes. It also allows background connection between devices thus allowing true seamless mesh networking.
You can try it here:
s....@gmail.com
The bug has nothing to do with a discoverable confirmation and is not helpful for my application as I do not need meshing.
In the meanwhile, I found out that one of the biggest problems (especially for the Nexus 4) is sending messages to all BLE devices at the same time. This causes the 0x22 error a lot of time so waiting between each transmission (I am currently using 10ms) could also be a workaround for you.
The next important thing is that you do no BLE communication while connecting or service discovery. I developed a small task system for all kinds of BLE communication to handle this. So I am using a macro task for connect and service discovery and do this for every BLE device in a single task. Only after that and while no other connect or service discovery task is running I am reading or writing characteristics.
But still I get these three error codes (8 (this one does not really affect the other connections so it is not so tragical), 16 and 133 (these to cause major problems in my application as stated in the first comment)).
The errors come up not very often since my last implementations but it is still annoying. Sometimes I even have to restart the phone to make it work again (happened with Nexus 4 and Galaxy S5).
In the meanwhile, I found out that one of the biggest problems (especially for the Nexus 4) is sending messages to all BLE devices at the same time. This causes the 0x22 error a lot of time so waiting between each transmission (I am currently using 10ms) could also be a workaround for you.
The next important thing is that you do no BLE communication while connecting or service discovery. I developed a small task system for all kinds of BLE communication to handle this. So I am using a macro task for connect and service discovery and do this for every BLE device in a single task. Only after that and while no other connect or service discovery task is running I am reading or writing characteristics.
But still I get these three error codes (8 (this one does not really affect the other connections so it is not so tragical), 16 and 133 (these to cause major problems in my application as stated in the first comment)).
The errors come up not very often since my last implementations but it is still annoying. Sometimes I even have to restart the phone to make it work again (happened with Nexus 4 and Galaxy S5).
ch...@google.com
Sorry, I forgot to say: The waiting of 10ms is additionally to waiting for the callback of the API.
[Deleted User] <[Deleted User]>
#15 I understand you so much. I wanted to develop similar system for connecting with iOS, but then though that even if I implement it, there will be some other stupid BLE bugs on Android which will prevent normal usage.
BLE and Bluetooth on Android is such a crap. And Android is just piece of trash too.
Btw, can you email to me? Maybe we find areas for experience exchange.
BLE and Bluetooth on Android is such a crap. And Android is just piece of trash too.
Btw, can you email to me? Maybe we find areas for experience exchange.
ch...@google.com
@lehner I am facing the same issue,
my ble connection works for 30 seconds, later on it disconnects & have the same error code 133.
Do suggest any steps or work around to solve this problem.
my ble connection works for 30 seconds, later on it disconnects & have the same error code 133.
Do suggest any steps or work around to solve this problem.
[Deleted User] <[Deleted User]>
#17 Google making some advancement to BLE stack in their AOSP bluetooth repo. Hoping that these bug will be fixed in Android 6.1.
Anyway, Android is piece of trash, so you must suffer.
Anyway, Android is piece of trash, so you must suffer.
ch...@google.com
What I also found out is, that Android explicitely says that the stack is made to connect only to one ble device at once. This is a major problem for me.
I "solved" this problem by not only making connect and service discovery one by one but also reading and writing characteristics is done one by one. It is important to always wait for the callback to tell you success or failure at reading or writing. It makes no difference if there are different devices. You should onl read or write, after you get the callback from the API. This is a big problem for my application as I have to write a characteristic on several devices at the same time. There should be no delays.
I also observed that it is possible to write them without waiting for the callback but they should never be written at the same time. If it is not so important you could synchronize writing across all devices so that they write one after another.
I had no time to test this because I am currently working on another project.
But a short test showed that it is possible.
With the implementations I have done (as I said in my post before) it is working not so bad for now. The errors got less. Sometimes it works without a problem during tests.
Hope this helps you a little.
I "solved" this problem by not only making connect and service discovery one by one but also reading and writing characteristics is done one by one. It is important to always wait for the callback to tell you success or failure at reading or writing. It makes no difference if there are different devices. You should onl read or write, after you get the callback from the API. This is a big problem for my application as I have to write a characteristic on several devices at the same time. There should be no delays.
I also observed that it is possible to write them without waiting for the callback but they should never be written at the same time. If it is not so important you could synchronize writing across all devices so that they write one after another.
I had no time to test this because I am currently working on another project.
But a short test showed that it is possible.
With the implementations I have done (as I said in my post before) it is working not so bad for now. The errors got less. Sometimes it works without a problem during tests.
Hope this helps you a little.
[Deleted User] <[Deleted User]>
Hey guy's would like to share regarding the fix i got with my issue.
Hope it helps you all,
I changed my advertising settings to setTimeout(0);
settings = new AdvertiseSettings.Builder()
.setAdvertiseMode(AdvertiseSettings.ADVERTISE_MODE_BALANCED)
.setConnectable(true)
.setTimeout(0)
.setTxPowerLevel(AdvertiseSettings.ADVERTISE_TX_POWER_MEDIUM)
.build();
Works fine without disconnection.
Also you can find the attached advertisement settings for more info.
Hope it helps you all,
I changed my advertising settings to setTimeout(0);
settings = new AdvertiseSettings.Builder()
.setAdvertiseMode(AdvertiseSettings.ADVERTISE_MODE_BALANCED)
.setConnectable(true)
.setTimeout(0)
.setTxPowerLevel(AdvertiseSettings.ADVERTISE_TX_POWER_MEDIUM)
.build();
Works fine without disconnection.
Also you can find the attached advertisement settings for more info.
ch...@google.com
Sorry if this is off-topic, feel free to flame me or contact me directly at pv@swooby.com:
lehner.a...@gmail.com, no offense, but what on earth were you doing with BLE that required that "there should be no delays" when writing to multiple devices? Mesh stuff? You can't possibly expect to depend on writes being exactly simultaneous. The BLE devices themselves may be in different states in the firmware and unable to process the write requests at the same time. It sounds like a classic "clock synchronization problem". It might be better to add a timestamp in to the payload of the write request.
It has taken me a year to come up with a decent BLE GATT connectivity implementation (which I am currently not at liberty to share). I have reverse engineered about a dozen BLE Android apps and perused several open source projects. It is ridiculous that Google/Android has continued to ship horrible BT implementations from day 1. I used to work at Google and had a pre-issue Android G1 and its BT API was horrible. I have a 3.5 year old still unanswered BT SCO question on stackoverflow (http://stackoverflow.com/q/12737446/252308 ), and then there is this horror, as well as these:
https://code.google.com/p/android/issues/detail?id=67272
https://code.google.com/p/android/issues/detail?id=82882
https://code.google.com/p/android/issues/detail?id=170132
https://code.google.com/p/android/issues/detail?id=173991
https://code.google.com/p/android/issues/detail?id=177358
https://code.google.com/p/android/issues/detail?id=179154
https://code.google.com/p/android/issues/detail?id=190372
https://code.google.com/p/android/issues/detail?id=191831
I'd darn near call that "pretty much unacceptable".
lehner.a...@gmail.com, no offense, but what on earth were you doing with BLE that required that "there should be no delays" when writing to multiple devices? Mesh stuff? You can't possibly expect to depend on writes being exactly simultaneous. The BLE devices themselves may be in different states in the firmware and unable to process the write requests at the same time. It sounds like a classic "clock synchronization problem". It might be better to add a timestamp in to the payload of the write request.
It has taken me a year to come up with a decent BLE GATT connectivity implementation (which I am currently not at liberty to share). I have reverse engineered about a dozen BLE Android apps and perused several open source projects. It is ridiculous that Google/Android has continued to ship horrible BT implementations from day 1. I used to work at Google and had a pre-issue Android G1 and its BT API was horrible. I have a 3.5 year old still unanswered BT SCO question on stackoverflow (
I'd darn near call that "pretty much unacceptable".
Description
Version used: 22.2
<android.support.design.widget.TabLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
app:tabBackground="@color/material_blue_grey_800"
app:tabIndicatorColor="@color/material_blue_grey_900"
app:tabIndicatorHeight="5dp"/>
Let's consider the above TabLayout.
Now when i specify tabIndicatorColor and tabBackground to TabLayout. Then, the tabIndicatorColor is not visible just because of tabBackgroud will overlap tabIndicatorColor. So When I use tabBackground , tabIndicatorColor is not visible.
But If specify only tabIndicatorColor then it is visible perfectly.