[Résolu] ADB et recovery stock

[decrescendo]

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é 5 février 2013 par decrescendo

[baastien]

Salut decrescendo

Je suis tombé là dessus, j'ai l'impression que ça peut aider.

http://denniskubes.c...ithout-rooting/

Modifié 2 février 2013 par baastien

[decrescendo]

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".

[Lannig]

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 ?

[decrescendo]

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é 4 février 2013 par decrescendo

[Lannig]

/data vide depuis un shell root ???

Là je sèche. Jamais vu ça. Désolé.

[decrescendo]

En recovery hein, pas depuis Android booté. Je commence à me dire que ce que je cherche à faire est impossible...

Merci beaucoup pour ton aide en tous cas.

[Lannig]

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)

[decrescendo]

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é 4 février 2013 par decrescendo

[kuroshinta]

intéressant comme topic et amusant de voir à quel point les gens peuvent se compliquer la vie ^^

[decrescendo]

C'est pas se compliquer la vie pour moi, ça m'intéresse et c'est également mon boulot de comprendre les technologies que j'utilise :ph34r:

Modifié 4 février 2013 par decrescendo

[kuroshinta]

tiens j'ai une question qui peu être bête mais osef :P

le push/pull fonctionne dans vers ton dossier sdcard ?

[decrescendo]

J'ai essayé vers /data et j'avais un permission denied en essayant de faire un push.

En fait si le pull fonctionnait ça me suffirait, c'est ce que je cherche à faire...

Modifié 4 février 2013 par decrescendo

[kuroshinta]

je viens de tester ca fonctionne parfaitement de mon coté

j'ai lu ceci : http://developer.android.com/tools/help/adb.html#copyfiles

[decrescendo]

En recovery ??

(C'est quand même écrit dans le premier post, le titre du thread et répété plusieurs fois après)

[kuroshinta]

Hum...non pas en recovery.

J'avais mon téléphone allumé normalement

Envoyé depuis mon Galaxy Nexus avec Tapatalk

[Lannig]

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é 5 février 2013 par Lannig

[decrescendo]

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 ?

[Lannig]

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é 5 février 2013 par Lannig

[decrescendo]

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é

[Lannig]

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.