Sélection d'outils
La méthode que je présente ici repose sur le code source Android de CyanogenMod.
Alors que l'AOSP de Google ne fournit que l'outil pour créer le boot.imgfichier, CyanogenMod ajoute également l' unpackbootimgoutil vous permettant de le décompresser . Cet outil ne semble pas spécifiquement conçu pour CyanogenMod, donc la plupart des chances sont qu'il fonctionnera également pour d'autres ROM.
Il existe cependant un nombre relativement important d'alternatives pour décompresser le boot.imgfichier qui fonctionnent toutes plus ou moins de la même manière.
Fondamentalement, cet outil de décompression extraira le contenu du boot.imgfichier et affichera un ensemble de paramètres que vous devrez transmettre à l' mkbootimgoutil de Google pour créer un fichier dont la configuration (principalement les paramètres du noyau et les adresses mémoire) correspondra à celle d'origine.
Voici quelques exemples, je ne les ai pas testés personnellement, je ne peux donc pas en recommander et je les présente uniquement à titre de référence:
Tous ces outils (et d'autres que vous pouvez trouver avec n'importe quel moteur de recherche) devraient fonctionner de la même manière, mais certains peuvent fonctionner mieux que d'autres dans la gestion de certains cas particuliers que vous pouvez rencontrer avec votre propre appareil. Cependant, la plupart d'entre eux, au moins dans l'arène open source, ne semblent pas régulièrement entretenus, donc le meilleur pari à mon avis d'avoir des outils de travail, maintenus et documentés est d'aller avec ceux de CyanogenMod.
Certains fabricants produisent des ROM plus ou moins éloignées du standard AOSP (adresses inhabituelles, en-têtes, format de fichier, etc.). Si la procédure standard ci-dessous ne fonctionne pas, peut-être qu'un de ces logiciels alternatifs peut faire l'affaire. Sinon, vous devrez vérifier les problèmes spécifiques à votre appareil: certains semblent avoir besoin d'une procédure spécifique ou même d'outils spécifiques (conférez cette question relative aux appareils MediaTek, par exemple).
Installation d'outils
La compilation du jeu d'outils CyanogenMod pour l' boot.imgemballage et le déballage est assez simple.
- Si vous avez déjà installé l'arborescence complète du code source Android (vous pouvez vérifier mon autre réponse pour obtenir plus d'informations à ce sujet), allez dans le
system/core/mkbootimg/répertoire (pour rappel, le code source AOSP de Google ne fournit que l'outil pour construire le boot.imgfichier, ils ne le font pas fournir tout outil de déballage),
Si vous n'en avez pas besoin et n'en avez pas besoin à d'autres fins, une solution plus simple et plus rapide consiste à cloner uniquement le référentiel android_system_core de CyanogenMod :
git clone https://github.com/CyanogenMod/android_system_core.git
cd android_system_core/mkbootimg/
Une fois dans le bon répertoire, compilez et installez:
gcc -o ./mkbootimg -I ../include ../libmincrypt/*.c ./mkbootimg.c
gcc -o ./unpackbootimg -I ../include ../libmincrypt/*.c ./unpackbootimg.c
sudo cp ./mkbootimg ./unpackbootimg /usr/bin/
Notez que Google remplace le C mkbootimgpar une version Python , donc dans les futures versions, aucune compilation ne sera plus nécessaire pour cette commande.
Vous devrez également installer des outils Android sur votre ordinateur pour le laisser communiquer avec votre téléphone. Vous aurez besoin de adb(Android Debug Bridge, un utilitaire shell permettant de communiquer avec le sous-système de débogage d'Android), adbd(le démon associé) et fastboot(un utilitaire shell permettant de communiquer avec le système de chargeur de démarrage de votre téléphone).
Votre distribution Linux préférée peut les fournir dans un package unique ou séparé, mais généralement ils sont toujours appelés "android-tools":
- Debian / Ubuntu:
sudo apt-get install android-tools-{adb,adbd,fastboot}
- Fedora / CentOS:
sudo yum install android-tools
- openSUSE:
sudo zypper install android-tools
boot.imgRécupérer le fichier
Extrayez le fichier boot.img à partir du fichier ROM .zip ou directement à partir du périphérique:
- À partir du fichier .zip ROM d'origine: certaines applications comme SuperSU peuvent modifier le boot.img directement sur l'appareil, en le remplaçant par celui d'origine, cela casserait ces applications.
- Directement à partir de l'appareil: certaines personnes signalent un problème de lecture entraînant une corruption
boot.img. OMI, ces problèmes sont probablement liés à l'utilisation de câbles USB ou d'un concentrateur USB de mauvaise qualité et peuvent être simplement évités en utilisant des câbles de bonne qualité reliant directement le téléphone à l'ordinateur. Vous devez également pouvoir exécuter ADB en mode root (selon la ROM utilisée, cela peut être trivial ou non).
La première méthode est très évidente: extrayez le fichier .zip avec n'importe quel logiciel ZIP, le boot.imgfichier devrait être juste là à la racine de l'archive.
Pour la deuxième méthode, vous devrez d'abord déterminer le chemin (malheureusement spécifique à l'appareil) vers le périphérique de stockage où boot.imgle contenu peut être récupéré. Je connais deux méthodes pour cela:
ls /dev/block/platform/*/by-name/(où *couvre encore un autre nom de dossier spécifique à l' appareil, il est probable qu'il est le seul répertoire ci - dessous platform/), le nom exact de la recherche est également dépendant de la plateforme mais logique habituelle (quelques exemples: boot, LNX(acronyme de « Linux »)). Les fichiers de ce répertoire sont en fait des liens symboliques et certaines personnes prennent la peine de se rendre manuellement à la cible, mais je recommande de s'en tenir au chemin basé sur le nom de niveau supérieur qui, bien que plus long, reste moins sujet aux erreurs. Vous vous retrouverez donc avec un chemin comme /dev/block/platform/sdhci-tegra.3/by-name/LNX.- Sur certains appareils (plus anciens?), Le bon appareil a pu être trouvé en étudiant la sortie de
cat /proc/mtd. Si vous voyez le périphérique mtd2associé à l' "boot"étiquette, vous utiliserez le chemin /dev/mtd2.
Maintenant:
- Depuis le menu développeur du téléphone:
- Activez le débogage sur votre téléphone,
- Autoriser l'accès root à ADB (cette étape s'applique aux téléphones exécutant CynogenMod, d'autres appareils peuvent nécessiter une procédure potentiellement plus complexe),
- Connectez-le à votre ordinateur (et de là à l'invité VM si vous exécutez des outils Android à partir d'une machine virtuelle).
Si cela n'est pas déjà fait, je recommande de démarrer manuellement le serveur ADB du côté de l'ordinateur, cela vous permettra de valider directement la clé RSA du côté de l'appareil sans affecter le comportement des commandes ADB suivantes:
adb start-server
Basculez ensuite ADB en mode root:
adb root
Enfin, vous devriez pouvoir extraire directement le boot.imgfichier de l'appareil en utilisant une telle commande (le chemin et les noms source et destination sont donnés à titre d'exemples, adaptez-les à vos besoins et préférences):
adb pull /dev/block/platform/sdhci-tegra.3/by-name/LNX ./boot.img
La commande copiera toute la partition, à la fois l'espace utilisé et l'espace libre, alors ne soyez pas surpris que le boot.imgfichier résultant soit plus grand que le boot.imgfichier d' origine fourni avec le fichier .zip ROM d'origine, le contenu lui-même reste similaire.
Une fois le transfert terminé, déconnectez le téléphone et n'oubliez pas de désactiver le débogage et l'accès root à partir du menu développeur.
Décompressez le boot.imgfichier d' origine
Décompressez le boot.imgfichier lui-même à l'aide de la commande compilée précédemment:
unpackbootimg -i ./boot.img
Cela produira plusieurs informations essentielles pour vous permettre de reconstruire un nouveau boot.imgavec la structure correcte par rapport au stock boot.img. Cependant, ne vous précipitez pas sur votre bloc-notes car CyanogenMod upackbootimgenregistre également les mêmes informations dans plusieurs fichiers que nous utiliserons plus tard.
Cette commande génère plusieurs fichiers avec des suffixes particuliers ajoutés au nom du fichier d'entrée:
*-second: Il s'agit du chargeur de démarrage de deuxième niveau, facultatif et rarement utilisé sur les téléphones des utilisateurs finaux. Si ce fichier est vide (le cas le plus courant), le chargeur de démarrage du téléphone appellera directement le noyau Linux.*-zImage: Ceci est le noyau Linux.*-ramdisk.gzou *-ramdisk.lz4: le disque RAM utilisé pour remplir le répertoire racine de l'appareil. L'extension diffère selon l'algorithme de compression utilisé.*-dt: L'arborescence des périphériques, remplie /dev.- Les autres sont de petits fichiers stockant chacun une des valeurs affichées en
unpackbootimgsortie. Ces valeurs définissent le paramètre de ligne de commande à transmettre au noyau Linux et les adresses où le chargeur de démarrage devra charger chaque objet au démarrage.
Le plus souvent, on décompresse le boot.imgpour pouvoir éditer le contenu du répertoire racine du téléphone. Comme vu ci-dessus, ce contenu est stocké dans le fichier *-ramdisk.gzou *-ramdisk.lz4et il peut être extrait à l'aide des commandes ci-dessous:
mkdir ./ramdisk
cd ./ramdisk/
gzip -dc ../boot.img-ramdisk.gz | cpio -imd
Pour un disque RAM compressé LZ4, remplacez la dernière étape par lz4 -d ../boot.img-ramdisk.lz4 | cpio -imd.
Vous êtes maintenant libre de faire la modification que vous souhaitez avant de continuer. Cependant, il pourrait être utile de suivre une fois la procédure complète de déballage - remballage - démarrage sans rien changer pour vous assurer que vos outils fonctionnent comme prévu. Sinon, en cas de problème, vous ne serez pas certain si la cause est votre modification ou une certaine incompatibilité (voir mes remarques au début sur certains fabricants nécessitant des procédures ou outils non standard).
Reconstruire pour obtenir le nouveau new-boot.imgfichier
Le processus de construction de la ROM CyanogenMod s'appuie sur un outil interne mkbootfspour produire le boot.imgfichier (cela se produit dans build / tools / releasetools / common.py ). Cependant, les étapes pour construire cet outil me semblent inutilement complexes, alors que l'utilisation du système fourni cpiosemble tout aussi bien fonctionner. La principale différence entre les deux, selon ma compréhension après une vérification (très) rapide du mkbootfscode souce, semble être que ce dernier applique certaines mesures d'intégrité en n'incluant pas les fichiers en pointillés et le /rootrépertoire dans l'archive résultante alors que la cpioprocédure basée ci-dessous va simplement mettre aveuglément toute l'arborescence de répertoires sélectionnée dans l'archive.
Conclusion: inutilement complexe à compiler avec très peu d'avantages, alors restons sur les outils fournis par le système!
Commencez par créer le nouveau disque RAM, à partir du ramdiskrépertoire créé ci-dessus, tapez:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Ou, si vous devez générer une archive LZ4:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | lz4 > ../new-boot.img-ramdisk.lz4
Le but ici est de créer un nouveau fichier disque RAM avec des propriétés aussi proches que possible de l'original (par exemple, la définition du propriétaire semble souvent manquante dans les procédures partagées dans les forums et les blogs, mais cela était requis sur mon appareil).
Allez maintenant dans le répertoire parent pour générer le new-boot.imgfichier lui-même.
cd ..
Comme vu ci-dessus, la unpackbootimgcommande de CyanogenMod génère un fichier correspondant à chaque paramètre attendu par mkbootimg. Par conséquent, tout ce que vous avez à faire est d'émettre un mkbootimg -hpour obtenir une liste de tous les paramètres, puis définissez chacun d'eux à la valeur appropriée à l'aide du fichier correspondant. Notez que certains paramètres attendent un chemin de fichier tandis que d'autres s'attendent à recevoir le contenu du fichier en tant que valeur. Voir un exemple de commande résultante ci-dessous:
mkbootimg --kernel ./boot.img-zImage \
--ramdisk ./new-boot.img-ramdisk.gz \
--second ./boot.img-second \
--cmdline "$(cat ./boot.img-cmdline)" \
--base "$(cat ./boot.img-base)" \
--pagesize "$(cat ./boot.img-pagesize)" \
--dt ./boot.img-dt \
--ramdisk_offset "$(cat ./boot.img-ramdisk_offset)"
--second_offset "$(cat ./boot.img-second_offset)" \
--tags_offset "$(cat ./boot.img-tags_offset)" \
--output ./new-boot.img
Seuls deux paramètres ne sont pas définis ici:
--board: Selon ma compréhension, ce n'est qu'un champ informatif permettant d'insérer un nom de modèle dans l'image résultante.--id: Celui-ci n'attend aucune valeur, il imprime juste un identifiant unique après la construction de l'image (combinant un horodatage et une somme de contrôle).
Flashez le new-boot.imgfichier sur l'appareil
- Démarrez l'appareil en mode fastboot (aka mode bootloader, généralement en maintenant les boutons d'alimentation et d'augmentation du volume).
- Connectez le câble USB.
Vérifiez que l'appareil est correctement détecté:
sudo fastboot devices
Essayez de démarrer en utilisant la nouvelle ROM (sans la flasher pour le moment, donc en cas de problème il vous suffit de redémarrer le téléphone pour le remettre sur les traces, remplacez le ./new-boot.imgnom du fichier par le vôtre):
sudo fastboot boot ./new-boot.img
Si le téléphone fonctionne correctement avec la nouvelle image de démarrage, revenez en mode fastboot et flashez-la en permanence:
sudo fastboot flash boot ./new-boot.img
sudo fastboot reboot
Conclusion
Cette procédure peut sembler intimidante au début, mais une fois que vous l'avez obtenue, vous verrez que ce n'est pas le cas.
L'aspect «intimidant» vient du fait qu'il n'y a pas un seul «système Android»: de nombreux fabricants et fournisseurs de ROM apportent des modifications qui peuvent aller d'une différence de chemin subtile à un environnement complètement non standard.
Ce que vous devez faire est de déterminer la posture de votre appareil particulier, puis quelles sont les quelques commandes qui sont appropriées dans votre cas. Une fois que vous les avez obtenus, vous pouvez vous en tenir à eux et même les écrire facilement si vous en avez souvent besoin.
Je suis entré volontairement dans des détails relativement bas parfois, car cela vous permettra de résoudre plus facilement vos problèmes. Souhaitez-vous utiliser un utilitaire opaque "plus facile" pour créer et flasher votre nouveau boot.imgfichier et voir que votre appareil ne peut pas commencer par lui, il serait plus difficile pour vous de déterminer quelle étape a mal tourné. Ici, à chaque étape, vous pourrez comparer les données que vous manipulez avec les données provenant du boot.imgfichier d' origine ou les données vues sur le téléphone, ou essayez par exemple de reconstruire le boot.imgfichier avec l'original ou le nouveau généré Fichier disque RAM pour vérifier si cela fait une différence (cela vous permet de déterminer si le problème provient de la boot.imgprocédure de génération de fichier disque RAM).
