Notas de implementación del BAD
Generalmente, todo el trabajo lo realiza:
Este es un proceso en segundo plano que se ejecuta en la máquina host. Su propósito es detectar puertos USB para saber cuándo se conectan/quitan dispositivos y cuándo se inician/detienen las instancias del emulador.
Debe mantener una lista de "dispositivos conectados" y asignar a cada dispositivo un "estado": fuera de línea, iniciado, recuperado o en línea (más sobre esto a continuación).
El servidor ADB es realmente un bucle de reutilización gigante, su propósito es organizar el intercambio de datos (paquetes, reales) entre clientes, servicios y dispositivos.
"Adbd" se ejecuta como un proceso en segundo plano en un dispositivo Android o sistema emulador. Su propósito es conectarse al servidor ADB (conectar el dispositivo mediante USB y el emulador mediante TCP) y proporcionar algunos servicios al cliente que se ejecuta en la máquina host.
Cuando el servidor ADB se conecta exitosamente a adbd dentro del dispositivo, considera que el dispositivo está en línea. De lo contrario, el dispositivo está fuera de línea, lo que significa que el servidor ADB detectó el nuevo dispositivo/emulador, pero no puede conectarse al demonio adbd.
Los estados del gestor de arranque y de recuperación corresponden al estado correspondiente del dispositivo en modo gestor de arranque o recuperación.
El programa de línea de comandos Adb se utiliza para ejecutar comandos adb en un shell o script. Primero intenta ubicar un servidor ADB en la máquina host; si no hay uno, iniciará uno automáticamente.
El cliente luego envía su solicitud de servicio al servidor ADB. No es necesario que lo sepa.
Actualmente se utiliza un binario "adb" como servidor y cliente. Esto facilita la distribución y el inicio de servidores.
Los clientes pueden interactuar básicamente con dos servicios.
Servicios de host:
Servicios locales:
Estos servicios se ejecutan dentro del demonio adbd o los inicia él mismo en el dispositivo. El servidor ADB se utiliza para multiplexar transmisiones entre clientes y servicios que se ejecutan en adbd. En este caso su función es inicializar la conexión y luego actuar como canal de datos.
Aquí se detalla el protocolo utilizado entre el cliente ADB y el propio servidor ADB. El servidor ADB escucha en TCP: localhost:5037.
El cliente envía la solicitud en el siguiente formato:
Por ejemplo, para consultar el número de compilación del servidor ADB, el cliente haría lo siguiente:
Prefijo "host:" se utiliza para indicar que la solicitud se envía al servidor mismo (analizaremos otros tipos de solicitudes más adelante). La longitud del contenido está codificada en ASCII para facilitar la depuración.
El servidor debe responder a la solicitud de una de las siguientes maneras:
Tenga en cuenta que después de aceptar, la conexión sigue activa, lo que permite al cliente realizar otras solicitudes. Pero en algunos casos, OKAY incluso cambiará el estado de la conexión.
Por ejemplo, en "Host:Transport:
FileServices.txt" se enumeran todos los servicios actualmente implementados por ADB.
ADB Transport tiene un enlace a ADB Servidor y Actualmente existen dos tipos de transportes para modelar conexiones entre dispositivos o emuladores:
En teoría, debería ser posible escribir un transporte local que actúe como proxy del servidor ADB para conectarse/ejecutarse en otra máquina. dispositivos/emuladores Aunque aún no está completo.
Cada transferencia puede transportar tráfico múltiple entre uno o más clientes y el dispositivo/emulador al que apuntan. Manejar correctamente interrupciones de transmisión inesperadas (por ejemplo, cuando el dispositivo está físicamente). desconectado)
Traducción del texto original