I work on an Android app with a third-party partner. This third-party partner provides us with an SDK to power most of the functionality in our app. They always provide us with a new version of the library SDK plus a demo sample app of how to use it.
The latest version they shared works perfectly on their sample demo app, but it is giving us an error on our end. Usually, these updates are quite straightforward and just require us to bump the SDK library version number and that’s it. However, this latest version is launching a VerifyError on our app.
The error looks like this:
java.lang.VerifyError: Verifier rejected class
com.bark.centralsdk.totkit.totorchestrator.FooCore:
void com.bark.centralsdk.totkit.totorchestrator.FooCore.<init>(
android.content.Context,
kotlinx.coroutines.CoroutineScope,
com.bark.centralsdk.totkit.totorchestrator.models.FooConfig,
com.bark.centralsdk.totkit.cloudcomms.timeprovider.ticktimes.TicTakProvider)
failed to verify:
void com.bark.centralsdk.totkit.totorchestrator.FooCore.<init>(
android.content.Context,
kotlinx.coroutines.CoroutineScope,
com.bark.centralsdk.totkit.totorchestrator.models.FooConfig,
com.bark.centralsdk.totkit.cloudcomms.timeprovider.ticktimes.TicTakProvider
): [0x69B] expected to be within a catch-all for an instruction where a monitor is held (declaration of 'com.bark.centralsdk.totkit.totorchestrator.FooCore' appears in /data/app/~~XskmXtT81XvYTFEIpq7GJg==/com.bells.central.dev-RJ1CF5SRQTu7TigMxGtk9w==/base.apk!classes7.dex)
at com.bark.centralsdk.belltxkit.bellcentral.FooCore.<init>(Unknown Source:671)
at com.bark.centralsdk.belltxkit.bellcentral.FooCore.<init>(Unknown Source:4)
at com.bark.centralsdk.belltxkit.bellcentral.FooCore$Companion.᫃(Unknown Source:526)
at com.bark.centralsdk.belltxkit.bellcentral.FooCore$Companion.create(Unknown Source:11)
at com.bells.central.ApplicationClass.initFoo(ApplicationClass.kt:221)
at com.bells.central.ApplicationClass.onCreate(ApplicationClass.kt:160)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1316)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:7848)
at android.app.ActivityThread.-$$Nest$mhandleBindApplication(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2486)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:230)
at android.os.Looper.loop(Looper.java:319)
at android.app.ActivityThread.main(ActivityThread.java:9063)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:588)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1103)
The crash happens immediately during the Application class onCreate when we initialize the SDK.
The error is definitely on our end since the provider’s sample app works as expected. I have been going one by one through all the differences between both projects, I have checked that:
- We use the same compileSdk, minSdkVersion and targetSdk in both apps.
...
android {
compileSdk 34
defaultConfig {
minSdkVersion 29
targetSdk 34
versionCode 297
-
We use the same Kotlin version.
-
We use the same Gradle version:
distributionUrl=https://services.gradle.org/distributions/gradle-8.9-bin.zip
- We use the same plugins:
plugins {
id 'com.android.application' version '7.4.2' apply false
id 'com.android.library' version '7.4.2' apply false
id 'org.jetbrains.kotlin.android' version '1.7.22' apply false
}
- We use the same compile options:
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
kotlinOptions {
jvmTarget = '1.8'
}
- The build that throws this error is a debug build that isn’t minified nor obfuscated:
...
debug {
testCoverageEnabled true
minifyEnabled false
shrinkResources false
}
...
I have gone as far as to print all the dependencies I have in my app vs the latest demo version vs the previous demo version to see if they have added a new dependency that might conflict with our project:
I have also tried to enable multidex in the project, my understanding is that it shouldn’t be necessary, but just in case:
...
android {
compileSdk 34
defaultConfig {
multiDexEnabled true
minSdkVersion 29
targetSdk 34
...
It is extremely difficult to pinpoint this issue, so any feedback or any lead that might help me troubleshoot the issue will be considered a proper answer.
Note:
- If I’m posting this question here it is because we have already raised this issue to our partner, but we haven’t found a solution so far.