Espace de stockage

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 dotés d' 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 une clé USB, c'est-à-dire pour le transfert de données temporaire/le stockage de fichiers. 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 en tant que 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.

Depuis 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 chiffré 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é par l'autorisation WRITE_EXTERNAL_STORAGE . À partir d'Android 4.1, l'accès en lecture est protégé par 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 avoir à détenir l'autorisation étendue 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 des 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 opter pour le stockage isolé. Les applications qui ciblent Android 10 et utilisent par défaut le stockage isolé peuvent temporairement s'en désabonner . Utilisez l'attribut manifeste requestLegacyExternalStorage , qui contrôle le modèle de stockage, pour modifier l'état par défaut.

Étant donné que les autorisations READ_EXTERNAL_STORAGE et WRITE_EXTERNAL_STORAGE sont à restriction logicielle, si le programme d'installation n'a pas ajouté l'application à la liste blanche, l'autorisation contrôle uniquement l'accès aux collections sonores 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 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ée. 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'accepte pas le stockage isolé, ou qu'elle cible Android 10 et se désengage.

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 .

Android 13 introduit des autorisations multimédias granulaires pour prendre en charge les applications qui accèdent aux fichiers multimédias créés par d'autres applications. Les applications doivent demander une ou plusieurs des autorisations multimédias granulaires répertoriées dans Autorisations multimédias granulaires au lieu de l'autorisation READ_EXTERNAL_STORAGE .

Autorisations d'exécution

Android 6.0 introduit un nouveau modèle d'autorisations d'exécution dans lequel les applications demandent des fonctionnalités en cas de besoin lors 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 affiché pour les applications sans autorisations de stockage spéciales et pour l'espace de noms racine où résident adbd et d'autres composants système.
• /mnt/runtime/read est affiché pour les applications avec READ_EXTERNAL_STORAGE (Définissez LEGACY_STORAGE pour Android 10)
• /mnt/runtime/write est affiché pour les 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 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 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.