Android Périphérique Debug Bridge (adb) - pas d'autorisations
Je ne parviens pas à connecter mon HTC Wildfire A3333 en mode débogage à mon Fedora Linux 17. Adb a déclaré:
./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 l’est 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 simmilar sans aucune chance: tilisation de HTC wildfire pour Android développement
La cause de ce problème est liée aux autorisations du système (merci @ IsaacCisneros pour cette suggestion). D'une certaine manière, HTC Wildfire (et peut-être les autres) ont besoin de quelque chose de plus du système que les appareils Samsung. La solution simple consiste à exécuter Eclipse en tant que racine, mais cela n’est pas très pratique avec des systèmes Linux non-Sudo tels que Fedora.
J'ai trouvé un autre moyen d'atteindre le même objectif, qui semble être plus convivial et constitue un moindre trou de sécurité que de lancer IDE entier avec des privilèges de super utilisateur. Attention, il ne s’agit toujours que d’une solution au problème. L'utilisation de la racine système ne devrait être minimisée que pour les tâches administratives et "adb" a été conçu pour fonctionner avec un compte d'utilisateur normal sans SUID. En dépit du fait que le paramètre correct de SUID est assez sécurisé, chaque augmentation d’autorisation constitue un risque potentiel pour la sécurité du système.
1. Définition de la propriété du fichier binaire adb (propriétaire - racine, groupe de propriétaires - groupe d'utilisateurs):
chown root:user_group adb
2. Configurer les autorisations avec SUID:
chmod 4550 adb
Cela devrait donner quelque chose de semblable à ceci (ls -llh):
-r-sr-x---. 1 root user_name 1.2M Jan 8 11:42 adb
Après cela, vous pourrez exécuter adb en tant que root, même si vous utiliserez votre compte d'utilisateur normal. Vous pouvez exécuter Eclipse en tant qu'utilisateur normal et votre HTC doit être détecté correctement.
./adb devices
List of devices attached
HT0BPPY15230 device
Je viens d'avoir ce problème moi-mê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 :)
J'ai le même problème:
$ adb devices
List of devices attached
4df15d6e02a55f15 device
???????????? no permissions
Enquête
Si je lance lsusb, je peux voir quels périphériques je suis connecté 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 S et mon Nexus 7 (2012) connecté.
Vérification des autorisations 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. Quelle? 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 les lignes GROUP="plugdev". Notez également que cela ne fonctionne pas pour l'autre ID de périphérique:
$ grep -Ri "4e42.*plugdev" .
(rien n'est retourné)
Le réparer
D'ACCORD. Alors, quelle est la solution?
Ajouter une règle
Créez 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"
Cela devrait être une seule ligne, je l'ai emballé ici pour plus de lisibilité
Redémarrer udev
$ Sudo udevadm control --reload-rules
$ Sudo service udev restart
C'est ça
Débranchez/rebranchez votre appareil.
L'essayer
$ adb devices
List of devices attached
4df15d6e02a55f15 device
015d2109ce67fa0c device
Votre règle semble erronée. Je l'ai utilisé et cela a fonctionné:
SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", MODE="0666", GROUP="plugdev"
(ATTR au lieu de SYSFS)
sous Ubuntu 12.04, Eclipse Juno. Je suis confronté au même problème. C'est ce que j'ai trouvé sur Yi Yu Blog
La solution est la même que Leon
Sudo -s
adb kill-server
adb start-server
adb devices
La réponse de Stephan fonctionne (avec Sudo adb kill-server), mais elle est temporaire. Il doit être réémis après chaque redémarrage.
Pour une solution permanente, la configuration d'udev doit être modifiée:
La réponse de Witrant est la bonne idée (copie de la documentation officielle Android). Mais ce n'est qu'un modèle. Si cela ne fonctionne pas pour votre appareil, vous devez entrer l'ID de périphérique approprié pour votre ou vos appareils.
lsusb
Bus 001 Device 002: ID 05c6:9025 Qualcomm, Inc.
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
...
Recherchez votre appareil Android dans la liste.
Ensuite, utilisez la première moitié de l'ID (4 chiffres) pour idVendor (la dernière moitié est idProduct, mais il n'est pas nécessaire de faire fonctionner adb).
Sudo vi /etc/udev/rules.d/51-Android.rules et ajoutez une règle pour chaque idVendor unique:
SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", MODE="0666", GROUP="plugdev"
C'est si simple. Vous n'avez pas besoin de tous ces autres champs dans certaines des réponses. Enregistrez le fichier.
Puis redémarrez. Le changement est permanent. (Roger montre un moyen de redémarrer udev, si vous ne voulez pas redémarrer).
... la propre réponse de l’opérateur est mal dans la mesure où il n’existe aucune "autorisation système spéciale". - Le problème de "non autorisation" se résume à ... aucune autorisation.
Malheureusement, le débogage n’est pas facile, car adb en fait un secret pour le périphérique auquel il tente d’accéder! Sous Linux, l’utilisateur essaie d’ouvrir le périphérique "Convertisseur série USB" du téléphone, par exemple,/dev/bus/usb/001/115 (votre numéro de bus et l'adresse de votre appareil varieront). Ceci est parfois lié et utilisé à partir de/dev/Android_adb.
lsusb aidera à trouver le numéro de bus et l'adresse de l'appareil. Veillez à ce que l'adresse de l'appareil change à coup sûr si vous vous reconnectez, tout comme le numéro de bus si le port ne comprend pas quelle vitesse utiliser (par exemple, un port physique aboutit sur un bus logique ou un autre).
Une ligne LSUSB ressemble à ceci: Bus 001 Appareil 115: ID 4321: fedc bla bla bla
lsusb -v pourrait vous aider à trouver le périphérique si "bla bla bla" n’est pas assez clair (il ne contient parfois 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 réellement accessible pour l'utilisateur en question! Ensuite, vérifiez que cela fonctionne avec chmod et corrigez votre configuration udev.
PS1:/dev/Android_adb ne peut pointer que vers un seul périphérique, assurez-vous donc qu’il fait ce que vous voulez.
PS2: Pas lié à cette question, mais moins connu: adb a une liste fixe d’identifiants de fournisseurs par lesquels elle passe. Cette liste peut être étendue à partir de ~/.Android/adb_usb.ini, qui devrait contenir 0x4321 (si nous suivons l'exemple de la ligne lsusb ci-dessus). - Inutile ici, car vous n’obtenez même pas le statut "pas d’autorisation" si l’identifiant du fournisseur n’est pas connu.
Changer le mode USB depuis un téléphone a fait l'affaire pour moi. (Je le configure pour le transfert de fichiers)
Je vais ajouter ce post-scriptum au début pour ne pas le perdre dans mon explication précédente.
Je peux produire et résoudre de manière fiable le problème sans autorisation en modifiant simplement le type de connexion USB de Caméra (PTP) à Périphérique multimédia (MTP). Le mode caméra permet le débogage; le mode média provoque la réponse no-permissions dans ADB.
Le raisonnement semble assez évident après y avoir réfléchi un instant. Le contenu non sécurisé sur le périphérique serait rendu accessible par le débogueur en mode serveur multimédia.
===========
Le périphérique n'est pas autorisé jusqu'à ce que vous acceptiez l'avertissement de cryptage RSA sur le périphérique débogué. À un moment donné, après la connexion, le périphérique demande à accepter la connexion de débogage. C'est un protocole de sécurité minimal qui garantit que vous pouvez accéder au périphérique au-delà du verrou de balayage initial. Je crois que le mode développeur doit être activé.
Le drapeau "no permissions" est en fait un bon premier indicateur du fait que adb reconnaît le périphérique comme une cible de débogage valide. Notez qu'il ne répertorie pas vos autres périphériques USB.
Détails dans les pages suivantes et connexes.
Même problème avec Pipo S1S après la mise à niveau à la version 4.2.2 du 4 juin.
$ adb devices
List of devices attached
???????????? no permissions
Toutes les suggestions ci-dessus, bien que valables pour faire reconnaître votre périphérique USB, ne résolvent pas le problème pour moi. (Android Debug Bridge version 1.0.31 s'exécutant sur Mint 15.)
La mise à jour de Android sdk tools, etc. réinitialise ~/.Android/adb_usb.ini.
Pour reconnaître Pipo VendorID 0x2207, procédez comme suit:
Ajouter à la ligne /etc/udev/rules.d/51-Android.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="0x2207", MODE="0666", GROUP="plugdev"
Ajouter une ligne à ~/.Android/adb_usb.ini:
0x2207
Puis supprimez les fichiers adbkey
rm -f ~/.Android/adbkey ~/.Android/adbkey.pub
et reconnectez votre appareil pour reconstruire les fichiers de clés avec une connexion adb correcte. Certains appareils demanderont une nouvelle autorisation.
Sudo adb kill-server
Sudo adb start-server
adb devices
Avait le même problème. C'était un problème avec les règles d'udev. J'ai essayé quelques-unes des règles mentionnées ci-dessus, mais n'a pas résolu le problème. Trouvé un ensemble de règles ici, https://github.com/M0Rf30/Android-udev-rules . J'ai suivi le guide là-bas et, voila, fixé.
J'ai rencontré le même problème aujourd'hui.
J'ai suivi le instructions officielles , mais je n'ai pas remarqué que Je devrais exécuter la commande
"chmod a + r /etc/udev/rules.d/51-Android.rules"
Après avoir défini ce fichier sur World Lisible et rebranchez mon câble USB status le statut est devenu non autorisé. Ensuite, accordez simplement la permission et tout se passe bien.
Je suis d'accord avec Robert Siemer et Michaël Witrant . Si cela ne fonctionne pas, essayez de déboguer avec strace
strace adb devices
Dans mon cas, il est utile de supprimer toutes les instances et de supprimer le fichier de socket /tmp/ADB_PORT (la valeur par défaut est /tmp/5037).
Le modem USB est une autre source possible de ce problème. Si vous avez utilisé le partage de connexion USB, éteignez-le, débranchez le périphérique de l'USB, rebranchez-le, puis faites
adb kill-server
adb devices
Cela a fait le tour dans mon cas (Ubuntu 12.04, Nexus S, SDK dans le répertoire personnel, jamais besoin de root pour le faire fonctionner). En fonction de votre appareil, vous devrez peut-être exécuter adb devices en tant que root.
Le résultat de ls -al /usr/bin/adb devrait indiquer qu'il appartient à l'utilisateur root et au groupe root. Vous pouvez utiliser la liste de contrôle d'accès (ACL) de Linux pour donner à votre utilisateur local les autorisations pour adb comme suit:
setfacl -m "u:userName:rwx" /usr/bin/adb
Cela est préférable à définir le bit SUID sur /usr/bin/adb et à limiter également les utilisateurs pouvant utiliser adb à nom d'utilisateur et racine.
Essayez la commande "Android update adb". Cela m'aide avec les engins Samsung Galaxy.
La réponse est tissée parmi les différents messages ici, je vais donc le mieux, mais cela semble être une raison très simple et évidente.
1) est qu'il y a généralement une variable "utilisateur" dans la règle udev quelque chose comme USER = "votre_utilisateur" probablement juste après GROUP = "plugdev"
2) Vous devez utiliser les bonnes valeurs SYSFS {idVendor} == ”#### ″ et SYSFS {idProduct} ==" #### "pour votre/vos périphérique (s). Si vous possédez des périphériques de plusieurs fabricants, par exemple Samsung et HTC, vous devez définir une entrée (règle) pour chaque fournisseur, et non une entrée pour chaque périphérique, mais pour chaque fournisseur différent que vous utiliserez. vous avez besoin d'une entrée pour HTC et Samsung. Il semble que vous ayez votre entrée pour Samsung, il vous en faut une autre. Rappelez-vous le USER = "votre_utilisateur". Utilisez 'lsusb' comme Robert Seimer suggère de trouver idVendor et idProduct. Ils sont généralement composés de chiffres et de lettres de ce format. X # X #: # X # XI pense que le premier est idVendor et le second idProduct mais faites cela pour chaque marque de téléphone/tablette que vous avez.
3) Je n'ai pas compris en quoi les règles 51-adb. et 99-adb.rules sont différentes, ni pourquoi.
4) Peut-être essayez-vous d'ajouter le groupe "plugdev" à votre utilisateur avec "usermod -a -G plugdev votre_utilisateur", essayez-le à vos risques et périls, même si je ne pense pas qu'il soit plus risqué de lancer une interface utilisateur en tant que root, mais je crois que si vous en aviez besoin devrait au moins utiliser "gksudo Eclipse" à la place.
J'espère que cela a aidé à clarifier certaines choses, la syntaxe des règles udev est un peu mystérieuse pour moi également, mais d'après ce que j'entends dire, elle peut être différente pour différents systèmes, alors essayez certaines choses, on a mangé un moment, et noter quel changement fonctionne .
Fermer en cours d'exécution
adb, pourrait être en cours d'exécution en cours d'exécution Android-studio.liste des périphériques,
/usr/local/Android-studio/sdk/platform-tools/adb devices