Scoped storage y el fin del acceso libre

El almacenamiento externo de Android nació como un sistema de ficheros compartido, plano y sin dueños, heredado directamente de la lógica de una tarjeta de memoria extraíble. Un único permiso de lectura abría todo: las fotos, los documentos, las copias de seguridad de otras aplicaciones, los registros de conversaciones que algún desarrollador descuidado había dejado en texto plano. La consecuencia fue previsible y está bien documentada: durante años, aceptar el permiso de almacenamiento de una linterna equivalía a entregarle el archivo completo de la vida digital de una persona. El desmantelamiento de ese modelo, que ocupó cuatro versiones de la plataforma y rompió miles de aplicaciones, es probablemente el cambio más profundo que Android ha hecho jamás en su superficie de API. Y su lógica es unitaria: el almacenamiento compartido deja de ser un sistema de ficheros al que se accede con rutas y pasa a ser una base de datos mediada a la que se accede con identificadores, consultas y consentimientos concretos.

De un sistema de ficheros a un índice mediado

El modelo actual parte de una separación tajante. Cada aplicación tiene un directorio privado, dentro y fuera de la memoria interna, sobre el que ejerce control absoluto sin necesidad de ningún permiso y que el sistema borra cuando la aplicación se desinstala. Todo lo que sea estado interno, cachés, descargas temporales o material de trabajo pertenece ahí, y la regla práctica es sencilla: si el usuario no necesita ver ese fichero desde otra aplicación, no tiene ningún motivo para estar fuera.

Fuera de ese directorio está el espacio compartido, y ahí ya no hay rutas sino colecciones. Las imágenes, los vídeos, el audio y las descargas viven en tablas indexadas por el proveedor de medios, y se manipulan con las mismas primitivas que cualquier otro proveedor de contenidos: consultas, inserciones, actualizaciones e identificadores. La ruta absoluta sigue existiendo por debajo, pero dejó de ser la interfaz.

La transición se ejecutó en dos tiempos deliberados. La API 29 introdujo el modelo y ofreció una válvula de escape para quien no llegara a tiempo, requestLegacyExternalStorage, que restauraba el comportamiento antiguo. La API 30 cerró la válvula: el atributo se ignora y no hay marcha atrás. Ese patrón de una versión de aviso seguida de una versión de aplicación es el mismo que Android ha usado después con cada endurecimiento de privacidad, y conviene reconocerlo porque anticipa el calendario de los que vengan.

La asimetría clave del modelo, y la que más cuesta interiorizar a quien viene del mundo antiguo, es esta: contribuir contenido nuevo al espacio compartido nunca requiere permiso, mientras que leer lo que otros contribuyeron siempre lo requiere. Guardar la foto que tu aplicación acaba de tomar en la galería del usuario es una operación libre. Enumerar las fotos que ya estaban ahí no lo es, y no lo será nunca más.

Escribir y modificar a través de MediaStore

La inserción de un medio nuevo sigue un patrón de dos fases que evita que otras aplicaciones vean ficheros a medio escribir. Primero se inserta el registro marcado como pendiente, después se vuelca el contenido en el flujo de salida asociado, y solo al terminar se retira la marca y el elemento aparece en la galería.

val valores = ContentValues().apply {
    put(MediaStore.Images.Media.DISPLAY_NAME, "recibo.jpg")
    put(MediaStore.Images.Media.MIME_TYPE, "image/jpeg")
    put(MediaStore.Images.Media.RELATIVE_PATH, "Pictures/MiApp")
    put(MediaStore.Images.Media.IS_PENDING, 1)
}

val destino = MediaStore.Images.Media.getContentUri(
    MediaStore.VOLUME_EXTERNAL_PRIMARY,
)
val uri = resolver.insert(destino, valores) ?: return

resolver.openOutputStream(uri)?.use { salida -> mapa.compress(JPEG, 90, salida) }

resolver.update(uri, ContentValues().apply { put(IS_PENDING, 0) }, null, null)

El campo RELATIVE_PATH sustituye a la construcción manual de rutas y es la única forma admitida de decidir en qué carpeta visible aterriza el fichero. Lo que no puedes hacer es inventarte una carpeta de primer nivel arbitraria: el sistema exige que el destino cuelgue de una de las colecciones estándar, y esa restricción es exactamente lo que impidió que la raíz del almacenamiento siguiera llenándose de directorios con nombres de producto.

Modificar o borrar contenido que tu aplicación no creó es un caso distinto y mucho más interesante, porque no basta con tener el permiso de lectura. El sistema exige una confirmación por operación, que se solicita construyendo una petición de escritura y lanzándola como una actividad cuyo resultado indica si el usuario accedió.

val peticion = MediaStore.createWriteRequest(resolver, listOf(uriAjena))
lanzadorDeIntent.launch(IntentSenderRequest.Builder(peticion).build())

Este mecanismo, junto con sus hermanos para borrar y para enviar a la papelera, convierte una operación destructiva sobre datos ajenos en una decisión consciente del usuario sobre elementos concretos. Es la traducción al almacenamiento de la misma doctrina que gobierna el resto del sistema: el permiso amplio se sustituye por el consentimiento puntual y verificable.

El Photo Picker: pedir nada y obtener lo necesario

La observación empírica que ordena todo este terreno es que la inmensa mayoría de las aplicaciones que piden acceso a la galería no quieren la galería: quieren una foto. Una foto de perfil, un adjunto, un comprobante. Para ese caso, que cubre casi todo el volumen real de peticiones de almacenamiento del ecosistema, existe una solución que no requiere ningún permiso.

El selector visual del sistema se lanza como cualquier otro contrato de resultado, muestra al usuario su propia galería en un proceso que no es el tuyo, y te devuelve un identificador de contenido con acceso concedido únicamente a lo que la persona seleccionó. Tu aplicación nunca ve el resto. No hay diálogo de permiso porque no hay nada que conceder: la selección es el consentimiento.

private val elegirFoto = registerForActivityResult(
    ActivityResultContracts.PickVisualMedia(),
) { uri -> uri?.let { cargarAvatar(it) } }

private fun alPulsarCambiarAvatar() {
    elegirFoto.launch(
        PickVisualMediaRequest(ActivityResultContracts.PickVisualMedia.ImageOnly),
    )
}

Existe también la variante de selección múltiple con un tope de elementos, y la biblioteca de compatibilidad lo respalda en versiones antiguas apoyándose en los servicios de Google Play, de modo que la ruta funciona muy por debajo de la versión en que se introdujo. La consecuencia es que la excusa del soporte de versiones antiguas ya no sostiene la petición del permiso.

Para documentos que no son medios existe el marco de acceso a documentos, con sus acciones de abrir, crear y abrir un árbol completo. Su propiedad más útil es la persistencia: el acceso obtenido puede conservarse entre reinicios tomando explícitamente el permiso persistible sobre el identificador, lo que permite construir editores que recuerdan sus ficheros sin ningún permiso declarado.

private val abrirDocumento = registerForActivityResult(
    ActivityResultContracts.OpenDocument(),
) { uri ->
    uri?.let {
        contentResolver.takePersistableUriPermission(
            it,
            Intent.FLAG_GRANT_READ_URI_PERMISSION or
                Intent.FLAG_GRANT_WRITE_URI_PERMISSION,
        )
        recordarUltimoDocumento(it)
    }
}

El número de accesos persistibles que el sistema conserva por aplicación es finito, de modo que conviene liberar los que dejan de usarse en lugar de acumularlos indefinidamente. Un editor con una lista de documentos recientes que nunca poda su colección acabará descubriendo, en el dispositivo de algún usuario intensivo, que los identificadores más antiguos han dejado de funcionar.

flowchart TD
A[Necesito un fichero] --> B[Es de mi aplicacion]
B -->|si| C[Directorio privado sin permisos]
B -->|no| D[Es una imagen o un video que elige el usuario]
D -->|si| E[Photo Picker sin permisos]
D -->|no| F[Es un documento concreto]
F -->|si| G[Marco de acceso a documentos]
F -->|no| H[Necesito enumerar la biblioteca completa]
H -->|si| I[Permisos granulares de medios]
H -->|no| J[Revisa el requisito otra vez]

Permisos granulares y acceso parcial

Cuando la enumeración es realmente necesaria —una aplicación de edición que muestra la biblioteca, un cliente de copia de seguridad, un reproductor de música local— la plataforma dejó de ofrecer un permiso único. La API 33 dividió el antiguo permiso de lectura en tres piezas independientes por tipo de medio, y ese es hoy el máximo de granularidad que puedes declarar.

<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />
<uses-permission android:name="android.permission.READ_MEDIA_VIDEO" />
<uses-permission
    android:name="android.permission.READ_MEDIA_VISUAL_USER_SELECTED" />
<uses-permission
    android:name="android.permission.READ_EXTERNAL_STORAGE"
    android:maxSdkVersion="32" />

La API 34 añadió un tercer estado que rompe la dicotomía habitual: el acceso parcial. El usuario puede responder al diálogo eligiendo fotos concretas en lugar de conceder o denegar, y tu aplicación recibe entonces el permiso de selección visual pero no el de imágenes. Al consultar la colección solo verás lo que la persona eligió, y el conjunto puede ampliarse más tarde.

Manejar ese estado correctamente exige comprobar los dos permisos por separado y ofrecer, cuando el acceso es parcial, una vía visible para gestionar la selección. Una aplicación que trate el acceso parcial como una denegación está descartando al usuario que dijo que sí con condiciones, que es precisamente el usuario más cuidadoso de todos.

Queda el acceso total a todos los archivos, que existe y funciona, y cuya declaración desencadena un proceso de revisión en Google Play donde hay que justificar por qué ninguna de las alternativas anteriores sirve. Los casos aceptados forman una lista corta y muy concreta: gestores de ficheros, herramientas de copia de seguridad y migración, antivirus. Si tu producto no es literalmente uno de esos, la solicitud se rechaza y la publicación se bloquea.