Dispositif Android Debug Bridge (adb) - pas de permissions

Question

J'ai un problème pour connecter le HTC Wildfire A3333 en mode débogage avec mon Fedora Linux 17. Adb dit :

./adb devices
List of devices attached 
????????????    no permissions

mes règles udev (première règle pour Samsung qui fonctionne très bien et deuxième pour HTC qui ne fonctionne pas) :

SUBSYSTEM=="usb",SYSFS{idVendor}=="04e8",SYMLINK+="android_adb",MODE="0666",GROUP="plugdev" 
SUBSYSTEM=="usb",SYSFS{idVendor}=="0bb4",SYMLINK+="android_adb",MODE="0666",GROUP="plugdev"

Pour les appareils Samsung, tout va bien :

 ./adb devices
List of devices attached 
00198a9422618e  device

J'ai essayé toutes les réponses données dans un fil similaire, mais sans succès : Utilisation de HTC wildfire pour le développement d'Android

Answer 1

Je viens moi-même d'avoir ce problème sous Debian Wheezy. J'ai redémarré le démon adb avec sudo :

sudo ./adb kill-server
sudo ./adb start-server
sudo ./adb devices

Tout fonctionne :)

Answer 2

La cause de ce problème est liée aux permissions du système (merci à @ IsaacCisneros pour cette suggestion). D'une certaine manière, le HTC Wildfire (et peut-être les autres) ont besoin de quelque chose de plus du système que les appareils Samsung. La solution simple est d'exécuter Eclipse en tant que Root, mais ce n'est pas très confortable avec les systèmes Linux non-sudo comme Fedora.

J'ai trouvé un autre moyen d'atteindre le même objectif, qui semble être plus convivial et qui présente moins de failles de sécurité que l'exécution de l'ensemble de l'IDE avec des privilèges de super-utilisateur. Attention, il ne s'agit encore que d'une solution de contournement du problème. L'utilisation de la racine du système devrait être réduite aux seules tâches administratives, et "adb" a été conçu pour fonctionner avec un compte utilisateur normal sans SUID. Malgré le fait que la configuration correcte du SUID est assez sûre, chaque augmentation de permission est une faille potentielle de sécurité du système.

1. définir la propriété du binaire adb (propriétaire - Root, groupe propriétaire - groupe utilisateur) :

chown root:user_group adb

2. définir les permissions avec SUID :

chmod 4550 adb

Cela devrait donner quelque chose de similaire à ceci (ls -llh) :

-r-sr-x---. 1 root user_name 1.2M Jan 8 11:42 adb

Après cela, vous serez en mesure de lancer adb en tant que Root, même si vous utilisez votre compte utilisateur normal. Vous pouvez lancer Eclipse en tant qu'utilisateur normal et votre HTC devrait être découvert correctement.

./adb devices 
List of devices attached 
HT0BPPY15230    device

Answer 3

J'ai un problème similaire :

$ adb devices
List of devices attached 
4df15d6e02a55f15    device
????????????    no permissions

Enquête

Si je cours lsusb Je peux voir quels sont les appareils que j'ai connectés, et où :

$ lsusb
...
Bus 002 Device 050: ID 04e8:6860 Samsung Electronics Co., Ltd GT-I9100 Phone ...
Bus 002 Device 049: ID 18d1:4e42 Google Inc. 

Cela montre mon Samsung Galaxy S3 et mon Nexus 7 (2012) connecté.

Je vérifie les permissions sur ceux-ci :

$ ls -l /dev/bus/usb/002/{049,050}
crw-rw-r--  1 root root    189, 176 Oct 10 10:09 /dev/bus/usb/002/049
crw-rw-r--+ 1 root plugdev 189, 177 Oct 10 10:12 /dev/bus/usb/002/050

Attendez. Quoi ? D'où vient ce groupe "plugdev" ?

$ cd /lib/udev/rules.d/
$ grep -R "6860.*plugdev" .
./40-libgphoto2-2.rules:ATTRS{idVendor}=="0bb4", ATTRS{idProduct}=="6860", \
  ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary", \
  ENV{ID_MEDIA_PLAYER}="1", MODE="0664", GROUP="plugdev"
./40-libgphoto2-2.rules:ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="6860", \
  ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary", \
  ENV{ID_MEDIA_PLAYER}="1", MODE="0664", GROUP="plugdev"

(J'ai enveloppé ces lignes)

Notez le GROUP="plugdev" lignes. Notez également que cela ne fonctionne pas pour l'autre ID de dispositif :

$ grep -Ri "4e42.*plugdev" .

(rien n'est renvoyé)

Réparation

OK. Alors, quelle est la solution ?

Ajouter une règle

Créer un fichier /etc/udev/rules.d/99-adb.rules contenant la ligne suivante :

ATTRS{idVendor}=="18d1", ATTRS{idProduct}=="4e42", ENV{ID_GPHOTO2}="1",
  ENV{GPHOTO2_DRIVER}="proprietary", ENV{ID_MEDIA_PLAYER}="1",
  MODE="0664", GROUP="plugdev"

Ceci devrait être une seule ligne, je l'ai enveloppé ici pour la lisibilité.

Redémarrer udev

$ sudo udevadm control --reload-rules
$ sudo service udev restart

C'est ça.

Débranchez/rebranchez votre appareil.

Essayez-le.

$ adb devices
List of devices attached 
4df15d6e02a55f15    device
015d2109ce67fa0c    device

Answer 4

Votre règle udev semble erronée. J'ai utilisé ceci et ça a marché :

SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", MODE="0666", GROUP="plugdev"

( ATTR au lieu de SYSFS )

Answer 5

...la réponse du PO est la suivante mauvais dans la mesure où il n'y a pas de "permissions spéciales du système". - Le problème de "l'absence de permission" se résume à ... l'absence de permission.

Malheureusement, il n'est pas facile de déboguer, car adb rend secret le périphérique auquel il tente d'accéder ! Sous Linux, il essaie d'ouvrir le périphérique "convertisseur série USB" du téléphone, qui est par exemple /dev/bus/usb/001/115 (le numéro de votre bus et l'adresse du périphérique varient). Celui-ci est parfois lié et utilisé depuis /dev/android_adb.

lsusb vous aidera à trouver le numéro de bus et l'adresse du périphérique. Attention, l'adresse du périphérique changera à coup sûr si vous rebranchez, tout comme le numéro de bus si le port ne sait pas quelle vitesse utiliser (par exemple, un port physique se retrouve sur un bus logique ou un autre).

Une ligne lsusb ressemble à ceci : Bus 001 Périphérique 115 : ID 4321:fedc bla bla bla

lsusb -v peut vous aider à trouver l'appareil si le "bla bla bla" n'est pas assez explicite (parfois il ne contient ni le fabricant, ni le modèle du téléphone).

Une fois que vous connaissez l'appareil, vérifiez de vos propres yeux que ls -a /dev/bus/usb/001/115 est vraiment accessible pour l'utilisateur en question ! Vérifiez ensuite qu'il fonctionne avec chmod et corrigez votre configuration udev.

PS1 : /dev/android_adb ne peut pointer que vers un seul périphérique, donc assurez-vous qu'il fait ce que vous voulez.

PS2 : Sans rapport avec cette question, mais moins connu : adb a une liste fixe d'identifiants de fournisseurs qu'il parcourt. Cette liste peut être étendue à partir de ~/.Android/adb_usb.ini, qui devrait contenir 0x4321 (si nous suivons mon exemple de ligne lsusb ci-dessus). - Ce n'est pas nécessaire ici, car vous n'obtenez même pas un "no permissions" si l'identifiant du fournisseur n'est pas connu.