Proyecto de la librería Android com.android.dex.DexException: Varios archivos dex definen Lcom / google / gson / JsonSerializer

Hay dos casos que deben considerarse en

• En primer lugar, considere eliminar Gson si lo ha declarado en app / build.gradle

  Dependencies {compilar 'com.google.code.gson: gson: 2.4'}

• En segundo lugar, si no lo ha declarado en su app/build.gradle Es posible que tenga que investigar qué bibliotecas que tienen duplicados declaran la dependencia de Gson. A continuación, puede excluir el Gson de esa biblioteca. Puede que desee comprobar esto Excluyendo dependencias transitivas

Aquí, voy a proporcionar un ejemplo de excluir appcompat-v7 de una biblioteca

Ejecute este comando para ver el árbol de gráfico de dependencias

 ./gradlew app:dependencies 

Se mostrará el árbol de dependencias como el ejemplo siguiente

 | \--- com.mikepenz:materialdrawer:4.6.3 | +--- com.android.support:appcompat-v7:23.1.1 (*) | +--- com.android.support:recyclerview-v7:23.1.1 (*) | +--- com.mikepenz:materialize:0.5.1 | | \--- com.android.support:appcompat-v7:23.1.1 (*) | +--- com.mikepenz:iconics-core:2.5.3 | | \--- com.android.support:appcompat-v7:23.1.1 (*) | \--- com.android.support:support-annotations:23.1.1 

Después de encontrar la biblioteca declarada dependencia duplicada. Puede empezar a excluirlo.

 dependencies { compile("com.mikepenz:materialdrawer:4.6.3") { exclude module: 'appcompat-v7' } } 

Gradle no puede resolver magicamente este problema – puede haber diferentes versiones de la misma biblioteca en su SDK y en la aplicación del usuario – no se pueden fusionar ni diferenciar de alguna manera.

También desarrollé SDK que utilizó varias bibliotecas populares de terceros. Acabo de declarar que los utilicé y ese usuario no tiene que proporcionar los tarros para esas dependencias en su propia aplicación si él también las necesita. Creo que está bien siempre y cuando proporcione las últimas versiones de esas bibliotecas en su SDK.

1. La única buena manera de evitar colisiones que puedo pensar es cambiar nombres de clase en bibliotecas importadas – pero eso es realmente aburrido y agotador. También se puede utilizar algo como gradle shadow plugin para reubicar los paquetes, pero que parece arriesgado para mí. Se parece a esto:

shadowJar { relocate 'com.google.gson', 'shadow.com.google.gson' }

2. También su desarrollador puede unjar su biblioteca, quitar gson y re-jar de nuevo. Pero si usa otra versión de gson, su biblioteca puede romperse.

3. Oh, sí, también puedes distribuir tu SDK como fuente, no como JAR – entonces los usuarios podrán agregarlo dentro de su aplicación y usar cualquier librería que quieran. Pero por lo general no desea poner el código de su SDK en público (incluso a través de frascos de la biblioteca son muy fáciles de revertir …).

La opción –multi-dex a dx es incompatible con proyectos de biblioteca pre-dexing. Por lo tanto, si su aplicación utiliza proyectos de biblioteca, debe desactivar el predexing antes de poder utilizar –multi-dex.

O

Actualice su IDE

Si eliminar GSON no es una opción para usted, pruebe el soporte multidex de enablin en su archivo build.gradle :

 android { ... ... defaultConfig { ... ... // Enabling multidex support. multiDexEnabled true } }