Todo app Android tem um ID do aplicativo exclusivo que se parece com um nome de pacote Java, como com.example.myapp. Esse ID identifica o app de modo exclusivo no dispositivo e na Google Play Store. Se você quiser fazer upload de uma nova versão do app, o ID do aplicativo (e o certificado de assinatura) precisará ser o mesmo do artefato original. Se você mudar o ID do aplicativo, a Google Play Store tratará o upload como um app completamente diferente. Então, depois de publicar o app, não mude o ID do aplicativo.
O ID do aplicativo é definido pela propriedade applicationId
no
arquivo build.gradle
do módulo, como mostrado abaixo:
Groovy
android { defaultConfig { applicationId "com.example.myapp" minSdkVersion 15 targetSdkVersion 24 versionCode 1 versionName "1.0" } ... }
Kotlin
android { defaultConfig { applicationId = "com.example.myapp" minSdkVersion(15) targetSdkVersion(24) versionCode = 1 versionName = "1.0" } ... }
Quando você cria um novo projeto no Android Studio, o applicationId
é exatamente
igual ao nome de pacote estilo Java que você escolheu na etapa de configuração. No entanto, o
ID do aplicativo e o nome do pacote são independentes além desse ponto.
Você pode mudar o nome de pacote do seu código (o namespace do código) sem
afetar o ID do aplicativo e vice-versa. No entanto, como já explicamos, não é possível mudar
o ID do aplicativo depois de publicar o app. Mudar o nome do pacote
tem outras consequências que você precisa considerar, então consulte a seção sobre
como fazer essa mudança.
E, embora o ID do aplicativo pareça um nome de pacote Java tradicional, as regras de atribuição de nome dele são um pouco mais restritivas:
- Ele precisa ter pelo menos dois segmentos (um ou mais pontos).
- Cada segmento precisa começar com uma letra.
- Todos os caracteres precisam ser alfanuméricos ou um sublinhado [a-zA-Z0-9_].
Observação: o ID do aplicativo costumava ser diretamente vinculado ao
nome do pacote do código. Por isso, algumas APIs Android usam o termo "package name" (nome do pacote) nos
nomes de métodos e de parâmetros delas, mas esse é, na verdade, o ID do
aplicativo. Por exemplo, o método Context.getPackageName()
retorna o ID do aplicativo.
Não é necessário compartilhar o verdadeiro nome do pacote do código fora do
código do app.
Cuidado: se você estiver usando WebView
,
considere usar o nome do pacote como um prefixo no ID do aplicativo, ou
você poderá enfrentar problemas, conforme descrito no
problema 211768.
Alterar o ID do aplicativo para variantes de build
Ao criar um APK ou AAB para o app, as ferramentas de compilação marcam o app com o
ID do aplicativo definido no bloco defaultConfig
do arquivo build.gradle
,
como mostrado abaixo. No entanto, se você quiser criar versões diferentes do app
para aparecerem como listagens separadas na Google Play Store, como uma versão "free" (grátis) e uma "pro" (avançada),
será necessário criar variantes de build
separadas, cada uma com um ID do aplicativo
diferente.
Nesse caso, cada variante de build precisa ser definida como uma variação de produto
diferente. Para cada variação
dentro do bloco productFlavors
, é possível redefinir a propriedade
applicationId
ou anexar um segmento ao ID do aplicativo padrão
usando applicationIdSuffix
, como demonstrado abaixo:
Groovy
android { defaultConfig { applicationId "com.example.myapp" } productFlavors { free { applicationIdSuffix ".free" } pro { applicationIdSuffix ".pro" } } }
Kotlin
android { defaultConfig { applicationId = "com.example.myapp" } productFlavors { create("free") { applicationIdSuffix = ".free" } create("pro") { applicationIdSuffix = ".pro" } } }
Dessa forma, o ID do aplicativo para uma variação de produto "free" é "com.example.myapp.free".
Você também pode usar applicationIdSuffix
para anexar um segmento de acordo com o
tipo de build da seguinte forma:
Groovy
android { ... buildTypes { debug { applicationIdSuffix ".debug" } } }
Kotlin
android { ... buildTypes { getByName("debug") { applicationIdSuffix = ".debug" } } }
Como o Gradle aplica a configuração do tipo de build de acordo com a variação do produto, o ID do aplicativo para a variante de build "free debug" (depuração grátis) agora é "com.example.myapp.free.debug". Isso é útil quando se quer ter o build de depuração e de lançamento no mesmo dispositivo, porque dois apps nunca podem ter o mesmo ID do aplicativo.
Para apps legados que são distribuídos usando APKs no Google Play (criados antes de agosto
de 2021), se você quiser usar a mesma página "Detalhes do app" para distribuir vários APKs voltados
a diferentes configurações de dispositivo (como o nível da API),
você precisa usar o mesmo ID do aplicativo para cada variante de build, mas dar a cada
APK um versionCode
diferente. Para mais
informações, leia sobre
Suporte a vários APKs. A publicação
com AABs não é afetada, porque usa um único artefato com um único
código de versão e ID do aplicativo por padrão.
Cuidado: para compatibilidade com Ferramentas do SDK anteriores, se
você não definir a propriedade applicationId
no
arquivo build.gradle
, as ferramentas de compilação usarão o nome do pacote do
arquivo AndroidManifest.xml
como o ID do aplicativo. Nesse caso,
a refatoração do nome de pacote também muda o ID do aplicativo.
Dica: se você precisar fazer referência ao ID do aplicativo no
arquivo de manifesto, use o marcador ${applicationId}
em qualquer
atributo do manifesto. Durante uma compilação, o Gradle substitui essa tag pelo
ID do aplicativo. Para saber mais, acesse Injetar variáveis de compilação no
manifesto.
Mudar o ID do aplicativo para testes
Por padrão, as ferramentas de compilação aplicam um ID do aplicativo ao seu
APK de teste de instrumentação
usando o ID do aplicativo para a variante de build em questão, que contém
.test
no nome. Por exemplo, um APK de teste da variante de compilação
com.example.myapp.free
tem com.example.myapp.free.test
como ID do aplicativo.
Embora não seja necessário, você pode mudar o ID do aplicativo definindo
a propriedade testApplicationId
no bloco defaultConfig
ou
productFlavor
.
Mudar o nome do pacote
Embora o nome de pacote do seu projeto seja igual ao ID do aplicativo por padrão, é
possível mudá-lo. Porém, se você quiser mudar o nome do pacote, esse nome,
conforme definido pela estrutura de diretórios do projeto, precisa sempre ser igual
ao atributo package
no arquivo AndroidManifest.xml
, conforme mostrado
a seguir:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.myapp"
android:versionCode="1"
android:versionName="1.0" >
As ferramentas de compilação do Android usam o atributo package
para duas coisas:
- Aplicar esse nome como o namespace para a classe
R.java
gerada pelo app.Exemplo: com o manifesto acima, a classe
R
serácom.example.myapp.R
. - Usá-lo para resolver nomes de classe relativos declarados no
arquivo de manifesto.
Exemplo: com o manifesto acima, uma atividade declarada como
<activity android:name=".MainActivity">
é resolvida comocom.example.myapp.MainActivity
.
Sendo assim, o nome no atributo package
precisa sempre ser igual ao nome do pacote básico do seu projeto,
onde você mantém as atividades e o resto do código do app. É claro,
você pode ter subpacotes no projeto, mas, se esse for o caso, esses arquivos precisam
importar a classe R.java
usando o namespace do atributo package
e
todos os componentes do aplicativo declarados no manifesto precisam adicionar os nomes de subpacote
que faltam (ou usar nomes de pacote totalmente qualificados).
Se você quiser refatorar o nome do pacote completamente, não deixe de atualizar o
atributo package
também. Desde que você use as ferramentas do Android Studio para renomear
e refatorar os pacotes, eles permanecerão sincronizados automaticamente. Se eles
não permanecerem sincronizados, o código do app não poderá resolver a classe R
,
porque ela não estará mais no mesmo pacote, e o manifesto não identificará suas
atividades ou outros componentes.
Você precisa sempre especificar o atributo package
no arquivo AndroidManifest.xml
principal
do projeto. Se você tiver outros arquivos de manifesto, como para uma
variação de produto ou um tipo de build, verifique se o nome do pacote fornecido pelo
arquivo de manifesto de maior prioridade é sempre usado no manifesto integrado final.
Para saber mais, leia
Integrar vários arquivos de manifesto.
Mais uma coisa: embora você possa ter um nome diferente
para o manifesto de package
e o applicationId
do Gradle, as ferramentas de compilação copiam o ID do aplicativo para o arquivo de manifesto final do app ao término da compilação. Então, se você inspecionar
o arquivo AndroidManifest.xml
após uma compilação, não se surpreenda se o
atributo package
tiver mudado. O atributo package
é o que a Google Play Store e a plataforma Android realmente buscam para identificar
seu app. Por isso, depois que a compilação tiver usado o valor original (para atribuir um namespace à classe
R
e resolver nomes de classe do manifesto), ela descartará esse valor
e passará a usar o ID do aplicativo.