| page.title=Fundamentos de aplicativos |
| @jd:body |
| |
| <div id="qv-wrapper"> |
| <div id="qv"> |
| |
| <h2>Neste documento</h2> |
| <ol> |
| <li><a href="#Components">Componentes de aplicativo</a> |
| <ol> |
| <li><a href="#ActivatingComponents">Ativação de componentes</a></li> |
| </ol> |
| </li> |
| <li><a href="#Manifest">O arquivo de manifesto</a> |
| <ol> |
| <li><a href="#DeclaringComponents">Declaração de componentes</a></li> |
| <li><a href="#DeclaringRequirements">Declaração de requisitos do aplicativo</a></li> |
| </ol> |
| </li> |
| <li><a href="#Resources">Recursos do aplicativo</a></li> |
| </ol> |
| </div> |
| </div> |
| |
| <p>Os aplicativos do Android são programados em linguagem de programação Java. As ferramentas Android SDK compilam |
| o código — em conjunto com todos os arquivos de dados e recursos — em um APK, que é o <i>pacote do Android</i>, |
| um arquivo de arquivamento com sufixo {@code .apk}. Os arquivos de APK contêm todo o conteúdo |
| de um aplicativo do Android e são os arquivos que os dispositivos desenvolvidos para Android usam para instalar o aplicativo.</p> |
| |
| <p>Depois de instalado em um dispositivo, cada aplicativo do Android é ativado em sua própria área de segurança: </p> |
| |
| <ul> |
| <li>O sistema operacional Android é um sistema Linux multiusuário em que cada aplicativo |
| é um usuário diferente.</li> |
| |
| <li>Por padrão, o sistema atribui a cada aplicativo um ID de usuário do Linux exclusivo (o ID é usado somente |
| pelo sistema e é desconhecido para o aplicativo). O sistema define permissões para todos os arquivos |
| em um aplicativo, de modo que somente o ID de usuário atribuído àquele aplicativo pode acessá-los. </li> |
| |
| <li>Cada processo tem sua própria máquina virtual (VM), portanto o código de um aplicativo é executado isoladamente |
| de outros aplicativos.</li> |
| |
| <li>Por padrão, cada aplicativo é executado em seu próprio processo Linux. O Android inicia o processo quando é preciso |
| executar algum componente do aplicativo; em seguida, encerra-o quando não mais é |
| necessário ou quando o sistema precisa recuperar memória para outros aplicativos.</li> |
| </ul> |
| |
| <p>Assim, o sistema Android implementa o <em>princípio do privilégio mínimo</em>. Ou seja, |
| cada aplicativo, por padrão, tem acesso somente aos componentes necessários para a execução do seu trabalho |
| e nada mais. Isso cria um ambiente muito seguro em que o aplicativo não pode acessar partes |
| do sistema para o qual não tem permissão.</p> |
| |
| <p>No entanto, sempre existe uma maneira de um aplicativo compartilhar dados com outros aplicativos |
| e acessar serviços do sistema:</p> |
| |
| <ul> |
| <li>É impossível fazer com que dois aplicativos compartilhem o mesmo ID de usuário do Linux, caso em que |
| eles são capazes de acessar os arquivos um do outro. Para preservar os recursos do sistema, os aplicativos com o mesmo |
| ID de usuário também podem ser combinados para serem executados no mesmo processo Linux e compartilhar a mesma VM |
| (também é preciso atribuir o mesmo certificado aos aplicativos).</li> |
| <li>Um aplicativo pode solicitar permissão para acessar dados de dispositivo como |
| contatos do usuário, mensagens SMS, o sistema montável (cartão SD), câmera, Bluetooth etc. Todas |
| as permissões de aplicativo devem ser concedidas pelo usuário no momento da instalação.</li> |
| </ul> |
| |
| <p>Essas são as informações básicas de como um aplicativo do Android existe dentro do sistema. O restante |
| deste documento apresenta o leitor a:</p> |
| <ul> |
| <li>Componentes fundamentais de estrutura que definem o aplicativo.</li> |
| <li>O arquivo de manifesto em que os componentes são declarados e os recursos de dispositivo necessários |
| ao aplicativo.</li> |
| <li>Recursos separados do código do aplicativo que permitem |
| otimizar o comportamento de uma variedade de configurações de dispositivo.</li> |
| </ul> |
| |
| |
| |
| <h2 id="Components">Componentes de aplicativo</h2> |
| |
| <p>Os componentes de aplicativo são os blocos de construção fundamentais de um aplicativo do Android. |
| Cada componente é um ponto diferente pelo qual o sistema pode entrar no aplicativo. Nem todos |
| os componentes são pontos de entrada reais para o usuário e alguns dependem uns dos outros, mas cada um existe |
| como uma entidade independente e desempenha uma função específica — cada um é um bloco de construção exclusivo |
| que ajuda a definir o comportamento geral do aplicativo.</p> |
| |
| <p>Há quatro tipos diferentes de componentes de aplicativo. Cada tipo tem uma finalidade distinta |
| e tem um ciclo de vida específico que define a forma pela qual o componente é criado e destruído.</p> |
| |
| <p>A seguir apresentam-se os quatro tipos de componentes de aplicativos:</p> |
| |
| <dl> |
| |
| <dt><b>Atividades</b></dt> |
| |
| <dd>As <i>atividades</i> representam uma tela única com uma interface do usuário. Por exemplo: |
| um aplicativo de e-mails pode ter uma atividade que mostra uma lista de novos |
| e-mails, outra atividade que compõe um e-mail e outra ainda que lê e-mails. Embora |
| essas atividades funcionem juntas para formar uma experiência de usuário coesa no aplicativo de e-mails, |
| elas são independentes entre si. Portanto, um aplicativo diferente pode iniciar qualquer uma |
| dessas atividades (se o aplicativo de e-mails permitir). Por exemplo: um aplicativo de câmera pode iniciar |
| a atividade no aplicativo de e-mail que compõe o novo e-mail para que o usuário compartilhe uma foto. |
| |
| <p>Uma atividade é implementada como uma subclasse de {@link android.app.Activity} — saiba mais sobre isso |
| no guia do desenvolvedor |
| <a href="{@docRoot}guide/components/activities.html">Atividades</a>.</p> |
| </dd> |
| |
| |
| <dt><b>Serviços</b></dt> |
| |
| <dd>Os <i>serviços</i> são componentes executados em segundo plano para realizar operações |
| de execução longa ou para realizar trabalho para processos remotos. Eles |
| não apresentam uma interface do usuário. Por exemplo: um serviço pode tocar música em segundo plano |
| enquanto o usuário está em um aplicativo diferente ou buscar dados na rede sem bloquear |
| a interação do usuário com uma atividade. Outro componente, como uma atividade, pode iniciar |
| o serviço e deixá-lo executar ou vincular-se a ele para interagir. |
| |
| <p>Um serviço é implementado como uma subclasse de {@link android.app.Service} — saiba mais sobre isso |
| no guia do desenvolvedor |
| <a href="{@docRoot}guide/components/services.html">Serviços</a>.</p> |
| </dd> |
| |
| |
| <dt><b>Provedores de conteúdo</b></dt> |
| |
| <dd>Os <i>provedores de conteúdo</i> gerenciam um conjunto compartilhado de dados do aplicativo. É possível armazenar os dados |
| no sistema de arquivos, em um banco de dados SQLite ou em qualquer local de armazenamento persistente |
| que o aplicativo possa acessar. Por meio do provedor de conteúdo, outros aplicativos podem consultar ou até modificar |
| os dados (se o provedor de conteúdo permitir). Por exemplo: o sistema Android oferece um provedor |
| de conteúdo que gerencia as informações de contato do usuário. Assim, qualquer aplicativo |
| com as permissões adequadas pode consultar parte do provedor de conteúdo (como {@link |
| android.provider.ContactsContract.Data}) para ler e gravar informações sobre uma pessoa específica. |
| |
| <p>Os provedores de conteúdo são úteis para ler e gravar dados privados |
| no aplicativo e não compartilhados. Por exemplo: o exemplo de aplicativo <a href="{@docRoot}resources/samples/NotePad/index.html">Note Pad</a> usa |
| um provedor de conteúdo para salvar notas.</p> |
| |
| <p>Um provedor de conteúdo é implementado como uma subclasse de {@link android.content.ContentProvider} |
| e precisa implementar um conjunto padrão de APIs que permitem a outros aplicativos |
| realizar transações. Para obter mais informações, consulte o guia de desenvolvedor |
| <a href="{@docRoot}guide/topics/providers/content-providers.html">Provedores de conteúdo</a>.</p> |
| </dd> |
| |
| |
| <dt><b>Receptores de transmissão</b></dt> |
| |
| <dd>Os <i>receptores de transmissão</i> são componentes que respondem a anúncios de transmissão |
| por todo o sistema. Muitas transmissões se originam do sistema — por exemplo, uma transmissão que anuncia |
| que uma tela foi desligada, a bateria está baixa ou uma tela foi capturada. |
| Os aplicativos também podem iniciar transmissões — por exemplo, para comunicar a outros dispositivos |
| que alguns dados foram baixados no dispositivo e estão disponíveis para uso. Embora os receptores |
| de transmissão não exibam nenhuma interface do usuário, eles podem <a href="{@docRoot}guide/topics/ui/notifiers/notifications.html">criar uma notificação na barra de status</a> |
| para alertar ao usuário quando ocorre uma transmissão. Mais comumente, no entanto, um receptor de transmissão |
| é somente um "portal" para outros componentes e realiza uma quantidade mínima de trabalho. Por |
| exemplo: ele pode iniciar um serviço para executar um trabalho baseado no evento. |
| |
| <p>Os receptores de transmissão são implementados como subclasses de {@link android.content.BroadcastReceiver} |
| e cada transmissão é entregue como um objeto {@link android.content.Intent}. Para obter mais informações, |
| consulte a classe {@link android.content.BroadcastReceiver}.</p> |
| </dd> |
| |
| </dl> |
| |
| |
| |
| <p>Um aspecto exclusivo do projeto do sistema Android é que qualquer aplicativo pode iniciar |
| um componente de outro aplicativo. Por exemplo: se você quiser que o usuário capture |
| uma foto com a câmera do dispositivo, provavelmente haverá outro aplicativo que faz isso |
| e o seu aplicativo poderá usá-lo, ou seja, não será necessário desenvolver uma atividade para capturar uma foto. Não é |
| necessário incorporar nem mesmo vinculá-lo do aplicativo da câmera ao código. |
| Em vez disso, basta iniciar a atividade no aplicativo da câmera que captura |
| uma foto. Quando concluída, a foto até retorna ao aplicativo em questão para ser usada. Para o usuário, |
| parece que a câmera é realmente parte do aplicativo.</p> |
| |
| <p>Quando o sistema inicia um componente, ele inicia o processo daquele aplicativo (se ele já |
| não estiver em execução) e instancia as classes necessárias para o componente. Por exemplo: se o aplicativo |
| iniciar a atividade no aplicativo da câmera que captura uma foto, aquele aplicativo |
| é executado no processo que pertence ao aplicativo da câmera e não no processo do aplicativo. |
| Portanto, ao contrário dos aplicativos na maioria dos outros sistemas, os aplicativos do Android não têm um ponto |
| de entrada único (não há a função {@code main()}, por exemplo).</p> |
| |
| <p>Como o sistema executa cada aplicativo em um processo separado com permissões de arquivo |
| que restringem o acesso a outros aplicativos, o aplicativo não pode ativar diretamente um componente |
| a partir de outro aplicativo. No entanto, o sistema Android pode. Portanto, para ativar um componente |
| em outro aplicativo, é preciso enviar uma mensagem ao sistema que especifique a <em>intenção</em> |
| de iniciar um componente específico. Em seguida, o sistema ativa o componente.</p> |
| |
| |
| <h3 id="ActivatingComponents">Ativação de componentes</h3> |
| |
| <p>Três dos quatro tipos de componente — atividades, serviços |
| e receptores de transmissão — são ativados por uma mensagem assíncrona chamada <em>intenção</em>. |
| As intenções vinculam componentes individuais entre si em tempo de execução (como |
| mensageiros que solicitam uma ação de outros componentes), seja o componente pertencente |
| ao aplicativo ou não.</p> |
| |
| <p>A intenção é criada com um objeto {@link android.content.Intent}, que define uma mensagem |
| para ativar um componente específico ou um <em>tipo</em> específico de componente — as intenções |
| podem ser explícitas ou implícitas, respectivamente.</p> |
| |
| <p>Para atividades e serviços, as intenções definem a ação a executar (por exemplo, "exibir" ou |
| "enviar" algo) e podem especificar a URI dos dados usados na ação (entre outras coisas |
| que o componente a iniciar precisa saber). Por exemplo: uma intenção pode transmitir uma solicitação |
| de uma atividade para exibir uma imagem ou abrir uma página da web. Em alguns casos, é preciso iniciar |
| uma atividade para receber um resultado; nesse caso, a atividade também retorna |
| o resultado em um {@link android.content.Intent} (por exemplo, é possível emitir uma intenção para |
| que o usuário selecione um contato pessoal e o retorne a você — a intenção de retorno contém |
| uma URI que aponta para o contato selecionado).</p> |
| |
| <p>Para receptores de transmissão, a intenção simplesmente define |
| o anúncio que está sendo transmitido (por exemplo, uma transmissão para indicar que a bateria do dispositivo está acabando |
| contém uma string de ação conhecida que indica "nível baixo da bateria").</p> |
| |
| <p>O outro tipo de componente, o provedor de conteúdo, não é ativado por intenções. Em vez disso, |
| ele é ativado por uma solicitação de um {@link android.content.ContentResolver}. O resolvedor |
| de conteúdo manipula todas as transações diretas com o provedor de conteúdo para que o componente |
| que executa as transações com o provedor não precise e, em vez disso, chama os métodos no objeto {@link |
| android.content.ContentResolver}. Isso deixa uma camada de abstração entre o provedor |
| de conteúdo e o componente que solicita informações (por segurança).</p> |
| |
| <p>Há dois métodos separados para ativar cada tipo de componente:</p> |
| <ul> |
| <li>É possível iniciar uma atividade (ou dar-lhe algo novo para fazer) |
| passando uma {@link android.content.Intent} a {@link android.content.Context#startActivity |
| startActivity()} ou {@link android.app.Activity#startActivityForResult startActivityForResult()} |
| (para que, quando desejado, a atividade retorne um resultado).</li> |
| <li>É possível iniciar um dispositivo (ou dar novas instruções a um serviço em andamento) |
| passando uma {@link android.content.Intent} a {@link android.content.Context#startService |
| startService()}. Ou então, é possível vincular ao serviço passando uma{@link android.content.Intent} |
| a {@link android.content.Context#bindService bindService()}.</li> |
| <li>É possível iniciar uma transmissão passando uma{@link android.content.Intent} a métodos como |
| {@link android.content.Context#sendBroadcast(Intent) sendBroadcast()}, {@link |
| android.content.Context#sendOrderedBroadcast(Intent, String) sendOrderedBroadcast()} ou {@link |
| android.content.Context#sendStickyBroadcast sendStickyBroadcast()}.</li> |
| <li>É possível iniciar uma consulta a um provedor de conteúdo chamando {@link |
| android.content.ContentProvider#query query()} em um {@link android.content.ContentResolver}.</li> |
| </ul> |
| |
| <p>Para obter mais informações sobre intenções, consulte o documento |
| <a href="{@docRoot}guide/components/intents-filters.html">Intenções e filtros de intenções</a>. Veja mais informações sobre a ativação de componentes específicos |
| nos seguintes documentos: <a href="{@docRoot}guide/components/activities.html">Atividades</a>, <a href="{@docRoot}guide/components/services.html">Serviços</a>, {@link |
| android.content.BroadcastReceiver} e <a href="{@docRoot}guide/topics/providers/content-providers.html">Provedores de conteúdo</a>.</p> |
| |
| |
| <h2 id="Manifest">O arquivo de manifesto</h2> |
| |
| <p>Antes de o sistema Android iniciar um componente de aplicativo, é preciso ler o arquivo {@code AndroidManifest.xml} |
| (o arquivo de "manifesto") |
| do aplicativo para que o sistema saiba se o componente existe. O aplicativo precisa declarar todos os seus componentes nesse arquivo, que deve estar na raiz |
| do diretório do projeto do aplicativo.</p> |
| |
| <p>O manifesto faz outras coisas além de declarar os componentes do aplicativo, |
| por exemplo:</p> |
| <ul> |
| <li>Identifica todas as permissões do usuário de que o aplicativo precisa, como acesso à internet |
| ou acesso de somente leitura aos contatos do usuário.</li> |
| <li>Declara o <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#ApiLevels">nível de API</a> mínimo |
| exigido pelo aplicativo com base nas APIs que o aplicativo usa.</li> |
| <li>Declara os recursos de hardware e software usados ou exigidos pelo aplicativo, como câmera, |
| serviços de bluetooth ou tela multitoque.</li> |
| <li>As bibliotecas de API às quais o aplicativo precisa vincular-se (outras além das APIs |
| de estrutura do Android), como a <a href="http://code.google.com/android/add-ons/google-apis/maps-overview.html">biblioteca |
| Google Maps</a>.</li> |
| <li>E outros.</li> |
| </ul> |
| |
| |
| <h3 id="DeclaringComponents">Declaração de componentes</h3> |
| |
| <p>A principal tarefa do manifesto é informar ao sistema os componentes do aplicativo. Por |
| exemplo: um arquivo de manifesto pode declarar uma atividade da seguinte forma: </p> |
| |
| <pre> |
| <?xml version="1.0" encoding="utf-8"?> |
| <manifest ... > |
| <application android:icon="@drawable/app_icon.png" ... > |
| <activity android:name="com.example.project.ExampleActivity" |
| android:label="@string/example_label" ... > |
| </activity> |
| ... |
| </application> |
| </manifest></pre> |
| |
| <p>No elemento <code><a |
| href="{@docRoot}guide/topics/manifest/application-element.html"><application></a></code> |
| , o atributo {@code android:icon} aponta para recursos de um ícone que identifica |
| o aplicativo.</p> |
| |
| <p>No elemento <code><a |
| href="{@docRoot}guide/topics/manifest/activity-element.html"><activity></a></code>, |
| o atributo {@code android:name} especifica o nome da classe totalmente qualificada da subclasse de {@link |
| android.app.Activity} e o atributo {@code android:label} especifica uma string |
| a usar como a etiqueta da atividade visível ao usuário.</p> |
| |
| <p>É preciso declarar todos os componentes desta forma:</p> |
| <ul> |
| <li>Elementos <code><a |
| href="{@docRoot}guide/topics/manifest/activity-element.html"><activity></a></code> |
| para atividades</li> |
| <li>Elementos <code><a |
| href="{@docRoot}guide/topics/manifest/service-element.html"><service></a></code> |
| para serviços</li> |
| <li>Elementos <code><a |
| href="{@docRoot}guide/topics/manifest/receiver-element.html"><receiver></a></code> |
| para receptores de transmissão</li> |
| <li>Elementos <code><a |
| href="{@docRoot}guide/topics/manifest/provider-element.html"><provider></a></code> |
| para provedores de conteúdo</li> |
| </ul> |
| |
| <p>Atividades, serviços e provedores de conteúdo incluídos na fonte, mas não declarados |
| no manifesto, não ficam visíveis para o sistema e, consequentemente, podem não ser executados. No entanto, receptores |
| de transmissão |
| podem ser declarados no manifesto dinamicamente no código (como objetos |
| {@link android.content.BroadcastReceiver}) e registrados no sistema chamando-se |
| {@link android.content.Context#registerReceiver registerReceiver()}.</p> |
| |
| <p>Para obter mais informações sobre a estrutura do arquivo de manifesto de aplicativos, consulte a documentação |
| <a href="{@docRoot}guide/topics/manifest/manifest-intro.html">O arquivo AndroidManifest.xml</a>. </p> |
| |
| |
| |
| <h3 id="DeclaringComponentCapabilities">Declaração de recursos de componentes</h3> |
| |
| <p>Conforme abordado acima, em <a href="#ActivatingComponents">Ativação de componentes</a>, é possível usar |
| uma {@link android.content.Intent} para iniciar atividades, serviços e receptores de transmissão. Isso pode ser feito |
| nomeando-se explicitamente o componente-alvo (usando o nome da classe do componente) na intenção. No entanto, |
| a verdadeira força das intenções reside no conceito de <em>intenções implícitas</em>. As intenções implícitas |
| descrevem simplesmente o tipo de ação a executar (e, opcionalmente, os dados em que |
| a ação deve ser executada) e permitem ao sistema encontrar e iniciar um componente no dispositivo que pode executar |
| a ação. Se houver mais de um componente que possa executar a ação descrita |
| pela intenção, o usuário selecionará qual deles usar.</p> |
| |
| <p>Para o sistema identificar os componentes que podem responder a uma intenção, compara-se |
| a intenção recebida com os <i>filtros de intenções</i> fornecidos no arquivo de manifesto de outros aplicativos |
| do dispositivo.</p> |
| |
| <p>Ao declarar uma atividade no manifesto do aplicativo, pode-se incluir |
| filtros de intenções que declarem os recursos da atividade para que ela responda |
| a intenções de outros aplicativos. Para declarar um filtro de intenções no componentes, |
| adiciona-se um elemento <a href="{@docRoot}guide/topics/manifest/intent-filter-element.html">{@code |
| <intent-filter>}</a> como filho do elemento de declaração do componente.</p> |
| |
| <p>Por exemplo: se você estiver programando um aplicativo de e-mail com uma atividade de compor um novo e-mail, |
| é possível declarar um filtro de intenções para responder a intenções "enviar" (para enviar um novo e-mail), assim:</p> |
| <pre> |
| <manifest ... > |
| ... |
| <application ... > |
| <activity android:name="com.example.project.ComposeEmailActivity"> |
| <intent-filter> |
| <action android:name="android.intent.action.SEND" /> |
| <data android:type="*/*" /> |
| <category android:name="android.intent.category.DEFAULT" /> |
| </intent-filter> |
| </activity> |
| </application> |
| </manifest> |
| </pre> |
| |
| <p>Em seguida, se outro aplicativo criar uma intenção com a ação {@link |
| android.content.Intent#ACTION_SEND} e passá-la para {@link android.app.Activity#startActivity |
| startActivity()}, o sistema poderá iniciar a atividade de forma que o usuário possa rascunhar e enviar |
| um e-mail.</p> |
| |
| <p>Para obter mais informações sobre filtros de intenções, consulte o documento <a href="{@docRoot}guide/components/intents-filters.html">Intenções e filtros de intenções</a>. |
| </p> |
| |
| |
| |
| <h3 id="DeclaringRequirements">Declaração de requisitos do aplicativo</h3> |
| |
| <p>Existem vários dispositivos desenvolvidos para Android e nem todos apresentam os mesmos |
| recursos e características. Para evitar que o aplicativo seja instalado em dispositivos |
| que não contenham os recursos que o aplicativo necessita, é importante definir um perfil |
| para os tipos de dispositivo compatíveis com o aplicativo. É preciso declarar os requisitos de dispositivo e software |
| no arquivo de manifesto. A maior parte dessas declarações é somente informativa e o sistema não as lê, |
| mas serviços externos, como o Google Play, as leem para oferecer uma filtragem |
| aos usuários quando buscam esses aplicativos para seu dispositivo.</p> |
| |
| <p>Por exemplo: se o aplicativo exige uma câmera e usa APIs introduzidas no Android 2.1 (<a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#ApiLevels">API de nível</a> 7), |
| deve-se declarar esses requisitos no arquivo de manifesto da seguinte forma:</p> |
| |
| <pre> |
| <manifest ... > |
| <uses-feature android:name="android.hardware.camera.any" |
| android:required="true" /> |
| <uses-sdk android:minSdkVersion="7" android:targetSdkVersion="19" /> |
| ... |
| </manifest> |
| </pre> |
| |
| <p>Assim, dispositivos que <em>não</em> tenham câmera e tenham |
| versão Android <em>anterior</em> a 2.1 não poderão instalar o aplicativo a partir do Google Play.</p> |
| |
| <p>No entanto, também é possível declarar que o aplicativo usa a câmera como recurso |
| <em>não obrigatório</em>. Nesse caso, o aplicativo precisa definir o atributo <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html#required">{@code required}</a> |
| como {@code "false"} e verificar em tempo de execução |
| se o dispositivo tem câmera e desativar os recursos da câmera conforme o necessário.</p> |
| |
| <p>Veja mais informações sobre o gerenciamento da compatibilidade do aplicativo com diferentes dispositivos |
| no documento <a href="{@docRoot}guide/practices/compatibility.html">Compatibilidade |
| do dispositivo</a>.</p> |
| |
| |
| |
| <h2 id="Resources">Recursos do aplicativo</h2> |
| |
| <p>Os aplicativos Android são compostos por mais do que somente códigos — eles requerem recursos |
| separados do código-fonte, como imagens, arquivos de áudio e tudo o que se relaciona |
| com a apresentação visual do aplicativo. Por exemplo: deve-se definir animações, menus, estilos, cores |
| e o layout das interfaces do usuário da atividade com arquivos XML. O uso de recursos de aplicativo facilita |
| a atualização de diversas características do aplicativo sem a necessidade de modificar |
| o código e — fornecendo conjuntos de recursos alternativos — permite otimizar o aplicativo |
| para diversas configurações de dispositivo (como idiomas e tamanhos de tela diferentes).</p> |
| |
| <p>Para todo recurso incluído no projeto Android, as ferramentas de programação SDK definem |
| um ID inteiro exclusivo que o programador pode usar para referenciar o recurso do código do aplicativo |
| ou de outros recursos definidos no XML. Por exemplo: se o aplicativo contiver um arquivo de imagem de nome {@code |
| logo.png} (salvo no diretório {@code res/drawable/}), as ferramentas de SDK gerarão um ID de recurso |
| chamado {@code R.drawable.logo}, que pode ser usado para referenciar a imagem e inseri-la |
| na interface do usuário.</p> |
| |
| <p>Um dos aspectos mais importantes de fornecer recursos separados do código-fonte |
| é a capacidade de fornecer recursos alternativos para diferentes configurações |
| de dispositivo. Por exemplo: ao definir strings de IU em XML, é possível converter as strings em outros |
| idiomas e salvá-las em arquivos separados. Em seguida, com base em um <em>qualificador</em> de idioma |
| acrescentado ao nome do diretório do recurso (como {@code res/values-fr/} para valores |
| de string em francês) e a configuração de idioma do usuário, o sistema Android aplica as strings de idioma adequadas |
| à IU.</p> |
| |
| <p>O Android aceita vários <em>qualificadores</em> para recursos alternativos. O qualificador |
| é uma string curta incluída no nome dos diretórios de recurso para definir |
| a configuração de dispositivo em que esses recursos serão usados. Outro exemplo: |
| deve-se criar diferentes layouts para as atividades conforme a orientação |
| e o tamanho da tela do dispositivo. Por exemplo: quando a tela do dispositivo está em orientação |
| retrato (vertical), pode ser desejável um layout com botões na vertical, mas, quando a tela está em orientação |
| paisagem (horizontal), os botões devem estar alinhados horizontalmente. Para alterar o layout |
| conforme a orientação, pode-se definir dois layouts diferentes e aplicar o qualificador |
| adequado ao nome do diretório de cada layout. Em seguida, o sistema aplica automaticamente o layout adequado |
| conforme a orientação atual do dispositivo.</p> |
| |
| <p>Para obter mais informações sobre os diferentes tipos de recursos a incluir no aplicativo |
| e como criar recursos alternativos para diferentes configurações de dispositivo, leia <a href="{@docRoot}guide/topics/resources/providing-resources.html">Como fornecer recursos</a>.</p> |
| |
| |
| |
| <div class="next-docs"> |
| <div class="col-6"> |
| <h2 class="norule">Continue lendo sobre:</h2> |
| <dl> |
| <dt><a href="{@docRoot}guide/components/intents-filters.html">Intenções e filtros de intenções</a> |
| </dt> |
| <dd>Informações sobre o uso de APIs {@link android.content.Intent} para |
| ativar componentes de aplicativos, como atividades e serviços, e como disponibilizar componentes |
| de aplicativo para uso em outros aplicativos.</dd> |
| <dt><a href="{@docRoot}guide/components/activities.html">Atividades</a></dt> |
| <dd>Informações sobre a criação de uma instância da classe {@link android.app.Activity}, |
| que permite uma tela diferente no aplicativo com uma interface do usuário.</dd> |
| <dt><a href="{@docRoot}guide/topics/resources/providing-resources.html">Como fornecer recursos</a></dt> |
| <dd>Informações sobre a estrutura de aplicativos Android para recursos de aplicativo separados do código-fonte |
| , inclusive como fornecer recursos alternativos para configurações |
| de dispositivo específicas. |
| </dd> |
| </dl> |
| </div> |
| <div class="col-6"> |
| <h2 class="norule">Você também pode se interessar por:</h2> |
| <dl> |
| <dt><a href="{@docRoot}guide/practices/compatibility.html">Compatibilidade do dispositivo</a></dt> |
| <dd>Informações sobre como o Android funciona em diferentes tipos de dispositivo e uma introdução |
| a como otimizar o aplicativo para cada dispositivo ou restringir a disponibilidade |
| a diferentes dispositivos.</dd> |
| <dt><a href="{@docRoot}guide/topics/security/permissions.html">Permissões do sistema</a></dt> |
| <dd>Informações sobre como o aplicativo restringe o acesso do Android a determinadas APIs sem um |
| sistema de permissão que exija o consentimento do usuário para que o aplicativo use essas APIs.</dd> |
| </dl> |
| </div> |
| </div> |
| |