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.rules
fichier. 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. 0666
est 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 udev
de s'en servir. Le moyen le plus sûr (à côté d'un redémarrage;) est de redémarrer le udev
service. Selon votre distribution Linux, cela peut être fait via service udev restart
ou /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.ini
et ajoutez-y une seule ligne, en nommant le fournisseur que vous avez découvert lsusb
ci-dessus; pour le Swift qui serait 0x2970
(yupp, ici vous devez le préfixer par 0x
pour 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 devices
devrait le voir.
Connecter l'appareil
Vous avez peut-être remarqué adb devices
quelque 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 shell
maintenant - 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 adb 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