Stockage

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 de dispositifs de support Android avec le stockage traditionnel , qui comprend le stockage portable et émulé. Stockage portable peut être fourni par des supports physiques, comme une carte SD ou USB, qui est pour le stockage temporaire de transfert de données / fichier. Le support physique peut rester avec l'appareil pendant une période prolongée, mais n'est pas lié à l'appareil 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. Stockage émulé est fourni en exposant une partie de stockage interne à travers une couche d'émulation et est disponible depuis les applications 3.0.

A partir de Android 6.0, Android prend en charge le stockage adoptable , qui est fourni par un support physique, comme une carte SD ou USB, qui est crypté et formaté pour se comporter comme le 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. A partir de Android 1.0, l' accès en écriture est protégé par la WRITE_EXTERNAL_STORAGE permission. A partir de Android 4.1, l' accès en lecture est protégé par la READ_EXTERNAL_STORAGE permission.

À 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 paquet sur le stockage externe sans exiger qu'ils détiennent le large WRITE_EXTERNAL_STORAGE autorisation. Par exemple, l'application avec le nom du package com.example.foo peut désormais accéder librement Android/data/com.example.foo/ sur les périphériques de stockage externes sans autorisations. Ces autorisations synthétisées sont obtenues en enveloppant les périphériques de stockage bruts dans un démon FUSE.

A partir de Android 10, apps Android qui cible 9 et inférieure par défaut de stockage existants, et peut opter pour le stockage isolé. Les applications qui cible les applications 10 et par défaut de stockage isolé peuvent opter temporairement hors de celui - ci. Utilisez l'attribut manifeste requestLegacyExternalStorage , qui contrôle le modèle de stockage, pour changer l'état par défaut.

Puisque les deux READ_EXTERNAL_STORAGE et WRITE_EXTERNAL_STORAGE autorisations sont restreintes doux, si le programme d' installation n'a pas whitelist l'application, l'accès aux contrôles d'autorisation aux collections sonores et visuelles seulement, 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 dures et restrictions douces, voir restrictions dures et souples dans Android 10 .

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

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 configuration du READ_EXTERNAL_STORAGE autorisation, voir setWhitelistedRestrictedPermissions() dans la PackageInstaller.SessionParams classe.

Autorisations d'exécution

Android 6.0 introduit une nouvelle autorisations d'exécution modèle où les applications demandent des capacités en cas de besoin lors de l' exécution. Parce que le nouveau modèle inclut les READ/WRITE_EXTERNAL_STORAGE autorisations, les besoins de la plate - forme d'accès de stockage de subvention de façon dynamique sans tuer ou 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 indiqué aux applications sans autorisations spéciales de stockage et de l'espace de noms racine où adbd et d' autres composants du système en direct.
  • /mnt/runtime/read est affiché à des applications avec READ_EXTERNAL_STORAGE (Set LEGACY_STORAGE pour les applications 10)
  • /mnt/runtime/write est montré aux applications avec WRITE_EXTERNAL_STORAGE

Au moment du fork de Zygote, nous créons un espace de noms de montage pour chaque application en cours d'exécution et lions le montage de 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 de lier monte la vue mis à jour en place. Notez que les rétrogradations d'autorisation entraînent toujours la suppression de l'application.

Le setns() fonctionnalité 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 à Linux 3.4. Le PermissionsHostTest essai CTS peut être utilisé pour vérifier le comportement du noyau correct.