web-dev-qa-db-fra.com

Impossible d'ajuster les classes demandées dans un seul fichier dex, même pour les validations antérieures qui précédemment compilées correctement

Je viens donc d'atteindre la limite maximale de nombre de méthodes pour mon projet Android, qui ne parvient pas à générer avec le message d'erreur suivant:

Erreur: null, impossible de placer les classes demandées dans un seul fichier dex (méthodes #: 117407> 65536)

Je comprends ce que signifie le message et comment le résoudre (exécuter proguard, activer le multidex, etc.). Mon problème est que je ne comprends pas pourquoi je reçois soudainement ce message - je faisais en supprimant de vieux morceaux de code qui étaient redondants, puis je construisais, et maintenant je reçois ce message.

Question 1: Comment est-il possible que mon nombre de méthodes (117407 selon le message d'erreur) soit soudainement massivement au-dessus de la limite (65536), même si je n'ai ajouté aucune dépendance de bibliothèque? En fait, j'ai supprimé du code, et tout à coup, j'ai comme 50 000 méthodes de trop?

Maintenant, c'est là que ça devient vraiment bizarre: je voulais analyser l'APK pour déterminer la cause du problème, mais bien sûr, je ne peux pas le construire. Donc, au lieu d'activer le multidex, j'ai décidé de ramener mon code à hier (ce qui a certainement bien fonctionné hier - j'ai l'application sur mon téléphone pour le prouver!), Mais je toujours obtenez ce message d'erreur de génération. Je ne comprends pas comment cela est possible. J'ai essayé de revenir à il y a plusieurs jours, la même chose (clonage d'un nouveau dépôt et vérification d'un commit précédent).

Donc, question 2: Comment puis-je obtenir cette erreur de construction pour le même code exact qui hier s'est bien construit sans erreur?

La seule chose à laquelle je peux penser, c'est qu'une bibliothèque que j'utilise comme dépendance a soudainement augmenté de taille - mais je déclare des versions spécifiques de tout dans ma version gradle, par exemple:

// RxJava
implementation 'io.reactivex.rxjava2:rxandroid:2.1.0'
implementation 'io.reactivex.rxjava2:rxjava:2.2.4'

// Retrofit
implementation 'com.squareup.retrofit2:retrofit:2.5.0'
implementation 'com.squareup.retrofit2:converter-gson:2.5.0'

Alors, sûrement mes dépendances n'auraient pas dû changer?

Toutes les idées que je peux faire pour comprendre cela sont grandement appréciées. J'ai essayé de nettoyer mon projet et d'invalider les caches/redémarrages dans Android studio. Je ne veux vraiment pas activer le multidex ou devoir exécuter proguard sur ma version de débogage.

Voici le build.gradle complet:

apply plugin: 'com.Android.application'
apply plugin: 'kotlin-Android'
apply plugin: 'kotlin-Android-extensions'
apply plugin: 'kotlin-kapt'

Android {
    compileSdkVersion 28
    defaultConfig {
    applicationId "XXXXXXXXX"
    minSdkVersion 19
    targetSdkVersion 28
    versionCode 1
    versionName "0.1"
    testInstrumentationRunner "Android.support.test.runner.AndroidJUnitRunner"
    vectorDrawables.useSupportLibrary = true  // see https://developer.Android.com/studio/write/vector-asset-studio#sloption
}
buildTypes {
    release {
        minifyEnabled false
        // Do code shrinking!
        proguardFiles getDefaultProguardFile('proguard-Android.txt'), 'proguard-rules.pro'
    }
}
}

dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])

// Core stuff
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
implementation 'com.Android.support:appcompat-v7:28.0.0'
implementation 'com.Android.support:recyclerview-v7:28.0.0'
testImplementation 'junit:junit:4.12'
androidTestImplementation 'com.Android.support.test:runner:1.0.2'
androidTestImplementation 'com.Android.support.test.espresso:espresso-core:3.0.2'
implementation 'Android.Arch.lifecycle:extensions:1.1.1'
implementation 'com.Android.support:design:28.0.0'
implementation 'com.Android.support:support-vector-drawable:28.0.0'
implementation 'com.google.Android.gms:play-services-wearable:16.0.1'

// Dagger
implementation 'com.google.dagger:dagger:2.21'
kapt 'com.google.dagger:dagger-compiler:2.21'
// Dagger for Android
implementation 'com.google.dagger:dagger-Android:2.21'
implementation 'com.google.dagger:dagger-Android-support:2.21' // if you use the support libraries
kapt 'com.google.dagger:dagger-Android-processor:2.21'

// Constraint layout
implementation 'com.Android.support.constraint:constraint-layout:1.1.3'

// Associated WearOS project
wearApp project(':wear')

// Common library project
implementation project(':common')

// These were added to resolve gradle error on the 'com.Android.support:appcompat-v7:28.0.0' implementation:
// All com.Android.support libraries must use the exact same version specification (mixing versions can lead to
// runtime crashes). Found versions 28.0.0, 26.1.0. Examples include com.Android.support:animated-vector-drawable:28.0.0
// and com.Android.support:support-media-compat:26.1.0
// This seems to be related to linking the wear project. If the wear project was not linked, the error went away.
implementation 'com.Android.support:support-media-compat:28.0.0'
implementation 'com.Android.support:support-v4:28.0.0'

// RxJava
implementation 'io.reactivex.rxjava2:rxandroid:2.1.0'
implementation 'io.reactivex.rxjava2:rxjava:2.2.4'

// Retrofit
implementation 'com.squareup.retrofit2:retrofit:2.5.0'
implementation 'com.squareup.retrofit2:converter-gson:2.5.0'
// Retrofit RxJava
implementation 'com.squareup.retrofit2:adapter-rxjava2:2.5.0'
// Retrofit logging:
implementation 'com.squareup.okhttp3:logging-interceptor:3.12.1'

// Room
def room_version = "1.1.1"
implementation "Android.Arch.persistence.room:runtime:$room_version"
implementation "Android.Arch.persistence.room:common:$room_version"
implementation "Android.Arch.persistence.room:rxjava2:$room_version"
kapt "Android.Arch.persistence.room:compiler:$room_version"

// For modern time handling (Java.time requires API 26 or higher)
implementation 'com.jakewharton.threetenabp:threetenabp:1.1.1'

// Graphing
implementation 'com.github.PhilJay:MPAndroidChart:v3.1.0-alpha'

// Dropbox
implementation 'com.dropbox.core:dropbox-core-sdk:3.0.11'

// OpenCSV
implementation 'com.opencsv:opencsv:4.5'

}

MODIFIER

Ainsi, après avoir activé le multidex, certaines dépendances importantes apparaissent sous les TLD suivants lorsque j'analyse l'APK à l'aide de Android Studio (je ne suis pas sûr de devoir regarder les numéros de méthode définis ou référencés). ?):

  • com.dropbox: 26000 méthodes définies, 34000 méthodes référencées
  • com.Android (principalement les bibliothèques de support): 18700 définis, 24600 référencés
  • org.Apache (communs, journal, etc.): 15000 définis, 15700 référencés

Ceux-ci seuls me portent à la limite. Je ne comprends toujours pas pourquoi cela se produit soudainement :( Sûrement si je n'ai pas ajouté de bibliothèques, ces chiffres n'auraient pas dû changer?

8
James Allen

Après avoir regardé l'intégralité de votre fichier de build, votre problème découle définitivement de vos dépendances! Essayez de les nettoyer et d'en supprimer autant que vous ne les utilisez pas. Il est probable que vous étiez très proche de la limite et l'une de ces dépendances peut avoir été mise en cache à l'aide d'anciennes versions. Vous pouvez essayer de supprimer l'intégralité du dossier de construction (et nettoyer votre cache Gradle) mais je suis assez certain que le problème ne disparaîtra pas.

Si toutes ces dépendances sont nécessaires, vous devrez malheureusement suivre les routes que vous avez mentionnées, soit en multi-dex, soit en minimisant les versions de débogage. Le multi-dex devrait être correct et ne devrait pas causer de problèmes imprévus tandis que la réduction ralentirait vos builds et pourrait causer l'instabilité de Android Studio (en particulier les changements d'exécution/d'application instantanés!)

Bonne chance, une chose à retenir de cela est de garder vos dépendances propres et précises, ne les ajoutez qu'en cas de besoin absolu, et si tout le reste échoue, le multi-dex est votre ami.

3
Andres S

Ajoutez simplement ceci à votre gradle (Module: app) >> multiDexEnabled true

Android {
    defaultConfig {
        ...
        minSdkVersion 21 
        targetSdkVersion 28
        multiDexEnabled true
    }
    ...
}

puis Reconstruire le projet dans le menu, cliquez sur => Créer> Reconstruire le projet.

7
Driss Baidou

Après avoir lu votre question, je ne peux que suggérer d'essayer d'invalider le cache et de redémarrer après et de forcer le rafraîchissement de votre dépendance en utilisant ceci.

./gradlew build --refresh-dependencies
0
End User

Comme votre problème, j'ai dû supprimer le dossier build et le *.iml fichiers (fichiers de projet Android Studio) y J'ai dû recréer le projet, puis la construction et tout a bien fonctionné à nouveau.

0
Jairo Martínez

dans l'application build.gradle

implementation 'com.Android.support:multidex:2.0.1'

Android {
    multiDexEnabled true

}

0
Mohamed Maher

J'ai rencontré le même problème et la solution consistait à activer Instant Run sous Fichier -> Paramètres -> Build, Execution, Deployment -> Instant Run et cela a résolu mon problème. J'espère que c'est utile.

0
ali sampson

J'ai essayé ça. espère que cela aide, l'a trouvé sur une documentation (oublié l'url :()

build.gradle app

dependencies {...
grdef multidex_version ='2.0.1'

implementation "androidx.multidex:multidex:$multidex_version"
}...
0
Rudy Rosa

Je recommanderais de créer l'application avec multidex, puis d'extraire les identifiants de méthode des multiples fichiers dex de la nouvelle apk, et également d'extraire les id de méthode de l'ancienne apk single-dex et de comparer les deux listes.

grosso modo, quelque chose comme:

baksmali list dex new.apk
baksmali list method new.apk/classes.dex > new.list
baksmali list method new.apk/classes2.dex >> new.list
sort new.list > new.sorted.list

baksmali list method old.apk > old.list
diff new.sorted.list old.list

Cependant, si vous utilisez proguard, vous devrez peut-être trouver un moyen d'appliquer le changement de nom de proguard inverse avant de comparer les listes.

0
JesusFreke