Implementación de emuladores de Android en AWS EC2 [1/3] | Arquitectura ARM y Genmony | Soluciones para un desarrollador en solitario | de Uddeshya Singh | Noviembre de 2020

Pero usaremos específicamente imágenes del sistema; android-25; google_apis; armeabi-v7a versión. Ahora déjeme justificar esta elección.

¿Por qué Android-25? 🤔

Esto es algo que Trell necesitaba para controlar el registro de eventos de Firebase, algo menos que Android-29, por lo que elegir una versión decentemente más baja tenía sentido para observar la portabilidad hacia atrás de la aplicación.

¿Por qué la versión google_api? 🙇🏽‍♂️

Podemos realizar una amplia variedad de operaciones en nuestro emulador de Android si están rooteados por defecto (tenemos acceso de superusuario). Para conectarse en modo raíz y acceder al shell del emulador usando la línea de comando, esta versión debe ser “predeterminada” o “google_apis “ porque google_apis_playstore no permitirá la conexión de root desde el puente de depuración de Android (en arquitecturas Intel) pero en ARM (como este) puedes agarrar a cualquiera, ¡todo será rooteado por defecto!

¿Por qué la arquitectura armeabi-v7a? 💁🏾‍♂️️

v7a representa una versión de 32 bits de la arquitectura ARM (algo que se requiere para la aplicación Trell). Ahora, ¿por qué ARM? porque la arquitectura Intel (x86) requiere aceleración de hardware para funcionar y esto se puede hacer con Intel HAXM (en Windows) o KVM (en Ubuntu). Puede probar esta secuencia de comandos para verificar si KVM se puede habilitar en su instancia o no.

$ sudo apt install cpu-checker -y
$ kvm-ok

Esto le dará la bienvenida con el siguiente mensaje.

INFO: Your CPU does not support KVM extensions
INFO: For more detailed results, you should run this as root
HINT:   sudo /usr/sbin/kvm-ok

¿Por qué los emuladores de Intel no funcionan en estas instancias EC2? 😭

Antes de entrar en esto, echemos un vistazo rápido a cómo funcionan los emuladores. QEMU es una herramienta que imita el hardware del dispositivo invitado y luego traduce el archivo Interfaz de aplicación binaria (ABI) del dispositivo invitado para que coincida con el del dispositivo host. (armeabi-v7a para intel x86_64 en este caso). Ahora, para acelerar este complejo y lento proceso, hipervisor son introducidos.

Intel HAXM (Hardware Acceleration Execution Manager) es un componente de hipervisor para Windows y macOS. Existe KVM (máquina virtual basada en kernel) para Linux. Con la aceleración de hardware, el emulador de Android puede ejecutar dispositivos virtuales a velocidades similares a las de la CPU de su estación de trabajo.

Cuando elegimos imágenes del sistema; android-25; defecto; x86 estamos intentando ejecutar una máquina virtual dentro una máquina virtual. ¿Es un segundo nivel o virtualización anidada que estamos tratando de lograr y que, lamentablemente, aún no se apoya. El hardware de Intel solo admite una capa única de virtualización asistida por hardware, y agregar soporte para un anidamiento eficiente (es decir, no dolorosamente lento) requiere mucha ingeniería de software inteligente en los hipervisores.

Toda la teoría expresada actualmente sobre qué funcionará y qué no, centrémonos en crear un dispositivo de prueba virtual. ¡Sigue los pasos para hacerlo!

$ sdkmanager "system-images;android-25;google_apis;armeabi-v7a"
$ echo "no" | avdmanager create avd --name "testDevice" -k "system-images;android-25;google_apis;armeabi-v7a"

Entonces, acabas de crear un AVD, ¿cómo verificarlo? puedes usar avdmanager para controlar sus dispositivos Android virtuales.

$ avdmanager list avd

¡Ahora ejecutemos este dispositivo virtual!

$ emulator -ports 5554,5555 -avd testDevice -writable-system -no-window -no-audio -gpu swiftshader_indirect -show-kernel &

-ports 5554,5555 Defina los puertos de conexión en los que el puente de depuración de Android se conectará a este emulador (en este caso, 5554) y deben ser consecutivos.

-writable-system le daría acceso para editar cualquier archivo o enviar cualquier archivo como desee en la configuración de la raíz.

-no-window simplemente ejecutará el emulador sin cabeza (sin esta bandera, no funcionará porque no tenemos ninguna configuración de gráficos basada en OpenGL en una CLI)

-no-audio eliminaría el soporte de audio (algo que le sugiero que haga)

-gpu swiftshader_indirect para evitar un ciclo de arranque.

-show-kernel algo para mantener la cordura y comprobar el progreso del kernel en el arranque, porque tardará una eternidad (60–90 minutos) en arrancar correctamente.

Estos son los testimonios de por qué debería no elija algo tan lento como sería contraproducente, puede probar en sus dispositivos locales en lugar de en un dispositivo que tardará 1 hora en funcionar correctamente y aún así le dará un promedio de 2.5 minutos para instalar un APK normal.

Si es un desarrollador en solitario y puede pagar la suscripción de Genmony PaaS ($ 0.5 + costos de instancia de Amazon), ese es su camino a seguir. Por ejemplo, estoy usando m4.xlarge con Genmony PaaS encima, te costará $ 0.7 / hora y será un trato decente si se lo puede permitir.

Genmony sigue siendo un emulador de referencia para muchas organizaciones y el increíble soporte y velocidad que brindan sus emuladores son lo suficientemente buenos para el propósito que queremos resolver, si y solo si, su bolsillo le permite tanta libertad.

Sin embargo, $ 0.7 / h por emulador es un poco demasiado caro, al menos si desea realizar pruebas a gran escala.

En esta publicación, hemos explorado la configuración básica de un entorno de emulador y cómo configurar un AVD simple. Qué funciona en una instancia t2 general y cuáles son las alternativas.

En el siguiente, exploraremos cómo configurar múltiples emuladores en una sola instancia y exploraremos el puente de depuración de Android en profundidad personalizando nuestro dispositivo y ejecutando aplicaciones simples con emuladores Intel (que son al menos 10 veces más rápidos que estos).