La búsqueda persistente encontró el cambio de código original que agregó autenticación de clave pública a ADB. Eso dice:
En el host, el par de claves pública/privada del usuario se genera automáticamente, si no existe, cuando el daemon de adb se inicia y se almacena en $HOME/.android/adb_key(.pub) o en $ANDROID_SDK_HOME en Windows. Si es necesario, la variable de entorno ADB_KEYS_PATH puede ser configurada como una lista separada por :- (; en Windows) de claves privadas, por ejemplo, claves de toda la empresa o del fabricante.
Sin embargo, esto no parece funcionar con las versiones recientes de adb y Android.
Experimentos
Usé adb 1.0.41 de platform tools 31.0.2-7242960, corriendo en Windows 10, con un Samsung Galaxy A52s 5G corriendo Android 12. Al inicio de los experimentos, tenía el dispositivo autorizado para depuración USB, y adb shell
funcionando bien. Puse el dispositivo fuera de mi alcance mientras seguía conectado, para no habilitar una nueva clave por error.
-
Detener el servidor de adb con adb kill-server
y renombrar mi directorio .android como .android.original. Ejecutar adb start-server
para generar un nuevo par de claves en un nuevo directorio .android, y luego ejecutar adb devices
para verificar que el dispositivo apareció pero no estaba autorizado.
-
Detener el servidor de adb. Configurar la variable de entorno ADB_KEYS_PATH al nombre completo de mi directorio .android.original. Iniciar el servidor de adb y luego ejecutar adb devices
. Resultado: El dispositivo se muestra, pero no está autorizado.
-
Como en #2, pero configurando ADB_KEYS_PATH al nombre completo de mi archivo .android.original\adbkey.pub. Resultado: como en #2.
-
Como en #2, pero configurando ADB_KEYS_PATH al nombre completo de mi archivo .android.original\adbkey. Resultado: como en #2.
-
Restaurar original: detener el servidor de adb, eliminar mi directorio .android y renombrar el directorio .android.original de vuelta a .android. Iniciar el servidor de adb y luego ejecutar adb devices
. Resultado: El dispositivo se muestra y muestra como autorizado.
Al mirar la pantalla del dispositivo después de completar el conjunto completo de pruebas, tenía una serie de diálogos, todos ofreciendo la oportunidad de aceptar la nueva clave de adb. Presioné "Cancelar" en todos ellos.
Si alguien con una colección de dispositivos Android antiguos y versiones antiguas de adb quiere experimentar más, estaría interesado en ver los resultados. Estoy razonablemente satisfecho de que no funcione con adb moderno.
Algo que no funcionará
La variable de entorno ADB_VENDOR_KEYS no es la respuesta, a menos que trabajes para un fabricante de dispositivos y tengas acceso a versiones de ingeniería ("eng") de Android.
0 votos
¿No debería ser diferente la adbkey en cada dispositivo?
0 votos
Quise decir por dispositivo Android, no por dispositivo de servidor
0 votos
Sí, también me refería al dispositivo Android. ¿No se supone que se debe hacer con un cálculo utilizando el número de serie del dispositivo? ¿Y algunas otras cosas?
0 votos
Como entiendo, el host (computadora) tiene una clave RSA que utiliza para autenticarse ante el dispositivo (teléfono/tablet/u otro) para que el usuario pueda aprobar las conexiones de depuración. Esta clave (y por lo tanto la huella digital en el diálogo) debe ser la misma para cualquier dispositivo al que se conecte el host.
0 votos
El dispositivo tiene una adbkey diferente. Eso es lo que ayuda al demonio ab a identificar el dispositivo, y lo que aparece como el código de identificación del dispositivo cuando ejecutas adb devices, por lo que ya estás obteniendo esa funcionalidad.
0 votos
¿Estás hablando del número en la salida de
adb devices
? Eso solo me da el número de serie del dispositivo.0 votos
¿Has intentado consultar la documentación oficial de adb?
0 votos
Sí, ¿encontraste algo que me hayga perdido?
0 votos
Si existe, está bien oculto. La variable de entorno ADB_VENDOR_KEYS no es la respuesta, a menos que trabajes para un fabricante de dispositivos y tengas acceso a compilaciones de Android de ingeniería ("eng").