Apparently if you set a max SDK verison of 30 you get to use the old permissions model, but Google didn't tell anyone that years ago when this library was being written, so of course nobody magically saw the future and wrote the old code to complain if used in an app that uses too new of an SDK.
Either the library should be set to hint to the build process that it won't work on SDK versions later than 30, or else the library should be updated to do the runtime permission flow, or at least to poll for the required permissions and not try to make the forbidden calls if the app hasn't acquired them.
Thanks for pre-debugging this for us! I'm a bit puzzled, because we do have runtime permission dialogs to enable Bluetooth, but maybe the code in this library does something else on startup.
As of SDK version 31, your app will be killed (or at least not work?) if you try to use Bluetooth without requesting permissions for it at runtime: https://developer.android.com/guide/topics/connectivity/bluetooth/permissions#declare-android12-or-higher
Apparently if you set a max SDK verison of 30 you get to use the old permissions model, but Google didn't tell anyone that years ago when this library was being written, so of course nobody magically saw the future and wrote the old code to complain if used in an app that uses too new of an SDK.
Either the library should be set to hint to the build process that it won't work on SDK versions later than 30, or else the library should be updated to do the runtime permission flow, or at least to poll for the required permissions and not try to make the forbidden calls if the app hasn't acquired them.
This seems to be causing https://gitlab.com/staltz/manyverse/-/issues/2135
See also: %yYOy7KnB/KEIa/eLAjCRGvsfAXkjGGiiAPLJun1kB08=.sha256 and %Rgge2u/qxEtF4zIObUUnCZA0PjDij+E42w0OBF1JaQo=.sha256