Los cambios de Scoped Storage en Android Q son un dolor de cabeza, porque el marco de acceso al almacenamiento tiene algunas fallas en este momento.
Android Q está cambiando fundamentalmente la forma en que funciona el almacenamiento en su teléfono. En todas las versiones hasta Pie, el almacenamiento de Android funcionaba como una computadora de escritorio: puedes usar cualquier aplicación que quieras para leer o escribir cualquier archivo (si le otorgas permiso a una aplicación para hacerlo). Con Q, Google está introduciendo (y exigiendo) "Almacenamiento con alcance," lo que hace que Android funcione más como un iPhone, donde el almacenamiento está aislado para cada aplicación. Una aplicación solo puede acceder a sus propios archivos y, si se desinstala, se eliminan todos sus archivos.
Afortunadamente, Android Q aún conserva parte del comportamiento original de Android como sistema de archivos central. Desafortunadamente, ahora es engorroso para el usuario configurar aplicaciones para acceder a él y ha reducido significativamente el rendimiento y la capacidad. Y los desarrolladores tendrán que recodificar sustancialmente las aplicaciones para admitirlo.
Aplicaciones que necesitan acceso general al sistema de archivos, p. una suite ofimática, un editor de imágenes o un administrador de archivos ahora necesitarán usar una API de Android llamada "Marco de acceso al almacenamiento" (SAF), para todas las operaciones con archivos. SAF ha estado disponible desde Android 5.0 Lollipop, pero los desarrolladores tienden a no usarlo a menos que sea necesario, ya que tiene una versión difícil y deficiente. API documentada, una mala experiencia de usuario, un rendimiento deficiente y una confiabilidad deficiente (en gran parte en forma de implementación específica del proveedor del dispositivo). asuntos). Como resultado de la dificultad para realizar la transición a SAF, Google decidió permitir aplicaciones que aún no indican La compatibilidad con Android Q funcionará como antes, pero esto cambiará cuando Play Store requiera que todas las aplicaciones sean compatibles con Q. el próximo año.
El cambio más obvio para el usuario con SAF es la experiencia de otorgar acceso al almacenamiento a una aplicación. Para que una aplicación obtenga acceso, realiza una solicitud al sistema operativo, que luego muestra una pantalla de selección de directorio. En esta pantalla, el usuario selecciona la raíz de una jerarquía de carpetas en la que esa aplicación podrá leer y escribir archivos. El usuario debe pasar por este proceso para cada aplicación que requiera acceso a archivos locales, o dos veces por aplicación si también necesita otorgarle acceso a una tarjeta SD externa.
Google al menos mejoró este proceso durante qbeta 3, ya que las versiones beta anteriores no permitían que una aplicación sugiriera siquiera una ubicación para que el usuario la seleccionara, lo que requería que el usuario hiciera bastante trabajo para encontrar realmente el almacenamiento principal de su dispositivo.
El rendimiento de E/S de archivos se ve afectado en cierta medida con SAF, pero el problema más destacado reside en la configuración de archivos. operaciones de directorio, donde es ~ 25 a 50 veces más lento que el acceso a archivos convencional posible en Tarta. En el caso de los administradores de archivos, eso significa que llevará mucho más tiempo realizar búsquedas y cálculos de uso de almacenamiento. Un informe de error con una aplicación de demostración es disponible aquí.
Un problema de rendimiento aún mayor es que algunas aplicaciones tendrán que copiar archivos a su área de "almacenamiento de alcance" local antes de poder trabajar con ellos. Esto puede resultar problemático cuando dichos archivos tienen un tamaño de varios gigabytes, p. en el caso de archivos de vídeo o archivos comprimidos. Muchas aplicaciones de Android aprovechan la asombrosa cantidad de bibliotecas Java de código abierto en la comunidad de desarrolladores, y estas bibliotecas comúnmente requieren acceso directo al sistema de archivos para funcionar. No son específicos de Android y requerirían reescribirlos para que funcionen con SAF. Peor aún, muchas de las bibliotecas internas de Android no funcionan con él, como el administrador de paquetes o la API zip. Por ejemplo, un administrador de archivos ni siquiera podrá mostrar el ícono de un archivo APK (usando la API estándar de Android) sin antes copiar el APK completo a su propia área de almacenamiento. Informe de error.
Para las personas con inclinaciones técnicas, actualmente es posible deshabilitar el "Almacenamiento con alcance" de Android Q por aplicación a través de ADB usando un comando appops. Los usuarios root pueden ejecutar los comandos directamente en su dispositivo sin una computadora de escritorio. Dichos comandos se describen en la documentación como características del desarrollador y, por lo tanto, pueden eliminarse en cualquier momento.
Habilite el acceso al almacenamiento general para una aplicación:
adb shell cmd appops set your-package-name android: legacy_storage allow && \adb shell am force-stop your-package-nameDeshabilite el acceso al almacenamiento general para una aplicación:
adb shell cmd appops set your-package-name android: legacy_storage default && \adb shell am force-stop your-package-nameGoogle promociona los beneficios de seguridad y privacidad de este cambio, pero técnicamente hablando, no hay ninguna mejora. Las aplicaciones han tenido la capacidad de almacenar archivos de forma privada desde Android 1.0 y casi todas las aplicaciones utilizan esta capacidad. Cuando le otorgas a una aplicación acceso al directorio raíz de tu almacenamiento a través de SAF, esta puede leer, escribir y enviar cualquier archivo que desee. quiere a su nefasto desarrollador exactamente de la misma manera que lo haría cuando le concedió a una aplicación acceso al almacenamiento en Pie.
La única "mejora de seguridad" se produce porque ahora es un proceso más arduo para un usuario hacer esto. A menos, por supuesto, que una aplicación sólo quiera robar tu información más personal, como fotos y vídeos que hayas tomado, para lo cual Google ha agregado una solución de acceso alternativa que utiliza una simple ventana emergente de seguridad, haga clic en Sí. diálogo.
No se sabe qué beneficios espera conseguir Google con este cambio. La razón oficial declarada en la documentación beta de Android Q es "dar a los usuarios más control sobre sus archivos y limitar el acceso a archivos". desorden." El almacenamiento con alcance, en su forma actual, es una nueva limitación de lo que el usuario puede hacer, no una extensión de su control. La afirmación de reducir el desorden puede ser algo válida, pero sólo porque el cambio reduce la capacidad de utilizar archivos. Y el "desorden" aumenta si se tiene en cuenta el problema de que algunas aplicaciones ahora tienen que duplicar archivos para funcionar con ellas.
Si Google está realmente preocupado por dar a los usuarios más control sobre los archivos y el desorden, debería diseñar una solución que aborda directamente eso, en lugar de calificar falsamente el diseño actual de Android Q como tal mejora. La respuesta más simple sería permitir que los usuarios decidan si quieren que una aplicación tenga acceso general o de alcance al sistema de archivos, utilizando el cuadro de diálogo de solicitud de permiso de almacenamiento existente. Si existe una preocupación particular por los usuarios que toman malas decisiones aquí, ciertamente es posible hacer que ese diálogo sea más prominente y requerir interacción adicional del usuario para aprobar una aplicación por completo acceso.
La respuesta a cómo Android puede dar a los usuarios más control sobre sus archivos es darles más control, no quitárselo y limitar fundamentalmente las capacidades de la plataforma Android.
Nota del editor: este es un artículo invitado escrito por un miembro senior de XDA tliebeck, mejor conocido por su trabajo en Explorador de archivos FX. El contenido de este artículo refleja su propia opinión y análisis de las restricciones de almacenamiento con alcance de Android Q, con aportaciones y ediciones mínimas de Mishaal Rahman, editor en jefe de XDA-Developers. Nos comunicamos con Google para preguntarles sobre algunas de estas inquietudes, pero al momento de la publicación no hemos recibido respuesta de la empresa.