Excepción Android DEX 65k – Módulo Gradle – ¿Alguna otra Idea?

ACTUALIZAR CONTRA PREGUNTA DUPLICADA:
No quiero usar multidex. Debería haber una solución sin él, porque las classs utilizadas por ": aplicación" no necesitan este gran package de bibliotecas.

Actualmente estoy trabajando en un proyecto de networking: server de aplicaciones y aplicación cliente de Android. He terminado una versión pre-alpha del server y ahora quiero comenzar a codificar la aplicación cliente de Android.

Mi idea: quiero include el repository de git del server como un submodule de git en mi carpeta de proyectos de Android para que gradle pueda usarlo como una dependencia para mi proyecto ': app'.
PERO: el repository del server utiliza jersey restful classes. Entonces, si incluyo el proyecto de server gradle como una dependencia, la compilation de Android falla con el popular "Imposible ejecutar dex: Id. De método no en [0, 0xffff]: 65536" error: DEX 65k Problema.

Bueno, mi proyecto de cliente de Android no usa ninguna class que necesite dependencies jersey. Hay solo unas pocas classs que incluyen methods de análisis y manejo para los datos proporcionados por el server. Los he incluido en el repository del server, por lo que siempre tiene las classs de clientes correctas para la estructura del server real. Si creo un segundo repository para classs de clientes, es posible que no se sincronicen cada vez.

¿Como puedo resolver esto? Pensé en dividir el repository del server en dos modules de gradle, pero el mismo repository git.

¿¿Algunas ideas??

PD: El problema 65k: siempre incluyo classs en el proyecto de cliente de Android que solo tienen dependencies propias de Java. ¿El 65k significa methods "disponibles" o "usados"?

Usar dos modules Gradle suena como la mejor solución, si está utilizando algunas classs disponibles del server, pero no la mayoría del código del server. Java es muy liberal en el assembly de la ruta de acceso de class, poniendo a disposition todas las classs que posiblemente podrían usarse; sin embargo, esto significa que si no tiene cuidado con su ruta de class, el dexer asumirá que todas esas classs y methods deberían estar disponibles en su dispositivo y convertir mucho más de lo que realmente necesita.

También puede considerar habilitar Proguard , que puede recortar classs y methods no utilizados y methods cortos en línea. Ambos mantienen la count atrás de la class, aunque con un costo de procesamiento adicional y una configuration adicional. Especialmente deberá tener cuidado si usa el código reflection o nativo, ya que Proguard puede no ser lo suficientemente inteligente como para detectar methods que no se invocan a través de la semántica normal de llamadas de Java.


Para una explicación más detallada sobre el límite (65.536 método total y references de campo), definitivamente respaldo el enlace de Anubian Noob en los comentarios ( Cómo networkingucir el código – 65k límite de método en dex ). No debe cambiar a Multidex hasta que sea absolutamente necesario: todo el código deberá downloadse en los dispositivos (y convertido en formatting OAT en los dispositivos Lollipop y más adelante), lo que perderá time y datos si el código es estrictamente innecesario. En su lugar, introduzca el contenedor de input más pequeño posible al dexer, lo que implica dividir los modules o usar Proguard.