Google tue l'accès en écriture sur SD externe, Samsung suit

Par franck_29 - Le 18/02/14 - Affichages : 60637
Je vous présente aujourd'hui la traduction d'un article dernièrement paru chez http://www.androidpolice.com. Il y a longtemps en effet que je souhaitais partager au sujet des cartes SD externes qui ne seraient plus accessibles en écriture depuis Android KitKat. Et cet article de Cody Toombs, fort bien documenté, m'en donne l'occasion.
Paru sous le titre original "External Blues: Google Has Brought Big Changes To SD Cards In KitKat, And Even Samsung Is Implementing Them"
(Coup de blues "externe" : Google apporte d'importants changements à la gestion des cartes SD avec KitKat, et même le rebèle Samsung le suit) [ndt : jeu de mot sur carte SD externe], cet article apporte les clarifications nécessaires en ces heures de doutes sur la nouvelle posture de Google sur les cartes SD externes. On sait en effet que Google ne les aime pas beaucoup (arguant d'une complexité induite pour l'utilisateur) et il semble bien que l'arrivée de KitKat apporte de nouvelles règles vis à vis de ces cartes additionnelles, de nouvelles règles encore plus contraignantes.

Voyons ce qu'en dit Cody Toombs (adresse de l'article original)

Image

Ces dernières années, Google ne s'est clairement pas montré particulièrement hospitalier vis à vis des cartes SD externes sur son système Android. Le meilleur exemple de cette "aversion" est sans doute la gamme Nexus où le seul appareil à offrir un stockage extensible fut le Nexus One. Mais en dépit des arguments de Dan Morril et Matias Duarte (ndt : respectivement ingénieur et architecte en chef d'Android chez Google) tendant à justifier cette position par une volonté de maintenir une interface android simple et à terme, sans gestionnaire de fichiers, les utilisateurs ont toujours voulu plus d'espace de stockage.
Pourtant, il semble bien que Google affermisse encore sa position sur les stockages amovibles, en en limitant la flexibilité et la façon dont nous pouvions y accéder jusqu’alors.

Un peu d'histoire

Commençons par un peu de terminologie. Presque tous les types de stockage sur android sont considérés comme 'externes' (external storage), même la mémoire flash interne livrée avec chaque appareil, que l'on désigne comme "stockage primaire". Tout le reste est considéré comme du stockage secondaire. Depuis les tout débuts d'android, une application devait requérir l'autorisation WRITE_EXTERNAL_STORAGE pour accéder à n'importe lequel de ces espaces de stockage externe

Image

En mars 2011, soit il y a maintenant 3 ans, une petite modification est intervenue sur le code source d'android. Elle a changé la façon dont les supports de stockage secondaires (Cartes SD) devaient être montées par le système d'exploitation, à savoir via le label AID_MEDIA_RW au lieu de l'antérieur AID_SDCARD_RW. La conséquence en a été que désormais les applications devaient appartenir au groupe "media_rw" pour accéder en écriture à la carte SD. Afin d'accéder à ce groupe, il fallait désormais donner à l'application, la permission WRITE_MEDIA_STORAGE qui venait d'être ajoutée au système.

Code: Select All Code
<!-- Allows an application to write to external storage.
Starting in API level 19, this permission is not required to
read/write files in your application-specific directories returned by
android.content.Context#getExternalFilesDir and
android.content.Context#getExternalCacheDir. -->
<permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"
android:permissionGroup="android.permission-group.STORAGE"
android:label="@string/permlab_sdcardWrite"
android:description="@string/permdesc_sdcardWrite"
android:protectionLevel="dangerous" />
 
<!-- Allows an application to write to internal media storage
@hide -->
<permission android:name="android.permission.WRITE_MEDIA_STORAGE"
android:permissionGroup="android.permission-group.STORAGE"
android:label="@string/permlab_mediaStorageWrite"
android:description="@string/permdesc_mediaStorageWrite"
android:protectionLevel="signature|system" />

source: /platform/frameworks/base/core/res/AndroidManifest.xml

en substance, WRITE_MEDIA_STORAGE dupliquait la fonctionnalité originelle WRITE_EXTERNAL_STORAGE, mais avec un détail en plus : il devenait impossible pour une application "normale" de requérir cette autorisation. La nouvelle permission avait en effet un niveau de protection "systemOrSignature", qui en fait, la limitait aux applications systèmes (habituellement celles incluses par Google et les constructeurs) signées par le créateur de la permission (l'OS lui même)

Le résultat final a été que la permission originelle WRITE_EXTERNAL_STORAGE ne pouvait plus donner que la possibilité accéder en écriture au stockage primaire, mais plus au stockage secondaire. La nouvelle permission WRITE_MEDIA_STORAGE permettait l'accès au stockage secondaire, mais seules les applications systèmes pouvaient y accéder. A la base, cela coupait court à toute possibilité, pour une application tierce, de modifier des données sur vos cartes SD externe. Il y a un peu plus à dire sur cette histoire mais nous y reviendrons plus tard.

Image Image
à gauche : tentative de créer un fichier, A droite: tentative d'en détruire un

Ce changement est en fait apparu avec Honeycomb 3.2, mais il a alors très peu attiré l'attention. On peut attribuer ce manque d'intérêt aux quelques facteurs suivants : pour commencer, le code source de Honeycomb 3.2 a été ouvert seulement après la publication de Ice Cream Sandwich (ICS), noyant ces modifications au sein de milliers d'autres. Ensuite, le Nexus One n'a jamais reçu de mise à jour OTA vers ICS, la perte de l'accès à la carte SD n'a donc pas été visible. En fait, le seul smartphone impacté par le changement a été le motorola XOOM. Mais à l'époque où le XOOM faisait tourner HoneyComb, sa carte SD était désactivée, rendant encore une fois le problème indétectable.

Quoi qu'il en soit, la principale raison pour laquelle le sujet n'a jamais fait la une des gros titres, c'est parce que les constructeurs ou les développeurs de CUSTOM ROM n'ont pas suivi Google. Par exemple, la solution de Samsung attribuait automatiquement l'autorisation WRITE_MEDIA_STORAGE à toute application demandant l'autorisation WRITE_EXTERNAL_STORAGE. Et effectivement tout développeur, ayant besoin d'un accès complet, selon les anciennes permissions, les obtenaient en pratique. D'une façon similaire, CyanogenMod a simplement remis le groupe à l'ancienne mode (sdcard_rw), ainsi qu'il était d'usage auparavant.

Note : l'énorme crédit de toute cette connaissance revient à @Chainfire, qui a posté ses recherches et découvertes sur le sujet il y a maintenant plus d'un an. Quand il a rapporté ces éléments, le code AOSP montait par défaut l'ensemble des stockages non primaires sous "media_rw" (ndt : cf. début de l'article). Depuis cette époque, avec Android 4.2, il me semble, les permissions sur les systèmes de fichiers ont été restructurées selon le modèle FUSE (FileSystem in UserSpace) Le code est désormais différent du post originel de @Chainfire, mais le résultat est globalement le même.


Les nouveautés


J'ai dit plus haut que les applications tierces ne pouvaient plus modifier le contenu de la carte SD, cela n'est en fait, pas entièrement exact. Sur KitKat, Google a en fait spécifié de nouveaux comportements pour les applications tierces.

[Pour tout stockage externe]

“depuis android 4.4, le propriétaire, le groupe et les modes des fichiers présents sur stockage externe sont désormais spécifiés sur la base de la structure des répertoires. Cela rend possible, pour les applications, de gérer des données qui leur sont propres sur stockage externe sans requérir la permission WRITE_EXTERNAL_STORAGE. Par exemple une application dont le nom du package est com.example.foo peut librement accéder à Android/data/com.example.foo/ sur le stockage externe, sans permission supplémentaire. Cette simplification des permissions est rendue possible en gérant les périphériques de stockage en mode RAW au travers d'un démon FUSE (ndt : by wrapping raw storage devices in a FUSE daemon)


[Pour le stockage secondaire, s'il existe]

La permission WRITE_EXTERNAL_STORAGE doit seulement donner l'accès en écriture au stockage primaire externe d'un appareil. Les applications ne doivent pas être autorisées à accéder aux stockages externes secondaires, sauf dans leur propre répertoire (basé sur leur nom de package) ainsi qu'il est désormais permis selon les permission simplifiées (cf. plus haut). Cette limitation des droits en écriture permet d'assurer, qu'en cas de désinstallation de l'application, ses données puissent être purgées proprement par le système.

- http://source.android.com/devices/tech/storage/


Simplement dit, les applications peuvent désormais disposer d'un répertoire sur carte SD, conçu pour leur usage exclusif, où elles pourront faire ce qu'elles veulent sans qu'absolument aucune permission spécifique ne soit nécessaire. C'est exactement la même chose que le répertoire privé dont chaque application dispose déjà sur le stockage primaire (ndt : /data/data), mais avec une sécurité négligeable, puisque la carte SD peut être extraite et librement accédée depuis un ordinateur. la permission WRITE_EXTERNAL_STORAGE donne toujours des droits sans restriction aux répertoires publics du stockage primaire, mais écrire quoi que ce soit sur le stockage secondaire - en dehors du répertoire désigné - est totalement impossible pour toute application tierce.

La dernière phrase (ndt : de l'encart) est importante, elle stipule que toutes les données écrites dans le répertoire privé de l'application seront effacées en cas de désinstallation de l'application. Cela signifie que les applications classiques comme des éditeurs d'image, des applications appareil photo alternatives, des applications de journalisation GPS ne devraient probablement pas stocker leur données dans ces répertoires privés dans la mesure où elles seraient effacées en cas de désinstallation pour quelque raison que ce soit. Nous y reviendrons plus tard.

Bien que cela ne soit pas clairement documenté, il existe une astuce (ndt : un tweak) à propos de la permission WRITE_EXTERNAL_STORAGE. En dehors des répertoire privés sur stockage secondaire, tout le reste est accessible en lecture. Cela permet à l'utilisateur de poser des photos, des musiques ou des vidéos sur sa carte SD pour un usage ultérieur. Quoi qu'il en soit, il n'y a toujours aucun moyen de les modifier, de les supprimer ou d'y ajouter d'autres fichiers via des applications tierces.

Il doit être noté, pour être complet, que les dispositifs de stockage temporaire, comme les stockages USB, ne sont pas couverts par ces règles. La façon dont ils doivent être accédés reste encore largement à l'appréciation des constructeurs.

Pourquoi en parler maintenant ?

Historiquement, les constructeurs ont toujours très peu suivi les intentions de Google sur le terrain des cartes SD. Après tout, tout cela a débuté avec Honeycomb et la plupart des utilisateurs n'y a jamais été confronté. Pourtant, les première mises à jour OTA KitKat de Samsung montrent que le constructeur a suivi les intentions de Google. Les raisons de ce revirement ne sont pas très claires, mais les constructeurs pourraient être "tenus" de s'aligner sur ces lignes directrices de Google.

Gardez bien à l'esprit, qu'il n'y a aucune certitude que les firmwares des contructeurs fonctionneront de cette façon. La seule preuve que nous ayons pour le moment, est un firmware fuité d'un seul constructeur, et une documentation du portail de développement d'Android. Bien sûr les versions "Google Play Edition" du Samsung Galaxy S4 et du LG GPad fonctionnent comme nous le décrivons, il y a donc des précédents.

Les conséquences

Pour résumer, voici les options laissées ouvertes aux applications tierces sur KitKat :
  • Une application sans permission peut :
    • Lire et écrire au sein d'un répertoire désigné et privé sur le stockage primaire et secondaire
  • Une application avec la permission WRITE_EXTERNAL_STORAGE peut aussi :
    • Lire et écrire sur tout dossier public du stockage primaire (interne)
    • Lire (pas écrire) tout dossier public du stockage secondaire (SD Card)


Globalement, la perception du problème par les utilisateurs dépendra de leurs propres perspectives, d'aucun y verront un sérieux problème, d'autres simplement un inconvénient d'autres encore y verront un changement tout à fait inoffensif. Quoi qu'il en soit c'est définitivement une mauvaise mesure pour qui est un temps soit peu "power user" de son smartphone, si de simples tâches comme faire des sauvegardes ou nettoyer de vieux fichiers deviennent un parcours d'obstacles. Ce n'est pas que ces actions ne seront plus possibles via d'autres méthodes, mais elles vont devenir fastidieuses et ennuyeuses.

Ces problèmes, en revanche, vont devenir bien pires pour les créateurs de contenu. Les photographes seront les premiers à faire face à ces restrictions, en particulier ceux qui utilisent des appareils photos haut de gamme et qui veulent ensuite éditer leurs clichés sur leur android. Visualiser des photos sur une carte SD ne sera pas un problème, mais que se passera-t-il quand il s'agira d'effacer les mauvais clichés ou de sauvegarder des éditions intermédiaires? Cela va clairement devenir une "expérience" douloureuse et confuse. Et ces problèmes empireront de façon exponentielle à mesure qu'android deviendra une plate-forme viable de création et d'édition de musiques et de vidéos.

Bien sûr, certains prétendront que rooter est la solution, et ils n'auront pas complètement tort. Les powers users sont plus à l'aise avec cette solution. Mais qu'en sera-t-il des autres utilisateurs? Android en était rendu à ce point où le rootage n'était plus qu'un outil pour les hard modders (spécialement pour les fan de Xposed) et les enthousiastes avec des besoins spécifiques (application de sauvegarde ou autre). Fondamentalement, Android ne devrait pas donner à un utilisateur normal, une raison supplémentaire de "hacker" sont smartphone ou sa tablette.

Mais peut-être y a-t-il un plan ?

Si ce nouveau comportement devait devenir obligatoire au sein d'android, l'avenir ne semble pas rose pour les extensions de mémoire par cartes SD. Nous sommes en train de perdre la plus basique des fonctionnalités, celle dont nous disposons depuis les touts débuts d'android. Puisque la gestion de contenu sur carte externe SD va devenir une galère, les utilisateurs vont a priori s'en détacher. De prime abord, tout se passe comme si l'avenir de la carte SD était de devenir un lieu de stockage temporaire pour du contenu, du cache ou encore le réceptacle de fichiers de jeu téléchargés. L'objectif est il de réellement supprimer toute demande pour du stockage extensible? Que cherche réellement Google sur ce dossier ?

Une explication possible nous ramène au commentaire de Dan Morrill à propos du gestionnaire de fichiers qui le gène tant. Peut-être que les concepteurs d'Android ont finalement déterminé qu'un gestionnaire de fichiers était tout simplement inévitable, aussi la nouvelle orientation est-elle peut-être censée rendre l'expérience la plus élégante possible en cachant les filesystems aux utilisateurs. En ce sens, l'arrivée du "Storage Access Framework", la nouvelle fonctionnalité d'android KitKat, n'est sans doute pas une coïncidence.

Ce "Storage Access Framework" rejoint mieux les critères que les concepteurs d'Android ont cherché à atteindre depuis ICS : l'interface utilisateur est plaisante et cohérente d'une application à l'autre, chaque fournisseur peut appliquer ses propres politiques de sécurité, et les fichiers peuvent être représentés par plus qu'une simple liste de noms. Il n'est pas important que le fichier soit stocké sur le smartphone, sur une carte SD ou dans le cloud. Au travers de cette interface, Android pourrait évoluer selon le paradigme dans lequel les fichiers sont détenus par des applications, et non plus organisés comme des "touffes" de données organisées au sein d'un "foutoir" de dossiers. En supposant que les apps soient configurées de façon appropriée, le SAF (Storage Access Framework) pourrait même autoriser une application à modifier ou supprimer les fichiers appartenant à une autre application (si cette application a obtenu cet accès via le SAF) comme si elle accédait à ses fichiers directement. L'information sur l'emplacement réel - carte SD, stockage primaire ou encore le cloud - ne serait pertinente et utile que dans la mesure où l'application fournissant l'accès à ces fichiers a été en mesure de les modifier elle-même.

Image Image Image

Il n'est pas difficile d'imaginer que le "Storage Access Framework" pourrait être un remplaçant "évident" du classique accès file system (ndt : accès par chemin d'accès). Sans doute est-ce un futur "brillant" et une meilleure expérience pour l'utilisateur final. Certes, cela ressemble à quelque chose que nous pourrions attendre d'un iOS ou d'un WindowsPhone, mais ce n'est pas forcément une mauvaise chose.

Quoi qu'il en soit, si Google a vraiment l'intention de conduire les développeurs d'application à transformer leurs applications en fournisseurs de documents (Document Provider) c'est un chemin assez "musclé" pour y parvenir. Sans direction claire et publique envers les développeurs, tout cela ressemble à une surprise, comme si les devs étaient supposés avoir l'intuition de ce "plan".

Il y a aussi des failles dans cette solution, qui, de fait, parait largement improvisée. En particulier, comment les utilisateurs seront ils alertés que supprimer une application peut conduire à la suppression de données auxquelles ils tenaient? Cela n'est pas un mode de fonctionnement auquel les utilisateurs sont habitués sur Android.

Peut-être suis-je aller trop loin, et peut être qu'il ne faut voir aucun rapport entre la nouvelle façon de considérer les cartes SD et un hypothétique futur système de gestion de fichiers gouverné par les applications. Peut-être les plans de Google sont tout simplement de progressivement écarter les cartes SD de son Android au profit des services dans le cloud. J'en doute, mais admettons.

De toute façon, les fans de stockage extensible vont probablement être très furieux si leur mise à jour vers KitKat se traduit par la mort de l'accès en écriture sur leur carte SD, sans avertissement préalable, sans aucun moyen de récupérer l'ancienne fonctionnalité.

Sérieux ! ce n'est pas cool Google.

---- Fin de traduction
75 réponse(s) -