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 são geralmente escritos na linguagem de programação Java e executados na máquina virtual Android Runtime (ART). 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 .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 UI para o usuário, mas não é obrigatório - algumas atividades nunca exibem UIs. 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-se" a um serviço e invocam métodos nele por meio de chamadas de procedimento remoto. Um exemplo de serviço é um reprodutor de mídia: 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 tocando mesmo quando a IU é 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: acessando 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 de aplicativos Android a recursos que, se usados incorretamente ou maliciosamente, podem impactar negativamente a experiência do usuário, a rede ou os dados no dispositivo.
Essas restrições são implementadas de diversas formas. Algumas capacidades são restritas por uma falta intencional de APIs para funcionalidades sensíveis (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 acontece com o isolamento de armazenamento por aplicativo. Em outros casos, as APIs confidenciais destinam-se ao uso por aplicativos confiáveis e são 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ó são acessíveis 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 6.0 e superiores do Android usam um modelo de permissões de tempo de execução . Se um usuário solicitar um recurso de um aplicativo que exija uma API protegida, o sistema exibirá uma caixa de diálogo solicitando que o usuário negue ou conceda a permissão.
Uma vez concedidas, as permissões serã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 serã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 dos aplicativos que instalaram anteriormente. Os usuários também podem desligar algumas funcionalidades globalmente quando quiserem, como desabilitar GPS, rádio ou wi-fi.
No caso de um aplicativo tentar usar um recurso protegido que não tenha sido declarado no manifesto do aplicativo, a falha de permissão normalmente resultará em uma exceção de segurança sendo devolvida ao aplicativo. As verificações de permissão de API protegida são aplicadas no nível mais baixo possível para evitar evasão. Um exemplo de mensagem do usuário quando um aplicativo é instalado enquanto solicita acesso a APIs protegidas é mostrado na Figura 2 .
As permissões padrão do sistema estã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 manter 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 subscriptionOrSystem.
Como os usuários entendem os aplicativos de terceiros
O Android se esforça para deixar claro aos 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 será solicitado novamente a confirmar quaisquer permissões.
Há muitos motivos 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 elas atendem à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 todas as vezes tornaria o usuário mais lento e impediria que o Android proporcionasse uma ótima experiência ao usuário. Fazer com que o usuário revise as permissões no momento da instalação dá ao usuário a opção de não instalar o aplicativo caso se sinta desconfortável.
Além disso, muitos estudos de interface do usuário mostraram que solicitar excessivamente ao usuário faz com que ele comece a dizer "OK" para qualquer caixa de diálogo exibida. Um dos objetivos de segurança do Android é transmitir efetivamente informações de segurança importantes ao usuário, o que não pode ser feito por meio de caixas de diálogo que o usuário será treinado para ignorar. Ao apresentar as informações importantes uma vez e somente quando forem importantes, é mais provável que o usuário pense 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 entendam e discutam facilmente os recursos do aplicativo. Embora nem sempre seja possível que todos os usuários 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 inesperadas de permissões podem levar usuários mais sofisticados a fazer perguntas críticas sobre a funcionalidade do aplicativo e compartilhar suas preocupações em locais como o Google Play , onde ficam visíveis para todos os usuários.
| Permissões na instalação do aplicativo – Google Tradutor | 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. Os 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” de visualizar a URL criando uma instância de Intent e entregando-a ao sistema. O sistema localiza algum outro trecho de código (neste caso, o Navegador) que sabe como lidar com aquele 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 armazenamento de dados que fornece acesso aos dados no dispositivo; o exemplo clássico é o ContentProvider 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 IPC usando outros mecanismos, como soquetes de rede ou arquivos graváveis mundialmente, essas são as estruturas Android IPC recomendadas. Os desenvolvedores Android serão incentivados a usar as melhores práticas 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 para a rede. A plataforma Android colocou APIs sensíveis ao custo na lista de APIs protegidas controladas pelo sistema operacional. O usuário terá que conceder permissão explícita a aplicativos de terceiros que solicitem o uso de APIs sensíveis a custos. 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, o que pode causar cobranças adicionais. O usuário pode escolher se permite que o aplicativo envie a mensagem ou bloqueie-a.
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 às informações pessoais (contatos) na memória do cartão SIM. As aplicações também não podem acessar comandos AT, pois estes são gerenciados exclusivamente pela Radio Interface Layer (RIL). O RIL não fornece APIs de alto nível para esses comandos.
Informações pessoais
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 à aplicação. 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 durante a 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 poderá aplicar permissões ao mecanismo IPC que são aplicadas pelo sistema operacional.
Dispositivos de entrada de dados confidenciais
Os dispositivos Android frequentemente fornecem dispositivos de entrada de dados confidenciais que permitem que os aplicativos interajam com o ambiente circundante, como câmera, microfone ou GPS. Para que um aplicativo de terceiros acesse esses dispositivos, primeiro ele deve receber acesso explicitamente do 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 quiser saber a localização do usuário, o aplicativo exigirá 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, caso o usuário não queira que nenhum aplicativo acesse sua localização, então o usuário pode executar o aplicativo “Configurações”, ir em “Localização e Segurança”, e desmarcar “Usar redes sem fio” e “Ativar satélites GPS” . Isto 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 que podem revelar indiretamente características sobre o usuário, suas preferências e a maneira como ele usa um dispositivo.
Por padrão, os aplicativos não têm acesso aos registros 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 certificadoras
O Android inclui um conjunto de autoridades de certificação de 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 fornecidas 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, já que a modificação pelos fabricantes dos 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 que a CA seja adicionada à CA padrão do Android 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 das 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 de 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 serem assinados são rejeitados pelo Google Play ou pelo instalador do pacote no dispositivo Android.
No Google Play, a assinatura de aplicativos une 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 sem modificações para o dispositivo Android; e os desenvolvedores podem ser responsabilizados pelo comportamento de seus aplicativos.
No Android, a assinatura de aplicativos é a primeira etapa 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 sob diferentes IDs de usuário. A assinatura de aplicativos garante que um aplicativo não possa acessar qualquer outro aplicativo, exceto através de 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 terá a opção de especificar no manifesto que compartilhará um UID com o outro de forma semelhante. 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 realiza verificação de CA para certificados de aplicativos.
Os aplicativos também são capazes de 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 sandboxes 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 de aplicativos
Android 4.2 e versões posteriores suportam verificação de aplicativos. Os usuários podem optar por ativar “Verificar aplicativos" e ter os aplicativos 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 .
Gestão de Direitos Digitais
A plataforma Android fornece uma estrutura 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 DRM um dispositivo suporta são deixados para o fabricante do dispositivo.
A estrutura Android DRM é implementada em duas camadas arquitetônicas (veja a figura abaixo):
Uma API de estrutura DRM, que é exposta a aplicativos por meio da estrutura de aplicativos Android e executada por meio do ART 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 (agentes) de DRM para lidar com gerenciamento de direitos e descriptografia para vários esquemas de DRM
Figura 3. Arquitetura de Gerenciamento de Direitos Digitais na plataforma Android