android - descargar - comandos adb shell
Dispositivo Android Debug Bridge(adb)-sin permisos (20)
Esta pregunta ya tiene una respuesta aquí:
Tengo un problema para conectar el HTC Wildfire A3333 en modo de depuración con mi Fedora Linux 17. Adb dice:
./adb devices
List of devices attached
???????????? no permissions
mis reglas de udev (primera regla para Samsung que funciona bien y segunda para HTC que no):
SUBSYSTEM==”usb”,SYSFS{idVendor}==”04e8″,SYMLINK+=”android_adb”,MODE=”0666″,GROUP="plugdev"
SUBSYSTEM==”usb”,SYSFS{idVendor}==”0bb4″,SYMLINK+=”android_adb”,MODE=”0666″,GROUP="plugdev"
Para dispositivos Samsung, todo está bien:
./adb devices
List of devices attached
00198a9422618e device
He estado probando todas las respuestas dadas en un hilo similar sin suerte: usando HTC Wildfire para el desarrollo de Android
Cerrar ejecutando
adb, podría estar cerrando ejecutar android-studio.enumerar dispositivos,
/usr/local/android-studio/sdk/platform-tools/adb devices
... la propia respuesta del OP es incorrecta hasta ahora, que no hay "permisos especiales del sistema". - El problema de "no permiso" se reduce a ... sin permisos.
Lamentablemente, no es fácil depurar, porque adb hace que sea un secreto el dispositivo al que intenta acceder. En Linux, intenta abrir el dispositivo "convertidor serie USB" del teléfono, que es, por ejemplo, / dev / bus / usb / 001/115 (el número de bus y la dirección del dispositivo variarán). Esto a veces se vincula y se usa desde / dev / android_adb.
lsusb ayudará a encontrar el número de bus y la dirección del dispositivo. Tenga en cuenta que la dirección del dispositivo cambiará con seguridad si se vuelve a enchufar, al igual que el número de bus si el puerto se confunde sobre qué velocidad usar (por ejemplo, un puerto físico termina en un bus lógico u otro).
Una lsusb-line es similar a esto: Bus 001 Device 115: ID 4321: fedc bla bla bla
lsusb -v puede ayudarte a encontrar el dispositivo si el "bla bla bla" no es suficiente (a veces ni contiene el fabricante ni el modelo del teléfono).
Una vez que conozca el dispositivo, compruebe con sus propios ojos que ls -a /dev/bus/usb/001/115 es realmente accesible para el usuario en cuestión. Luego verifica que funcione con chmod y arregla tu configuración de udev.
PS1: / dev / android_adb solo puede apuntar a un dispositivo, así que asegúrese de hacer lo que desee.
PS2: no relacionado con esta pregunta, pero menos conocido: adb tiene una lista fija de identificadores de proveedores que atraviesa. Esta lista se puede extender desde ~ / .android / adb_usb.ini, que debe contener 0x4321 (si seguimos mi ejemplo de la línea lsusb de arriba). - No es necesario aquí, ya que ni siquiera se obtiene un "sin permisos" si no se conoce la identidad del proveedor.
Acabo de tener este problema yo mismo bajo Debian Wheezy. Reinicié el adb daemon con sudo:
sudo ./adb kill-server
sudo ./adb start-server
sudo ./adb devices
Todo funciona :)
Cambiando el modo USB del teléfono me funcionó. (Lo configuro para Transferencia de archivos)
En THL W100, ejecutar el dispositivo como root (como se describe arriba) funcionó solo junto con tethering habilitado (utilicé AirDroid para eso).
Encontré el mismo problema hoy.
Seguí las instrucciones oficiales , pero no me di cuenta de que DEBO ejecutar el comando
"chmod a + r /etc/udev/rules.d/51-android.rules"
Después de configurar este archivo como legible en todo el mundo y volver a enchufar mi cable usb, el estado no se autoriza. Entonces solo conceden el permiso y todo va bien.
Estoy de acuerdo con Robert Siemer y Michaël Witrant . Si no funciona, intenta depurar con strace
strace adb devices
En mi caso, ayuda a eliminar todas las instancias y eliminar el archivo socket /tmp/ADB_PORT (el valor predeterminado es /tmp/5037 ).
La causa de ese problema tiene que ver con los permisos del sistema (gracias @ IsaacCisneros por esta sugerencia). De alguna manera, HTC Wildfire (y tal vez los demás) necesitan algo más del sistema que los dispositivos de Samsung. La solución simple es ejecutar Eclipse como raíz, pero esto no es muy cómodo con sistemas Linux no sudo como Fedora.
He encontrado otra forma de lograr el mismo objetivo, que parece ser más fácil de usar y tiene menos problemas de seguridad que ejecutar IDE completo con privilegios de superusuario. Tenga en cuenta que esto sigue siendo solo una solución al problema. El uso de la raíz del sistema se debe minimizar solo a las tareas administrativas, y "adb" se diseñó para funcionar con una cuenta de usuario normal sin SUID. A pesar del hecho de que la configuración adecuada de SUID es bastante segura, cada aumento de permiso individual es un potencial agujero de seguridad del sistema.
1.Configurar la propiedad del archivo binario adb (propietario - raíz, grupo propietario - grupo_usuario):
chown root:user_group adb
2. Establecer permisos con SUID:
chmod 4550 adb
Esto debería dar como resultado algo similar a esto (ls -llh):
-r-sr-x---. 1 root user_name 1.2M Jan 8 11:42 adb
Después de eso, podrá ejecutar adb como un evento raíz, aunque utilizará su cuenta de usuario normal. Puede ejecutar Eclipse como un usuario normal y su HTC debe ser descubierto correctamente.
./adb devices
List of devices attached
HT0BPPY15230 device
La respuesta de Stephan funciona (usando sudo adb kill-server), pero es temporal. Debe volver a emitirse después de cada reinicio.
Para una solución permanente, la configuración de udev debe ser modificada:
La respuesta de Witrant es la correcta (copiada de la documentación oficial de Android). Pero es solo una plantilla. Si eso no funciona para su dispositivo, debe completar el ID del dispositivo correcto para su (s) dispositivo (s).
lsusb
Bus 001 Device 002: ID 05c6:9025 Qualcomm, Inc.
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
...
Encuentra tu dispositivo Android en la lista.
A continuación, utilice la primera mitad de la ID (4 dígitos) para idVendor (la última mitad es idProduct, pero no es necesario que adb funcione).
sudo vi /etc/udev/rules.d/51-android.rules y agregue una regla para cada idVendor único:
SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", MODE="0666", GROUP="plugdev"
Es así de simple. No necesita todos los otros campos que figuran en algunas de las respuestas. Guarda el archivo.
Luego reinicia. El cambio es permanente. (Roger muestra una forma de reiniciar udev, si no desea reiniciar).
La respuesta está entretejida entre los diversos mensajes, lo haré lo mejor posible, pero parece una razón muy simple y obvia.
1) es que generalmente hay una variable de "usuario" en la regla de udev, algo así como USER = "your_user" probablemente justo después del GROUP = "plugdev"
2) Debe usar los valores SYSFS {idVendor} == "####" y SYSFS {idProduct} == "####" correctos para su dispositivo / s. Si tiene dispositivos de más de un fabricante, digamos uno de Samsung y uno de HTC, debe tener una entrada (regla) para cada proveedor, no una entrada para cada dispositivo, sino para cada proveedor diferente que utilizará, por lo que necesita una entrada para HTC y Samsung. Parece que tienes tu entrada para Samsung ahora que necesitas otra. Recuerde el USUARIO = "su_usuario". Use ''lsusb'' como Robert Seimer sugiere encontrar el idVendor y idProduct, generalmente son algunos números y letras en este formato X # X #: # X # XI creo que el primero es el idVendor y el segundo idProduct pero va a necesitar haga esto para cada marca de teléfono / tableta que tenga.
3) No he descubierto cómo 51-adb.rules y 99-adb.rules son diferentes o por qué.
4) tal vez intente agregar el grupo "plugdev" a su usuario con "usermod -a -G plugdev your_user". Inténtelo bajo su propio riesgo, aunque no creo que sea más peligroso que lanzar una interfaz gráfica de usuario como root, pero creo que si es necesario al menos debería usar "gksudo eclipse".
Espero que haya ayudado a aclarar algunas cosas, la sintaxis de las reglas de udev también es un misterio para mí, pero por lo que escucho puede ser diferente para diferentes sistemas, pruebe algunas cosas, uno se comió un tiempo y observe qué cambio funciona .
La salida de ls -al /usr/bin/adb debe mostrar que es propiedad de la root usuario y la root grupo. Puede usar ACL de Linux (Listas de control de acceso) para otorgar a su usuario local permisos para adb siguiente manera:
setfacl -m "u:userName:rwx" /usr/bin/adb
Esto es preferible a establecer el bit SUID en /usr/bin/adb y también limita a los usuarios que pueden usar adb para userName y root .
Mismo problema con Pipo S1S después de actualizar a 4.2.2 stock Rom 4 de junio.
$ adb devices
List of devices attached
???????????? no permissions
Todas las sugerencias anteriores, aunque son válidas para que tu dispositivo USB sea reconocido, no resuelven el problema por mí. (Android Debug Bridge versión 1.0.31 ejecutándose en Mint 15.)
La actualización de las herramientas sdk de Android restablece ~/.android/adb_usb.ini .
Para reconocer Pipo VendorID 0x2207, siga estos pasos
Agregar a la línea /etc/udev/rules.d/51-android.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="0x2207", MODE="0666", GROUP="plugdev"
Agregar línea a ~/.android/adb_usb.ini :
0x2207
A continuación, elimine los archivos adbkey
rm -f ~/.android/adbkey ~/.android/adbkey.pub
y reconecte su dispositivo para reconstruir los archivos clave con una conexión adb correcta. Algunos dispositivos solicitarán volver a autorizar.
sudo adb kill-server
sudo adb start-server
adb devices
Otra posible fuente de este problema es la conexión USB. Si usó el anclaje a red USB, apáguelo, luego desenchufe el dispositivo del USB, vuelva a enchufarlo, luego haga
adb kill-server
adb devices
Eso hizo el truco en mi caso (Ubuntu 12.04, Nexus S, SDK en el directorio de inicio, nunca necesitó root para ejecutarlo). Dependiendo de su dispositivo, es posible que necesite adb devices como root.
Precederé esta postdata aquí en la parte superior para que no se pierda en mi explicación anterior.
Puedo producir y resolver de forma confiable el problema de los no permisos simplemente cambiando el tipo de conexión USB de la Cámara (PTP) al Dispositivo de Medios (MTP). El modo de cámara permite la depuración; el modo de medios causa la respuesta de no permisos en ADB.
El razonamiento parece bastante evidente después de reflexionar sobre eso por un momento. El depurador podría acceder al contenido no protegido en el dispositivo en el modo de servidor de medios.
===========
El dispositivo no se ejecutará hasta que acepte la advertencia de cifrado RSA en el dispositivo depurado. En algún momento después de la conexión, el dispositivo pedirá que acepte la conexión de depuración. Es un protocolo de seguridad mínimo que garantiza que puede acceder al dispositivo más allá del bloqueo de deslizamiento inicial. El modo de desarrollador debe estar habilitado, creo.
El indicador "sin permisos" es en realidad un buen primer indicador de que adb reconoce el dispositivo como un objetivo de depuración válido. Tenga en cuenta que no muestra sus otros dispositivos USB.
Detalles en las siguientes páginas y relacionadas.
Pruebe el comando "android update adb". Me ayuda con el equipo de Samsung Galaxy.
Tenía el mismo problema. Fue un problema con las reglas de udev. Intenté algunas de las reglas mencionadas anteriormente pero no solucioné el problema. Encontré un conjunto de reglas aquí, https://github.com/M0Rf30/android-udev-rules . Seguí la guía allí y, voila, reparado.
Tengo un problema similar:
$ adb devices
List of devices attached
4df15d6e02a55f15 device
???????????? no permissions
Investigación
Si ejecuto lsusb , puedo ver qué dispositivos he conectado y dónde:
$ lsusb
...
Bus 002 Device 050: ID 04e8:6860 Samsung Electronics Co., Ltd GT-I9100 Phone ...
Bus 002 Device 049: ID 18d1:4e42 Google Inc.
Esto muestra mi Samsung Galaxy S3 y mi Nexus 7 (2012) conectados.
Verificando los permisos en aquellos:
$ 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
Espere. ¿Qué? ¿De dónde vino ese grupo "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"
(He envuelto esas líneas)
Tenga en cuenta las líneas GROUP="plugdev" . También tenga en cuenta que esto no funciona para la otra ID del dispositivo:
$ grep -Ri "4e42.*plugdev" .
(nada es devuelto)
Arreglando lo
DE ACUERDO. Entonces, ¿cuál es la solución?
Agrega una regla
Cree un archivo /etc/udev/rules.d/99-adb.rules contenga la siguiente línea:
ATTRS{idVendor}=="18d1", ATTRS{idProduct}=="4e42", ENV{ID_GPHOTO2}="1",
ENV{GPHOTO2_DRIVER}="proprietary", ENV{ID_MEDIA_PLAYER}="1",
MODE="0664", GROUP="plugdev"
Esto debería ser una sola línea, lo he envuelto aquí para la legibilidad
Reiniciar udev
$ sudo udevadm control --reload-rules
$ sudo service udev restart
Eso es
Desenchufe / vuelva a conectar su dispositivo.
Intentalo
$ adb devices
List of devices attached
4df15d6e02a55f15 device
015d2109ce67fa0c device
Tu regla de udev parece incorrecta. Usé esto y funcionó:
SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", MODE="0666", GROUP="plugdev"
( ATTR lugar de SYSFS )
Tuve la misma situación en la que tres dispositivos se conectaban a un mismo host pero solo uno tenía "ningún permiso", otros estaban en línea.
Agregar otro SUID o SGID en adb fue otro problema para mí. Los dispositivos se ven desconectados cada vez que se reinicia adb, hasta que reconoce en los dispositivos todo el tiempo.
Resolví este problema de "no permisos" al agregar el permiso ''o + w'' para un archivo de dispositivo.
chmod o + w / dev / bus / usb / 00n / xxx
bajo ubuntu 12.04, eclipse juno. Me enfrento al mismo problema. Esto que encontré en Yi Yu Blog
La solución es la misma que Leon
sudo -s
adb kill-server
adb start-server
adb devices