Descripción del problema
Recientemente, al refactorizar proyectos antiguos de Android, separé las funciones relacionadas en bibliotecas de bibliotecas individuales y luego agregué dependencias a módulos de aplicaciones u otros módulos. En este momento, encontré un problema: y luego la versión de depuración empaquetada apk puede ejecutarse normalmente, mientras la versión de lanzamiento empaquetada 独立的这个library中依赖了本地的第三方提供的aar文件Informe siempre un error. (但是，如果是主项目module,如app module直接依赖本地aar是不会报错的).
En este momento, la versión de Android Studio y la versión de Gradle de mi proyecto son las siguientes:
Android Studio: Arctic Fox | 2020.3.1
Gradle:
classpath "com.android.tools.build:gradle:7.0.0"
La configuración de mi proyecto es la siguiente
En este momento, al compilar la versión de lanzamiento, ocurrió el siguiente error:
el error específico es el siguiente:
> Direct local .aar file dependencies are not supported when building an AAR. The resulting AAR would be
broken because the classes and Android resources from any local .aar file dependencies would not be
packaged in the resulting AAR. Previous versions of the Android Gradle Plugin produce broken AARs in this
case too (despite not throwing this error).
Pasos de solución
1. Cambie el modo de dependencia en el módulo de la biblioteca a compileOnly fileTree (...)
el código se muestra a continuación:
compileOnly fileTree(include: ['*.jar', '*.aar'], dir: 'libs')
2. Cambie el modo de dependencia AAR del proyecto principal a implementación fileTree (...)
El código es el siguiente (ejemplo):
implementation fileTree(include: ['*.jar', '*.aar'], dir: 'libs')
3. Copie el archivo aar en libs en la biblioteca y colóquelo en libs del proyecto principal
Luego reescriba la compilación, hasta ahora el problema está resuelto.
Resumir
Este tipo de problema de dependencia debe ser causado por el cambio de la versión del entorno. De acuerdo con la descripción del error, el método de dependencia directa anterior destruirá el archivo aar y ya no será compatible después de la versión superior. Nuestra solución es dejar la biblioteca hace que el compilador compile Al no informar un error, el archivo copiado en el proyecto principal se puede llamar normalmente después del empaquetado.
Tomó mucho tiempo resolver este problema, registrarlo, con la esperanza de ayudar a los colegas que enfrentan problemas similares.