Biblioteca de arquivos do Android (aar) x jar padrão

Eu tenho lido alguns artigos sobre a nova adoção do Gradle como o sistema de compilação padrão para aplicativos Android. Bem, vindo do desenvolvimento padrão do Java, geralmente dependo de arquivos jar para construir meu projeto. No entanto, parece que o Android também possui pacotes aar , que são equivalentes aos arquivos DLL em um sistema operacional Windows, conforme mencionado aqui :

Primeiro, você deve perceber que a plataforma Android não permite “bibliotecas compartilhadas” no nível do aplicativo. Nas plataformas “tradicionais” da linguagem de programação, C, C ++, Java, você escolhe, temos esse mecanismo de compartilhamento de bibliotecas de tempo de execução. (Por exemplo, DLL no Windows, DSO no Unix, Jar na JVM, etc.). No Android, no entanto, você não pode fazer isso, a menos que seja o Google ou um fabricante de celulares (consulte a Nota de rodapé 1 abaixo). Como desenvolvedor de aplicativos, isso pode ser uma limitação fundamental. Os códigos de "compartilhamento" ou "reutilização", tanto no tempo de construção quanto no tempo de execução, são uma parte muito importante da prática de engenharia de software. Isso é bastante difícil (não impossível, apenas mais difícil) no Android por causa da limitação acima mencionada.

No entanto, tenho algumas dúvidas sobre esse conceito. Quero dizer, quando um desenvolvedor deve estar interessado, incluindo dependências aar em sua aplicação? Essas dependências foram reforçadas para alguma versão mínima do SDK?

Por exemplo, em um projeto, acesso uma porta COM, para a qual uso as bibliotecas .so pré-compiladas do NDK . Tenho que criar um aar se quiser compartilhar este utilitário?

AARos arquivos são mais parecidos com Jars do que com Dlls pelo seguinte motivo:

Dlls podem ser compartilhados entre aplicativos nos quais AARs e jarros são empacotados com seu aplicativo.

AARs vs Jars:

A principal diferença entre a Jare a AARé que AARs incluem recursos como layouts, drawablesetc. Isso facilita muito a criação de componentes visuais independentes. Por exemplo, se você possui vários aplicativos que usam a mesma tela de login, com Jars você pode compartilhar classes, mas não o layout, estilos, etc., você ainda precisará duplicá-los. Com AARs tudo é empacotado em um único pacote.

Em conclusão, AARs são um grande passo na direção certa.

Nota:
Tentativas semelhantes foram feitas com apk-libs, mas agora estão obsoletas, pois AARs são muito melhores.

A declaração " A principal diferença entre um Jar e um AAR é que os AARs incluem recursos como layouts, drawables etc. " não corresponde à especificação do arquivo JAR e, portanto, não é uma verdade. De acordo com a especificação do arquivo JAR :

O arquivo JAR é um formato de arquivo baseado no popular formato de arquivo ZIP e é usado para agregar muitos arquivos em um. Um arquivo JAR é essencialmente um arquivo zip que contém um diretório META-INF opcional.

Como você pode ver, não há nenhuma limitação de conteúdo que proíba a inclusão de recursos como layouts, drawables etc. em um arquivo JAR. Para obter mais detalhes, consulte o artigo 5.3 "Criação e carregamento" da especificação da máquina virtual Java®.

Então, sobre a questão Android Archive Library (aar) vs jar padrão. A resposta depende de qual ferramenta de construção você está usando.

Se você estiver usando o Android Studio como uma ferramenta de criação (respectivamente como organizador do projeto), é melhor usar os arquivos * .aar para compartilhar recursos encapsulados entre projetos do Android. O formato de arquivo AAR faz parte da compilação do Android Studio e, como comentado nos outros comentários aqui, sua interface com o usuário suporta o formato aar para bibliotecas do Android.

Mas, exceto o Android Studio, o resto do mundo não sabe o que é esse arquivo aar (artefato). Por exemplo, se sua compilação do Android for baseada no Maven, o arquivo preferido para o compartilhamento de recursos será jar, porque esse é o artefato nativo do projeto java do Maven e não há limitação no que colocar no arquivo jar padrão. Além disso, existe uma maneira de explicar ao Maven qualquer formato de arquivo, incluindo aar usando o aprimoramento do ciclo de vida com um novo componente. Um exemplo simples está disponível aqui. Como crio um novo tipo de embalagem para o Maven?

A citação na pergunta não tem nada em comum com a realidade atual. Obviamente, é possível usar bibliotecas externas no Android e existem muitas bibliotecas disponíveis. Talvez eles quisessem dizer que cada aplicativo deve agrupar todas as bibliotecas de que precisa, mas a reutilização da biblioteca no momento da construção (vinculação estática) não é realmente um problema.

.aardifere de .jarnão mais do que .jardifere de .zip. Tem certos conceitos em que tipo de conteúdo deve ser esperados lá, mas ambos .jare .aarna maioria das vezes contêm compilado classes e eles recursos. .aarapenas especifica que a biblioteca é específica para Android e tem alguma estrutura esperada, razoável para essas bibliotecas (bem, .jartambém tem alguma estrutura esperada).

A exibição de que .aar é suportada apenas pelo Android studio também está obsoleta. Essas bibliotecas podem ser implantadas no Maven Central, e ferramentas como gradle podem fazer referência a elas usando o sufixo @aar, por exemplo:

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

para fazer referência a essa implantação central do Maven.