Elementos de Aplicativos
O Android fornece uma plataforma de código aberto e um ambiente de aplicativos para dispositivos móveis. O sistema operacional principal é baseado no kernel Linux. Os aplicativos Android geralmente são escritos na linguagem de programação Java e executados na máquina virtual Dalvik. No entanto, os aplicativos também podem ser escritos em código nativo. Os aplicativos são instalados a partir de um único arquivo com a extensão de arquivo .apk.
Os principais blocos de construção de aplicativos Android são:
AndroidManifest.xml : O arquivo AndroidManifest.xml é o arquivo de controle que informa ao sistema o que fazer com todos os componentes de nível superior (especificamente atividades, serviços, receptores de transmissão e provedores de conteúdo descritos abaixo) em um aplicativo. Isso também especifica quais permissões são necessárias.
Atividades : Uma atividade é, geralmente, o código para uma única tarefa focada no usuário. Geralmente inclui a exibição de uma interface do usuário para o usuário, mas não é obrigatório - algumas atividades nunca exibem interfaces de usuário. Normalmente, uma das atividades do aplicativo é o ponto de entrada para um aplicativo.
Serviços : Um serviço é um corpo de código executado em segundo plano. Ele pode ser executado em seu próprio processo ou no contexto do processo de outro aplicativo. Outros componentes "ligam" a um serviço e invocam métodos nele por meio de chamadas de procedimento remoto. Um exemplo de serviço é um media player: mesmo quando o usuário sai da interface de seleção de mídia, o usuário provavelmente ainda pretende que a música continue tocando. Um serviço mantém a música funcionando mesmo quando a interface do usuário é concluída.
Broadcast Receiver : Um BroadcastReceiver é um objeto que é instanciado quando um mecanismo IPC conhecido como Intent é emitido pelo sistema operacional ou outro aplicativo. Um aplicativo pode registrar um receptor para a mensagem de bateria fraca, por exemplo, e alterar seu comportamento com base nessa informação.
O modelo de permissão do Android: como acessar APIs protegidas
Todos os aplicativos no Android são executados em um Application Sandbox . Por padrão, um aplicativo Android só pode acessar uma gama limitada de recursos do sistema. O sistema gerencia o acesso do aplicativo Android a recursos que, se usados incorretamente ou maliciosamente, podem afetar negativamente a experiência do usuário, a rede ou os dados no dispositivo.
Essas restrições são implementadas em uma variedade de formas diferentes. Alguns recursos são restritos por uma falta intencional de APIs para a funcionalidade sensível (por exemplo, não há API Android para manipular diretamente o cartão SIM). Em alguns casos, a separação de funções fornece uma medida de segurança, como no isolamento de armazenamento por aplicativo. Em outros casos, as APIs confidenciais são destinadas ao uso por aplicativos confiáveis e protegidas por meio de um mecanismo de segurança conhecido como Permissões.
Essas APIs protegidas incluem:
- Funções da câmera
- Dados de localização (GPS)
- Funções Bluetooth
- Funções de telefonia
- Funções SMS/MMS
- Conexões de rede/dados
Esses recursos são acessíveis apenas por meio do sistema operacional. Para fazer uso das APIs protegidas no dispositivo, um aplicativo deve definir os recursos necessários em seu manifesto. Todas as versões do Android 6.0 e superiores usam um modelo de permissões de tempo de execução . Se um usuário solicitar um recurso de um aplicativo que requer uma API protegida, o sistema exibirá uma caixa de diálogo, solicitando que o usuário negue ou permita a permissão.
Uma vez concedidas, as permissões são aplicadas ao aplicativo enquanto ele estiver instalado. Para evitar confusão do usuário, o sistema não notifica o usuário novamente sobre as permissões concedidas ao aplicativo, e os aplicativos incluídos no sistema operacional principal ou agrupados por um OEM não solicitam permissões do usuário. As permissões são removidas se um aplicativo for desinstalado, portanto, uma reinstalação subsequente resultará novamente na exibição de permissões.
Nas configurações do dispositivo, os usuários podem visualizar as permissões para aplicativos que instalaram anteriormente. Os usuários também podem desativar algumas funcionalidades globalmente quando quiserem, como desativar GPS, rádio ou wi-fi.
No caso de um aplicativo tentar usar um recurso protegido que não foi declarado no manifesto do aplicativo, a falha de permissão normalmente resultará em uma exceção de segurança sendo lançada de volta ao aplicativo. As verificações de permissão de API protegidas são aplicadas no nível mais baixo possível para evitar fraudes. Um exemplo de mensagens do usuário quando um aplicativo é instalado ao solicitar acesso a APIs protegidas é mostrado na Figura 2 .
As permissões padrão do sistema são descritas em https://developer.android.com/reference/android/Manifest.permission.html . Os aplicativos podem declarar suas próprias permissões para uso de outros aplicativos. Essas permissões não estão listadas no local acima.
Ao definir uma permissão, um atributo protectionLevel informa ao sistema como o usuário deve ser informado sobre os aplicativos que exigem a permissão ou quem tem permissão para ter uma permissão. Detalhes sobre como criar e usar permissões específicas do aplicativo estão descritos em https://developer.android.com/guide/topics/security/security.html .
Existem alguns recursos do dispositivo, como a capacidade de enviar intenções de transmissão de SMS, que não estão disponíveis para aplicativos de terceiros, mas que podem ser usados por aplicativos pré-instalados pelo OEM. Essas permissões usam a permissão signatureOrSystem.
Como os usuários entendem os aplicativos de terceiros
O Android se esforça para deixar claro para os usuários quando eles estão interagindo com aplicativos de terceiros e informar o usuário sobre os recursos que esses aplicativos possuem. Antes da instalação de qualquer aplicativo, o usuário recebe uma mensagem clara sobre as diferentes permissões que o aplicativo está solicitando. Após a instalação, o usuário não é solicitado novamente a confirmar nenhuma permissão.
Há muitas razões para mostrar as permissões imediatamente antes do momento da instalação. É quando o usuário está revisando ativamente as informações sobre o aplicativo, o desenvolvedor e a funcionalidade para determinar se ela atende às suas necessidades e expectativas. Também é importante que eles ainda não tenham estabelecido um compromisso mental ou financeiro com o aplicativo e possam facilmente comparar o aplicativo com outros aplicativos alternativos.
Algumas outras plataformas usam uma abordagem diferente para notificação do usuário, solicitando permissão no início de cada sessão ou enquanto os aplicativos estão em uso. A visão do Android é fazer com que os usuários alternem facilmente entre os aplicativos à vontade. Fornecer confirmações a cada vez diminuiria a velocidade do usuário e impediria que o Android oferecesse uma ótima experiência ao usuário. Ter as permissões de revisão do usuário no momento da instalação dá ao usuário a opção de não instalar o aplicativo se se sentir desconfortável.
Além disso, muitos estudos de interface do usuário mostraram que solicitar demais ao usuário faz com que o usuário comece a dizer "OK" para qualquer caixa de diálogo exibida. Um dos objetivos de segurança do Android é transmitir informações de segurança importantes para o usuário, o que não pode ser feito usando caixas de diálogo que o usuário será treinado para ignorar. Ao apresentar as informações importantes uma vez, e somente quando for importante, o usuário tem mais chances de pensar sobre o que está concordando.
Algumas plataformas optam por não mostrar nenhuma informação sobre a funcionalidade do aplicativo. Essa abordagem impede que os usuários compreendam e discutam facilmente os recursos do aplicativo. Embora não seja possível que todos os usuários sempre tomem decisões totalmente informadas, o modelo de permissões do Android torna as informações sobre aplicativos facilmente acessíveis a uma ampla gama de usuários. Por exemplo, solicitações de permissões inesperadas podem fazer com que usuários mais sofisticados façam perguntas críticas sobre a funcionalidade do aplicativo e compartilhem suas preocupações em locais como o Google Play , onde são visíveis para todos os usuários.
| Permissões na instalação do aplicativo -- Google Maps | Permissões de um aplicativo instalado -- Gmail |
 |  |
Figura 1. Exibição de permissões para aplicativos
Comunicação entre processos
Os processos podem se comunicar usando qualquer um dos mecanismos tradicionais do tipo UNIX. Exemplos incluem o sistema de arquivos, soquetes locais ou sinais. No entanto, as permissões do Linux ainda se aplicam.
O Android também fornece novos mecanismos IPC:
Binder : Um mecanismo leve de chamada de procedimento remoto baseado em capacidade projetado para alto desempenho ao executar chamadas em processo e entre processos. O Binder é implementado usando um driver Linux personalizado. Consulte https://developer.android.com/reference/android/os/Binder.html .
Serviços : Os serviços (discutidos acima) podem fornecer interfaces diretamente acessíveis usando o binder.
Intents : Um Intent é um objeto de mensagem simples que representa uma "intenção" de fazer algo. Por exemplo, se seu aplicativo deseja exibir uma página da Web, ele expressa sua "Intenção" para visualizar a URL criando uma instância de Intenção e entregando-a ao sistema. O sistema localiza algum outro pedaço de código (neste caso, o Browser) que sabe como lidar com esse Intent e o executa. As intenções também podem ser usadas para transmitir eventos interessantes (como uma notificação) em todo o sistema. Consulte https://developer.android.com/reference/android/content/Intent.html .
ContentProviders : um ContentProvider é um armazém de dados que fornece acesso aos dados no dispositivo; o exemplo clássico é o ContentProvider que é usado para acessar a lista de contatos do usuário. Um aplicativo pode acessar dados que outros aplicativos expuseram por meio de um ContentProvider, e um aplicativo também pode definir seus próprios ContentProviders para expor seus próprios dados. Consulte https://developer.android.com/reference/android/content/ContentProvider.html .
Embora seja possível implementar o IPC usando outros mecanismos, como soquetes de rede ou arquivos graváveis em todo o mundo, essas são as estruturas de IPC do Android recomendadas. Os desenvolvedores do Android serão incentivados a usar as práticas recomendadas para proteger os dados dos usuários e evitar a introdução de vulnerabilidades de segurança.
APIs sensíveis ao custo
Uma API sensível ao custo é qualquer função que possa gerar um custo para o usuário ou a rede. A plataforma Android colocou APIs sensíveis ao custo na lista de APIs protegidas controladas pelo SO. O usuário terá que conceder permissão explícita a aplicativos de terceiros que solicitem o uso de APIs sensíveis ao custo. Essas APIs incluem:
- Telefonia
- SMS/MMS
- Rede/dados
- Faturamento no aplicativo
- Acesso NFC
O Android 4.2 adiciona mais controle sobre o uso de SMS. O Android fornecerá uma notificação se um aplicativo tentar enviar SMS para um código curto que usa serviços premium que podem causar cobranças adicionais. O usuário pode optar por permitir que o aplicativo envie a mensagem ou bloqueá-la.
Acesso ao cartão SIM
O acesso de baixo nível ao cartão SIM não está disponível para aplicativos de terceiros. O sistema operacional lida com todas as comunicações com o cartão SIM, incluindo o acesso a informações pessoais (contatos) na memória do cartão SIM. Os aplicativos também não podem acessar os comandos AT, pois estes são gerenciados exclusivamente pela camada de interface de rádio (RIL). O RIL não fornece APIs de alto nível para esses comandos.
Informação pessoal
O Android colocou APIs que fornecem acesso aos dados do usuário no conjunto de APIs protegidas. Com o uso normal, os dispositivos Android também acumularão dados do usuário em aplicativos de terceiros instalados pelos usuários. Os aplicativos que optam por compartilhar essas informações podem usar verificações de permissão do sistema operacional Android para proteger os dados de aplicativos de terceiros.
Figura 2. O acesso a dados confidenciais do usuário está disponível apenas por meio de APIs protegidas
Os provedores de conteúdo do sistema que provavelmente contêm informações pessoais ou de identificação pessoal, como contatos e calendário, foram criados com permissões claramente identificadas. Essa granularidade fornece ao usuário uma indicação clara dos tipos de informações que podem ser fornecidas ao aplicativo. Durante a instalação, um aplicativo de terceiros pode solicitar permissão para acessar esses recursos. Se a permissão for concedida, o aplicativo poderá ser instalado e terá acesso aos dados solicitados a qualquer momento no momento da instalação.
Quaisquer aplicativos que coletam informações pessoais terão, por padrão, esses dados restritos apenas ao aplicativo específico. Se um aplicativo optar por disponibilizar os dados para outros aplicativos por meio do IPC, o aplicativo que concede acesso pode aplicar permissões ao mecanismo IPC que são impostas pelo sistema operacional.
Dispositivos de entrada de dados confidenciais
Os dispositivos Android geralmente fornecem dispositivos de entrada de dados confidenciais que permitem que os aplicativos interajam com o ambiente ao redor, como câmera, microfone ou GPS. Para que um aplicativo de terceiros acesse esses dispositivos, primeiro ele deve receber acesso explicitamente fornecido pelo usuário por meio do uso de Permissões do sistema operacional Android. Após a instalação, o instalador solicitará ao usuário permissão para o sensor pelo nome.
Se um aplicativo deseja saber a localização do usuário, o aplicativo requer uma permissão para acessar a localização do usuário. Após a instalação, o instalador perguntará ao usuário se o aplicativo pode acessar a localização do usuário. A qualquer momento, se o usuário não quiser que nenhum aplicativo acesse sua localização, o usuário poderá executar o aplicativo "Configurações", acessar "Localização e segurança" e desmarcar as opções "Usar redes sem fio" e "Ativar satélites GPS" . Isso desativará os serviços baseados em localização para todos os aplicativos no dispositivo do usuário.
Metadados do dispositivo
O Android também se esforça para restringir o acesso a dados que não são intrinsecamente confidenciais, mas podem revelar indiretamente características sobre o usuário, preferências do usuário e a maneira como eles usam um dispositivo.
Por padrão, os aplicativos não têm acesso aos logs do sistema operacional, histórico do navegador, número de telefone ou informações de identificação de hardware/rede. Se um aplicativo solicitar acesso a essas informações no momento da instalação, o instalador perguntará ao usuário se o aplicativo pode acessar as informações. Se o usuário não conceder acesso, o aplicativo não será instalado.
Autoridades de certificação
O Android inclui um conjunto de Autoridades de Certificação do sistema instaladas, que são confiáveis em todo o sistema. Antes do Android 7.0, os fabricantes de dispositivos podiam modificar o conjunto de CAs enviados em seus dispositivos. No entanto, os dispositivos que executam a versão 7.0 e superior terão um conjunto uniforme de CAs do sistema, pois a modificação pelos fabricantes de dispositivos não é mais permitida.
Para ser adicionada como uma nova CA pública ao conjunto de ações do Android, a CA deve concluir o Processo de inclusão de CA da Mozilla e, em seguida, registrar uma solicitação de recurso no Android ( https://code.google.com/p/android/issues/entry ) para ter a CA adicionada à CA do Android padrão definida no Android Open Source Project (AOSP).
Ainda existem CAs que são específicas do dispositivo e não devem ser incluídas no conjunto principal de CAs AOSP, como CAs privadas de operadoras que podem ser necessárias para acessar com segurança componentes da infraestrutura da operadora, como gateways SMS/MMS. Os fabricantes de dispositivos são incentivados a incluir as CAs privadas apenas nos componentes/aplicativos que precisam confiar nessas CAs. Para obter mais detalhes, consulte Configuração de segurança de rede .
Assinatura do aplicativo
A assinatura de código permite que os desenvolvedores identifiquem o autor do aplicativo e atualizem seu aplicativo sem criar interfaces e permissões complicadas. Todo aplicativo executado na plataforma Android deve ser assinado pelo desenvolvedor. Os aplicativos que tentam instalar sem estar assinados são rejeitados pelo Google Play ou pelo instalador do pacote no dispositivo Android.
No Google Play, a assinatura de aplicativos conecta a confiança que o Google tem com o desenvolvedor e a confiança que o desenvolvedor tem com seu aplicativo. Os desenvolvedores sabem que seu aplicativo é fornecido, não modificado para o dispositivo Android; e os desenvolvedores podem ser responsabilizados pelo comportamento de seu aplicativo.
No Android, a assinatura do aplicativo é o primeiro passo para colocar um aplicativo em seu Application Sandbox. O certificado de aplicativo assinado define qual ID de usuário está associado a qual aplicativo; diferentes aplicativos são executados em diferentes IDs de usuário. A assinatura do aplicativo garante que um aplicativo não possa acessar nenhum outro aplicativo, exceto por meio de um IPC bem definido.
Quando um aplicativo (arquivo APK) é instalado em um dispositivo Android, o Gerenciador de Pacotes verifica se o APK foi assinado corretamente com o certificado incluído nesse APK. Se o certificado (ou, mais precisamente, a chave pública no certificado) corresponder à chave usada para assinar qualquer outro APK no dispositivo, o novo APK tem a opção de especificar no manifesto que compartilhará um UID com o outro da mesma forma APKs assinados.
Os aplicativos podem ser assinados por terceiros (OEM, operadora, mercado alternativo) ou autoassinados. O Android fornece assinatura de código usando certificados autoassinados que os desenvolvedores podem gerar sem assistência ou permissão externa. Os pedidos não precisam ser assinados por uma autoridade central. Atualmente, o Android não executa a verificação de CA para certificados de aplicativos.
Os aplicativos também podem declarar permissões de segurança no nível de proteção de assinatura, restringindo o acesso apenas a aplicativos assinados com a mesma chave, mantendo UIDs e caixas de proteção de aplicativos distintos. Um relacionamento mais próximo com um Application Sandbox compartilhado é permitido por meio do recurso UID compartilhado, onde dois ou mais aplicativos assinados com a mesma chave de desenvolvedor podem declarar um UID compartilhado em seu manifesto.
Verificação do aplicativo
Android 4.2 e posterior suportam a verificação de aplicativos. Os usuários podem optar por ativar "Verificar aplicativos" e fazer com que os aplicativos sejam avaliados por um verificador de aplicativos antes da instalação. A verificação de aplicativos pode alertar o usuário se ele tentar instalar um aplicativo que possa ser prejudicial; se um aplicativo for especialmente ruim, poderá bloquear a instalação .
Gerenciamento de direitos digitais
A plataforma Android fornece uma estrutura de DRM extensível que permite que os aplicativos gerenciem conteúdo protegido por direitos de acordo com as restrições de licença associadas ao conteúdo. A estrutura DRM suporta muitos esquemas DRM; quais esquemas de DRM um dispositivo suporta é deixado para o fabricante do dispositivo.
A estrutura do Android DRM é implementada em duas camadas de arquitetura (veja a figura abaixo):
Uma API de estrutura DRM, que é exposta a aplicativos por meio da estrutura de aplicativos Android e executada por meio da Dalvik VM para aplicativos padrão.
Um gerenciador de DRM de código nativo, que implementa a estrutura de DRM e expõe uma interface para plug-ins de DRM (agentes) para lidar com gerenciamento de direitos e descriptografia para vários esquemas de DRM
Figura 3. Arquitetura do Gerenciamento de Direitos Digitais na plataforma Android