Android Archive Library (aar) vs jar estándar

He estado leyendo algunos artículos sobre la nueva adopción de Gradle como sistema de compilación estándar para aplicaciones de Android. Bueno, viniendo del desarrollo estándar de Java, generalmente dependo de los archivos jar para construir mi proyecto. Sin embargo, parece que Android también tiene paquetes aar , que son equivalentes a los archivos dll en un sistema operativo Windows, como se menciona aquí :

Primero, debe darse cuenta de que la plataforma Android no permite "bibliotecas compartidas" a nivel de aplicación. En las plataformas de lenguaje de programación "tradicional", C, C ++, Java, lo que sea, tenemos este mecanismo para compartir bibliotecas de tiempo de ejecución. (Por ejemplo, DLL en Windows, DSO en Unix, Jar en JVM, etc.). Sin embargo, en Android, no puede hacerlo, a menos que sea Google o un fabricante de teléfonos (consulte la Nota 1 a pie de página a continuación). Como desarrollador de aplicaciones, esto puede ser una limitación fundamental. "Compartir" o "reutilizar" códigos, tanto en tiempo de compilación como en tiempo de ejecución, es una parte muy importante de la práctica de ingeniería de software. Esto es bastante difícil (no imposible, solo más difícil) en Android debido a la limitación mencionada anteriormente.

Sin embargo, tengo algunas dudas sobre este concepto. Quiero decir, ¿cuándo debería estar interesado un desarrollador incluyendo las dependencias aar en su aplicación? ¿Estas dependencias están ajustadas a alguna versión mínima de SDK?

Por ejemplo, en un proyecto accedo a un puerto COM, para el que uso las bibliotecas .so precompiladas de NDK . ¿Tengo que crear un aar si quiero compartir esta utilidad?

AARlos archivos son más similares a Jars que a Dlls por la siguiente razón:

Dlls se pueden compartir entre aplicaciones donde los AARs y los frascos se empaquetan con su aplicación.

AARs vs Jars:

La principal diferencia entre ay Jara AARes que AARincluye recursos como layouts, drawablesetc. Esto hace que sea mucho más fácil crear componentes visuales autónomos. Por ejemplo, si tiene varias aplicaciones que usan la misma pantalla de inicio de sesión, con Jars puede compartir clases pero no el diseño, los estilos, etc., aún debe duplicarlas. Con AARs todo está incluido en un paquete ordenado.

En conclusión, los AARs son un gran paso en la dirección correcta.

Nota:
Se hicieron intentos similares con apk-libs pero ahora son obsoletos ya que AARs son mucho mejores.

La afirmación " La principal diferencia entre un Jar y un AAR es que los AAR incluyen recursos como diseños, dibujos, etc. " no corresponde a la especificación del archivo JAR y, por lo tanto, no es una verdad. Según la especificación del archivo JAR :

El archivo JAR es un formato de archivo basado en el formato de archivo ZIP popular y se utiliza para agregar muchos archivos en uno. Un archivo JAR es esencialmente un archivo zip que contiene un directorio opcional META-INF.

Como puede ver, no hay limitación de contenido que prohíba incluir recursos como diseños, diseños, etc. en un archivo JAR. Para obtener más detalles, consulte el artículo 5.3 "Creación y carga" de la especificación de máquina virtual Java®.

Entonces, sobre la pregunta Android Archive Library (aar) vs jar estándar. La respuesta depende de qué herramienta de compilación esté utilizando.

Si está utilizando Android Studio como herramienta de compilación (respectivamente como organizador de proyectos), definitivamente será mejor que use archivos * .aar para compartir recursos encapsulados entre proyectos de Android. El formato de archivo AAR es parte de la compilación de Android Studio y, como se comenta en los otros comentarios aquí, su interfaz de usuario admite el formato aar para las bibliotecas de Android.

Pero excepto Android Studio, el resto del mundo no sabe qué es ese archivo aar (artefacto). Por ejemplo, si su compilación de Android se basa en Maven, el archivo preferido para compartir recursos será jar porque ese es el artefacto nativo del proyecto Java Maven y no hay ninguna limitación sobre qué poner en el archivo jar estándar. Además, hay una manera de explicarle a Maven cualquier formato de archivo, incluido aar mediante la mejora del ciclo de vida con un nuevo componente. Un ejemplo simple está disponible aquí. ¿Cómo creo un nuevo tipo de empaque para Maven?

La cita en la pregunta no tiene nada en común con la realidad actual. Por supuesto, es posible usar bibliotecas externas en Android y hay muchas bibliotecas disponibles. Tal vez quisieron decir que cada aplicación debe agrupar todas las bibliotecas que necesita, pero reutilizar la biblioteca en el momento de la compilación (enlace estático) realmente no es un problema.

.aardifiere de .jarno más de lo que .jardifiere de .zip. Tiene ciertos conceptos en los que se deben esperar allí tipo de contenido, pero ambos .jar, y .aarmás a menudo contienen compilado clases y recursos. .aarsolo especifica que la biblioteca es específica de Android y tiene una estructura esperada, razonable para dichas bibliotecas (bueno, .jartambién tiene una estructura esperada).

La opinión de que .aar solo es compatible con Android Studio también está en desuso. Dichas bibliotecas se pueden implementar en Maven Central, y herramientas como gradle pueden hacer referencia a ellas utilizando el sufijo @aar, por ejemplo:

dependencies {
    compile ('io.github.andviane:uncover:2.0.1@aar')
    ..
}  

para hacer referencia a este despliegue central de Maven.