Google is committed to advancing racial equity for Black communities. See how.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Espace de rangement

Icône HAL de stockage externe Android

Android a évolué au fil du temps pour prendre en charge une grande variété de types et de fonctionnalités de périphériques de stockage. Toutes les versions d'Android prennent en charge les appareils avec un stockage traditionnel , qui comprend un stockage portable et émulé. Le stockage portable peut être fourni par un support physique, comme une carte SD ou USB, c'est-à-dire pour le transfert temporaire de données / stockage de fichiers. Le support physique peut rester avec le périphérique pendant une période prolongée, mais n'est pas lié au périphérique et peut être retiré. Les cartes SD sont disponibles comme stockage portable depuis Android 1.0; Android 6.0 a ajouté la prise en charge USB. Le stockage émulé est fourni en exposant une partie du stockage interne via une couche d'émulation et est disponible depuis Android 3.0.

À partir d'Android 6.0, Android prend en charge le stockage adoptable , qui est fourni par un support physique, comme une carte SD ou une clé USB, qui est crypté et formaté pour se comporter comme un stockage interne. Le stockage adoptable peut stocker tous les types de données d'application.

Autorisations

L'accès au stockage externe est protégé par diverses autorisations Android. À partir d'Android 1.0, l'accès en écriture est protégé avec l'autorisation WRITE_EXTERNAL_STORAGE . À partir d'Android 4.1, l'accès en lecture est protégé avec l'autorisation READ_EXTERNAL_STORAGE .

À partir d'Android 4.4, le propriétaire, le groupe et les modes des fichiers sur les périphériques de stockage externes sont désormais synthétisés en fonction de la structure des répertoires. Cela permet aux applications de gérer leurs répertoires spécifiques aux packages sur un stockage externe sans exiger qu'elles détiennent la large autorisation WRITE_EXTERNAL_STORAGE . Par exemple, l'application avec le nom de package com.example.foo peut désormais accéder librement à Android/data/com.example.foo/ sur des périphériques de stockage externes sans autorisation. Ces autorisations synthétisées sont obtenues en enveloppant les périphériques de stockage bruts dans un démon FUSE.

À partir d'Android 10, les applications qui ciblent Android 9 et les versions antérieures utilisent par défaut le stockage hérité et peuvent activer le stockage isolé. Les applications qui ciblent Android 10 et utilisent par défaut le stockage isolé peuvent temporairement le désactiver . Utilisez l'attribut manifest requestLegacyExternalStorage , qui contrôle le modèle de stockage, pour modifier l'état par défaut.

Étant READ_EXTERNAL_STORAGE que les autorisations READ_EXTERNAL_STORAGE et WRITE_EXTERNAL_STORAGE sont restreintes par WRITE_EXTERNAL_STORAGE , si le programme d'installation n'a pas ajouté l'application à la liste blanche, l'autorisation contrôle uniquement l'accès aux collections auditives et visuelles, sans accès à la carte SD. Cela s'applique même si l'application demande un stockage hérité. Pour plus d'informations sur les restrictions matérielles et les restrictions logicielles, consultez Restrictions matérielles et logicielles dans Android 10 .

Si le programme d'installation a ajouté l'autorisation à la liste blanche, une application exécutée en mode hérité obtient le comportement d'autorisation non isolé. L'autorisation contrôle l'accès à la carte SD et les collections auditives et visuelles. Cela se produit lorsque l'application cible Android 9 ou une version antérieure et n'active pas le stockage isolé, ou qu'elle cible Android 10 et se désiste.

L'état de la liste blanche ne peut être spécifié qu'au moment de l'installation et ne peut pas être modifié tant que l'application n'a pas été installée.

Pour plus d'informations sur la définition de l'autorisation READ_EXTERNAL_STORAGE , consultez setWhitelistedRestrictedPermissions() dans la classe PackageInstaller.SessionParams .

Autorisations d'exécution

Android 6.0 introduit un nouveau modèle d' autorisations d'exécution dans lequel les applications demandent des capacités en cas de besoin au moment de l'exécution. Étant donné que le nouveau modèle inclut les autorisations READ/WRITE_EXTERNAL_STORAGE , la plate-forme doit accorder dynamiquement l'accès au stockage sans tuer ni redémarrer les applications déjà en cours d'exécution. Pour ce faire, il conserve trois vues distinctes de tous les périphériques de stockage montés:

  • /mnt/runtime/default est montré aux applications sans autorisations de stockage spéciales, et à l'espace de noms racine où adbd et d'autres composants système.
  • /mnt/runtime/read est affiché aux applications avec READ_EXTERNAL_STORAGE (Définir LEGACY_STORAGE pour Android 10)
  • /mnt/runtime/write est affiché aux applications avec WRITE_EXTERNAL_STORAGE

Au moment du fork Zygote, nous créons un espace de noms de montage pour chaque application en cours d'exécution et nous fixons la vue initiale appropriée en place. Plus tard, lorsque les autorisations d'exécution sont accordées, vold saute dans l'espace de noms de montage des applications déjà en cours d'exécution et bind monte la vue mise à niveau en place. Notez que les rétrogradations d'autorisation entraînent toujours la suppression de l'application.

La fonctionnalité setns() utilisée pour implémenter cette fonctionnalité nécessite au moins Linux 3.8, mais les correctifs ont été rétroportés avec succès vers Linux 3.4. Le test PermissionsHostTest CTS peut être utilisé pour vérifier le comportement correct du noyau.