Kable's application context does not get initialized

[alongotv]

I was trying to connect to a specific Bluetooth device, but received an error saying that the applicationContext has not been initialized.

Steps to reproduce:

1. Obtain the Advertisement using Scanner().advertisements.
2. Create a Peripheral using the data from the previous step.

The stack trace: UninitializedPropertyAccessException: lateinit property applicationContext has not been initialized at com.juul.kable.KableInitializerKt.getApplicationContext(KableInitializer.kt:6) at com.juul.kable.AndroidPeripheral.<init>(Peripheral.kt:511) at com.juul.kable.PeripheralKt.peripheral(Peripheral.kt:116)

Turns out, Kable's InitializationProvider declared in the library's AndroidManifest.xml does not start for some reason. I tried analyzing the APK, and there were no traces of the InitializationProvider in the merged Manifest. Straight-up copy-pasting the provider into my application's AndroidManifest.xml did the trick. Do you have any idea why this could happen? If this is an intended behaviour, could you consider adding the Manifest Provider declaration part to the documentation? Thank you!

[twyatt]

Do you have any idea why this could happen?

Yikes, I do not know why that would happen.

If this is an intended behaviour

It is not intended behavior.

What Android version are you seeing this on? Can you also check if you're pulling in androidx.startup:startup-runtime, and if so, which version. Just want to see if maybe there was a change in AndroidX startup that might be causing this. 🤷

Not really sure, to be honest. We haven't seen this issue internally; do you happen to have a simple reproducer project that I could look at and debug?

Thanks for the issue report!

[alongotv]

Turns out, this is definenly not Kable's fault. I use WorkManager (androidx.work:work-runtime-ktx:2.6.0 – androidx.startup is a part of this library) with manual component initialization, so I had to prevent my components from initializing automatically using this: <provider android:name="androidx.startup.InitializationProvider" android:authorities="${applicationId}.androidx-startup" tools:node="remove" />

And it seems to have affected the library too. Anyway, thank you for you time, Travis! I think we can count this issue as resolved.

[alongotv]

If anybody else comes across the same issue: I am going to stick with the following solution and see how it goes:

<provider android:name="androidx.startup.InitializationProvider" android:authorities="${applicationId}.androidx-startup" android:exported="false" tools:node="merge"> <meta-data android:name="androidx.work.WorkManagerInitializer" android:value="androidx.startup" tools:node="remove" /> </provider>

[jbstewart]

I just wanted to comment that I too ran into this in an app that uses WorkManager, and adding the <provider>...</provider> block as mentioned by @alongotv did in fact fix the problem.