Android Q está cambiando fundamentalmente la forma en que funciona el almacenamiento en tu 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 requiriendo) "Almacenamiento con alcance", 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, que consistía en un sistema de archivos central. Lamentablemente, ahora resulta complicado para el usuario configurar aplicaciones para que accedan a él y el rendimiento y la capacidad se han reducido significativamente. Además, los desarrolladores tendrán que recodificar sustancialmente las aplicaciones para que sean compatibles.

Las aplicaciones que necesitan acceso general al sistema de archivos, por ejemplo, una suite ofimática, un editor de imágenes o un gestor de archivos, ahora tendrán que utilizar una API de Android llamada "Storage Access Framework" (SAF), para todas las operaciones con archivos. SAF ha estado disponible desde Android 5.0 Lollipop, pero los desarrolladores tienden a no utilizarlo a menos que sea necesario, ya que tiene una API difícil y mal documentada, una mala experiencia de usuario, un rendimiento deficiente y una fiabilidad deficiente (en gran medida en forma de problemas de implementación específicos del proveedor del dispositivo). Como resultado de la dificultad de la transición a SAF, Google ha decidido permitir que las aplicaciones que todavía no indican compatibilidad con Android Q funcionen como antes, pero esto cambiará cuando Play Store exija que todas las aplicaciones sean compatibles con Q el año que viene.

El cambio más obvio para el usuario con SAF es la experiencia de otorgarle a una aplicación acceso al almacenamiento. 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 realizar 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 paraQ beta 3, ya que las versiones beta anteriores no permitían que una aplicación siquiera sugiriera una ubicación para que el usuario seleccionara, lo querequería que el usuario hiciera un gran trabajopara encontrar 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 se encuentra en las operaciones de directorio de archivos, donde es entre 25 y 50 veces más lento que el acceso a archivos convencional posible en Pie. En el caso de los administradores de archivos, eso significa que se necesitarán órdenes de magnitud más para realizar búsquedas y cálculos de uso de almacenamiento. Haydisponible un informe de errores con una aplicación de demostración aquí.

Ejemplo de ejecución de prueba de SAFTest que muestra la diferencia de rendimiento entre la API de E/S de archivos convencional con SAF.

Un problema de rendimiento aún mayor es que algunas aplicaciones tendrán que copiar archivos a su área de "almacenamiento de ámbito" local antes de poder trabajar con ellos. Esto puede ser problemático cuando dichos archivos tienen un tamaño de varios gigabytes, por ejemplo, en el caso de archivos de video o archivos comprimidos. Muchas aplicaciones de Android aprovechan la increíble cantidad de bibliotecas Java de código abierto en la comunidad de desarrolladores, y estas bibliotecas generalmente requieren acceso directo al sistema de archivos para funcionar. No son específicas de Android y requerirían reescritura para funcionar con SAF. Peor aún, muchas de las bibliotecas internas de Android no funcionarán 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 copiar primero el APK completo a su propia área de almacenamiento de ámbito.Informe de error.

Para los usuarios con conocimientos técnicos, actualmente es posible desactivar el "Almacenamiento con ámbito" de Android Q en cada 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 funciones para desarrolladores y, por lo tanto, pueden eliminarse en cualquier momento.

Habilitar el acceso al almacenamiento general para una aplicación:

adb shell cmd appopssetyour-package-nameandroid:legacy_storageallow&& \adb shell amforce-stopyour-package-name

Deshabilitar el acceso al almacenamiento general para una aplicación:

adb shell cmd appopssetyour-package-nameandroid:legacy_storagedefault&& \adb shell amforce-stopyour-package-name

Google 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 hacen uso de esta capacidad. Cuando le otorgas a una aplicación acceso al directorio raíz de tu almacenamiento a través de SAF, puede leer, escribir y enviar cualquier archivo que desee a su malicioso desarrollador exactamente de la misma manera que podía hacerlo cuando le otorgabas a una aplicación acceso al almacenamiento en Pie.

La única "mejora de seguridad" se debe a que ahora es un proceso más arduo para el usuario realizar esta acción, a menos que, por supuesto, una aplicación solo quiera robar tu información más personal, como las fotos y los vídeos que hayas tomado, para lo cual Google ha añadido una solución de acceso alternativa que utiliza un sencillo cuadro de diálogo de seguridad emergente en el que hay que hacer clic.

No se sabe qué beneficios espera Google lograr con este cambio. La razón oficial que se indica en la documentación de la versión beta de Android Q es “dar a los usuarios más control sobre sus archivos y limitar el desorden de archivos”. El almacenamiento limitado, 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 usar archivos en absoluto. Y el “desorden” aumenta cuando se considera el problema de que algunas aplicaciones ahora tienen que duplicar archivos para trabajar con ellos.

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 aborde directamente esa cuestión, en lugar de etiquetar falsamente el diseño actual de Android Q como una mejora. La respuesta más simple sería dejar que los usuarios decidan si quieren que una aplicación tenga acceso general o limitado 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 en este sentido, es ciertamente posible hacer que ese cuadro de diálogo sea más destacado y requerir una interacción adicional del usuario para aprobar una aplicación para el acceso completo.

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 portliebeck, miembro senior de XDA , mejor conocido por su trabajo enFX File Explorer. El contenido de este artículo refleja su propia opinión y análisis de las restricciones de Scoped Storage de Android Q, con un aporte y edición mínimos de Mishaal Rahman, editor en jefe de XDA-Developers. Nos comunicamos con Google para preguntarles sobre algunas de estas inquietudes, pero no recibimos respuesta de la empresa al momento de la publicación.