Habilitar la depuración USB en el dispositivo
Esto se hace en Ajustes ' Desarrollo . Si no tiene esa entrada en su menú de configuración, vaya a Configuración ' Acerca de , desplázate hasta el "Número de compilación", y martillea como un mono hasta que tu dispositivo te felicite por haberte convertido en desarrollador. Vuelve a la página principal del Ajustes y cerca de la parte inferior debería ver la configuración de "Desarrollo" (o "Desarrolladores") ahora. Entra en ella, y activa Depuración USB aquí.
Identificar el dispositivo
Primero necesitamos saber cómo se identifica el dispositivo en el bus USB. Para ello, con el dispositivo Android NO conectado, coge un shell y ejecuta el comando lsusb . A continuación, conecte el dispositivo y ejecute de nuevo el comando. Observa la nueva línea. Para el Wileyfox Swift se trata de un "dispositivo sin nombre":
Bus 004 Device 003: ID 2970:2282
Establecimiento de las normas para el ADB
Ahora necesitamos los números al final de la línea anterior: 2970:2282 . En ellos se especifica el proveedor (2970) y el propio dispositivo (2282). Teniendo esos datos, necesitamos un root en nuestra máquina Linux para editar (o crear, si aún no existe) el /etc/udev/rules.d/51-android.rules archivo. Allí, añada una línea para su dispositivo. La siguiente línea de ejemplo muestra cómo se ve para el Wileyfox Swift:¹
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2970", ATTRS{idProduct}=="2282", MODE="0666" GROUP="androiddev", SYMLINK+="android%n"
Si tiene un dispositivo diferente, sustituya los ID de proveedor y de producto por los que ha encontrado anteriormente al ejecutar lsusb . Una breve explicación de la línea:
-
SUBSYSTEMS=="usb" : obviamente esta regla es sólo para USB ;)
-
ATTRS{idVendor}=="2970" : el ID de proveedor del dispositivo para el que se aplica esta regla
-
ATTRS{idProduct}=="2282" : el ID del dispositivo
-
MODE="0666" : permisos que obtendrá el nodo del dispositivo. 0666 es bastante laxo, ya que da a todos los usuarios del sistema permisos de lectura y escritura, así que si le preocupa, puede intentar sustituirlo por un 0660 (dando sólo lectura-escritura al propietario y al grupo, y negando todo a los demás).
-
GROUP="androiddev" : a qué grupo debe pertenecer el nodo del dispositivo. Debe ser un grupo al que pertenezcan los usuarios que vayan a trabajar con el dispositivo.
-
SYMLINK+="android%n" : sólo para dar un nombre bonito al nodo, para poder encontrarlo más fácilmente en /dev (en mi caso, luego apareció allí como /dev/android5 )
Esa norma entró en /etc/udev/rules.d/51-android.rules Debemos decir udev para hacer uso de ella. La forma más segura (junto a un reinicio ;) es reiniciar el udev servicio. Dependiendo de su distribución de Linux, esto se puede hacer a través de service udev restart o /etc/init.d/udev restart .
Hecho esto, deja la cáscara de root. Desconecte y vuelva a conectar su dispositivo Android, intente adb devices de nuevo. La mayoría de los dispositivos aparecieron ahora, pero no el Wileyfox Swift - que obviamente quiere algunos mimos extra. Si te encuentras en esa situación, abre (o crea si no existe) el archivo ~/.android/adb_usb.ini y añada una sola línea, nombrando al proveedor que ha encontrado con lsusb arriba; para el Swift que sería 0x2970 (yupp, aquí hay que ponerle el prefijo 0x para señalar que es un número hexadecimal). A continuación, reinicie el servidor ADB: adb kill-server && adb start-server . Desconecte y vuelva a conectar el dispositivo. Ahora adb devices debería verlo.
Conectar el dispositivo
Puede que te hayas dado cuenta de que adb devices te dijo algo así como 0123456789ABCDEF unauthorized . Eso está bien y para su seguridad (de los dispositivos): su ordenador debe estar autorizado primero para poder acceder al dispositivo. Así que simplemente emite adb shell ahora - que se dejará con un error: device unauthorized. Please check the confirmation dialog on your device. Sigue estos consejos (opcionalmente marca la casilla para autorizar permanentemente tu ordenador), y ya está: Ahora puedes usar adb para acceder a su dispositivo.
Actualizaciones:
¹ Tenga en cuenta que en versiones posteriores de Linux, la sintaxis de las reglas UDEV ha cambiado ligeramente, como por ejemplo jcomeau_ictx señaló en su comentario. Para los valores que hemos encontrado arriba sería:
SUBSYSTEM=="usb", ATTR{idVendor}=="2970", ATTR{idProduct}=="2282", MODE="0666", GROUP="plugdev", SYMLINK+="android%n"
Dos diferencias: ahora es SUBSYSTEM (sin plural), y el grupo ha cambiado de androiddev a plugdev (el primero no existe en los sistemas recientes, el segundo sí y suele asignarse al menos al primer usuario).
Además, es posible que tenga que añadir el vendorID a su ~/.android/adb_usb.ini (un ID por línea, en notación hexadecimal):
# ANDROID 3RD PARTY USB VENDOR ID LIST
# 1 USB VENDOR ID PER LINE.
0x2970
0 votos
Siempre estoy abierto a las críticas, pero un voto negativo sin explicación es difícil de interpretar. Así que, ¿podría el autor del voto negativo explicar qué debería mejorarse en la pregunta? Prometo no abusar de mis poderes de mod para castigar :)
3 votos
Supongo que el votante no se dio cuenta de que publicaste la pregunta para autoresponderte (no debió fijarse en ti en la respuesta). Dado que no hay ninguna pista en la pregunta o en los comentarios de que se publicó con el propósito de auto-respuesta el votante podría haber objetado al penúltimo párrafo (muestra la pereza, si se lee en el contexto de cualquier usuario normal y su pregunta). Por ahora no se me ocurre ninguna otra razón.
1 votos
@Firelord me parece convincente (he editado un poco la pregunta para evitar pasos en falso adicionales). Pero entonces, ese usuario debería haber upvoted la respuesta. ¿O también me he perdido algo? ;)