Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Almacenamiento

Icono HAL de almacenamiento externo de Android

Android ha evolucionado con el tiempo para admitir una amplia variedad de tipos y características de dispositivos de almacenamiento. Todas las versiones de Android admiten dispositivos con almacenamiento tradicional , que incluye almacenamiento portátil y emulado. El almacenamiento portátil puede ser proporcionado por medios físicos, como una tarjeta SD o USB, que es para la transferencia temporal de datos / almacenamiento de archivos. Los medios físicos pueden permanecer con el dispositivo durante un período prolongado de tiempo, pero no están vinculados al dispositivo y pueden retirarse. Las tarjetas SD han estado disponibles como almacenamiento portátil desde Android 1.0; Android 6.0 agregó soporte USB. El almacenamiento emulado se proporciona exponiendo una parte del almacenamiento interno a través de una capa de emulación y ha estado disponible desde Android 3.0.

A partir de Android 6.0, Android admite almacenamiento adoptable , que es proporcionado por medios físicos, como una tarjeta SD o USB, que está encriptado y formateado para comportarse como almacenamiento interno. El almacenamiento adoptable puede almacenar todo tipo de datos de aplicaciones.

Permisos

El acceso al almacenamiento externo está protegido por varios permisos de Android. A partir de Android 1.0, el acceso de escritura está protegido con el permiso WRITE_EXTERNAL_STORAGE . A partir de Android 4.1, el acceso de lectura está protegido con el permiso READ_EXTERNAL_STORAGE .

A partir de Android 4.4, el propietario, el grupo y los modos de los archivos en los dispositivos de almacenamiento externo ahora se sintetizan según la estructura del directorio. Esto permite que las aplicaciones administren sus directorios específicos del paquete en el almacenamiento externo sin requerir que tengan el amplio permiso WRITE_EXTERNAL_STORAGE . Por ejemplo, la aplicación con el nombre del paquete com.example.foo ahora puede acceder libremente a Android/data/com.example.foo/ en dispositivos de almacenamiento externo sin permisos. Estos permisos sintetizados se logran envolviendo dispositivos de almacenamiento sin procesar en un demonio FUSE.

A partir de Android 10, las aplicaciones que se dirigen a Android 9 y tienen un valor predeterminado más bajo para el almacenamiento heredado, y pueden optar por el almacenamiento aislado. Las aplicaciones que se dirigen a Android 10 y predeterminadas al almacenamiento aislado pueden inhabilitarlas temporalmente . Use el atributo manifiesto requestLegacyExternalStorage , que controla el modelo de almacenamiento, para cambiar el estado predeterminado.

Dado que los READ_EXTERNAL_STORAGE y WRITE_EXTERNAL_STORAGE están restringidos, si el instalador no incluyó en la lista blanca la aplicación, el permiso controla el acceso a las colecciones auditivas y visuales solamente, sin acceso a la tarjeta SD. Esto se aplica incluso si la aplicación solicita almacenamiento heredado. Para obtener más información sobre las restricciones físicas y físicas, consulte Restricciones físicas y físicas en Android 10 .

Si el instalador incluyó el permiso en la lista blanca, una aplicación que se ejecuta en modo heredado obtiene el comportamiento de permiso no aislado. El permiso controla el acceso a la tarjeta SD y las colecciones auditivas y visuales. Esto sucede cuando la aplicación se dirige a Android 9 o inferior y no opta por el almacenamiento aislado, o se dirige a Android 10 y se excluye.

El estado de la lista blanca solo se puede especificar en el momento de la instalación y no se puede cambiar hasta que se haya instalado la aplicación.

Para obtener más información sobre cómo configurar el permiso READ_EXTERNAL_STORAGE , vea setWhitelistedRestrictedPermissions() en la clase PackageInstaller.SessionParams .

Permisos de tiempo de ejecución

Android 6.0 presenta un nuevo modelo de permisos de tiempo de ejecución donde las aplicaciones solicitan capacidades cuando es necesario en tiempo de ejecución. Debido a que el nuevo modelo incluye los permisos READ/WRITE_EXTERNAL_STORAGE , la plataforma necesita otorgar dinámicamente acceso al almacenamiento sin matar o reiniciar las aplicaciones que ya se están ejecutando. Lo hace manteniendo tres vistas distintas de todos los dispositivos de almacenamiento montados:

  • /mnt/runtime/default se muestra a las aplicaciones sin permisos de almacenamiento especiales, y al espacio de nombres raíz donde adbd y otros componentes del sistema.
  • /mnt/runtime/read se muestra a las aplicaciones con READ_EXTERNAL_STORAGE (Establecer LEGACY_STORAGE para Android 10)
  • /mnt/runtime/write se muestra a las aplicaciones con WRITE_EXTERNAL_STORAGE

En el momento de la bifurcación de Zygote, creamos un espacio de nombres de montaje para cada aplicación en ejecución y vinculamos el montaje de la vista inicial adecuada en su lugar. Más tarde, cuando se otorgan los permisos de tiempo de ejecución, vold salta al espacio de nombres de montaje de aplicaciones que ya se están ejecutando y enlaza monta la vista actualizada en su lugar. Tenga en cuenta que las degradaciones de permisos siempre dan como resultado que se elimine la aplicación.

La funcionalidad setns() utilizada para implementar esta característica requiere al menos Linux 3.8, pero los parches se han exportado con éxito a Linux 3.4. La prueba PermissionsHostTest CTS se puede utilizar para verificar el comportamiento correcto del kernel.