As mudanças no armazenamento com escopo no Android Q são uma dor de cabeça, porque o Storage Access Framework tem algumas falhas no momento.
O Android Q está mudando fundamentalmente a forma como o armazenamento funciona no seu telefone. Em todas as versões até o Pie, o armazenamento do Android funcionava como um computador desktop: você pode usar qualquer aplicativo que desejar para ler ou gravar qualquer arquivo (se você conceder permissão a um aplicativo para fazer isso). Com Q, o Google está introduzindo (e exigindo) "Armazenamento com escopo”, o que faz com que o Android funcione mais como um iPhone, onde o armazenamento é isolado para cada aplicativo. Um aplicativo só pode acessar seus próprios arquivos e, se for desinstalado, todos os seus arquivos serão excluídos.
Felizmente, o Android Q ainda mantém parte do comportamento original do Android de um sistema de arquivos central. Infelizmente, agora é complicado para o usuário configurar aplicativos para acessá-lo e reduziu significativamente o desempenho e a capacidade. E os desenvolvedores terão que recodificar substancialmente os aplicativos para suportá-lo.
Aplicativos que precisam de acesso geral ao sistema de arquivos, por ex. um pacote de escritório, editor de imagens ou gerenciador de arquivos agora precisará usar uma API Android chamada "Estrutura de acesso ao armazenamento" (SAF), para todas as operações de arquivo. O SAF está disponível desde o Android 5.0 Lollipop, mas os desenvolvedores tendem a não usá-lo a menos que seja necessário, pois é difícil e de baixa qualidade. API documentada, uma experiência de usuário insatisfatória, desempenho insatisfatório e confiabilidade insatisfatória (em grande parte na forma de implementação específica do fornecedor do dispositivo problemas). Devido à dificuldade de transição para SAF, o Google decidiu permitir aplicativos que ainda não indiquem O suporte do Android Q funcionará como antes, mas isso mudará quando a Play Store exigir que todos os aplicativos sejam compatíveis com Q Próximo ano.
A mudança mais óbvia para o usuário no SAF é a experiência de conceder acesso ao armazenamento a um aplicativo. Para que um aplicativo obtenha acesso, ele faz uma solicitação ao sistema operacional, que exibe uma tela de seleção de diretório. Nesta tela o usuário seleciona a raiz de uma hierarquia de pastas na qual aquele aplicativo poderá ler e gravar arquivos. O usuário deve passar por esse processo para cada aplicativo que requer acesso a arquivos locais, ou duas vezes por aplicativo, se precisar também conceder acesso a um cartão SD externo.
O Google pelo menos melhorou esse processo para Q beta 3, já que os betas anteriores não permitiam que um aplicativo sugerisse um local para o usuário selecionar, o que exigia que o usuário fizesse bastante trabalho para realmente encontrar o armazenamento primário do dispositivo.
O desempenho de E/S de arquivos sofre um certo impacto no SAF, mas o problema mais notável está no arquivo operações de diretório, onde é cerca de 25 a 50 vezes mais lento do que o acesso convencional a arquivos possível em Torta. No caso de gerenciadores de arquivos, isso significa que levará muito mais tempo para realizar pesquisas e cálculos de uso de armazenamento. Um relatório de bug com um aplicativo de demonstração é disponivel aqui.
Um problema de desempenho ainda maior é que alguns aplicativos terão que copiar arquivos para sua área local de “armazenamento com escopo definido” antes de poder trabalhar com eles. Isso pode ser problemático quando esses arquivos têm vários gigabytes de tamanho, por ex. no caso de arquivos de vídeo ou arquivos compactados. Muitos aplicativos Android aproveitam o incrível número de bibliotecas Java de código aberto na comunidade de desenvolvedores, e essas bibliotecas geralmente exigem acesso direto ao sistema de arquivos para funcionar. Eles não são específicos do Android e exigiriam reescrita para funcionar com SAF. Pior ainda, muitas das bibliotecas internas do Android não funcionam com ele, como o gerenciador de pacotes ou a API zip. Por exemplo, um gerenciador de arquivos nem mesmo será capaz de exibir o ícone de um arquivo APK (usando a API padrão do Android) sem primeiro copiar o APK inteiro para sua própria área de armazenamento com escopo definido. Relatório de erro.
Para pessoas com conhecimento técnico, atualmente é possível desativar o "armazenamento com escopo" do Android Q por aplicativo via ADB usando um comando appops. Os usuários root podem executar os comandos diretamente em seus dispositivos, sem um computador desktop. Tais comandos são descritos na documentação como recursos de desenvolvedor e, portanto, podem ser removidos a qualquer momento.
Habilite o acesso geral ao armazenamento para um aplicativo:
adb shell cmd appops set your-package-name android: legacy_storage allow && \adb shell am force-stop your-package-nameDesative o acesso geral ao armazenamento para um aplicativo:
adb shell cmd appops set your-package-name android: legacy_storage default && \adb shell am force-stop your-package-nameO Google apregoa os benefícios de segurança e privacidade dessa mudança, mas, tecnicamente falando, não há melhorias. Os aplicativos têm a capacidade de armazenar arquivos de forma privada desde o Android 1.0, e quase todos os aplicativos fazem uso desse recurso. Quando você concede a um aplicativo acesso ao diretório raiz do seu armazenamento via SAF, ele pode ler, gravar e enviar qualquer arquivo que desejar. deseja ao seu desenvolvedor nefasto exatamente da mesma maneira que faria quando você concedeu a um aplicativo acesso ao armazenamento no Pie.
A única “melhoria de segurança” ocorre porque agora é um processo mais árduo para um usuário fazer isso. A menos, é claro, que um aplicativo queira apenas roubar suas informações mais pessoais, como fotos e vídeos que você tomada, para a qual o Google adicionou uma solução de acesso alternativa que usa um simples pop-up de segurança clique-sim diálogo.
Não se sabe quais benefícios o Google espera alcançar com esta mudança. O motivo oficial declarado na documentação beta do Android Q é “dar aos usuários mais controle sobre seus arquivos e limitar o arquivo desordem." O armazenamento com escopo definido, em sua forma atual, é uma nova limitação do que o usuário pode fazer, e não uma extensão de sua capacidade. ao controle. A alegação de reduzir a desordem pode ser válida, mas apenas porque a mudança reduz a capacidade de usar arquivos. E a “desordem” aumenta quando você considera o problema de alguns aplicativos agora terem que duplicar arquivos para funcionar com eles.
Se o Google está realmente preocupado em dar aos usuários mais controle sobre arquivos e desordem, eles deveriam arquitetar um solução que aborda isso diretamente, em vez de rotular falsamente o design atual do Android Q como tal melhoria. A resposta mais simples seria permitir que os usuários decidissem se desejam que um aplicativo tenha acesso geral ou com escopo ao sistema de arquivos, usando a caixa de diálogo de solicitação de permissão de armazenamento existente. Se houver uma preocupação particular com os usuários que tomam decisões erradas aqui, certamente é possível tornar essa caixa de diálogo mais proeminente e exigir interação adicional do usuário para aprovar um aplicativo totalmente acesso.
A resposta sobre como o Android pode dar aos usuários mais controle sobre seus arquivos é, na verdade, dar aos usuários mais controle, e não retirá-lo e restringir fundamentalmente os recursos da plataforma Android.
Nota do Editor: Este é um artigo convidado escrito por XDA Senior Member tliebeck, mais conhecido por seu trabalho em Explorador de arquivos FX. O conteúdo deste artigo reflete sua própria opinião e análise das restrições de armazenamento com escopo do Android Q, com contribuição e edição mínimas de Mishaal Rahman, editor-chefe do XDA-Developers. Entramos em contato com o Google para perguntar sobre algumas dessas preocupações, mas não recebemos resposta da empresa até o momento da publicação.