Todo aplicativo tem que ter um arquivo AndroidManifest.xml (precisamente com esse nome) no seu diretório raiz. O arquivo de manifesto apresenta informações essenciais sobre o aplicativo ao sistema Android, necessárias para o sistema antes que ele possa executar o código do aplicativo. Entre outras coisas, o manifesto serve para:
O diagrama ilustra a estrutura geral do arquivo de manifesto e cada elemento que ele pode conter. Cada elemento e seus atributos são documentados na totalidade em um arquivo separado. Para exibir informações detalhadas sobre cada elemento, clique no nome do elemento no diagrama, na lista de elementos em ordem alfabética que acompanha o diagrama ou em qualquer outra menção ao nome do elemento.
<?xml version="1.0" encoding="utf-8"?> <manifest> <uses-permission /> <permission /> <permission-tree /> <permission-group /> <instrumentation /> <uses-sdk /> <uses-configuration /> <uses-feature /> <supports-screens /> <compatible-screens /> <supports-gl-texture /> <application> <activity> <intent-filter> <action /> <category /> <data /> </intent-filter> <meta-data /> </activity> <activity-alias> <intent-filter> . . . </intent-filter> <meta-data /> </activity-alias> <service> <intent-filter> . . . </intent-filter> <meta-data/> </service> <receiver> <intent-filter> . . . </intent-filter> <meta-data /> </receiver> <provider> <grant-uri-permission /> <meta-data /> <path-permission /> </provider> <uses-library /> </application> </manifest>
Todos os elementos que podem aparecer no arquivo de manifesto estão relacionados abaixo em ordem alfabética. Estes são os únicos elementos legais. Não é possível adicionar elementos ou atributos próprios.
<action>
<activity>
<activity-alias>
<application>
<category>
<data>
<grant-uri-permission>
<instrumentation>
<intent-filter>
<manifest>
<meta-data>
<permission>
<permission-group>
<permission-tree>
<provider>
<receiver>
<service>
<supports-screens>
<uses-configuration>
<uses-feature>
<uses-library>
<uses-permission>
<uses-sdk>
Algumas convenções e regras se aplicam geralmente a todos os elementos e atributos no manifesto:
<manifest>
e <application>
são necessários — eles devem estar presentes e ocorrer somente uma vez.
A maioria dos outros pode ocorrer diversas vezes ou nunca — embora
pelo menos alguns deles devam estar presentes para que o manifesto
realize algo significativo.
Se um elemento contiver qualquer coisa, ele conterá outros elementos. Todos os valores são definidos por meio de atributos, e não como dados de caracteres dentro de um elemento.
Elementos de mesmo nível geralmente não são ordenados. Por exemplo: os elementos
<activity>,
<provider>
e <service>
podem ser combinados entre si em qualquer sequência. (O elemento
<activity-alias>
é uma exceção a essa regra: ele deve seguir o
<activity>
para o qual é alias.)
Exceto por alguns atributos do elemento
<manifest>
raiz, todos os nomes de atributo têm um prefixo {@code android:} —
por exemplo, {@code android:alwaysRetainTaskState}. Como o prefixo é universal,
a documentação geralmente o omite ao referir-se a atributos
pelo nome.
<application>
) e seus componentes principais — atividades
(<activity>),
serviços
(<service>),
receptores de transmissão
(<receiver>)
e provedores de conteúdo
(<provider>).
Se uma subclasse for definida, como quase sempre acontece para classes de componentes ({@link android.app.Activity}, {@link android.app.Service}, {@link android.content.BroadcastReceiver} e {@link android.content.ContentProvider}), a subclasse será declarada por meio de um atributo {@code name}. O nome deve conter toda a designação do pacote. Por exemplo: uma subclasse {@link android.app.Service} pode ser declarada assim:
<manifest . . . >
<application . . . >
<service android:name="com.example.project.SecretService" . . . >
. . .
</service>
. . .
</application>
</manifest>
No entanto, para encurtar, se o primeiro caractere da string for um ponto,
a string será acrescentada ao nome do pacote do aplicativo (conforme especificado pelo atributo
package
do elemento
<manifest>
). A seguinte atribuição é igual à atribuição acima:
<manifest package="com.example.project" . . . >
<application . . . >
<service android:name=".SecretService" . . . >
. . .
</service>
. . .
</application>
</manifest>
Ao iniciar um componente, o Android cria uma instância da subclasse nomeada. Se nenhuma subclasse for especificada, ele criará uma instância da classe base.
<intent-filter . . . >
<action android:name="android.intent.action.EDIT" />
<action android:name="android.intent.action.INSERT" />
<action android:name="android.intent.action.DELETE" />
. . .
</intent-filter>{@code @[pacote:]tipo:nome}
em que o nome do pacote pode ser omitido se o recurso estiver no mesmo pacote que o aplicativo tipo é um tipo de recurso — como uma "string" ou "drawable" (desenhável) — e nome é o nome que identifica o recurso específico. Por exemplo:
<activity android:icon="@drawable/smallPic" . . . >
Os valores de um tema são expressos de forma semelhante, mas, com um '{@code ?}' em vez de '{@code @}':
{@code ?[pacote:]tipo:nome}
As seções a seguir descrevem como alguns recursos do Android se refletem no arquivo de manifesto.
Os componentes fundamentais de um aplicativo (suas atividades, serviços e receptores de transmissão) são ativados por intenções. Intenções são pacotes de informações (objetos {@link android.content.Intent}) que descrevem uma ação desejada — inclusive os dados usados em ações, a categoria do componente que deve executar a ação e outras instruções pertinentes. O Android localiza um componente adequado para responder à intenção, inicia uma nova instância do componente se necessário e passa-o ao objeto da intenção.
Os componentes anunciam seus recursos — os tipos de intenção aos quais eles podem
responder — por meio de filtros de intenções. Como o sistema Android
precisa saber que intenções um componente pode tratar antes de iniciá-lo, os filtros
de intenções são especificados no manifesto como elementos
<intent-filter>
. Os componentes podem ter qualquer quantidade de filtros, em que cada um descreve
um recurso diferente.
A intenção que nomeia explicitamente um componente alvo ativará aquele componente — o filtro não desempenha nenhuma função. Porém, uma intenção que não especifica nenhum alvo pelo nome pode ativar um componente somente se ele puder passar por um dos filtros do componente.
Para ver como os objetos de intenção são testados em relação aos filtros de intenções, consulte o documento Intenções e filtros de intenções em separado.
Alguns elementos têm atributos {@code icon} e {@code label} de um pequeno ícone
e uma etiqueta de texto que pode ficar visível para os usuários. Alguns deles também têm um atributo
{@code description} para um texto explicativo mais longo que também pode ser
exibido na tela. Por exemplo: o elemento
<permission>
tem todos os três atributos; assim, quando o usuário é consultado para dar
permissão a um aplicativo que a solicitou, serão apresentados ao usuário um ícone
que representa a permissão, o nome da permissão e uma descrição
de tudo o que está envolvido.
Em todo caso, o ícone e a etiqueta definidos em um elemento recipiente se tornam as configurações
{@code icon} e {@code label} padrão de todos os subelementos do contêiner.
Assim, o ícone e a etiqueta definidos no elemento
<application>
são o ícone e a etiqueta padrão para cada um dos componentes do aplicativo.
Da mesma forma, o ícone e a etiqueta definidos para um componente — por exemplo, um elemento
<activity>
— são as configurações padrão para cada um dos elementos
<intent-filter>
do componente. Se um elemento
<application>
define uma etiqueta, mas uma atividade e seu filtro de intenção não definem,
a etiqueta do aplicativo é tratada como a etiqueta de atividade
e do filtro de intenção.
O ícone e a etiqueta definidos para um filtro de intenção são usados para representar um componente apresentado para o usuário para preencher a função anunciada pelo filtro. Por exemplo: um filtro com as configurações "{@code android.intent.action.MAIN}" e "{@code android.intent.category.LAUNCHER}" anuncia uma atividade como uma que inicia um aplicativo — ou seja, que deve ser exibida no inicializador do aplicativo. O ícone e a etiqueta definidos no filtro são, portanto, as exibidas no inicializador.
As permissões são restrições que limitam o acesso a parte do código ou aos dados de um dispositivo. A limitação é imposta para proteger dados essenciais que podem sofrer mau uso e distorções ou prejudicar a experiência do usuário.
Cada permissão é identificada por uma etiqueta exclusiva. Geralmente a etiqueta indica a ação que foi restringida. A seguir há alguns exemplos de permissões definidas pelo Android:
{@code android.permission.CALL_EMERGENCY_NUMBERS}
{@code android.permission.READ_OWNER_DATA}
{@code android.permission.SET_WALLPAPER}
{@code android.permission.DEVICE_POWER}
Um recurso pode ser protegido por, no máximo, uma permissão.
Se um aplicativo precisar de acesso a um recurso protegido por uma permissão,
ele deve declarar que precisa da permissão com um elemento
<uses-permission>
no manifesto. Assim, quando o aplicativo é instalado
no dispositivo, o instalador determina se concederá ou não a permissão
solicitada, marcando as autoridades que assinaram os certificados
do aplicativo e, em alguns casos, perguntando ao usuário.
Se a permissão for concedida, o aplicativo será capaz de usar os recursos
protegidos. Caso contrário, sua tentativa de acessar esses recursos simplesmente falhará
sem nenhuma notificação ao usuário.
Um aplicativo também pode proteger seus componentes (atividades, serviços,
receptores de transmissão e provedores de conteúdo) com permissões. Ele pode empregar
qualquer uma das permissões definidas pelo Android (listadas em
{@link android.Manifest.permission android.Manifest.permission}) ou declaradas
por outros aplicativos. Ou então, ele pode definir as suas próprias. As novas permissões são declaradas
com o elemento
<permission>.
Por exemplo: uma atividade pode ser protegida da seguinte forma:
<manifest . . . >
<permission android:name="com.example.project.DEBIT_ACCT" . . . />
<uses-permission android:name="com.example.project.DEBIT_ACCT" />
. . .
<application . . .>
<activity android:name="com.example.project.FreneticActivity"
android:permission="com.example.project.DEBIT_ACCT"
. . . >
. . .
</activity>
</application>
</manifest>
Observe que, nesse exemplo, a permissão {@code DEBIT_ACCT}, além de declarada
com o elemento
<permission>
, tem seu uso solicitado com o elemento
<uses-permission>.
Ela deve ser solicitada para que outros componentes do aplicativo
iniciem a atividade protegida, mesmo que a proteção
seja imposta pelo próprio aplicativo.
Se, no mesmo exemplo, o atributo {@code permission} fosse definido
como uma permissão declarada em outro lugar
(como {@code android.permission.CALL_EMERGENCY_NUMBERS}), não seria
necessário declará-la novamente com um elemento
<permission>.
No entanto, ainda seria necessário solicitar seu uso com
<uses-permission>.
O elemento
<permission-tree>
declara um espaço de nome de um grupo de permissões que será definido
no código. E
<permission-group>
define um etiqueta de um conjunto de permissões (os dois declarados no manifesto com elementos
<permission>
e as declaradas em outro lugar). Ele afeta somente a forma com que as permissões estão
agrupadas quando apresentadas ao usuário. O elemento
<permission-group>
não especifica que permissões pertencem ao grupo;
ele só dá um nome ao grupo. Para incluir uma permissão no grupo,
designa-se o nome do grupo ao atributo
permissionGroup
do elemento
<permission>.
Todo aplicativo está vinculado à biblioteca Android padrão, que contém os pacotes básicos para programar aplicativos (com classes comuns tais como Activity, Service, Intent, View, Button, Application, ContentProvider etc.).
No entanto, alguns pacotes residem em suas próprias bibliotecas. Se o aplicativo
usar código de algum desses pacotes, ele deve receber solicitação explícita para ser
vinculado a eles. O manifesto deve conter um elemento
<uses-library>
separado para nomear cada uma das bibliotecas (o nome da biblioteca se encontra
na documentação do pacote).