DocumentationAPI Reference
SDK reference · Android SDK / Android Getting Started

Troubleshooting

This page lists common build and runtime errors when integrating the Incode Android SDK, each with its cause and fix. Install the SDK if you haven't already.

Runtime Crash in androidx.compose.* (NoSuchMethodError / NoClassDefFoundError)

java.lang.NoClassDefFoundError: Failed resolution of: Landroidx/compose/material3/ExposedDropdownMenuAnchorType;

Or a java.lang.NoSuchMethodError / AbstractMethodError naming a class in androidx.compose.material3, androidx.compose.foundation, or androidx.compose.ui, thrown when a Compose screen opens. Depending on the screen, this can involve a Material3 control (a dynamic-form dropdown or date field, the CURP screen) or a more common building block such as a scrolling list or a tappable field (the phone-number input, country pickers, and most V2 screens).

Cause: The SDK's Compose screens are compiled against specific versions of androidx.compose.material3, androidx.compose.foundation, and androidx.compose.ui. Two kinds of API make this version-sensitive:

  • Some Material3 APIs the SDK uses are annotated @ExperimentalMaterial3Api, which carries no binary-compatibility guarantee, so their compiled class and method signatures can change between minor releases (for example the ExposedDropdownMenu family and DatePicker).
  • Stable Compose APIs that simply gained a parameter in a newer release. Because the SDK is compiled against the newer version, its bytecode binds the newer signature (for example LazyColumn / LazyRow / LazyVerticalGrid, which gained an overscrollEffect parameter, and Modifier.pointerInput, in Compose 1.8).

Compose reaches your app transitively, resolved by Gradle's highest-version-wins rule. If your app resolves any of these artifacts below the version the SDK was built against, the signature the SDK's bytecode calls does not exist there, the call cannot be linked at runtime, and the screen crashes.

This SDK version is built against Compose Material3 1.4.0 and Compose 1.8 (foundation / UI), so your app must resolve androidx.compose.material3 to 1.4.0 or later and androidx.compose.foundation / androidx.compose.ui to 1.8.0 or later. The two floors are coupled, since Material3 1.4.0 itself depends on Compose 1.8, so satisfying Material3 1.4.0 normally pulls a compatible Compose set automatically. Earlier SDK releases were built against Material3 1.3.2 / Compose 1.7; this requirement applies from this version onward.

Fix: In most projects nothing is required. If your app or any of its dependencies pulls Material3 1.4.0 (and therefore Compose 1.8) or newer, Gradle's highest-wins resolution already satisfies it. Act only if you have explicitly pinned Material3 or Compose below those versions:

  • Remove any resolutionStrategy.force, strict version, or dependency constraint holding androidx.compose.material3 below 1.4.0, or androidx.compose.foundation / androidx.compose.ui (or their -android artifacts) below 1.8.0.
  • If you deliberately manage Compose versions, align Material3 to 1.4.0 or newer together with a matching Compose UI / Foundation set at 1.8.0 or newer, for example via the Compose BOM.

Confirm the version your app actually resolves with:

./gradlew :app:dependencies --configuration releaseRuntimeClasspath | grep -E 'compose\.(material3|foundation|ui)'

Class Was Compiled with an Incompatible Version of Kotlin

Class 'com.incode.welcome_sdk.IncodeWelcome' was compiled with an incompatible version of Kotlin.
The binary version of its metadata is 2.2.0, expected version is 2.1.0.

Reported at build time (not at runtime) against any SDK class your code references. Unlike the runtime crash above, this error stops your app from compiling at all.

Cause: The SDK is compiled with Kotlin 2.2.21, so its classes carry Kotlin metadata version 2.2.0. The Kotlin compiler reads metadata at most one minor version ahead of its own, so a 2.0.x compiler reads metadata up to 2.1 and rejects the SDK's classes. The SDK's OkHttp and logging-interceptor 5.3.2 dependencies also ship Kotlin metadata built with 2.2.x, which compilers older than 2.2.x cannot read. The minimum Kotlin version for apps integrating this SDK version is therefore 2.2.x, and matching the SDK's own 2.2.21 or newer is recommended. The version that matters is the Kotlin compiler (Kotlin Gradle plugin) your app builds with, not the kotlin-stdlib your dependencies resolve.

Fix: Upgrade your project's Kotlin Gradle plugin to 2.2.x (2.2.21 or newer), for example:

plugins {
    id 'org.jetbrains.kotlin.android' version '2.2.21'
}

Java-only apps that do not apply the Kotlin plugin are unaffected, since the metadata check is performed only by the Kotlin compiler.

Attribute application@allowBackup Value Conflict

Attribute application@allowBackup value=(true) from AndroidManifest.xml is also present at [com.incode.sdk:welcome:x.x.x] AndroidManifest.xml value=(false).
Suggestion: add 'tools:replace="android:allowBackup"' to `<application>` element at AndroidManifest.xml to override.

Cause: Your AndroidManifest.xml sets allowBackup to true, but the SDK sets it to false.

Fix: Setting allowBackup to true is a potential security risk. Incode recommends setting it to false.

If you need to allow backups, add tools:replace="android:allowBackup" to the <application> element in your AndroidManifest.xml. If you already have attributes in tools:replace, separate them with commas.

Static Interface Methods Are Only Supported Starting with Android N

Static interface methods are only supported starting with Android N (--min-api 24): Lbutterknife/Unbinder;lambda$static$0()V
Error while dexing. The dependency contains Java 8 bytecode. Please enable desugaring by adding the following to build.gradle
android {
    compileOptions {
        sourceCompatibility 1.8
        targetCompatibility 1.8
}}

Fix: Add the following to the android{} block in your module]/build.gradle.

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
}

compileOptions {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
}

All Modules with Native Libraries Must Support the Same Set of ABIs

Execution failed for task ':app:packageDebugBundle'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
   > All modules with native libraries must support the same set of ABIs, but module 'base' supports '[X86, ARMEABI_V7A, ARM64_V8A, X86_64, MIPS, ARMEABI]' and module 'incode_core' supports '[ARMEABI_V7A, X86, X86_64, ARM64_V8A]'.
- problem when generating bundles.

Fix: Add the following NDK ABI filters to the defaultConfig{} block in your [module]/build.gradle.

ndk {
    abiFilters "arm64-v8a", "armeabi-v7a", "x86", "x86_64"
}

ndk {
    abiFilters.addAll(listOf("arm64-v8a", "armeabi-v7a", "x86", "x86_64"))
}

FATAL EXCEPTION: RxCachedThreadScheduler

E/AndroidRuntime: FATAL EXCEPTION: RxCachedThreadScheduler-2
    Process: com.incode.welcome.example, PID: 6842
    io.reactivex.exceptions.UndeliverableException: The exception could not be delivered to the consumer because it has already canceled/disposed the flow or the exception has nowhere to go to begin with. Further reading: https://github.com/ReactiveX/RxJava/wiki/What's-different-in-2.0#error-handling | java.lang.NoSuchMethodError: No virtual method log(ILjava/lang/String;Ljava/lang/Throwable;)V in class Lokhttp3/internal/platform/Platform; or its super classes (declaration of 'okhttp3.internal.platform.Platform' appears in /data/app/com.incode.welcome.example-HnCVs4pdPTZBq3BhFsJmdQ==/base.apk!classes3.dex)
        at io.reactivex.plugins.RxJavaPlugins.onError(RxJavaPlugins.java:367)
        at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:69)
        at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:57)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:301)
        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:919)
    Caused by: java.lang.NoSuchMethodError: No virtual method log(ILjava/lang/String;Ljava/lang/Throwable;)V in class Lokhttp3/internal/platform/Platform; or its super classes (declaration of 'okhttp3.internal.platform.Platform' appears in /data/app/com.incode.welcome.example-HnCVs4pdPTZBq3BhFsJmdQ==/base.apk!classes3.dex)
        at okhttp3.logging.HttpLoggingInterceptor$Logger$1.log(HttpLoggingInterceptor.java:114)
        at okhttp3.logging.HttpLoggingInterceptor.intercept(HttpLoggingInterceptor.java:173)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:100)
        at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:197)
        at okhttp3.internal.connection.RealCall.execute(RealCall.kt:148)
        at retrofit2.OkHttpCall.execute(OkHttpCall.java:186)
        at retrofit2.adapter.rxjava2.CallExecuteObservable.subscribeActual(CallExecuteObservable.java:45)
        at io.reactivex.Observable.subscribe(Observable.java:12267)
        at retrofit2.adapter.rxjava2.BodyObservable.subscribeActual(BodyObservable.java:34)
        at io.reactivex.Observable.subscribe(Observable.java:12267)
        at io.reactivex.internal.operators.observable.ObservableMap.subscribeActual(ObservableMap.java:32)
        at io.reactivex.Observable.subscribe(Observable.java:12267)
        at io.reactivex.internal.operators.observable.ObservableSubscribeOn$SubscribeTask.run(ObservableSubscribeOn.java:96)
        at io.reactivex.Scheduler$DisposeTask.run(Scheduler.java:578)
        at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:66)
        at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:57)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:301)
        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:919)

Cause: The okhttp3:okhttp dependency version does not match okhttp3:logging-interceptor or okhttp3:okhttp-urlconnection. For example, the following version mismatch causes this crash:

  • okhttp3:logging-interceptor:3.4.0
  • okhttp3:okhttp-urlconnection:3.4.1
  • okhttp3:okhttp:4.5.0

Fix: Match the versions of okhttp3:logging-interceptor and okhttp3:okhttp-urlconnection to okhttp3:okhttp. For the example above, set both to 4.5.0:

dependencies {
    ...

    implementation 'com.squareup.okhttp3:logging-interceptor:4.5.0'
    implementation 'com.squareup.okhttp3:okhttp-urlconnection:4.5.0'
}

dependencies {
    ...

    implementation("com.squareup.okhttp3:logging-interceptor:4.5.0")
    implementation("com.squareup.okhttp3:okhttp-urlconnection:4.5.0")
}

The crash also occurs if only one of logging-interceptor or okhttp-urlconnection is present and mismatched. Both must match okhttp3:okhttp.

InvalidUserCodeException: Build Was Configured to Prefer Settings

org.gradle.api.InvalidUserCodeException: Build was configured to prefer settings repositories over project repositories but repository 'maven' was added by build file 'build.gradle'

Cause: On Gradle 6.8 or later, repositories must be declared in the dependencyResolutionManagement block in settings.gradle, not in the project-level build-gradle.

Fix: Move the maven repository declaration from build.gradle to settings-gradle. See Stack Overflow for more information.

dependencyResolutionManagement {
    ...
    repositories {
        ...
        maven {
            url "https://maven.pkg.github.com/Incode-Technologies-Example-Repos/android-omni-packages"
            credentials {
                username = "incode-customers"
                password = "GITHUB_TOKEN"
            }
        }
    }
}

dependencyResolutionManagement {
    ...
    repositories {
        ...
        maven {
            url = uri("https://maven.pkg.github.com/Incode-Technologies-Example-Repos/android-omni-packages")
            credentials {
                username = "incode-customers"
                password = "GITHUB_TOKEN"
            }
        }
    }
}

A problem Occurred Evaluating Root Project

Cause: Your build was configured to prefer settings repositories over project repositories, but the google() repository was added by build-gradle.

Fix: In settings.gradle, set repositoriesMode to RepositoriesMode.PREFER_PROJECT.

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.PREFER_PROJECT)
    repositories {
        google()
        mavenCentral()
    }
}

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.PREFER_PROJECT)
    repositories {
        google()
        mavenCentral()
    }
}

Sentry Compatibility Issues

The SDK has included Sentry for crash reporting since version 5.24.0. As of version 5.39.0, the SDK uses Sentry version 7.22.6. If your project has its own Sentry integration, or another dependency includes one, you may encounter errors. The sub-sections below cover the most common failures, as well as how to disable crash reporting if needed.

Your Sentry Integration Appears Broken After Integrating the SDK

Cause: Java-based crash reporting tools rely on the ordering of Thread.UncaughtExceptionHandlers. Occasionally, crashes are not passed down handler chain correctly.

Fix: Swap the initialization order of your Sentry integration and IncodeWelcome.Builder()...build(). If the issue persists, disable SDK crash reporting.

Fatal Error During SentryAndroid.init(...) at Runtime

Cause: The following crash can occur with projects using Sentry 6.x.x.

java.lang.RuntimeException: Unable to get provider io.sentry.android.core.SentryInitProvider: java.lang.RuntimeException: Failed to initialize Sentry's SDK
...
Caused by: java.lang.RuntimeException: Failed to initialize Sentry's SDK
...
Caused by: java.lang.reflect.InvocationTargetException
...
Caused by: java.lang.NoSuchMethodError: No virtual method setEnableScopeSync(Z)V...

Fix: Upgrade to SDK 5.25.0 or newer and apply the following workaround:

  1. Exclude the Sentry library from SDK:

    implementation ('com.incode.sdk:welcome:5.25.0') { // Mandatory dependency
    exclude group: 'io.sentry', module: 'sentry' // Use this line if you're on Incode SDK version older than 5.39.0
    exclude group: 'io.sentry', module: 'sentry-android' // Use this line if you're on Incode SDK 5.39.0 or newer
}

    implementation("com.incode.sdk:welcome:5.25.0") { // Mandatory dependency 
    exclude(group = "io.sentry", module = "sentry") // Use this line if you're on Incode SDK version older than 5.39.0
    exclude(group = "io.sentry", module = "sentry-android") // Use this line if you're on Incode SDK 5.39.0 or newer
}

  2. Disable SDK crash reporting​.

Fatal Exception: java.lang.NoSuchMethodError: No virtual method getMainThreadChecker()

Cause: Projects using Sentry 8.x.x or a dependency that includes it may encounter the following crash due to breaking changes between Sentry 7.x.x and 8.x.x:

Fatal Exception: java.lang.NoSuchMethodError: No virtual method getMainThreadChecker()Lio/sentry/util/thread/IMainThreadChecker; in class Lio/sentry/SentryOptions; or its super classes (declaration of 'io.sentry.SentryOptions' appears in ...)

Fix: You have two options.

Option 1: Downgrade Sentry to 7.x.x

If your project adds Sentry 8 or later directly, remove the implementation line. The project will fall back to Sentry 7.x.x included with the SDK.

implementation 'io.sentry:sentry-android:8.x.x'

implementation("io.sentry:sentry-android:8.x.x")

If another dependency adds Sentry 8 or later, exclude it:

implementation ('other.dependency.including.sentry:8.x.x') {
    exclude group: 'io.sentry', module: 'sentry'
}

implementation("other.dependency.including.sentry:8.x.x") { // Mandatory dependency 
    exclude(group = "io.sentry", module = "sentry")
}

Option 2: Upgrade the SDK and Disable Crash Reporting

SDK 5.39.0 includes workarounds for the breaking changes between Sentry 7.x.x and 8.x.x. Upgrade to version 5.39.0 or later to prevent the crash. These workarounds prevent crashes but do not make crash reporting functional. Disable SDK crash reporting​.

Disable SDK Crash Reporting

If an issue is becoming difficult to resolve, you can disable SDK crash reporting.

IncodeWelcome.Builder()
    ...
    .setCrashReportingEnabled(false)
    .build()

new IncodeWelcome.Builder()
    ...
    .setCrashReportingEnabled(false)
    .build();

Was this page helpful?