sintaxe:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="string"
          android:sharedUserId="string"
          android:sharedUserLabel="string resource" 
          android:versionCode="integer"
          android:versionName="string"
          android:installLocation=["auto" | "internalOnly" | "preferExternal"] >
    . . .
</manifest>

contido em:
nenhum

precisa conter:
<application>
pode conter:
<compatible-screens>
<instrumentation>
<permission>
<permission-group>
<permission-tree>
<queries>
<supports-gl-texture>
<supports-screens>
<uses-configuration>
<uses-feature>
<uses-permission>
<uses-permission-sdk-23>
<uses-sdk>

descrição:
O elemento raiz do arquivo AndroidManifest.xml. Ele precisa conter um elemento <application> e especificar os atributos xmlns:android e package.
atributos:
xmlns:android
Define o namespace do Android. Esse atributo precisa sempre ser definido como "http://schemas.android.com/apk/res/android"
package
Um nome de pacote completo em estilo Java para o app Android. O nome pode conter letras maiúsculas ou minúsculas (de "A" até "Z"), números e sublinhados ("_"). No entanto, as partes do nome do pacote só podem começar com letras.

Ao criar o app em um pacote de apps (APK), o sistema de compilação usa o atributo package para duas coisas:

  • Aplicar esse nome como o namespace para a classe R.java gerada do app, que é usada para acessar os recursos do app.

    Por exemplo, se package for definido como "com.example.myapp", a classe R vai ser criada em com.example.myapp.R.

  • Ele usa esse nome para resolver quaisquer nomes de classe relativos que são declarados no arquivo de manifesto.

    Por exemplo, se package for definido como "com.example.myapp", uma atividade declarada como <activity android:name=".MainActivity"> vai ser resolvida como com.example.myapp.MainActivity.

Esse também é o nome padrão do processo do app. Consulte o atributo process do elemento <application>. Ele é a afinidade de tarefa padrão para as atividades. Consulte o atributo taskAffinity do elemento <activity>.

Esse nome também representa o ID do aplicativo, que precisa ser universalmente exclusivo para publicar o app no Google Play. No entanto, ao término do processo de compilação do APK, as ferramentas de build substituem o nome package usando a propriedade applicationId do arquivo build.gradle, usado por projetos do Android Studio. Contanto que você mantenha o nome package do manifesto igual ao applicationId do arquivo de build, isso não vai ser um problema. Mas se esses dois valores forem diferentes, você precisa entender as diferenças entre o "nome do pacote" e o "ID do aplicativo" lendo como definir o ID do aplicativo.

Para evitar conflitos com outros desenvolvedores, use a propriedade do domínio da Internet como base para os nomes dos pacotes (na ordem inversa). Por exemplo, os apps publicados pelo Google começam com com.google.

Observação: os namespaces com.example e com.android são proibidos pelo Google Play.

Se você quiser mudar o nome do seu pacote depois da publicação, isso é possível, mas você precisa manter o mesmo applicationId. O applicationId define a identidade exclusiva do app no Google Play. Portanto, se você mudar o ID, o APK vai ser considerado um app diferente, e os usuários da versão anterior não vão receber uma atualização. Para mais informações, veja como definir o ID do aplicativo.

android:sharedUserId

Esta constante foi descontinuada no nível 29 da API.
Os IDs de usuário compartilhados causam um comportamento não determinista no gerenciador de pacotes. Sendo assim, o uso deles não é recomendado e pode ser removido em uma versão futura do Android. Em vez disso, os apps precisam usar mecanismos de comunicação adequados, como serviços e provedores de conteúdo, para facilitar a interoperabilidade entre os componentes compartilhados. Os aplicativos existentes não podem remover esse valor, já que não é possível migrar um ID do usuário compartilhado.

O nome de um ID de usuário do Linux que vai ser compartilhado com outros apps. Por padrão, o Android atribui a cada app o próprio ID de usuário único. No entanto, se esse atributo for definido com o mesmo valor para dois ou mais apps, todos eles vão compartilhar o mesmo ID, desde que os conjuntos de certificados deles sejam idênticos. Apps com o mesmo ID de usuário podem acessar os dados uns dos outros e, se desejado, ser executados no mesmo processo.

android:targetSandboxVersion
O sandbox de destino que vai ser usado por este app. Quanto maior o número da versão do sandbox, maior o nível de segurança. O valor padrão é 1. Você também pode o definir como 2. A definição desse atributo como 2 alterna o app para outro sandbox SELinux.

As restrições abaixo se aplicam a um sandbox de nível 2:

  • O valor padrão de usesCleartextTraffic na configuração de segurança da rede é falso.
  • O compartilhamento de Uid não é permitido.

Para Instant Apps Android destinados ao Android 8.0 (nível 26 da API) ou versões mais recentes, esse atributo precisa ser definido como 2. Você pode definir o nível do sandbox na versão instalada do app para o nível menos restritivo 1, mas se fizer isso, o app não vai manter os dados do app instantâneo na versão instalada. É necessário definir o valor do sandbox do app instalado como 2 para que os dados do app instantâneo sejam mantidos na versão instalada.

Depois que um app for instalado, você só pode atualizar o sandbox de destino para um valor mais alto. Para fazer downgrade do valor da sandbox de destino, desinstale o app e o substitua por uma versão com um valor menor para esse atributo no manifesto.

android:sharedUserLabel

Esta constante foi descontinuada no nível 29 da API.
Os IDs de usuário compartilhados causam um comportamento não determinista no gerenciador de pacotes. Sendo assim, o uso deles não é recomendado e pode ser removido em uma versão futura do Android. Em vez disso, os apps precisam usar mecanismos de comunicação adequados, como serviços e provedores de conteúdo, para facilitar a interoperabilidade entre os componentes compartilhados. Os aplicativos existentes não podem remover esse valor, já que não é possível migrar um ID do usuário compartilhado.

Um rótulo legível pelo usuário para o ID de usuário compartilhado. O rótulo precisa ser definido como uma referência a um recurso de string, e não pode ser uma string bruta.

Esse atributo foi introduzido no nível 3 da API. Ele só vai ser significativo se o atributo sharedUserId também estiver definido.

android:versionCode
Um número de versão interno. Esse número é usado apenas para determinar se uma versão é mais recente que outra. Números maiores indicam versões mais recentes. Esse não é o número da versão exibido aos usuários, mas é definido pelo atributo versionName.

O valor precisa ser definido como um número inteiro positivo maior que zero. Você pode o definir como quiser, desde que cada versão sucessiva tenha um número maior. Por exemplo, ele pode ser um número de versão. Ou você pode converter um número de versão no formato "x.y" em um número inteiro codificando o "x" e o "y" separadamente nos 16 bits mais baixos e mais altos. Ou você pode simplesmente aumentar o número em uma unidade cada vez que uma nova versão for lançada.

android:versionName
O número da versão exibido aos usuários. Esse atributo pode ser definido como uma string bruta ou como uma referência a um recurso de string. A string não tem outra finalidade além de ser exibida aos usuários. O atributo versionCode é o número de versão significativo usado internamente.
android:installLocation
O local de instalação padrão do app.

As strings de palavras-chave abaixo são aceitas:

Valor Descrição
"internalOnly" O app só pode ser instalado no armazenamento interno do dispositivo. Se esse valor for definido, o app nunca vai ser instalado no armazenamento externo. Se o armazenamento interno estiver cheio, o sistema não vai instalar o app. Esse também é o comportamento padrão se você não definir android:installLocation.
"auto" O app pode ser instalado no armazenamento externo, mas o sistema vai instalar o app no armazenamento interno por padrão. Se o armazenamento interno estiver cheio, o sistema vai instalar o app no armazenamento externo. Depois de instalado, o usuário pode mover o app para o armazenamento interno ou externo usando as configurações do sistema.
"preferExternal" O app prefere ser instalado no armazenamento externo (cartão SD). Não há garantia de que o sistema vai aceitar esta solicitação. O app pode ser instalado no armazenamento interno se a mídia externa estiver indisponível ou cheia. Depois de instalado, o usuário pode mover o app para o armazenamento interno ou externo nas configurações do sistema.

Observação: por padrão, o app vai ser instalado no armazenamento interno e não pode ser instalado no armazenamento externo, a menos que esse atributo seja definido como "auto" ou "preferExternal".

Quando um app é instalado no armazenamento externo:

  • O arquivo .apk é salvo no armazenamento externo, mas todos os dados do app, como bancos de dados, ainda são salvos na memória interna do dispositivo.
  • O contêiner no qual o arquivo .apk é salvo é criptografado com uma chave que permite que o app opere apenas no dispositivo em que está instalado. Um usuário não pode transferir o cartão SD para outro dispositivo e usar os app instalados no cartão. No entanto, vários cartões SD podem ser usados no mesmo dispositivo.
  • A pedido do usuário, o app pode ser movido para o armazenamento interno.

O usuário também pode solicitar a migração de um app do armazenamento interno para o externo. No entanto, o sistema não vai permitir que o usuário mova o app para armazenamento externo se esse atributo estiver definido como internalOnly, que é a configuração padrão.

Leia Local da instalação do app para mais informações sobre como usar esse atributo, incluindo como manter a compatibilidade com versões anteriores.

Introduzido em: nível 8 da API.

introduzido em:
Nível 1 da API para todos os atributos, a menos que indicado de outra forma na descrição do atributo.

veja também:
<application>