¿Puedo habilitar la depuración USB usando adb?

Tengo un Samsung Galaxy S3 y la pantalla está rota y la depuración USB también está desactivada.

¿Cómo puedo habilitarlo usando ./adbcomandos? Ya he hecho estos pasos:

  • data/data/com.android.providers.settings/databases/settings.dbcambió adb_enabledel valor de 0 a 1.
  • Editado también build.propen /system.

Después de hacer todo esto, el teléfono parece bloqueado, no se enciende. Todo lo que quiero hacer es habilitar la depuración de USB y conectarlo a Vysor (beta) para poder controlarlo en mi computadora.

¡Bienvenidos! Buena pregunta. +1. Sin embargo, ¿por qué quieres controlar el teléfono a distancia?
Gracias... Porque la pantalla está rota y quiero examinar los datos que contiene. Aunque lo descubrí anoche... :)
La forma correcta de habilitar la depuración de USB sería descomprimir boot.img, editar init.rc (habilitar adb, luego deshabilitar la verificación RSA), volver a empaquetar boot.img y arrancar boot.img sin flashear. Una vez que se haya confirmado que la edición funciona, actualice boot.img en el dispositivo.

Respuestas (2)

Yo tengo que trabajar :)

NOTA : Esto requiere un gestor de arranque desbloqueado.

  • Conecte el dispositivo a Mac o PC en formato recovery mode. (Tuve que mapear el proceso en mi mente ya que la pantalla estaba rota).
  • Ahora abra terminal/CMD en la computadora y vaya a platform-tools/. escriba e ingrese ./adb devicespara verificar si el dispositivo está conectado en modo de recuperación.
  • Ahora escriba ./adb shell mount datay ./adb shell mount systemmonte los respectivos directorios.
  • Obtenga el persist.sys.usb.configarchivo en su sistema usando./adb pull /data/property/persist.sys.usb.config /Your directory
  • Ahora abra ese archivo en un editor de texto, edítelo mtp,adby guárdelo.
  • Ahora vuelva a colocar el archivo en el dispositivo;./adb push /your-directory/persist.sys.usb.config /data/property
  • Obtenga el archivo build.prop;./adb pull /system/build.prop /your-directory

  • Añade estas líneas:

    persistir.servicio.adb.habilitar=1                                                    
persistir.servicio.depurable=1
persist.sys.usb.config=mtp, adb
  • Vuelva a introducir build.prop en el dispositivo;./adb push /your-dir/build.prop /system/

De esta manera, habilitó la depuración de USB en su dispositivo. Pero sigues sin poder conectarte. ¿Por qué? Porque pide verificación RSA. Si pudiera ver su pantalla, podría tocar fácilmente YESpara autorizar el dispositivo. Actualmente estoy pensando en evitar esto. Tengo muchas ganas de revivir mi teléfono muerto. Si conoces alguna forma de hacerlo, compártela :)

¿Está ejecutando una recuperación personalizada?
No. La recuperación de existencias es.
Acerca de la parte de confirmación de RSA por parte del usuario, si está arrancado en el sistema operativo Android y se confirma de alguna manera que la pantalla muestra un cuadro de diálogo de confirmación, entonces puede usar adb shell input keyeventpara elegir SÍ. Vea el evento clave aquí . Es un tiro en la oscuridad, pero bien puede valer la pena disparar.
@Firelord Traté de hacer eso. Pero decía error de autorización. Parece que tengo que autorizarlo primero y luego hacer cualquier cosa...
¡Ah! Perdón por sugerir algo que no funcionaría. ¿Qué estaba pensando? Si el acceso ADB no está autorizado, entonces de ninguna manera adb shell inputfuncionaría. ¡Lo siento de nuevo! Veré si hay alguna forma de eludir la autorización de alguna manera.
Vi un cable USB a HDMI en una tienda el otro día, que supongo que podría usarse para conectar una pantalla externa a su dispositivo. Supongo que, con un concentrador USB, podría conectar eso, un mouse y un teclado a su dispositivo, todo a la vez. También encontré instrucciones para habilitar una conexión adb a través de Wi-Fi; usando todos esos juntos, es posible que tengas una muy buena oportunidad.
@Firelord, Aquí hay un malentendido fundamental. ¿Cómo estamos emitiendo comandos adb usando la recuperación de stock sin que adb esté habilitado? ¿No es esto un problema del huevo y la gallina? Pensé que la depuración USB habilitada era una condición necesaria antes de que el servidor adb permitiera las conexiones. Al menos en mi S5, si la depuración USB no está habilitada, el dispositivo no transmite su nombre a los servidores adb remotos.
@sherrellbc, este es uno de los casos excepcionales en los que una persona tiene una recuperación de stock que ejecuta un demonio ADB completo que proporciona acceso al shell. Una recuperación puede tener un demonio ADB y puede ser detectada por un cliente ADB independientemente del estado de depuración USB en el sistema operativo Android. En resumen, la depuración de USB es importante siempre que inicie el sistema operativo Android. Fuera de él, el escenario no tiene ningún significado.
@Firelord, Sí, por supuesto. Simplemente no estaba al tanto de ninguna imagen de recuperación de stock que proporcionara dicho acceso. De lo contrario, esto tiene sentido. ¡Gracias!
Invierta la aceptación de su respuesta, ya que no es correcta. Aunque es posible que haya editado build.prop, se olvidó de incluir el RSA en su respuesta. Sin el cumplimiento a través de RSA, no puede habilitar la depuración de USB. Lo que a su vez significa que la respuesta aceptada no es correcta.
¿Por qué en mi teléfono no existe este archivo? el objeto remoto '/data/property/persist.sys.usb.config' no existe

Para la verificación de RSA que solicitó omitir, no sé si funcionaría en su dispositivo, pero funcionó en mi pequeño experimento. En Lollipop, las claves ADB (después de la autorización) se guardan en formato /data/misc/adb/adb_keys. Su clave privada se guarda en la computadora. En Linux, la ubicación del directorio es $HOME/.android/. En Windows, eso generalmente se traduce como %USERPROFILE%\.android, pero las claves pueden terminar C:\Windows\System32\config\systemprofile\.androiden algunos casos. ( Fuente )

Hay un método descrito aquí por ashoke que podría ayudar a eludir la autorización.

Sin embargo, en mi Lollipop, el método varía. Noté que en mi ROM Lollipop primaria y secundaria adb_keystenían la misma clave en realidad. Todo lo que hice fue revocar la autorización de la ROM secundaria (el archivo se eliminó automáticamente), desconecté el dispositivo de la PC, copié adb_keysde la ROM principal a la ROM secundaria, conecté el dispositivo a la PC y ¡listo! No me pidieron esa autorización. Verifiqué dos veces el uso de la autorización adb devicesy todo estaba bien.

Pruebe la respuesta vinculada primero. Autorice un teléfono Android diferente, copie sus claves en su dispositivo desde el modo de recuperación y vea si funciona.

Hey gracias. Transferí adb_keys de la nota 2 a S3 y funcionó :)
Esta es la información necesaria para que la respuesta aceptada sea correcta. Buen trabajo. +1
Para aquellos que ejecutan un sistema operativo basado en Unix, adb push ~/.android/adbkey.pub /data/misc/adb/adb_keysfunciona de manera confiable.
@ChrisOlin: gracias por tu aporte. Pero supongo que adb debería ejecutarse en modo root (adb root); de lo contrario, el usuario no podrá colocar directamente un archivo en /data/misc/. ¿Correcto?
No exactamente, pero planteas una buena pregunta. Si está intentando habilitar la depuración de USB a través de ADB, deberá iniciar la recuperación para lograrlo. Los shells de recuperación (al menos con TWRP) por defecto son root. Si no lo hacen, entonces sí, el usuario no podrá ingresar directamente a /data/misc.
¿Puedo habilitar la depuración USB usando adb?
RespuestasAquíPolítica de privacidad1y, 10v