ClassNotFoundException: com.braintreepayments.api.dropin.DropInRequest

General information

• SDK/Library version: API 27 | Braintree Android 2.6.2/Drop-in 3.1/Card 5.1.1
• Gradle version: 4.4.1
• Environment: Sandbox
• Android Version and Device: Galaxy S7/7.0

Issue description

I’m working with this library in relation to the cordova-plugin-braintree library. Building the app works great, but when I tap on the drop-in UI, the app crashes and I see the following in the logs:

Class not found when unmarshalling: com.braintreepayments.api.dropin.DropInRequest
ClassNotFoundException: com.braintreepayments.api.dropin.DropInRequest

Here’s the gradle file for the plugin:

def packageName = getPackageName()

android {
    defaultConfig {
        applicationId packageName
    }
}

dependencies {
    compile 'com.braintreepayments.api:braintree:2.3.12'
    compile 'com.braintreepayments.api:drop-in:3.0.1'
    compile 'io.card:android-sdk:5.4.1'
}

def getPackageName() {
    def config = file("res/xml/config.xml").getText()
    def xml = new XmlParser(false, false).parseText(config)
    return xml.attribute("id")
}

I realize that this may not be directly related to the SDK, so just hoping for some pointers on what I might look for. Appreciated!

[codinronan]

Yep we recently stopped supporting anything older than Android 4.4 so that helps immensely.

[codinronan]

@jamesdixon hey dude so in and amongst trying to figure out why the latest Android SDK was causing a severe crash in android.support, I saw this error as well but it never actually causes the app to crash.

I believe - I don’t know for sure but I believe - that this is not a real error, caused by Cordova itself and the way it marshalls the object calls back and forth between native and the webview. The reason it doesn’t matter is because the Braintree Drop-In native code already knows about the class type so it is properly reconstructed on the other side; the class name cordova gives it is just a suggestion. I’m not sure the actual source of the error but I noticed that when the error occurs is long before the DropIn itself is actually invoked.

Anyway, it works beautifully with my latest changes over in the PR on Taraque’s repo, so even if it continues to be thrown we can ignore it.