IssueTracker

We have the same problem.

I have the same bug on LG Nexus 4

According to https://android.googlesource.com/platform/external/bluetooth/bluedroid/+/android-5.1.0_r1/stack/include/gatt_api.h
the error number 22 (0x16) means GATT CONN TERMINATE LOCAL HOST.

Do you know, how this error can raise?
It would be interesting if it comes from the BLE device or from the Android stack.

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

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.

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

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.

I pair manually at the moment. I know that pairing is not standard approach. Do you think that bonding can help in this situation?

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.

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

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).

Sorry, I forgot to say: The waiting of 10ms is additionally to waiting for the callback of the API.

#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.

@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.

#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.

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.

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".

#21 Google doesn't care about my or your problems. We must suffer.

Also take a look at AOSP Bluetooth repository — it seems that Google finally fixes bluetooth due to its Brillo project.
I think their managers finally tried to use Android Bluetooth stack themselves and accidentially found out that it doesn't work at all.

#22, good point

Keep an eye out here for changes:
https://android.googlesource.com/platform/system/bt/

For more AOSP BT info:
https://source.android.com/devices/bluetooth.html

@ p...@pebblebee.com:
I should explain a little better. I do not need any real time communication. What I mean with delay are delays that can be noticed by humans. So delays of several 100 ms and this is a very high value for writing this small amount of bytes. More concretely I am setting colors of several juggling balls. The problem is for example if you set a color effect rainbow (all colors fading) then you can see that every ball starts after another. Sometime even half a second later. Here it would be important if they are synchronous. I know what happens in the firmware as these balls are also developed in the company I am working in.
There also exists an app for iOS which does not have this problem.

Thanks for your links. I will check them on later time.

Thank you for your feedback.  We assure you that we are doing our best to address all issues reported. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with the bug report here https://goo.gl/TbMiIO and reference this bug for context.

>> #24

Datadog SDK for Android has a try catch, https://github.com/microsoft/cpp_client_telemetry/pull/798/files. Though, a back-off retry logic might also satisfy functional needs.

We are also facing the same issue with Android 11(OnePlus 6 Device).  Below is the stack trace of the crash.

java.lang.SecurityException: Package android does not belong to 10470
  at android.os.Parcel.createExceptionOrNull(Parcel.java:2373)
  at android.os.Parcel.createException(Parcel.java:2357)
  at android.os.Parcel.readException(Parcel.java:2340)
  at android.os.Parcel.readException(Parcel.java:2282)
  at android.net.IConnectivityManager$Stub$Proxy.getNetworkCapabilities(IConnectivityManager.java:2543)
  at android.net.ConnectivityManager.getNetworkCapabilities(ConnectivityManager.java:1415)

We see this crash on a POCO X2 device when getNetworkCapabilities is invoked  (only on Android 11)

Caused by java.lang.SecurityException: Package android does not belong to 10025
       at android.os.Parcel.createExceptionOrNull(Parcel.java:2376)
       at android.os.Parcel.createException(Parcel.java:2360)
       at android.os.Parcel.readException(Parcel.java:2343)
       at android.os.Parcel.readException(Parcel.java:2285)
       at android.net.IConnectivityManager$Stub$Proxy.getNetworkCapabilities(IConnectivityManager.java:2456)

Caused by android.os.RemoteException
Remote stack trace: at android.app.AppOpsManager.checkPackage(AppOpsManager.java:7794) at com.android.server.ConnectivityService.getNetworkCapabilities(ConnectivityService.java:1778) at android.net.IConnectivityManager$Stub.onTransact(IConnectivityManager.java:978) at android.os.Binder.execTransactInternal(Binder.java:1154) at android.os.Binder.execTransact(Binder.java:1123)

Any ETA on the fix or a reliable workaround ?

Any updates on this crash. 100% OS 11 & 100% in background. This is spread across all brands.

Fatal Exception: java.lang.SecurityException: Package android does not belong to 10267
       at android.os.Parcel.createExceptionOrNull(Parcel.java:2373)
       at android.os.Parcel.createException(Parcel.java:2357)
       at android.os.Parcel.readException(Parcel.java:2340)
       at android.os.Parcel.readException(Parcel.java:2282)
       at android.net.IConnectivityManager$Stub$Proxy.getNetworkCapabilities(IConnectivityManager.java:2456)
       at android.net.ConnectivityManager.getNetworkCapabilities(ConnectivityManager.java:1385)
       at androidx.work.impl.constraints.trackers.NetworkStateTracker.isActiveNetworkValidated(NetworkStateTracker.java:149)
       at androidx.work.impl.constraints.trackers.NetworkStateTracker.getActiveNetworkState(NetworkStateTracker.java:138)
       at androidx.work.impl.constraints.trackers.NetworkStateTracker.getInitialState(NetworkStateTracker.java:80)
       at androidx.work.impl.constraints.trackers.NetworkStateTracker.getInitialState(NetworkStateTracker.java:50)
       at androidx.work.impl.constraints.trackers.ConstraintTracker.addListener(ConstraintTracker.java:67)
       at androidx.work.impl.constraints.controllers.ConstraintController.replace(ConstraintController.java:99)
       at androidx.work.impl.constraints.WorkConstraintsTracker.replace(WorkConstraintsTracker.java:106)
       at androidx.work.impl.background.greedy.GreedyScheduler.schedule(GreedyScheduler.java:163)
       at androidx.work.impl.Schedulers.schedule(Schedulers.java:117)
       at androidx.work.impl.WorkerWrapper.onWorkFinished(WorkerWrapper.java:362)
       at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:318)
       at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
       at java.lang.Thread.run(Thread.java:923)

-----
Similar crash only on Samsung devices OS 11

Fatal Exception: java.lang.SecurityException: Package android does not belong to 10314
       at android.os.Parcel.createExceptionOrNull(Parcel.java:2385)
       at android.os.Parcel.createException(Parcel.java:2369)
       at android.os.Parcel.readException(Parcel.java:2352)
       at android.os.Parcel.readException(Parcel.java:2294)
       at android.net.IConnectivityManager$Stub$Proxy.getNetworkCapabilities(IConnectivityManager.java:3347)
       at android.net.ConnectivityManager.getNetworkCapabilities(ConnectivityManager.java:1549)
       at androidx.work.impl.constraints.trackers.NetworkStateTracker.isActiveNetworkValidated(NetworkStateTracker.java:149)
       at androidx.work.impl.constraints.trackers.NetworkStateTracker.getActiveNetworkState(NetworkStateTracker.java:138)
       at androidx.work.impl.constraints.trackers.NetworkStateTracker.getInitialState(NetworkStateTracker.java:80)
       at androidx.work.impl.constraints.trackers.NetworkStateTracker.getInitialState(NetworkStateTracker.java:50)
       at androidx.work.impl.constraints.trackers.ConstraintTracker.addListener(ConstraintTracker.java:67)
       at androidx.work.impl.constraints.controllers.ConstraintController.replace(ConstraintController.java:99)
       at androidx.work.impl.constraints.WorkConstraintsTracker.replace(WorkConstraintsTracker.java:106)
       at androidx.work.impl.background.greedy.GreedyScheduler.schedule(GreedyScheduler.java:163)
       at androidx.work.impl.background.greedy.DelayedWorkTracker$1.run(DelayedWorkTracker.java:75)
       at android.os.Handler.handleCallback(Handler.java:938)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at android.os.Looper.loop(Looper.java:246)
       at android.app.ActivityThread.main(ActivityThread.java:8587)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:602)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130)

Caused by android.os.RemoteException: Remote stack trace:
        at android.app.AppOpsManager.checkPackage(AppOpsManager.java:7783)
        at com.android.server.ConnectivityService.getNetworkCapabilities(ConnectivityService.java:2295)
        at android.net.IConnectivityManager$Stub.onTransact(IConnectivityManager.java:1357)
        at android.os.Binder.execTransactInternal(Binder.java:1190)
        at android.os.Binder.execTransact(Binder.java:1159)

The issue has been fixed in Android S and above.

The issue is happening in Android R (11-api-30). Is there a fix for earlier versions of Android?

If it's Pixel then the fix will apply when the devices will get upgraded from R to S. For any non-Pixel devices, device manufacturers have been shared the fix, but its upto the device manufacturer to plan for and apply it to R devices.

Wanted to +1 that this is the top crash in our app as well. For now, given the circumstances, we will have to catch the error and forego this functionality which is actually important to our app. Not ideal.

+1 We see this/a similar issue in our app as well.

Fatal Exception: java.lang.RuntimeException
Unable to create application com.adeptmobile.alliance.bootstrap.AllianceApplication: java.lang.SecurityException: Package android does not belong to 10479

Caused by android.os.RemoteException
Remote stack trace: at android.app.AppOpsManager.checkPackage(AppOpsManager.java:7783) at com.android.server.ConnectivityService.ensureSufficientPermissionsForRequest(ConnectivityService.java:8546) at com.android.server.ConnectivityService.requestNetwork(ConnectivityService.java:8648) at android.net.IConnectivityManager$Stub.onTransact(IConnectivityManager.java:2051) at android.os.Binder.execTransactInternal(Binder.java:1190)

Thus this issue was fixed on Android s and above , is there any workaround for android 11(R)? I am facing similar issue...

java.lang.SecurityException: Package android does not belong to 10308
android.app.ActivityThread.handleBindApplication

I'm facing similar issue too...
On top of that, this crash is greatly reducing the crash-free rate of the app.
Is there any workaround in Android 11 except to avoid crashes with try catch?
I'm not too keen on the concern that instead of not crashing, some of the features of the app will likely be unusable.

Saying "The issue has been fixed in Android S and above." isn't really helping as the users might be stuck on OS 11 for the remainder of their device life time.

what is the fix from the framework level? Please share here.

Any workaround for this? it is happening in android OS 11

In what OS versions can we see this fix? I hope it will be backported to Android 11.
Is there any workaround for Android 11 for the time being?

Any workaround for Android below 12?