Aller au contenu

[Résolu] ADB et recovery stock


Recommended Posts

Bonjour à tous

Ayant décidé de me passer totalement de CWM recovery, j'ai été amenée à utiliser ADB depuis le recovery Samsung. Mon but était d'accéder à mes données, mais impossible d'afficher le contenu de /data ou /sdcard (dossier data apparaissant vide et sdcard inexistant).

J'ai tenté un adb mount, mais sans succès.

Est-ce qu'il existe une solution pour accéder à ces dossiers, ou est-ce impossible sans recovery custom ?

Merci d'avance :)

Modifié par decrescendo
Lien vers le commentaire
Partager sur d’autres sites

Merci de ta réponse :)

Malheureusement, comme le précise l'auteur de l'article, la commande run-as sert à accéder uniquement à des applications en mode debug. Or, les applis que j'ai installées ne le sont pas (je ne suis pas dev Android), et surtout je voudrais pouvoir récupérer mes données perso stockées dans /sdcard.

J'ai bien les droits root mais pas de recovery custom, et donc pas de section "Mounts and storage".

Lien vers le commentaire
Partager sur d’autres sites

Il est normal qu'on ne puisse pas accèder à /data depuis un shell non-root. Je suis plus supris que ça soit aussi le cas pour /sdcard qui est un filesystem FAT donc sans aucune protection. Es-tu sûr que ce n'est pas plutôt /mnt/sdcard ?

Tu dis :

J'ai bien les droits root

Donc tu dois pouvoir faire un "su" dans ton shell et donc passer en root et par conséquent accèder à tout et n'importe quoi, non ?

Lien vers le commentaire
Partager sur d’autres sites

D'après ce que je comprends, /sdcard serait un lien symbolique vers /storage/sdcard0

/mnt/sdcard est également un lien vers ce même dossier.

Je peux effectivement prendre les droits roots dans le shell, mais ça ne change rien au problème : l'accès à /data et /sdcard ne m'est pas refusé : je peux y naviguer sans message d'erreur, mais ils m'apparaissent complètement vides.

edit : depuis le shell, je peux voir /sdcard et /sdcard1 (??), qui sont vides. Pas de dossier storage par contre.

Modifié par decrescendo
Lien vers le commentaire
Partager sur d’autres sites

Aahhhhhhh en recovery c'est parfaitement normal !!!

/data n'est pas monté au boot, ni /system d'ailleurs, pas plus que la SD (ni interne ni externe). Seulement /cache.

Il faut faire les montages à la main (ou à partir du menu du recovery si c'est une version évoluée genre CWM)

Lien vers le commentaire
Partager sur d’autres sites

Sauf que j'ai aucun mal à accéder à /system en recovery, je peux même le monter en écriture etc...

Et je veux bien monter à la main les dossiers manquants puisque je n'ai pas de recovery custom, mais j'ai pas trouvé comment faire.

Modifié par decrescendo
Lien vers le commentaire
Partager sur d’autres sites

Je suis complètement largué avec vos discussions, les gars.

Moi j'en suis resté à Decrescendo qui est en mode Recovery.

Si c'est un recovery stock, il n'y aura sans doute pas dans les menus de quoi monter /data et la /mnt/sdcard, il faut le faire en ligne de commande.

C'est du genre :

mount -t <fs> /dev/block/<device> /data

<fs> et <device> varient d'un terminal Android à l'autre, le seul moyen de le savoir pour sur est de lancer la commande

mount

(tout court) dans un emulateur de terminal sur Android booté. Cela te donnera le type de filesystem <fs> (probablement ext4, mais pas certain, ça peut être yaffs2 aussi) et le chemin complet du block device /dev/block/<device>

Modifié par Lannig
  • Like 2
Lien vers le commentaire
Partager sur d’autres sites

Merci pour toutes ces explications détaillées. J'avais trouvé des infos sur divers forums mais ça ressemblait plus à des recettes de cuisines que l'explication d'une commande. Et avec la liste d'options je savais vraiment pas quoi mettre pour "device".

Ça fonctionne sans problème, je vais pouvoir continuer à accéder à mes fichiers même si je foire ma ROM (wouhou), merci beaucoup :)

Par contre, je n'ai pas réussi à exécuter adb push/pull une fois sortie du shell (l'appareil n'est plus reconnu par adb devices), mais j'ai peut-être fait une mauvaise manip...

Au final si je comprends bien, un recovery custom permet seulement d'offrir une interface graphique pour des fonctions auxquelles on a déjà accès avec un shell root ? Et donc on peut par exemple flasher un kernel par ce biais ?

Lien vers le commentaire
Partager sur d’autres sites

Par contre, je n'ai pas réussi à exécuter adb push/pull une fois sortie du shell (l'appareil n'est plus reconnu par adb devices), mais j'ai peut-être fait une mauvaise manip...

Bizarre, à part que cela ait tué le process adbd sur le terminal Android, je ne vois pas ce qui peut se passer. Normalement sortir du shell (par "exit") ne devrait rien changer.

Au final si je comprends bien, un recovery custom permet seulement d'offrir une interface graphique pour des fonctions auxquelles on a déjà accès avec un shell root ? Et donc on peut par exemple flasher un kernel par ce biais ?

To recovery est déjà assez évolué par rapport à la moyenne puisqu'il te donne une connexion ADB fonctionnelle. C'est loin d'être le cas de tous les recovery stock.

Après, la différence se fait sur des menus plus ou moins riches en fonctions (montage, formatage de partitions, tests etc.), mais cela reste un menu en mode texte pour tous les recovery que j'ai utilisés Tous les recovery, même les stock, permettent en général d'installer un fichier update.zip qui a un format bien particulier (il contient des fichiers à extraire et un script qui s'exécute) qui permet de tout faire, en gros : depuis mettre à jour quelques fichiers jusqu'à reflasher totalement le terminal, en passant par le kernel et tout ce que tu veux.

La différence est souvent dans le fait que les recovery stock exigent un fichier zip signé, et souvent signé de la clef du fabricant, ce qui bloque de fait toute utilisation pour nous. CWM Recovery ne demande aucune signature.

Modifié par Lannig
Lien vers le commentaire
Partager sur d’autres sites

Je sais bien que la fonction "installer un update.zip" du recovery stock demande un zip signé, mais je pensais qu'utiliser adb permettait de contourner cette restriction puisqu'au final, en montant /system on peut bidouiller plus ou moins ce que l'on veut.

Enfin bref, tu as répondu à ma question et c'est beaucoup plus clair pour moi maintenant.

Merci encore pour tes réponses et ta réactivité

Lien vers le commentaire
Partager sur d’autres sites

En ADB shell on peut faire absolument tout ce qu'on veut... c'est simple. Mais il faut le faire à la main. Il n'y a aucun moyen d'appliquer automatiquement un update.zip y compris l'exécution des scripts qu'il contient. Et comme ces scripts ne sont pas des commandes shell mais des commandes pour un interpréteur fourni dans le update.zip, ça complique un peu.

Mais tout est faisable, aucune restriction.

Lien vers le commentaire
Partager sur d’autres sites

Rejoignez la conversation

Vous pouvez poster maintenant et vous enregistrez plus tard. Si vous avez un compte, connectez-vous maintenant pour poster.

Invité
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...