Principais Componentes do Android

O Android apresenta uma abordagem mais rica e complexa, oferecendo suporte a m´ultiplos pontos de entrada de aplicativos. As aplica¸c˜oes devem prever que o sistema poder´a inicializ´a-los em locais diferentes, dependendo do ponto em que se encontra o usu´ario e do que ele deseja fazer a seguir. Em vez de uma hierarquia de locais, seu programa ´e um grupo cooperante de componentes que podem ser inicializados a partir de um ponto fora do fluxo normal de seu aplicativo (Mednieks et al.,2012). Tais componentes ser˜ao descritos a seguir.

• Broadcast Receiver - Os aplicativos Android podem enviar ou receber mensagens de broadcast, ou em portuguˆes transmiss˜ao, do sistema Android e outros aplicativos Android, semelhantes ao padr˜ao de design de publica¸c˜ao e assinatura. Essas trans- miss˜oes s˜ao enviadas quando ocorre um evento de interesse. Por exemplo, o sistema Android envia transmiss˜oes quando ocorrem v´arios eventos do sistema, como quando o sistema ´e inicializado ou o dispositivo come¸ca a carregar. Os aplicativos tamb´em podem enviar transmiss˜oes personalizadas, por exemplo, para notificar outros apli- cativos sobre algo em que possam estar interessados (por exemplo, alguns novos dados foram baixados). Os aplicativos podem se registrar para receber transmiss˜oes espec´ıficas. Quando uma transmiss˜ao ´e enviada, o sistema roteia automaticamente as transmiss˜oes para aplicativos que se inscreveram para receber esse tipo espec´ıfico de transmiss˜ao. De um modo geral, as transmiss˜oes podem ser usadas como um sistema de mensagens entre aplicativos e fora do fluxo normal do usu´ario (Google,

2019a).

• Content Provider - Auxiliam aplicativos a gerenciar o acesso aos dados armaze- nados por si mesmo, armazenados por outros aplicativos e fornecer uma maneira de compartilhar dados com outros aplicativos. Eles encapsulam os dados e fornecem mecanismos para definir a seguran¸ca e constituem a interface padr˜ao que os conecta em um processo com o c´odigo em execu¸c˜ao em outro processo (Google,2019b). Eles permitir que outros aplicativos acessem e modifiquem com seguran¸ca os dados do aplicativo, conforme ilustrado na Figura 2.3.

• Permissions - O Android ´e um sistema operacional de privil´egio separado em que cada aplicativo executa com uma identidade de sistema distinta (ID de grupo e de usu´ario do Linux). Partes do sistema tamb´em s˜ao separadas em identidades distin- tas. O Linux, por meio disso, isola os aplicativos uns dos outros e do sistema (Google,

2019d). O objetivo de uma permiss˜ao ´e proteger a privacidade de um usu´ario do Android. Os aplicativos devem solicitar permiss˜ao para acessar dados confidenci- ais do usu´ario (como contatos e SMS), al´em de certos recursos do sistema (como cˆamera e internet). Dependendo do recurso, o sistema pode conceder a permiss˜ao automaticamente ou solicitar ao usu´ario que aprove a solicita¸c˜ao (Google, 2019d). As permiss˜oes do sistema s˜ao divididas em v´arios n´ıveis de prote¸c˜ao. Os dois n´ıveis

12 Cap´ıtulo 2. Levantamento bibliogr´afico

Figura 2.3: Diagrama de Vis˜ao Geral do Gerenciamento de Acesso ao Armazenamento do Content Provider.

Fonte: Adaptado de Google(2019b)

de prote¸c˜ao mais importantes que devem ser considerados s˜ao as permiss˜oes normais e perigosas:

– Permiss˜oes Normais: abrange ´areas onde os aplicativos necessitam ter acesso a dados ou recursos fora da sandbox do aplicativo, mas apresenta pouco risco `a privacidade do usu´ario ou `a opera¸c˜ao de outros aplicativos.

– Permiss˜oes Perigosas: cobrem ´areas onde as aplica¸c˜oes precisam de dados ou recursos que envolvem informa¸c˜oes pessoais do usu´ario ou que podem afetar os dados armazenados do usu´ario ou a opera¸c˜ao de outros aplicativos.

– H´a algumas permiss˜oes que n˜ao se comportam como as normais nem as perigo- sas. SYSTEM ALERT WINDOW e WRITE SETTINGS s˜ao particularmente sens´ıveis, portanto, a maioria dos aplicativos n˜ao as devem usar, conhecidas com Permiss˜oes Especiais. Se um aplicativo precisa de uma dessas permiss˜oes, deve declarar a permiss˜ao no manifesto e enviar uma intent solicitando a autoriza¸c˜ao do usu´ario.

Todas as permiss˜oes do sistema Android pertencem a grupos de permiss˜ao. Se um aplicativo solicita uma permiss˜ao perigosa listada no seu manifesto e n˜ao tem ne- nhuma permiss˜ao no grupo de permiss˜oes, o sistema mostra uma caixa de di´alogo ao usu´ario que descreve o grupo de permiss˜oes que o aplicativo quer acessar. Se um aplicativo solicita uma permiss˜ao perigosa listada no seu manifesto e o apli- cativo j´a tem outra permiss˜ao perigosa no mesmo grupo de permiss˜oes, o sistema imediatamente concede a permiss˜ao sem nenhuma intera¸c˜ao com o usu´ario (Google,

2019d). As permiss˜oes perigosas juntamente com seus grupos est˜ao listadas a seguir na Tabela 2.1.

MICROPHONE RECORD AUDIO

PHONE READ PHONE STATE, CALL PHONE, READ CALL LOG, WRITE CALL LOG, ADD VOICEMAIL, USE SIP, PROCESS OUTGOING CALLS

SENSORS BODY SENSORS

SMS SEND SMS, RECEIVE SMS, READ SMS, RECEIVE WAP PUSH, RE- CEIVE MMS

STORAGE READ EXTERNAL STORAGE, WRITE EXTERNAL STORAGE

• Intent - permite iniciar uma atividade em outro aplicativo descrevendo uma a¸c˜ao simples que vocˆe gostaria de executar (como “exibir um mapa” ou “tirar uma foto- grafia”) em um objeto Intent. Esse tipo de intent ´e chamado de impl´ıcito, porque n˜ao especifica o componente do aplicativo a iniciar. Em vez disso, ele especifica uma a¸c˜ao que fornece alguns dados com os quais realizar a a¸c˜ao. Ao chamar startActi- vity() ou startActivityForResult() e passar um intent impl´ıcito, o sistema resolve-o para um aplicativo que pode process´a-lo e inicia a Activity correspondente. Se hou- ver mais de um aplicativo que pode processar, o sistema apresentar´a ao usu´ario uma caixa de di´alogo para escolher o aplicativo a usar (Google,2019c).

• Service - componente de aplicativo que pode executar opera¸c˜oes de execu¸c˜ao de- morada em segundo plano e n˜ao fornece uma interface com o usu´ario. Outro com- ponente do aplicativo pode iniciar um servi¸co e continua em execu¸c˜ao em segundo plano, mesmo se o usu´ario alternar para outro aplicativo. Por exemplo, um servi¸co pode lidar com transa¸c˜oes de rede, tocar m´usica, executar Entrada/Sa´ıda de arqui- vos ou interagir com um Content Provider, tudo em segundo plano (Google,2019f). Existem trˆes diferentes tipos de Service:

– Foreground: realiza opera¸c˜oes que s˜ao percept´ıveis ao usu´ario, como por exem- plo, um aplicativo de ´audio usaria um service em primeiro plano para reproduzir uma faixa de ´audio. Este tipo de service continua em execu¸c˜ao mesmo quando o usu´ario n˜ao est´a mais interagindo com a aplica¸c˜ao.

– Background : executa opera¸c˜oes que n˜ao s˜ao percebidas diretamente pelo usu´ario. Por exemplo, se um aplicativo usasse uma service para compactar seu armaze- namento, isso geralmente seria uma service em segundo plano.

– Bound : quando um componente do aplicativo chama bindService() para vin- cul´a-lo. Uma service bound ou em portuguˆes vinculada oferece uma interface servidor-cliente que permite que os componentes interajam com a interface, en- viem solicita¸c˜oes, recebam resultados, mesmo em processos com comunica¸c˜ao interprocessual (IPC). Um servi¸co vinculado permanece em execu¸c˜ao somente enquanto outro componente do aplicativo estiver vinculado a ele.

14 Cap´ıtulo 2. Levantamento bibliogr´afico