7

There are times when I install my Android app and I get the following exception but this isn't always reproducible.

java.lang.ClassCastException: android.support.v7.widget.ContentFrameLayout cannot be cast to android.support.v7.widget.ContentFrameLayout

I am using multidex on my Android app and I read this question about Samsung devices having a bug with the multidex implementation but this happens on LG G3 running 5.1 and an HTC A9 running 6.0.

Anyone have any ideas why this is randomly happening and what can I do to fix it?

EDIT: I can't share much of the code because this is for a company I work for.

buildscript {
repositories {
    mavenCentral()
}

dependencies {
    classpath 'com.android.tools.build:gradle:1.5.0'
    classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'
}

}

apply plugin: 'com.android.application' apply plugin: 'com.neenbedankt.android-apt'

buildscript { repositories { mavenCentral() }

dependencies {
    classpath 'com.android.tools.build:gradle:1.5.0'
    classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'
}

}

apply plugin: 'com.android.application' apply plugin: 'com.neenbedankt.android-apt'

repositories { mavenCentral() maven { url 'https://repository-achartengine.forge.cloudbees.com/snapshot' } maven { url 'libs-localrepository' } }

android { buildToolsVersion "23.0.2" compileSdkVersion 23

dexOptions {
    javaMaxHeapSize "4g"
}

defaultConfig {
    minSdkVersion 18
    targetSdkVersion 23
    multiDexEnabled true
}

packagingOptions {
        exclude 'META-INF/LICENSE.txt'
        exclude 'META-INF/NOTICE.txt'
        exclude 'META-INF/LICENSE'
        exclude 'META-INF/NOTICE'
        exclude 'META-INF/ASL2.0'
        exclude 'META-INF/INDEX.LIST'
}

lintOptions {
    ignore 'ProtectedPermissions'
}

signingConfigs {

    release {
        storeFile file("somepath...")
        storePassword System.getenv("some_password")
        keyAlias "release"
        keyPassword System.getenv("some_password")
    }
}

buildTypes {

    release {
        minifyEnabled false
        proguardFile getDefaultProguardFile('proguard-android.txt')
        proguardFile 'proguard-config.txt'
    }

    debug {
        minifyEnabled false
        proguardFile getDefaultProguardFile('proguard-android.txt')
        proguardFile 'proguard-config.txt'
    }
}

dependencies {

    compile 'com.android.support:multidex:1.0.0'
    compile 'com.android.support:appcompat-v7:23.1.1'
    compile 'com.android.support:design:23.1.0'
    compile 'com.android.support:preference-v14:23.1.0'

    compile ('com.m.c:CE:1.0') {
        changing=true
    }

    compile ('com.m.c:APL:1.0') {
        changing=true
    }

    compile ('c.m.c:C:1.0') {
        changing=true
    }

    debugCompile 'ch.acra:acra:4.5.0'

    compile files('libs-gradle/aM.jar')
    compile files('libs-gradle/android-logging-log4j-m-1.0.3.jar')
    compile files('libs-gradle/ce.jar')
    compile 'com.google.android.gms:play-services-analytics:8.4.0'

    apt 'com.squareup.dagger:dagger-compiler:1.2.2'

}

}

apply plugin: 'com.google.gms.google-services'
Community
  • 1
  • 1
Juan Acevedo
  • 1,768
  • 2
  • 20
  • 39

2 Answers2

1

I found that the issue was with a flag that was set in the manifest for having a persistent process. My app is a system app loaded by the manufacturer and when an update happens, which kills the app, android os relaunches the old process thus resulting in odd behavior. My solution ended up having to change class names and android manifest components to use those new class names and let the other persistent process just hang around after the update. After the app is killed once or the phone is rebooted, those processes die and are never launched again. I also removed the flag for persistent process.

Juan Acevedo
  • 1,768
  • 2
  • 20
  • 39
0

Sometime back we faced similar kind of problem, we added 

    android {
        dexOptions {
          jumboMode = true
        }
    }

in build.gradle and extended Application class to MultiDexApplication, Please try whether this helps you.

Dinash
  • 3,027
  • 4
  • 32
  • 45
  • Thanks I will give it a try, but do you know why this is needed? The best information I have read on this but I still dont understand: https://developers.soundcloud.com/blog/congratulations-you-have-a-lot-of-code-remedying-androids-method-limit-part-1 – Juan Acevedo Mar 21 '16 at 20:58
  • Still don't understand why this is necessary, but so far I have not gotten another crash since. – Juan Acevedo Mar 24 '16 at 21:29
  • Just saw it again, so this doesn't fix the issue. The strange thing is that this happened after disabling and then re-enabling the app via setApplicationEnabledSetting, a system level permission. – Juan Acevedo Mar 29 '16 at 00:43
  • Is it the same exception? – Dinash Mar 29 '16 at 07:18
  • This is th same exception. – Juan Acevedo Apr 12 '16 at 18:44