O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Armazenamento

Ícone HAL de armazenamento externo Android

O Android evoluiu ao longo do tempo para oferecer suporte a uma ampla variedade de tipos e recursos de dispositivos de armazenamento. Todas as versões do Android suportam dispositivos com armazenamento tradicional , que inclui armazenamento portátil e emulado. O armazenamento portátil pode ser fornecido por mídia física, como um cartão SD ou USB, ou seja, para transferência temporária de dados / armazenamento de arquivos. A mídia física pode permanecer com o dispositivo por um longo período de tempo, mas não está ligada ao dispositivo e pode ser removida. Os cartões SD estão disponíveis como armazenamento portátil desde o Android 1.0; O Android 6.0 adicionou suporte USB. O armazenamento emulado é fornecido expondo uma parte do armazenamento interno através de uma camada de emulação e está disponível desde o Android 3.0.

A partir do Android 6.0, o Android suporta armazenamento adotável , fornecido por mídia física, como um cartão SD ou USB, criptografado e formatado para se comportar como o armazenamento interno. O armazenamento adotável pode armazenar todos os tipos de dados do aplicativo.

Permissões

O acesso ao armazenamento externo é protegido por várias permissões do Android. A partir do Android 1.0, o acesso de gravação é protegido com a permissão WRITE_EXTERNAL_STORAGE . A partir do Android 4.1, o acesso de leitura é protegido com a permissão READ_EXTERNAL_STORAGE .

A partir do Android 4.4, o proprietário, o grupo e os modos de arquivos em dispositivos de armazenamento externos agora são sintetizados com base na estrutura de diretórios. Isso permite que os aplicativos gerenciem seus diretórios específicos de pacotes no armazenamento externo sem exigir que eles tenham a ampla permissão WRITE_EXTERNAL_STORAGE . Por exemplo, o aplicativo com o nome do pacote com.example.foo agora pode acessar livremente Android/data/com.example.foo/ em dispositivos de armazenamento externos sem permissões. Essas permissões sintetizadas são realizadas envolvendo os dispositivos de armazenamento não processados ​​em um daemon do FUSE.

A partir do Android 10, os aplicativos que segmentam o Android 9 e reduzem o padrão para o armazenamento herdado e podem ativar o armazenamento isolado. Aplicativos direcionados ao Android 10 e padrão para armazenamento isolado podem desativá- lo temporariamente . Use o atributo manifesto requestLegacyExternalStorage , que controla o modelo de armazenamento, para alterar o estado padrão.

Como as permissões READ_EXTERNAL_STORAGE e WRITE_EXTERNAL_STORAGE são com restrição restrita, se o instalador não colocar na lista de permissões o aplicativo, a permissão controla o acesso apenas às coleções auditivas e visuais, sem acesso ao cartão SD. Isso se aplica mesmo que o aplicativo solicite armazenamento herdado. Para obter mais informações sobre restrições de hardware e de software, consulte Restrições de hardware e software no Android 10 .

Se o instalador colocou a permissão na lista de permissões, um aplicativo em execução no modo herdado obtém o comportamento da permissão não isolada. A permissão controla o acesso ao cartão SD e as coleções auditivas e visuais. Isso acontece quando o aplicativo segmenta o Android 9 ou inferior e não aceita armazenamento isolado ou o Android 10 e desativa.

O estado da lista de desbloqueio pode ser especificado apenas no momento da instalação e não pode ser alterado até que o aplicativo tenha sido instalado.

Para obter mais informações sobre como definir a permissão READ_EXTERNAL_STORAGE , consulte setWhitelistedRestrictedPermissions() na classe PackageInstaller.SessionParams .

Permissões de tempo de execução

O Android 6.0 introduz um novo modelo de permissões de tempo de execução , no qual os aplicativos solicitam recursos quando necessário em tempo de execução. Como o novo modelo inclui as permissões READ/WRITE_EXTERNAL_STORAGE , a plataforma precisa conceder dinamicamente acesso ao armazenamento sem interromper ou reiniciar os aplicativos já em execução. Isso é feito mantendo três visualizações distintas de todos os dispositivos de armazenamento montados:

  • /mnt/runtime/default é mostrado para aplicativos sem permissões especiais de armazenamento e para o espaço para nome raiz onde adbd e outros componentes do sistema.
  • /mnt/runtime/read é mostrado para aplicativos com READ_EXTERNAL_STORAGE (Defina LEGACY_STORAGE para Android 10)
  • /mnt/runtime/write é mostrado para aplicativos com WRITE_EXTERNAL_STORAGE

No momento da bifurcação do Zygote, criamos um espaço para nome de montagem para cada aplicativo em execução e vinculamos a montagem à visualização inicial apropriada. Mais tarde, quando as permissões de tempo de execução são concedidas, o vold salta para o namespace de montagem dos aplicativos já em execução e o bind monta a visualização atualizada no lugar. Observe que os downgrades de permissão sempre resultam na morte do aplicativo.

A funcionalidade setns() usada para implementar esse recurso requer pelo menos o Linux 3.8, mas os patches foram portados com êxito para o Linux 3.4. O teste PermissionsHostTest CTS pode ser usado para verificar o comportamento correto do kernel.