API 34 : One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn't being registered exclusively for system broadcasts

[QuentinFarizon]

I got this crash in production after having deployed on the Play Store : java.lang.SecurityException - <package>: One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn't being registered exclusively for system broadcasts

It is found here :
https://github.com/search?q=repo%3Adon%2Fcordova-plugin-ble-central%20registerReceiver&type=code

Here is the fix :
https://stackoverflow.com/a/77276774

I could submit a PR but I don't whether it should be exported or not

[peitschie]

Thanks for this @QuentinFarizon ... I'll take a look tomorrow.

[peitschie]

Relevant documentation from Android on this:

• https://developer.android.com/develop/background-work/background-tasks/broadcasts#context-registered-receivers
• https://developer.android.com/about/versions/14/behavior-changes-14

Although these are all system broadcasts, because they're being registered via an Activity, they're effectively context-registered receivers, and thus need a RECEIVER_EXPORTED flag, as the app needs intents coming from outside the application itself (i.e., from the system).

[peitschie]

@QuentinFarizon I've published this as cordova-plugin-ble-central@1.7.5-alpha.0.
Are you able to test the changes to see if this fixes the issue for you?

[QuentinFarizon]

@peitschie I think you can use ContextCompat.registerReceiver(..., ..., Context.RECEIVER_EXPORTED) to avoid checking for versions yourself

[peitschie]

@peitschie I think you can use ContextCompat.registerReceiver(..., ..., Context.RECEIVER_EXPORTED) to avoid checking for versions yourself

I can, but only if I mandate a compile SDK version that's new enough.
I've started a draft that forces this, but that's definitely a 2.0 release as to achieve this I need to deliberately drop compatibility with a lot of older releases of the platforms.

I have a plan/patch in progress for this, but wanted to get a fix out ASAP given the impact this seems to have on Android v34.

[sithwarrior]

Hey @peitschie is this needed for the Slim variant too? As everyone else we are getting ready to target lvl 34, and we are using the slim variant, because of Android permissions

[sithwarrior]

Hey @QuentinFarizon and @peitschie Any update if this fix is needed for api level 34?

[peitschie]

Hi @sithwarrior

This particular issue only occurs if you're listening to location state on Android. The normal Bluetooth enable/disable states are fine.

Having said that, I've pushed out a 1.7.5 & 1.7.5-slim variant today, so feel free to use them. If you hit any problems, let me know.