El boot.img
qui est responsable de l'amorçage d'Android, a ses scripts init intégrés dans le disque RAM de l'application réelle. boot.img
qui monte les partitions dans leurs /data
, /cache
, /system
points de montage respectivement.
En modifiant les scripts init à lancer sur la SDCard, cela pourrait conduire à un système instable, et de plus, réduire la durée de vie de la SDCard par l'usure de la SDCard - pourquoi ?
Le noyau, lorsqu'il démarre, est chargé depuis le fichier /
qui se trouve dans la même partition que le boot
d'où la nécessité de la présence du disque RAM en même temps que la partition. C'est ce dernier qui est chargé en mémoire - un système de fichiers temporaire, afin que les scripts d'initialisation puissent être lus et exécutés. Une fois que les points de montage sont établis, le disque RAM est retiré et ainsi, le système de fichiers temporaire est "basculé" sur les partitions réelles à un stade ultérieur pendant l'amorçage.
C'est là que le disque RAM entre en jeu - temporairement seulement, car c'est grâce à lui que tout le processus de démarrage peut avoir lieu.
Le problème est le suivant : le noyau, avant le démarrage, n'a aucune idée des partitions présentes !
En plus de cela, en codant en dur la SDCard dans le paramètre init du noyau, qui est une option spécifique qui peut être passée au noyau au démarrage et qui modifie le traitement de l'environnement par le noyau.
L'usure de la SDCard serait considérablement augmentée, sans compter que l'ensemble de l'écosystème Android changerait radicalement, les API ont défini le stockage interne et le stockage externe - ce qui pourrait entraîner une confusion quant à l'endroit où stocker leurs propres fournisseurs de contenu pour les contacts, etc. " Sommes-nous assis sur un stockage externe ou interne ? " du point de vue d'Android lui-même, gardez à l'esprit que les fournisseurs de contenu eux-mêmes sont logés dans le stockage interne et que, d'un point de vue général, il s'agit d'une convention standard de facto pour les systèmes de fichiers Android concernés.
Donc, pour résumer, je ne pense pas que ce soit possible, je n'exclus pas non plus que ce soit impossible, mais si c'est possible, il y a des chances que ce soit intimement lié à l'appareil lui-même, plus ou moins, ce que les fabricants y mettent du point de vue des types de format de partition (yaffs, emmc, LinusStoreIII, et plus important encore, le mécanisme de gestion de la SDCard du point de vue du noyau/matériel sera différent - je parle ici d'adresses d'E/S différentes) et, en plus de cela, des tailles de partitions différentes, ce qui rendrait le concept entier d'Android - pas exactement portable non plus en raison des scripts non standard trouvés dans le disque RAM lui-même.