O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
This page was translated by the Cloud Translation API.
Switch to English

Armazenamento

Ícone HAL de armazenamento externo do Android

O Android evoluiu com o 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 meio físico, como um cartão SD ou USB, 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; Android 6.0 adicionou suporte a USB. O armazenamento emulado é fornecido expondo uma parte do armazenamento interno por meio 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 , que é fornecido por mídia física, como um cartão SD ou USB, que é criptografado e formatado para se comportar como armazenamento interno. O armazenamento adotável pode armazenar todos os tipos de dados de aplicativos.

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, grupo e modos de arquivos em dispositivos de armazenamento externos agora são sintetizados com base na estrutura de diretório. Isso permite que os aplicativos gerenciem seus diretórios específicos de pacote 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 dispositivos de armazenamento bruto em um daemon FUSE.

A partir do Android 10, os aplicativos voltados para o Android 9 e versões anteriores têm como padrão o armazenamento legado e podem optar pelo armazenamento isolado. Apps voltados para o Android 10 e padrão para armazenamento isolado podem desativar temporariamente esse recurso . Use o atributo de 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 restritas por software, se o instalador não colocou o aplicativo na lista de permissões, a permissão controla o acesso apenas às coleções auditiva e visual, sem acesso ao cartão SD. Isso se aplica mesmo se o aplicativo solicitar armazenamento legado. Para obter mais informações sobre restrições rígidas e restrições flexíveis, consulte Restrições rígidas e flexíveis no Android 10 .

Se o instalador colocou a permissão na lista de permissões, um aplicativo em execução no modo legado obtém o comportamento de permissão não isolado. A permissão controla o acesso do cartão SD e as coleções aural e visual. Isso acontece quando o aplicativo é direcionado ao Android 9 ou inferior e não ativa o armazenamento isolado ou é direcionado ao Android 10 e desativa.

O estado da lista de permissões pode ser especificado apenas no momento da instalação e não pode ser alterado até que o aplicativo seja 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 em que os aplicativos solicitam recursos quando necessários no tempo de execução. Como o novo modelo inclui as permissões READ/WRITE_EXTERNAL_STORAGE , a plataforma precisa conceder acesso de armazenamento dinamicamente sem interromper ou reiniciar aplicativos já em execução. Ele faz isso 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 namespace raiz onde o adbd e outros componentes do sistema residem.
  • /mnt/runtime/read é mostrado para aplicativos com READ_EXTERNAL_STORAGE (Definir LEGACY_STORAGE para Android 10)
  • /mnt/runtime/write é mostrado para aplicativos com WRITE_EXTERNAL_STORAGE

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

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