Esta página descreve as propriedades e opções necessárias para preparar seu projeto da biblioteca Android para publicação usando o Plug-in do Android para Gradle (AGP). Mesmo que você tenha definido algumas dessas propriedades no início da criação da biblioteca, revise as orientações a seguir para otimizar as configurações.
Escolher um namespace
As bibliotecas do Android precisam declarar um namespace para gerar uma classe R
exclusiva quando os recursos são compilados. Esse namespace precisa corresponder
ao pacote de classes raiz da biblioteca para evitar confusão quando os usuários importam classes
regulares da biblioteca e da própria classe R
.
No AGP 7.0 e mais recentes, você pode definir o
namespace
no arquivo build.gradle
do app, conforme mostrado no exemplo de código a seguir.
Groovy
android { namespace = 'com.example.library' }
Kotlin
android { namespace = "com.example.library" }
O namespace é uma propriedade da biblioteca voltada para o desenvolvedor. Ele não está
relacionado à identidade do aplicativo, que é definida usando a
propriedade
applicationId
.
Nas versões anteriores do AGP, as propriedades applicationId
(para um
app) e namespace
(para uma biblioteca) podiam ser definidas usando o
atributo package
do manifesto, o que causava confusão.
Escolher um valor de minSdkVersion
A escolha de uma minSdkVersion
para
sua biblioteca é um aspecto importante da publicação. A
minSdkVersion
precisa refletir a versão mínima do Android com suporte ao
código.
Esteja ciente das seguintes considerações ao escolher uma minSdkVersion
:
Escolher um valor baixo para
minSdkVersion
geralmente permite uma distribuição mais ampla da biblioteca.O código de uma biblioteca geralmente não é executado, a menos que o app o chame explicitamente. Ainda é possível executar um app em uma versão do Android anterior à exigida por uma dependência de biblioteca (quando a biblioteca não é essencial para a funcionalidade principal do app) com verificações durante a execução antes de chamar a biblioteca. Portanto, defina uma
minSdkVersion
baixa o suficiente para que a biblioteca possa ser incorporada a apps e chamada quando possível para ajudar a alcançar mais usuários.Escolher uma
minSdkVersion
alta pode impedir que os aplicativos usem a biblioteca.A integração de manifestos, que é uma etapa do AGP que integra arquivos de manifesto do app e das dependências, garante que nenhuma dependência tenha uma
minSdkVersion
mais alta que o app.Escolher uma
minSdkVersion
alta pode fazer com que os desenvolvedores desativem as verificações de segurança da integração de manifestos, causando problemas no processo de build.Como a integração de manifestos impede que os projetos do app incluam bibliotecas com uma
minSdkVersion
mais alta que o próprio app, os desenvolvedores podem acabar desativando as verificações de segurança para minimizar erros de build. No entanto, isso pode causar problemas de compatibilidade.Escolher uma
minSdkVersion
alta pode ser necessário em casos especiais em que o manifesto de uma biblioteca inclui um broadcast receiver ou algum outro mecanismo que aciona o código automaticamente.Nesses casos, escolher uma
minSdkVersion
alta garante que o código seja executado. Como alternativa, é possível desativar o comportamento automatizado para que o app ative a execução da biblioteca depois de fazer as verificações corretas.
Para permitir a incorporação em apps, use a
anotação RequiresApi
na sua
biblioteca para indicar aos autores da chamada que eles precisam fazer verificações no momento da execução. O Android
Lint usa as informações do RequiresApi
para fazer as inspeções. Para ver mais recursos
sobre o uso de anotações para melhorar o código de API e suas APIs no geral, consulte Melhorar a inspeção
de código com anotações.
Configurar metadados de arquivos AAR
Uma biblioteca do Android é empacotada na forma de um arquivo ARchive do Android (AAR). Os metadados de arquivos AAR consistem em propriedades que ajudam o AGP a consumir bibliotecas. Se a biblioteca for consumida por uma configuração incompatível e os metadados de AAR estiverem configurados, os usuários receberão uma mensagem de erro para ajudar a resolver o problema.
Escolher um valor de minCompileSdk
A partir da versão 4.1, o AGP oferece suporte
a minCompileSdk
.
Isso indica o mínimo de
compileSdk
que
os projetos de consumo podem usar. Se a biblioteca contiver entradas de manifesto ou
recursos que usem atributos de plataforma mais recentes, será necessário
definir esse valor.
O valor minCompileSdk
pode ser definido nos blocos defaultConfig{}
,
productFlavors{}
e buildTypes{}
no arquivo build.gradle
do módulo.
Groovy
android { defaultConfig { aarMetadata { minCompileSdk = 29 } } productFlavors { foo { ... aarMetadata { minCompileSdk = 30 } } } }
Kotlin
android { defaultConfig { aarMetadata { minCompileSdk = 29 } } productFlavors { register("foo") { ... aarMetadata { minCompileSdk = 30 } } } }
Se você definir minCompileSdk
em vários locais, o Gradle priorizará os locais
de configuração da seguinte maneira durante o processo de build:
buildTypes{}
productFlavors{}
defaultConfig{}
No exemplo anterior, em que minCompileSdk
é definido em
defaultConfig{}
e productFlavors{}
, productFlavors{}
é priorizado,
e minCompileSdk
é definido como 30.
Para saber mais sobre como o Gradle prioriza as configurações ao combinar códigos e recursos, consulte Criar com conjuntos de origem.
Ativar recursos de teste
Os recursos de teste normalmente são usados para configurar o código que está sendo testado ou facilitar os testes de um componente. A partir da versão 7.1, o AGP pode criar recursos de teste para projetos de biblioteca, além de projetos de aplicativos e recursos dinâmicos.
Ao publicar uma biblioteca para outras pessoas consumirem, crie recursos de teste
para sua API. Eles podem ser ativados no arquivo build.gradle
do módulo:
Groovy
android { testFixtures { enable = true } }
Kotlin
android { testFixtures { enable = true } }
Quando você ativa os recursos de teste, o Gradle cria automaticamente um
conjunto de origem src/testFixtures
em que eles podem ser gravados.
Para saber mais, consulte a documentação do Gradle sobre como usar recursos de teste.