Fundamentos de aplicativos

Apps Android podem ser criados usando Kotlin, a linguagem de programação Java, e as linguagens C++. A compilação das Ferramentas do SDK do Android seu código e todos os arquivos de dados e recursos em um APK ou Android App Bundle.

Um pacote Android, que é um arquivo com um sufixo .apk, contém o conteúdo de um aplicativo Android exigido em tempo de execução, e é o arquivo que com tecnologia Android dispositivos usam para instalar o app.

Um Android App Bundle, que é um arquivo com um sufixo .aab, contém o conteúdo de um projeto de aplicativo Android, incluindo metadados adicionais que não são necessários em no ambiente de execução. Um AAB é um formato de publicação e não pode ser instalado em dispositivos Android. Ela adia a geração e a assinatura do APK para um estágio posterior.

Ao distribuir seu app pelo Google O Google Play, por exemplo, os servidores do Google Play geram APKs otimizados que contêm somente os recursos e exigidos pelo dispositivo específico que solicita a instalação do app.

Cada app Android reside em um sandbox próprio, protegido por os seguintes recursos de segurança do Android:

• O sistema operacional Android é um sistema Linux multiusuário em que cada app é um para um usuário diferente.
• Por padrão, o sistema atribui a cada app um ID de usuário do Linux exclusivo, que é usado apenas pelos sistema e for desconhecida para o app. O sistema define permissões para todos os arquivos de um para que apenas o ID de usuário atribuído a ele possa acessá-lo.
• Cada processo tem a própria máquina virtual (VM). Portanto, o código de um app é executado isoladamente e outros apps.
• Por padrão, cada aplicativo é executado no próprio processo do Linux. O sistema Android inicia o processo quando dos componentes do app precisam ser executados e, em seguida, encerra o processo quando não for mais necessário ou quando o sistema precisa recuperar memória para outros aplicativos.

O sistema Android implementa o princípio de privilégio mínimo. Ou seja, cada app, por padrão, tem acesso somente aos componentes necessários para a função e não mais. Isso cria um ambiente muito seguro em que um app não pode acessar partes do sistema para o qual não recebe permissão.

No entanto, há maneiras de um app compartilhar dados com outros aplicativos e por uma para acessar os serviços do sistema:

• É possível fazer com que dois apps compartilhem o mesmo ID de usuário do Linux. Nesse caso, eles possam acessar os arquivos uns dos outros. Para preservar os recursos do sistema, os apps com a Também é possível organizar um mesmo ID de usuário para execução no mesmo processo do Linux e compartilhar a mesma VM. A também precisam ser assinados com o mesmo certificado.
• Um app pode solicitar permissão para acessar dados do dispositivo, como localização, câmera e conexão Bluetooth. O usuário tem para conceder essas permissões explicitamente. Para mais informações sobre permissões, consulte Permissões no Android.

O restante deste documento apresenta os conceitos a seguir:

• Componentes fundamentais de biblioteca que definem o aplicativo.
• O arquivo de manifesto em que você declara os componentes e o dispositivo necessário recursos para sua app.
• Recursos separados do código do app que permitem que ele otimizar o comportamento dele corretamente em diversas configurações de dispositivos.

Componentes do app

Os componentes do app são os blocos de construção essenciais de um app Android. Cada componente é um ponto de entrada pelo qual o sistema ou um usuário pode entrar no seu app. Algumas dependem de outros.

Há quatro tipos de componentes de app:

• Atividades
• Serviços
• Broadcast receivers
• Provedores de conteúdo

Cada tipo tem uma finalidade distinta e tem um ciclo de vida distinto que define como um componente é criado e destruído. As seções a seguir descrevem os quatro tipos de componentes do aplicativo.

Atividades

Uma atividade é o ponto de entrada para interagir com o usuário. Ela representa um único com uma interface do usuário. Por exemplo: um app de e-mails pode ter uma atividade que mostra uma lista de novos e-mails, outra atividade para escrever um e-mail e outra para ler e-mails. Embora as atividades trabalham juntas para formar uma experiência do usuário coesa no aplicativo de e-mail, cada uma é independente umas das outras.

Outro app pode iniciar qualquer uma dessas opções se o app de e-mail permitir. Por exemplo, um app de câmera pode iniciar o atividade no app de e-mails para escrever um novo e-mail e permitir que o usuário compartilhe uma imagem.

Uma atividade facilita as principais interações a seguir entre sistema e aplicativo:

• Acompanhar o que o usuário considera importante no momento (o que está na tela) para que o sistema continua executando o processo que hospeda a atividade.
• Saber quais processos usados anteriormente contêm atividades interrompidas aos quais o usuário pode retornar e priorizando esses processos mais para manter a disponibilidade.
• Ajudar o app a lidar com a interrupção do processo para que o usuário possa retornar às atividades com o estado anterior restaurado.
• Oferecer aos aplicativos uma maneira de implementar fluxos de usuários entre si e para que o sistema coordenar esses fluxos. O principal exemplo disso é o compartilhamento.

Você implementa uma atividade como uma subclasse da classe Activity. Para mais informações sobre a classe Activity, consulte Introdução às atividades.

Serviços

Um serviço é um ponto de entrada de uso geral para manter um app em execução em segundo plano. por vários motivos. É um componente executado em segundo plano para executar ou realizar trabalho para processos remotos. Serviços não apresentam uma interface do usuário.

Para por exemplo, um serviço pode tocar música em segundo plano enquanto o usuário está em um app diferente ou ele pode buscar dados na rede sem bloquear a interação do usuário com uma atividade. Outra componente, como uma atividade, pode iniciar o serviço e permitir que ele seja executado ou vinculado a interagir com ele.

Há dois tipos de serviços que informam ao sistema como gerenciar um aplicativo: serviços iniciados e serviços vinculados.

Os serviços iniciados dizem ao sistema para mantê-los em execução até que o trabalho seja concluído. Isso pode acontecer para sincronizar alguns dados em segundo plano ou tocar músicas mesmo depois que o usuário sair do app. A sincronização de dados em segundo plano ou a reprodução de músicas representam diferentes tipos de que o sistema gerencia de forma diferente:

• A reprodução de música é algo de que o usuário está diretamente ciente, e o aplicativo comunica isso a o sistema, indicando que ele quer estar em primeiro plano, com uma notificação para informar o usuário que ele está executando. Nesse caso, o sistema prioriza a manutenção do serviço em execução, porque o usuário terá uma experiência ruim se ele desaparecer.
• Um serviço de segundo plano regular não é algo de que o usuário esteja diretamente ciente, então o sistema tem mais liberdade para gerenciar seu processo. Ele pode deixá-lo morto, reiniciar o serviço mais tarde se precisar de RAM para itens de uma preocupação imediata ao usuário.

Os serviços vinculados são executados porque algum outro aplicativo (ou o sistema) informou que gostaria de usar o serviço. Um serviço vinculado fornece uma API para outro processo, e o sistema sabe que há uma dependência entre esses processos. Portanto, se o processo A está vinculado a um serviço em no processo B, o sistema sabe que precisa manter o processo B e o serviço em execução para A. Além disso, se o processo A é algo que importa para o usuário, então ele sabe que deve tratar o processo B como algo que o usuário também se preocupa.

Devido à flexibilidade deles, os serviços são úteis elementos básicos para todos os tipos de conceitos de sistema de alto nível. Planos de fundo interativos, notificação listeners, protetores de tela, métodos de entrada, serviços de acessibilidade e muitos outros recursos essenciais do sistema são todos criados como serviços que os aplicativos implementam e que o sistema vincula quando são executados.

Um serviço é implementado como uma subclasse de Service. Para mais informações sobre a classe Service, consulte a Visão geral dos serviços.

Observação:caso seu app seja destinado ao Android 5.0 (nível 21 da API) ou versões mais recentes, use a classe JobScheduler para programar ações. O JobScheduler tem vantagem de conservar a bateria programando tarefas de forma otimizada para reduzir o consumo de energia e trabalhando com a API Soneca. Para mais informações sobre como usar essa classe, consulte a JobScheduler documentação de referência.

Broadcast receivers

Um broadcast receiver é um componente que permite ao sistema enviar eventos aos fora de um fluxo normal do usuário, para que possa responder a uma transmissão do sistema anúncios. Como os broadcast receivers são outra entrada bem definida no app, o sistema pode entregar transmissões até mesmo para apps que não estão em execução.

Por exemplo, um app pode programar um alarme para postar uma notificação e informar o usuário sobre um próximo evento. Como o alarme é entregue a um BroadcastReceiver no app, não é necessário que ele em execução até o alarme tocar.

Muitas transmissões se originam no sistema, como uma transmissão anunciando que a tela está desligada, se a bateria estiver fraca ou se uma imagem for tirada. Os apps também podem iniciar transmissões, por exemplo, para informar aos outros apps que alguns dados são transferidos por download para o dispositivo e ficam disponíveis para uso.

Embora a transmissão Os receptores não exibem uma interface do usuário, eles podem criar uma notificação na barra de status. para alertar o usuário quando ocorre um evento de transmissão. No entanto, é mais comum que um broadcast receiver apenas um gateway para outros componentes e realiza uma quantidade mínima de trabalho.

Por exemplo, um broadcast receiver pode programar um JobService para executar um trabalho baseado em um evento usando JobScheduler. Os broadcast receivers geralmente envolvem aplicativos que interagem entre si, por isso é importante estar ciente das implicações de segurança ao configurá-los.

Um broadcast receiver é implementado como uma subclasse de BroadcastReceiver. e cada transmissão é entregue como um objeto Intent. Para mais informações, consulte a classe BroadcastReceiver.

Provedores de conteúdo

Um provedor de conteúdo gerencia um conjunto compartilhado de dados de apps que você pode armazenar em no sistema de arquivos, em um banco de dados SQLite, na Web ou em qualquer outro armazenamento persistente. local em que o pode acessar. Pelo provedor de conteúdo, outros apps podem consultar ou modificar os dados, se o provedor de conteúdo permitir.

Por exemplo, o sistema Android fornece um content provedor que gerencia os dados de contato do usuário. Qualquer app com a permissão permissões podem consultar o provedor de conteúdo, como usar ContactsContract.Data, para ler e gravar informações sobre de uma determinada pessoa.

É tentador pensar em um provedor de conteúdo como uma abstração de um banco de dados, porque existe muita API e suporte integrado a elas para esse caso comum. No entanto, elas têm uma diferença do propósito principal do ponto de vista do design de sistemas.

Para o sistema, um provedor de conteúdo é um ponto de entrada em um app para publicar itens de dados nomeados. identificados por um esquema de URI. Assim, um aplicativo pode decidir como deseja mapear os dados que contém para um namespace do URI, distribuindo esses URIs a outras entidades que, por sua vez, podem usá-los para acessar o dados. Há algumas coisas específicas que isso permite que o sistema faça ao gerenciar um aplicativo:

• A atribuição de um URI não exige que o aplicativo permaneça em execução. Portanto, os URIs podem persistir após o dos apps proprietários são fechados. O sistema só precisa garantir que o app proprietário seja ainda está em execução quando recupera os dados do app a partir do URI correspondente.
• Os URIs também fornecem um importante modelo de segurança de controle preciso. Por exemplo, uma pode colocar o URI de uma imagem na área de transferência, mas deixar o conteúdo provedor bloqueado para que outros aplicativos não possam acessá-lo livremente. Quando um segundo app tenta para acessar esse URI na área de transferência, o sistema pode permitir que o app acessar os dados usando uma concessão de permissão de URI temporária para que ele acesse os dados apenas por trás desse URI e nada mais no segundo app.

Os provedores de conteúdo também são úteis para ler e gravar dados que são particulares de seu e não compartilhados.

Um provedor de conteúdo é implementado como uma subclasse de ContentProvider. e precisam implementar um conjunto padrão de APIs que permitem que outros aplicativos realizem transações. Para mais informações, consulte a página do desenvolvedor Provedores de conteúdo guia.

Um aspecto exclusivo do design do sistema Android é que qualquer aplicativo pode iniciar outro componente do app. Por exemplo, se você quer que o usuário capture com a câmera do dispositivo, provavelmente há outro aplicativo que faz isso, e seu pode usá-lo em vez de desenvolver uma atividade para tirar uma foto por conta própria. Você não precisa incorporar ou até mesmo criar um link para o código do aplicativo de câmera. Em vez disso, você pode iniciar a atividade no app de 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 seu aplicativo.

Quando o sistema inicia um componente, ele inicia o processo para o aplicativo, caso já em execução e instancia as classes necessárias para o componente. Por exemplo, se sua inicia a atividade no app de câmera que captura uma foto, essa atividade é executada no processo que pertence ao app da câmera, não no processo do app. Portanto, ao contrário dos apps da maioria dos outros sistemas, os apps Android não têm uma única entrada Ponto: não há função main().

Como o sistema executa cada aplicativo em um processo separado com permissões de arquivo que restringir o acesso a outros aplicativos, ele não poderá ativar diretamente um componente outro app. No entanto, o sistema Android consegue. Para ativar um componente outro app, você entrega uma mensagem ao sistema que especifica sua intenção de iniciar um componente específico. Em seguida, o sistema ativa o componente.

Ativar componentes

Uma mensagem assíncrona, chamada de intent, ativa três dos quatro tipos de componentes: atividades, serviços e broadcast receivers. Os intents vinculam componentes individuais uns aos outros no ambiente de execução. Pense nelas como os mensageiros que solicitam uma ação de outros componentes, se o componente pertence ao seu app ou a outro.

Uma intent é criada com um objeto Intent, que define uma mensagem para Ativar um componente específico (uma intent explícita) ou um tipo específico de componente (uma intent implícita).

Para atividades e serviços, uma intent define a ação a ser executada, como view ou enviar algo e especificar o URI dos dados com ação, entre outras coisas que o que o componente que está sendo iniciado precise saber.

Por exemplo, uma intent pode transmitir uma solicitação de uma para mostrar uma imagem ou abrir uma página da web. Em alguns casos, você pode iniciar um para receber um resultado. Nesse caso, a atividade também retorna o resultado em uma Intent. Também é possível emitir uma intent para que o usuário escolher um contato pessoal e devolvê-lo a você. A intent de retorno inclui um URI que aponta para o contato escolhido.

Para broadcast receivers, a intent define anúncio de transmissão. Por exemplo, uma transmissão para indicar que a bateria do dispositivo está fraca. inclui apenas uma string de ação conhecida que indica que a bateria está fraca.

Diferentemente de atividades, serviços e broadcast receivers, os provedores de conteúdo ativado quando segmentado por uma solicitação de um ContentResolver. O conteúdo o resolvedor processa todas as transações diretas com o provedor de conteúdo e o componente a realização de transações com o provedor chama métodos no ContentResolver. Isso deixa uma camada de abstração por motivos de segurança entre as provedor de conteúdo e o componente que solicita informações.

Há dois métodos para ativar cada tipo de componente:

• Você pode iniciar uma atividade ou dar a ela algo novo para fazer, transmitindo um Intent para startActivity(). ou, quando quiser que a atividade retorne um resultado, startActivityForResult()
• No Android 5.0 (nível 21 da API) e versões mais recentes, é possível usar a classe JobScheduler para programar ações. Para versões anteriores do Android, um serviço ou dar novas instruções a um serviço contínuo transmitindo um Intent para startService(). Você pode se vincular ao serviço transmitindo um Intent ao bindService().
• Você pode iniciar uma transmissão transmitindo um Intent para métodos como sendBroadcast() ou sendOrderedBroadcast()
• É possível realizar uma consulta em um provedor de conteúdo chamando query() em um ContentResolver.

Para saber mais sobre o uso de intents, consulte a seção Intents e Intent Filtros (link em inglês). Os documentos a seguir fornecem mais informações sobre a ativação de componentes específicos: Introdução às atividades, Visão geral dos serviços, BroadcastReceiver e Provedores de conteúdo.

O arquivo de manifesto

Antes que o sistema Android possa iniciar um componente de aplicativo, o sistema deve saber que o existe ao ler o arquivo de manifesto AndroidManifest.xml do app. O app declara todos os componentes nesse arquivo, que está na raiz do do projeto do app.

O manifesto faz outras coisas além de declarar os componentes do aplicativo, como o seguinte:

• Identifica todas as permissões do usuário que o app exige, como acesso à Internet ou acesso de leitura aos contatos do usuário.
• Declara o valor mínimo Nível da API exigidos pelo aplicativo com base nas APIs que ele usa.
• Declara os recursos de hardware e software usados ou exigidos pelo app, como câmera, Serviços Bluetooth ou uma tela multitoque.
• Declara as bibliotecas de API a que o app precisa ser vinculado (além do framework do Android) APIs), como as APIs biblioteca do Google Maps.

Declarar componentes

A principal tarefa do manifesto é informar o sistema sobre os componentes do app. Para exemplo, um arquivo de manifesto pode declarar uma atividade da seguinte forma:

<?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>

No <application> elemento, o atributo android:icon aponta para recursos para um ícone que identifica o app.

No elemento <activity>, o atributo android:name especifica o nome de classe totalmente qualificado do a subclasse Activity, e a O atributo android:label especifica uma string para usar como o rótulo visível ao usuário para a atividade.

É necessário declarar todos os componentes do aplicativo que usam os elementos a seguir:

• <activity> elementos para atividades
• <service> elementos para serviços
• <receiver> elementos para broadcast receivers
• <provider> elementos para provedores de conteúdo

Atividades, serviços e provedores de conteúdo que você inclui na fonte, mas não declara do manifesto não ficam visíveis para o sistema e, consequentemente, nunca podem ser executados. No entanto, transmissão Os receptores podem ser declarados no manifesto ou criados dinamicamente no código como BroadcastReceiver e registrados no sistema chamando registerReceiver().

Para saber mais sobre como estruturar o arquivo de manifesto do seu app, consulte a Visão geral do manifesto do app.

Declarar os recursos do componente

Como discutido na seção Ativar componentes, é possível usar um Intent para iniciar atividades, serviços e broadcast receivers. Você faz isso nomeando explicitamente o componente-alvo, usando o nome da classe do componente, na intent. Você também pode usar uma intent implícita, que descreve o tipo de ação a ser realizada e, opcionalmente, os dados que você deseja realizar a ação. Uma intent implícita permite que o sistema encontre um componente no dispositivo que podem realizar e iniciá-la. Se houver vários componentes que podem realizar a ação descrita pelo da intent, o usuário seleciona qual usar.

Cuidado: se você usar uma intent para iniciar uma Service, confira se o app é seguro usando uma explícito intenção. Usar uma intent implícita para iniciar um serviço é uma risco de segurança, porque não é possível determinar qual serviço responde à intent e o usuário não consegue saber qual serviço é iniciado. A partir do Android 5.0 (API de nível 21), o sistema gera uma exceção se você chamar bindService(). com uma intent implícita. Não declare filtros de intent para seus serviços.

O sistema identifica os componentes que podem responder a uma intent comparando o recebida pelos filtros de intent fornecidos no arquivo de manifesto de outros apps no o dispositivo.

Ao declarar uma atividade no manifesto do app, é possível incluir opcionalmente filtros de intents que declaram os recursos da atividade para que ela possa responder às intents de outros apps. Você faz isso adicionando um elemento <intent-filter> como filho do elemento de declaração do componente.

Por exemplo, se você criar um app de e-mails com uma atividade para escrever um novo e-mail, poderá declarar um filtro de intent para responder a "enviar" de enviar um novo e-mail, conforme mostrado neste exemplo:

<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>

Se outro app criar uma intent com a ação ACTION_SEND e a transmitir para startActivity(), o sistema pode iniciar sua atividade para que o usuário possa redigir e enviar uma e-mail.

Para saber mais sobre como criar filtros de intents, consulte o documento Intents e filtros de intents.

Declarar requisitos do app

Há diversos dispositivos desenvolvidos para Android, e nem todos fornecem a com os mesmos recursos e capacidades. Para evitar que seu app seja instalado em dispositivos que não tenham os recursos necessários para seu aplicativo, é importante que você defina claramente um perfil para os tipos de dispositivos com suporte do app, declarando requisitos de dispositivo e software no arquivo de manifesto do app.

A maioria dessas declarações é apenas informativa. O sistema não lê mas serviços externos, como o Google Play, fazem a leitura delas para fornecer para os usuários quando eles pesquisam aplicativos em seus dispositivos.

Por exemplo, suponha que seu aplicativo exija uma câmera e use APIs introduzidas no Android 8.0 (nível 26 da API). É necessário declarar esses requisitos. Os valores para minSdkVersion e targetSdkVersion são definidos em o arquivo build.gradle do módulo do app:

android {
  ...
  defaultConfig {
    ...
    minSdkVersion 26
    targetSdkVersion 29
  }
}

Observação:não defina minSdkVersion e targetSdkVersion diretamente no arquivo de manifesto, já que elas são substituídas pelo Gradle durante o processo de build. Para mais informações, consulte Especificar os requisitos de nível da API.

Declare o recurso da câmera no arquivo de manifesto do app:

<manifest ... >
    <uses-feature android:name="android.hardware.camera.any"
                  android:required="true" />
    ...
</manifest>

Com as declarações mostradas nesses exemplos, os dispositivos que não têm uma câmera ou tiver uma Não é possível instalar o app pelo Google Play com uma versão do Android anterior a 8.0. No entanto, também é possível declarar que o app usa a câmera, mas não require o atributo. Para fazer isso, defina o required como false, verifique se durante a execução o dispositivo tem uma câmera e desative todos os recursos dela conforme necessário.

Mais informações sobre como gerenciar a compatibilidade do seu app com diferentes dispositivos é fornecido na Visão geral de compatibilidade do dispositivo.

Recursos do app

Um app Android é composto de mais do que apenas código. Ela exige recursos que sejam separado do código-fonte, como imagens, arquivos de áudio e qualquer coisa relacionada ao visual apresentação do aplicativo. Por exemplo, você pode definir animações, menus, estilos, cores, e o layout das interfaces de usuário da atividade com arquivos XML.

Usar os recursos do app facilita para atualizar diversas características do app sem modificar o código. Fornecer conjuntos de recursos alternativos permite otimizar seu aplicativo para uma variedade de configurações do dispositivo, como diferentes idiomas e tamanhos de tela.

Para cada recurso incluído em seu projeto Android, as ferramentas de compilação do SDK definem uma ID de número inteiro, que pode ser usado para referenciar o recurso do código do app ou do outros recursos definidos em XML. Por exemplo, se o app tiver um arquivo de imagem chamado logo.png (salvo no diretório res/drawable/), as ferramentas do SDK geram um ID de recurso chamado R.drawable.logo. Esse ID é mapeado para um número inteiro específico do app, que você pode usar para fazer referência à imagem e inseri-la em sua interface do usuário.

Um dos aspectos mais importantes de fornecer recursos separados do código-fonte é a capacidade de fornecer recursos alternativos para diferentes dispositivos personalizadas.

Por exemplo, ao definir strings de interface em XML, é possível converter as strings em outros idiomas e salvar essas strings em arquivos separados. Depois, o Android aplica a strings de idioma adequadas à interface com base em um qualificador de linguagem que você anexa ao nome do diretório de recursos, como res/values-fr/ para string em francês. e a configuração de idioma do usuário.

O Android oferece suporte a muitos qualificadores para seus recursos alternativos. A qualificador é uma string curta incluída no nome dos diretórios de recursos para definem a configuração do dispositivo em que esses recursos são usados.

Para exemplo, é possível criar diferentes layouts para suas atividades dependendo do orientação e tamanho da tela do dispositivo. Quando a tela do dispositivo estiver no modo retrato (alta) orientação, você pode querer um layout com botões organizados verticalmente, mas quando a tela está orientação paisagem (ampla), convém alinhar os botões horizontalmente. Para alterar o layout dependendo da orientação, é possível definir dois layouts e aplicar o qualificador ao nome do diretório de cada layout. Em seguida, o sistema aplica automaticamente dependendo da orientação atual do dispositivo.

Para mais informações sobre os diferentes tipos de recursos que podem ser incluídos em seu aplicativo e como criar recursos alternativos para diferentes configurações de dispositivo, leia a Visão geral dos recursos de aplicativo. Para saber mais sobre as práticas recomendadas e projetar apps robustos com qualidade de produção, consulte o Guia para a arquitetura do app.

Outros recursos

Para aprender a desenvolver para Android usando vídeos e tutoriais de código, consulte o Desenvolver apps Android com Kotlin Udacity.

Continue lendo sobre:

Intents e filtros de intent

Aprenda a usar as APIs Intent para ativar componentes do app, como atividades e serviços, e como fazer os componentes do seu app disponíveis para uso por outros apps.

Introdução às atividades

Aprenda a criar uma instância da classe Activity. que fornece uma tela distinta no aplicativo com uma interface do usuário.

Visão geral dos recursos de app

Saiba como os apps Android são estruturados para separar os recursos do app código do app, incluindo como você pode fornecer recursos alternativos para dispositivos específicos personalizadas.

Outros interesses:

Visão geral da compatibilidade do dispositivo

Saiba como o Android funciona em diferentes tipos de dispositivo e como otimizar o app para cada dispositivo ou restringir a disponibilidade dele a dispositivos diferentes.

Permissões no Android

Saiba como o Android restringe o acesso de apps a determinadas APIs com uma permissão sistema que exige o consentimento do usuário para que seu aplicativo use essas APIs.