Debugging de Paquetes de Terceros en React Native

Cuando se es desarrollador de aplicaciones móviles con React Native, los desafíos técnicos son una constante. Recientemente, me encontré resolviendo un problema complejo justo antes de una importante liberación de software. Este artículo narra mi experiencia lidiando con un error inesperado en el SDK de Hypertrack, utilizado en Gigable para el rastreo de dispositivos, y cómo los logs del sistema y de la aplicación me ayudaron a identificar y solucionar el problema.

Un poco de contexto

El dilema comenzó con un proceso que, en principio, parecía rutinario: la generación de un device_id durante la inicialización del SDK de Hypertrack. Esta librería, diseñada para manejar eficientemente el rastreo de dispositivos, creando y registrando el device_id en los servidores de Hypertrack. El siguiente paso en nuestro flujo interno es invocar la API de Hypertrack para agregar metadatos al dispositivo recién creado, utilizando el endpoint PATCH /devices/{device_id}. Sin embargo, este proceso se encontró con un obstáculo inesperado: el endpoint devolvía un error 404, un fallo que no tenía una explicación inmediata. Motivado por la urgencia de resolver este problema antes de la liberación del software, inicié una investigación exhaustiva que me llevó a explorar en profundidad los logs del sistema, de la aplicación y finalmente los específicos del paquete SDK.

Usando el ADB (Android Debug Bridge) para ver los logs

¿Qué es ADB?

ADB, o Android Debug Bridge, es una herramienta versátil que forma parte del Android SDK (Software Development Kit) y que permite a los desarrolladores comunicarse con un dispositivo Android desde una PC, facilitando una amplia gama de tareas, desde la instalación de aplicaciones hasta la extracción de logs y la ejecución de comandos en el dispositivo. Esta herramienta es esencial para la depuración de aplicaciones, permitiendo a los desarrolladores acceder a información detallada sobre el funcionamiento interno de sus aplicaciones en un entorno Android.

Instalación de ADB

Para instalar ADB, debes seguir estos pasos:

1. Descarga el Android SDK: ADB viene incluido en el Android SDK Platform-Tools. Puedes descargarlo desde el sitio web de Android Developers.

2. Configuración del PATH: Una vez descargado, agrega la ubicación de la carpeta platform-tools a la variable de entorno PATH en tu sistema. Esto te permitirá ejecutar ADB desde cualquier directorio en la línea de comandos.

3. Verificación de la Instalación: Para verificar que ADB esté instalado correctamente, abre una terminal y escribe adb version. Esto debería mostrar la versión de ADB instalada en tu sistema.

$ adb version
Android Debug Bridge version 1.0.41
Version 28.0.2-debian
Installed as /usr/lib/android-sdk/platform-tools/adb

Uso de ADB

Utilizar ADB para depurar problemas en aplicaciones Android implica varios pasos:

1. Conectar el Dispositivo: Conecta tu dispositivo Android a la PC mediante un cable USB. Asegúrate de que el modo de depuración USB esté activado en el dispositivo, aunque tambien funciona de forma similar con emulatores que estan en ejecución.

2. Comprobación de Dispositivos Conectados: Puedes verificar si tu dispositivo está correctamente conectado y accesible mediante ADB utilizando el comando adb devices. Esto listará los dispositivos conectados.

$ adb devices
List of devices attached
emulator-5554   device

3. Acceso a Logs del Sistema y de Aplicaciones: Para acceder a los logs, utiliza el comando adb logcat. Esto te mostrará los logs del sistema y de las aplicaciones en tiempo real. Puedes filtrar estos logs para centrarte en los específicos de tu aplicación o del paquete SDK de terceros.

Por ejemplo:

adb logcat | grep -i "nombreDeTuAplicación"

Este comando filtra los logs para mostrar solo aquellos relacionados con tu aplicación.

4. Ejecución de Comandos en el Dispositivo: ADB también te permite ejecutar comandos directamente en el dispositivo. Esto es útil para operaciones como la copia de archivos o la ejecución de scripts.

$ adb shell
emu64xa:/ $

Localización y Extracción de Archivos de Logs

Explorando Logs con Logcat

Inicialmente, utilicé logcat para revisar los logs del sistema y de la aplicación. Logcat es una poderosa herramienta de línea de comandos que proporciona un flujo de logs del sistema y de las aplicaciones en un dispositivo Android. Sin embargo, debido a la gran cantidad de información que logcat proporciona, no pude identificar nada relevante o comprensible relacionado con el problema específico que estaba enfrentando. Los logs son extensos y pueden ser abrumadores si no se sabe exactamente qué buscar.

Búsqueda de los Logs del SDK

Decidí entonces explorar la estructura de carpetas del dispositivo más a fondo. Además, contacté al equipo de soporte de Hypertrack, quienes me indicaron que podía acceder a los logs específicos de su librería, ubicados en /data/data/com.aplication.mobile/files/hypertrack. Estos logs son generados por el SDK de Hypertrack y podrían contener información valiosa sobre el problema que estaba experimentando.

Empaquetando los Logs

Para acceder a estos logs, usé el siguiente comando en la terminal de ADB:

run-as com.aplication.mobile tar -cvf /data/data/com.aplication.mobile/files/hypertrack-logs.tar /data/data/com.aplication.mobile/files/hypertrack

Este comando se debe ejecutar una vez que se ha iniciado la sesión en el dispositivo con adb shell, y ahora te explico que ocurre aqui:

• run-as com.aplication.mobile: Este prefijo permite que el comando se ejecute en el contexto de la aplicación especificada, en este caso, com.aplication.mobile. Es necesario porque los archivos de logs están en un directorio al que solo tiene acceso la aplicación.

• tar -cvf: Este es un comando estándar de Unix para crear un archivo tar. tar significa "tape archive", y es una forma de empaquetar múltiples archivos en un solo archivo para un transporte o almacenamiento más fácil. Las opciones -cvf significan "crear" (c), "verboso" (v, para mostrar los archivos que se están añadiendo), y "archivo" (f, seguido del nombre del archivo de salida).

Extracción de los Logs a la Máquina Local

Una vez que empaqueté los logs en un archivo .tar, necesité transferir este archivo a mi máquina local para un análisis más detallado. Para hacer esto, utilicé otro comando en una nueva ventana de terminal:

adb exec-out "run-as com.application.mobile cat /data/data/com.application.mobile/files/hypertrack-logs.tar" > $HOME/Desktop/logs.tar

Este comando funciona de la siguiente manera:

• adb exec-out: Ejecuta un comando en el dispositivo y devuelve la salida al sistema local.

• "run-as com.application.mobile cat /data/data/com.application.mobile/files/hypertrack-logs.tar": Este comando usa cat para mostrar el contenido del archivo .tar que contiene los logs. Al igual que con el comando tar, run-as se usa para ejecutar este comando en el contexto de la aplicación.

• > $HOME/Desktop/logs.tar: Redirige la salida (en este caso, el contenido del archivo .tar) a un archivo en el escritorio de mi máquina local.

Análisis de Archivos de Logs con Bless

Una vez que obtuve los archivos de logs del SDK de Hypertrack, me encontré con un obstáculo inesperado: los logs estaban en formato hexadecimal. Este formato es común en archivos binarios, donde los datos se representan como una serie de valores hexadecimales. Esto puede ocurrir cuando los logs incluyen datos no solo en texto plano, sino también información binaria o codificada, lo cual no es directamente legible.

¿Qué es Bless y Cómo Funciona?

Para convertir estos datos hexadecimales en un formato legible, opté por utilizar Bless, un editor de archivos hexadecimales para Linux. Bless es una herramienta poderosa que permite a los usuarios ver y editar archivos en formato hexadecimal, lo que resulta útil cuando se trabaja con archivos binarios o datos codificados. Ofrece una interfaz gráfica que facilita la navegación por los archivos y la visualización de los datos tanto en formato hexadecimal como en su representación en caracteres ASCII.

Proceso de Análisis con Bless

Después de instalar Bless en mi sistema Linux, abrí los archivos de logs y comencé a explorar su contenido. La interfaz de Bless me permitió desplazarme por los datos hexadecimales y ver su correspondiente representación textual, lo que facilitó enormemente la tarea de interpretar los logs.

Mientras analizaba los archivos, encontré una sección particularmente reveladora que decía lo siguiente:

access-control-allow-origin: *
content-type: application/json
date: Wed, 29 Nov 2023 15:34:49 GMT
https://api.hypertrack.com/authenticate
{
    "error": "trial ended",
    "description": "You have exhausted your events quota"
}

Este fragmento fue la pieza clave para entender el problema, ya que reveló que, aunque la librería de Hypertrack generaba correctamente el device_id, había un problema en el registro del dispositivo con los servidores de Hypertrack. El mensaje de error "trial ended" y "You have exhausted your events quota" indicaba que el dispositivo no se registraba adecuadamente debido a limitaciones en la cuenta o en el uso del servicio. Esto explicaba por qué el intento posterior de agregar metadatos al dispositivo a través del endpoint PATCH /devices/{device_id} resultaba en un error 404: el servidor de Hypertrack no tenía constancia de este nuevo dispositivo debido al error inicial en el registro.

Conclusión

El descubrimiento de este error en los logs fue crucial, ya que me permitió entender que el problema no estaba en el código de la aplicación o en la implementación del SDK, sino en la configuración de la cuenta de Hypertrack. Una vez identificado este problema, pude tomar las medidas necesarias para resolverlo, ya sea ajustando la configuración de la cuenta o comunicándome con el soporte de Hypertrack para una solución.

Esta experiencia subraya la importancia de contar con las herramientas adecuadas para la depuración y el análisis de problemas. Bless se demostró como una herramienta invaluable en este proceso, permitiéndome convertir datos que parecían incomprensibles en información clara y útil para la resolución de problemas.

Igualmente me divertí bastante durante la exploración de este problema, este tipo de retos suelen ser entretenidos porque nos ponen a prueba y salimos de las herramientas normales que utilizamos diariamente durante los procesos de desarrollo y yo, por supuesto que soy fan de encontrar bugs y resolverlos, espero que este artículo te sirva para comprender como hacer debugging de aplicaciones con React Native.

Happy coding! :D

Photo by C M on Unsplash