Emulador de Android en la nube frente a teléfono en la nube

Si buscas un emulador de Android en la nube, encuentras dos productos distintos con el mismo nombre. Uno es el Android Emulator, el mismo que viene con Android Studio, corriendo en un servidor que alquilas o que opera otro. El otro es un teléfono en la nube: Android que corre en un centro de datos, configurado como un modelo de teléfono concreto y guardado para ti como un dispositivo.

Para echar un vistazo rápido a una app, cualquiera de los dos sirve. Para pruebas, automatización y trabajo de larga duración se comportan distinto, y elegir mal cuesta tiempo. Este artículo explica qué corre por debajo, qué ve tu app y cuándo conviene cada uno.

Tres formas de ejecutar Android en un servidor

El Android Emulator. Una máquina virtual basada en QEMU con hardware virtual que Google llama goldfish y, en las versiones actuales, ranchu. Arranca las imágenes del sistema que descargas en el SDK Manager. Solo es rápido con virtualización por hardware, que en un servidor Linux significa KVM, así que ejecutarlo en una VM de la nube requiere virtualización anidada o una instancia bare metal. Sin aceleración recurre a la emulación por software y se vuelve demasiado lento para el uso interactivo.

Cuttlefish. El dispositivo virtual de Google pensado para servidores y no para escritorios. Funciona sin interfaz, sirve su pantalla al navegador por WebRTC y se usa mucho en las pruebas de la plataforma Android. Es la mejor base si vas a montar tu propia flota de emuladores, y da por hecho que te manejas bien con hosts Linux y compilaciones de AOSP.

Android en contenedores. El espacio de usuario de Android corre en un contenedor sobre el kernel Linux del host, que necesita soporte de binder. Proyectos de código abierto como Anbox, Waydroid y redroid funcionan así, igual que muchos servicios de teléfonos en la nube, a menudo en servidores ARM donde las apps arm64 corren sin traducción. No hay una máquina virtual completa por teléfono, y por eso este enfoque escala a muchos teléfonos por servidor.

Qué ve tu app

Ejecuta tres comandos en un emulador y la respuesta es evidente:

adb shell getprop ro.product.model
adb shell getprop ro.hardware
adb shell wm size

Una imagen del sistema de Google responde con un modelo como sdk_gphone64_x86_64 o sdk_gphone64_arm64, hardware ranchu y el tamaño de pantalla que le haya dado la definición del AVD. Eso basta para probar tu propia lógica. Oculta todo lo que depende de la clase de dispositivo: errores de diseño que solo aparecen con el tamaño y la densidad de una pantalla real, comprobaciones de funciones con hasSystemFeature y código multimedia que elige un códec según lo que ofrece el chipset.

Un teléfono en la nube creado a partir de un modelo real reporta ese modelo: su nombre, la resolución y densidad de su pantalla, la versión de Android y la descripción del hardware. Tus diseños se encuentran con las pantallas que tienen tus usuarios, y un reporte de bug de un teléfono concreto se puede reproducir en el mismo modelo.

Dos salvedades para ser honestos. Primero, pregunta qué significa “modelo real” en cada servicio: la pantalla y la descripción del hardware del modelo, o el firmware propio del fabricante con su capa. Los bugs que viven en el optimizador de batería o en el launcher de un fabricante necesitan ese firmware, lo que en la práctica significa el teléfono físico. Segundo, en cualquier Android virtualizado los gráficos se traducen o se renderizan por software, así que ni un emulador ni un teléfono en la nube te dicen qué tan rápido dibuja tu app en hardware real.

La arquitectura también importa. En una imagen de emulador x86_64, las bibliotecas nativas arm64 corren a través de una capa de traducción que Google incluye en las imágenes desde Android 11. Funciona con la mayoría de las apps y rompe algunas, sobre todo juegos y apps con mucho código nativo. En hosts ARM, las imágenes arm64 ejecutan ese código de forma nativa.

Lado a lado

Si también estás considerando un VPS Android, teléfono en la nube vs emulador vs VPS Android compara los tres con ocho criterios.

Cuándo conviene el emulador

El emulador gana allí donde la velocidad de iteración y el control de las condiciones importan más que la clase de dispositivo.

• El ciclo de editar y ejecutar. El depurador, el inspector de diseño, las vistas previas de Compose y los despliegues instantáneos dan por hecho un emulador local o un teléfono por cable.
• Pruebas de instrumentación en CI. Gradle Managed Devices define los AVD en tu archivo de build y ejecuta las pruebas con una sola tarea, por ejemplo ./gradlew pixel6api34DebugAndroidTest. En un host de CI simple, un arranque sin interfaz se ve así:

emulator -avd ci-api34 -no-window -no-audio -no-boot-anim -gpu swiftshader_indirect
adb wait-for-device
./gradlew connectedDebugAndroidTest

• Condiciones simuladas. La consola del emulador fija la ubicación, la batería y la calidad de la red a pedido, algo que ningún teléfono real ni en la nube hace con la misma facilidad:

adb emu geo fix 13.405 52.52
adb emu power capacity 5
adb emu network speed edge

• Todos los niveles de API, incluidas las versiones preliminares. Google publica imágenes del sistema de las nuevas versiones antes de que lleguen a los teléfonos.

Cuándo conviene un teléfono en la nube

Un teléfono en la nube gana cuando el propio dispositivo forma parte de la pregunta, o cuando el teléfono tiene que durar más que una sesión de pruebas.

• Modelos reales. Reproduce un reporte de un teléfono concreto o revisa el diseño en las pantallas que de verdad tienen tus usuarios. La lista de modelos muestra lo disponible.
• Teléfonos que persisten. Mantén la sesión iniciada con cuentas de prueba, conserva los datos durante días y observa el comportamiento a lo largo de horas, algo que no puede hacer un emulador de CI que se descarta tras cada job.
• Nada que instalar. Un tester, un diseñador o un ingeniero de soporte abre el teléfono en el navegador. Los desarrolladores que quieren la experiencia del cable usan ADB.
• Agentes de IA. Un agente necesita un teléfono que pueda observar y manejar durante todo lo que dure la tarea; la página de agentes cubre ese uso.
• Países. Las apps se comportan distinto según la región, y un teléfono puede conectarse desde el país que necesitas.

En Clousd, por ejemplo, un teléfono se crea en cerca de un minuto con Android 12 a 17, se conecta desde el país que elijas con la zona horaria y el idioma correspondientes y se puede restablecer a un estado limpio entre ejecuciones.

Cuándo solo sirve un teléfono físico

Reserva el hardware real para la calidad de la cámara, la precisión de los sensores, el rendimiento gráfico y de la batería, el comportamiento térmico, NFC y Bluetooth, y todo lo que dependa del firmware propio de un fabricante. La attestation respaldada por hardware también entra aquí: no la esperes de ningún Android virtualizado.

Opciones gratis

Las búsquedas de “emulador de Android gratis en la nube” suelen terminar en uno de tres lugares.

1. Tu propia máquina. El Android Emulator es gratis y rápido en cualquier laptop reciente. Para muchos desarrolladores esa es la respuesta correcta, y no hace falta ninguna nube.
2. Runners de CI. Muchos servicios de CI ya exponen KVM en sus runners Linux, así que el emulador corre acelerado dentro de un nivel gratuito, sobre todo para repositorios públicos. Revisa la documentación de tu proveedor; en algunos hay que cambiar antes los permisos de /dev/kvm.
3. Pruebas de teléfonos alojados. Para ver rápido una app en un modelo real sin instalar nada, una prueba gratis de teléfono en la nube te da 30 minutos sin tarjeta.

Una advertencia. Los sitios que ofrecen un emulador online gratis y te piden subir un APK sin cuenta le están entregando tu build a un desconocido. No subas builds de release, y nunca subas una build con claves de producción dentro. Si el objetivo es solo abrir una app en el navegador, un emulador de Android online de un proveedor que puedas identificar es el camino más seguro, y emulador de Android en el navegador compara las opciones.