Muitas pessoas desenvolvem aplicativos para Android e nem mesmo sabem o que um app possui, ou como funcionam as coisas além dos códigos Java e Kotlin.

Pois Android não é somente a linguagem que usamos para desenvolver nossas aplicações. Vai bem mais afundo. Com a primeira edição desse artigo, quero compartilhar um pouco com os amigos, o que temos além do Java e Kotlin de cada dia.

O SO Android roda no sistema Linux, onde cada aplicativo possui seu próprio ID que é desconhecido para o app instalado no dispositivo.

As permissões que são concedidas para o app somente são acessadas pelo ID que o sistema criou da aplicação e cada aplicativo roda separadamente um do outro em sua própria máquina virtual, no próprio processo do Linux.

Esse processo é executado quando inicia o app e o mesmo é encerrado quando não tem mais utilidade ou quando o sistema precisa liberar mais memória para outros aplicativos.

Dois aplicativos podem compartilhar dados e services um com o outro, pois podem ter o mesmo ID de usuário no sistema e executarem no mesmo processo, mas para isso precisam ter o mesmo certificado. O Android implementa o princípio do privilégio mínimo, onde ele utiliza somente os recursos que ele tem permissão e que ele necessita para executar, e nada além disso.

Aplicativos devem solicitar permissão para ter acessos a dados do dispositivo, mas para isso, precisa perguntar ao usuário se ele aceita liberar os acessos aos recursos, como por exemplo acesso a câmera, contatos e etc.

Componentes de aplicativo

Activities

É a tela onde temos a interface do usuário que é composta pela classe Kotlin/Java e seu xml do layout. Por exemplo, tela Home, de Configurações e assim por diante. Todas elas são independentes uma da outra, mesmo estando no mesmo aplicativo, porém, um aplicativo pode solicitar outras Activities, como acessar a câmera para tirar uma foto e receber o resultado para seus próprios fins. Lembrando que uma Activity sempre implementa uma subclasse de Activity.

Services

São componentes executados em segundo plano. A execução de um player em background utiliza um serviço para se manter tocando. Os services não possuem interface para os usuários.

Broadcast receivers

Servem para transmitir dados pelo sistema através de Intents. Muitas transmissões se originam do sistema, como por exemplo: bateria baixa, status de um download em forma de notificação, entre outros, que são mostrados pelo Brodcast Receiver, mesmo ele não possuindo UI.

Content providers

Gerencia conjuntos de dados que podem ser compartilhados entre aplicativos. Pele ContentProvider outros apps podem consultar ou modificar dados de outro app se tiverem permissão. Um exemplo seria um aplicativo que gerencia contatos e querermos acessar esses dados para modificar um contato através de outra aplicação e também pode ser utilizado para salvar dados privados.

Ativação de componentes

Activity, Services e Broadcast Receivers são ativados assincronamente por uma chamada Intent. Esses Intents solicitam componentes individuais para executarem, sendo do aplicativo ou de outros aplicativos.

Nas Activities e Services, os intents definem a ação a ser executada, e podem especificar uma URI de dados para serem utilizadas na ação. Um exemplo é abrir a câmera e pegar a imagem para utilizar no app, o retorno vem através de um intent com o URI que possui o endereço daquela imagem.

Para Broadcast receivers, ele define o anúncio que é transmitido nas notificações, por exemplo.

O ContentProvider não é ativado por intents, e sim por uma solicitação de ContentResolver que trata todas as transações diretamente com o ContentProvider.

• É possível iniciar uma atividade (ou dar-lhe algo novo para fazer) passando uma Intent a startActivity() ou startActivityForResult() (para que, quando desejado, a atividade retorne um resultado).
• É possível iniciar um dispositivo (ou dar novas instruções a um serviço em andamento) passando uma Intent a startService(). Também é possível vincular ao serviço, passando uma Intent a bindService().
• Você pode iniciar uma transmissão passando uma Intent para métodos como sendBroadcast(), sendOrderedBroadcast() ou sendStickyBroadcast().
• É possível iniciar uma consulta a um provedor de conteúdo chamando query() em um ContentResolver.

AndroidManifest

Antes de iniciar o aplicativo, o sistema Android lê o arquivo AndroidManifest.xml para saber os componentes que possuem no app.

Dentro do manifest, é definida as permissões de usuário, nível mínimo de Api exigido pelo app, recursos de hardware, bibliotecas para se vincular, como Google Maps, definir componentes do aplicativo, para atividades, services, Broadcast Receivers e ContentProviders e vários outros que serão escritos em um artigo próprio sobre o AndroidManifest.

O intuito do artigo é instigar os Devs a estudarem a teoria por trás dos códigos e se tornarem melhores desenvolvedores. Em breve irei escrever mais artigos com conteúdo mais aprofundado sobre os temas acima.

Fiquem a vontade para sugerir mudanças e corrigir erros que encontrarem.

Todo o contéudo foi baseado/retirado do https://developer.android.com/guide/index.html