Comment puis-je faire détecter mon appareil par ADB sous Linux?


18

Je viens de recevoir mon nouveau Wileyfox Swift brillant - et avant de l'utiliser, je veux le oem unlockrooter (comme je le fais habituellement avec les nouveaux appareils;) Le problème est, bien que le soit activé sur l'appareil, et qu'une ligne correspondante /etc/udev/rules.d/51-android.rulesexiste , l'appareil n'est pas vu par adb devices.

Je sais qu'il y a plusieurs réponses dispersées autour de ce site, mais elles sont difficiles à trouver, couvrent simplement un appareil spécifique, ou ne couvrent pas toutes les étapes dont j'avais finalement besoin. Je prends donc cela comme une chance pour une question canonique indépendante de l'appareil et je lui donne une réponse détaillée ci-dessous:

Comment voir et utiliser mon appareil Android adbsous Linux?


Je suis toujours ouvert aux critiques - mais un downvote sans explication est difficile à interpréter. Est-ce que le downvoter pourrait expliquer ce qui devrait être amélioré sur la question? Je promets de ne pas abuser de mes pouvoirs de mod pour la punition :)
Izzy

3
Je suppose que l'électeur ne s'est pas rendu compte que vous avez posté la question pour y répondre lui-même (ne doit pas vous avoir remarqué dans la réponse). Puisqu'il n'y a aucun indice dans la question ou les commentaires qui ont été postés dans le but de répondre automatiquement, l'électeur aurait pu s'opposer à l'avant-dernier paragraphe (montre la paresse, si elle est lue dans le contexte d'un utilisateur ordinaire et de sa question). Je ne peux penser à aucune autre raison pour l'instant.
Firelord

1
@Firelord semble convaincant (édité un peu la question pour éviter des échecs supplémentaires). Mais alors, cet utilisateur aurait dû voter pour la réponse. Ou ai-je également raté quelque chose? ;)
Izzy

Réponses:


24

Activer le débogage USB sur l'appareil

Cela se fait dans Paramètres ›Développement . Si vous ne disposez pas de cette entrée dans votre menu de paramètres, accédez à Paramètres ›À propos de , faites défiler jusqu'au« Numéro de build »et martelez-le comme un singe jusqu'à ce que votre appareil vous félicite d'être devenu développeur. Revenez à la page principale du menu Paramètres et près du bas, vous devriez voir les paramètres "Développement" (ou "Développeurs") maintenant. Saisissez-le et activez le débogage USB ici.

Identifiez l'appareil

Nous devons d'abord savoir comment l'appareil s'identifie sur le bus USB. Pour cela, avec l'appareil Android NON connecté, saisissez un shell et exécutez la commande lsusb. Connectez ensuite l'appareil et réexécutez la commande. Repérez la nouvelle ligne. Pour le Wileyfox Swift, il s'agit d'un "appareil sans nom":

Bus 004 Device 003: ID 2970:2282

Définition des règles pour la BAD

Nous avons maintenant besoin les chiffres à la fin de la ligne ci - dessus: 2970:2282. Ceux-ci spécifient le fournisseur (2970) et le périphérique lui-même (2282). Ayant ces détails, nous avons besoin d'un shell racine sur notre machine Linux pour éditer (ou créer, s'il n'existe pas encore) le /etc/udev/rules.d/51-android.rulesfichier. Là, ajoutez une ligne pour votre appareil. L'exemple de ligne suivant montre à quoi il ressemble pour le Wileyfox Swift: ¹

SUBSYSTEMS=="usb", ATTRS{idVendor}=="2970", ATTRS{idProduct}=="2282", MODE="0666" GROUP="androiddev", SYMLINK+="android%n"

Si vous avez un appareil différent, remplacez les ID de fournisseur et de produit par ce que vous avez trouvé ci-dessus lors de l'exécution lsusb. Une brève explication de la ligne:

  • SUBSYSTEMS=="usb": évidemment cette règle est uniquement pour l'USB;)
  • ATTRS{idVendor}=="2970": l'ID du fournisseur de l'appareil auquel cette règle est destinée
  • ATTRS{idProduct}=="2282": l'ID de l'appareil
  • MODE="0666": autorisations que le nœud de périphérique doit obtenir. 0666est assez laxiste, accordant à chaque utilisateur de votre système des autorisations de lecture et d'écriture - donc si vous êtes inquiet, vous pouvez essayer de le remplacer par un 0660(en donnant uniquement le propriétaire et le groupe en lecture-écriture et tout refuser aux autres).
  • GROUP="androiddev": à quel groupe le nœud de périphérique doit appartenir. Il doit s'agir d'un groupe auquel les utilisateurs destinés à travailler avec l'appareil appartiennent.
  • SYMLINK+="android%n": juste pour donner au nœud un joli nom, afin que vous puissiez le trouver plus facilement dans /dev(dans mon cas, il est apparu plus tard comme /dev/android5)

Cette règle est entrée /etc/udev/rules.d/51-android.rules, il faut dire udevde s'en servir. Le moyen le plus sûr (à côté d'un redémarrage;) est de redémarrer le udevservice. Selon votre distribution Linux, cela peut être fait via service udev restartou /etc/init.d/udev restart.

Faites cela, laissez la coque de la racine. Déconnectez et reconnectez votre appareil Android, réessayez adb devices. La plupart des appareils sont apparus maintenant, mais pas le Wileyfox Swift - qui veut évidemment des câlins supplémentaires. Si vous êtes dans cette situation, ouvrez (ou créez s'il n'existe pas) le fichier ~/.android/adb_usb.iniet ajoutez-y une seule ligne, en nommant le fournisseur que vous avez découvert lsusbci-dessus; pour le Swift qui serait 0x2970(yupp, ici vous devez le préfixer par 0xpour indiquer qu'il s'agit d'un nombre hexadécimal). Redémarrez ensuite le serveur de la BAD: adb kill-server && adb start-server. Déconnectez et reconnectez à nouveau l'appareil. Maintenant adb devicesdevrait le voir.

Connecter l'appareil

Vous avez peut-être remarqué adb devicesquelque chose comme 0123456789ABCDEF unauthorized. C'est OK et pour votre sécurité (appareils): votre ordinateur doit d'abord être autorisé pour pouvoir accéder à l'appareil. Alors lancez simplement adb shellmaintenant - qui sera fermé avec un error: device unauthorized. Please check the confirmation dialog on your device.conseil Suivez ce conseil (cochez éventuellement la case pour autoriser de manière permanente votre ordinateur), et vous avez terminé: vous pouvez maintenant utiliser pour accéder à votre appareil.


Mises à jour:

¹ Notez que dans les versions Linux ultérieures, la syntaxe des règles UDEV a légèrement changé, comme par exemple jcomeau_ictx l'a souligné dans son commentaire. Pour les valeurs que nous avons trouvées ci-dessus, ce serait:

SUBSYSTEM=="usb", ATTR{idVendor}=="2970", ATTR{idProduct}=="2282", MODE="0666", GROUP="plugdev", SYMLINK+="android%n"

Deux différences: c'est maintenant SUBSYSTEM(pas de pluriel), et le groupe est passé de androiddevà plugdev(le premier n'existe pas sur les systèmes récents, le second existe et est généralement attribué au moins au premier utilisateur).

De plus, vous devrez peut-être ajouter le vendorID à votre ~/.android/adb_usb.ini(un ID par ligne, en notation hexadécimale):

# ANDROID 3RD PARTY USB VENDOR ID LIST
# 1 USB VENDOR ID PER LINE.
0x2970

1
le format de la règle udev était différent sur mon système Jessie: jcomeau@aspire:~$ tail -n 1 /etc/udev/rules.d/99-android.rules SUBSYSTEM=="usb", ATTR{idVendor}=="0e8d", ATTR{idProduct}=="201d", MODE="0666", GROUP="plugdev", SYMLINK+="android%n" jcomeau@aspire:~$ cat ~/.android/adb_usb.ini # ANDROID 3RD PARTY USB VENDOR ID LIST -- DO NOT EDIT. # USE 'android update adb' TO GENERATE. # 1 USB VENDOR ID PER LINE. 0x0e8d j'ai dû ignorer les conseils pour l'exécuter android update adbet le saisir manuellement comme vous l'avez indiqué.
jcomeau_ictx

@jcomeau_ictx merci pour la rétroaction! Pour autant que je puisse voir dans votre commentaire, il s'agit simplement d'utiliser un groupe d'utilisateurs différent ( plugdevau lieu de androiddev). Non vérifié, mais je dirais que la partie importante ici est que c'est un groupe que votre utilisateur (avec lequel vous souhaitez utiliser USB) a également.
Izzy

1
également SUBSYSTEMau lieu de SUBSYSTEMS, ATTRau lieu de ATTRS, virgule après MODE="0666" ne pas être sûr que tous ces changements étaient nécessaires, mais c'est ce qui a fonctionné.
jcomeau_ictx

Oh - merci, j'ai raté ces petits, @jcomeau_ictx - bon point!
Izzy

Pour Linux, les gens non avertis sudo wget -O /etc/udev/rules.d/51-android.rulesd' ici ont travaillé pour moi pour mon Xiaomi Mi A1. Bien sûr, il vaut mieux apprendre mais bon d'être paresseux :)
beeshyams

0

Quelques commentaires d'une nouvelle distribution Linux. Fedora 29 avec un Nexus 5X ou le téléphone Nokia 7.1 (Android One).

Déconnectez d'abord le téléphone, s'il est déjà connecté.

  1. Installez les outils android qui fourniront ADB ( sudo dnf install android-tools)
  2. Copier les règles udev ( sudo cp /usr/share/doc/android-tools/51-android.rules /etc/udev/rules.d)
  3. Recharger les règles udev ( sudo udevadm control --reload-rules)
  4. Redémarrez ADB pour être sûr ( sudo systemctl restart adb)

Connectez maintenant le téléphone et exécutez à adb devicespartir de la ligne de commande. Vous verrez probablement un appareil répertorié sans "autorisations". C'est bon.
S'il n'est pas répertorié, vous devrez ajouter votre appareil au fichier de règles udev, mais pour moi, les appareils testés ont juste fonctionné avec les règles prédéfinies.

Exécutez adb shellet j'espère que vous recevrez une notification de sécurité sur le téléphone vous demandant si vous voulez faire confiance à l'ordinateur, sélectionnez oui.
SI à la place, votre ordinateur dit "erreur: autorisations insuffisantes pour l'appareil", vous devez vous assurer que sur le téléphone, vous avez configuré votre port USB en mode "Transférer des fichiers", et non "Charger cet appareil". Sur Android 8.1, cela se trouve dans les paramètres sous "Appareils connectés"> "USB".

J'ai remarqué que même si vous avez tout fonctionne aujourd'hui, que demain il peut soudainement se casser sans raison apparente. Si cela se produit, vérifiez d'abord le paramètre du port USB sur l'appareil, qui peut être revenu en mode de charge, et si cela échoue, révoquez les autorisations de débogage USB sur l'appareil (dans les paramètres sous Options du développeur), et vous devriez, espérons-le, obtenir la pop -up à nouveau lorsque vous exécutez adb shell.

Avec cela, je suis en mesure d'exécuter Android Studio et d'exécuter sur l'appareil connecté.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.