Usar una máquina virtual en un móvil Android ya no es algo reservado a frikis de sistemas o desarrolladores muy avanzados. Entre apps como VMOS, soluciones basadas en QEMU o Limbo y el propio emulador oficial de Google, hoy es perfectamente posible tener otro sistema operativo corriendo dentro de tu smartphone, con mayor o menor comodidad según lo que quieras hacer.
Ahora bien, no todas las opciones sirven para lo mismo, ni todos los móviles aguantan igual la carga. A lo largo de esta guía vas a ver qué tipos de máquinas virtuales se pueden usar en Android, qué tal funcionan en la práctica, para qué resultan útiles (y para qué no), qué requisitos necesitas y también el camino inverso: instalar Android como VM en VMware o VirtualBox para desarrollo y pruebas.
Qué es exactamente una máquina virtual en Android
Cuando hablamos de una máquina virtual (VM) en Android nos referimos a un sistema operativo completo que se ejecuta dentro de una app, aislado del Android principal. Es parecido a lo que harías en un PC con VMware o VirtualBox: el móvil actúa como host y dentro corres otro sistema invitado (otro Android, una distro Linux, Windows ARM, etc.).
Este enfoque se diferencia de cosas como crear un segundo usuario o un espacio privado en el teléfono. Esos perfiles separados comparten el mismo kernel y parte de la pila del sistema, mientras que una máquina virtual emula su propio entorno, con su almacenamiento virtual, su arranque, su gestión de memoria y, hasta cierto punto, su propia configuración de hardware simulado.
Gracias a ese encapsulamiento, una VM sirve tanto como zona de pruebas o sandbox para apps sospechosas, como para desarrollo, uso de dos cuentas de una misma aplicación o ejecución de sistemas que el móvil, de serie, no podría cargar en modo nativo.
VMOS: Android dentro de Android con aislamiento total
Una de las soluciones más populares para correr una máquina virtual de Android sobre Android es VMOS. Se trata de una app que, una vez instalada, descarga una ROM de Android (normalmente basada en Lollipop 5.1 o versiones más modernas según la edición) y la ejecuta como si fuera un teléfono completamente independiente dentro del tuyo.
VMOS ofrece un entorno aislado en el que cualquier aplicación que instales no afecta al sistema real. Esto quiere decir que si metes malware, pruebas apps de procedencia dudosa o juegas con configuraciones locas, los daños se quedan dentro de la máquina virtual. Sus creadores insisten en que incluso un virus no debería poder escapar al teléfono físico, de modo que sirve como capa extra de seguridad y protección para tus datos personales.
El enfoque está muy orientado a usuarios avanzados y desarrolladores que necesitan un entorno independiente para hacer pruebas. También encaja muy bien para quien busca un espacio privado donde tener fotos, ficheros o cuentas que no quiere mezclar con el perfil principal, ya que VMOS permite cifrar y aislar ficheros dentro de la VM.
Otro punto interesante es que VMOS soporta múltiples máquinas virtuales en paralelo. Puedes tener, por ejemplo, un Android “limpio” para trabajo, otro para pruebas con root y otro para juegos en segundo plano, todos ejecutándose al mismo tiempo en el móvil si el hardware aguanta.
Funciones clave de VMOS: lo que puedes hacer en la práctica
Detrás del concepto de “Android dentro de Android” hay una serie de funciones que hacen que VMOS sea especialmente versátil. A grandes rasgos, esta aplicación permite:
1. Seguridad y aislamiento gracias a un sistema virtual totalmente separado del teléfono real. Es perfecto para desarrollo, pruebas de apps y análisis de archivos potencialmente maliciosos, reduciendo el riesgo de cargarte el sistema principal o de que un virus tenga acceso a tus datos reales.
2. Ejecución simultánea de varias VMs, con soporte para que varias instancias permanezcan en segundo plano. Esto abre la puerta a tener diferentes perfiles de uso (trabajo, ocio, pruebas) corriendo de manera paralela, algo que en un único Android físico es bastante limitado.
3. Manejo cómodo con un botón flotante que te permite minimizar, cambiar de modo ventana, alternar entre el sistema huésped y el host o activar el modo Picture-in-Picture. El cambio entre entornos es bastante ágil si el terminal tiene suficiente RAM y una CPU decente.
4. Ajuste de parámetros internos de la VM, como resolución, cantidad de memoria asignada o ciertas propiedades simuladas del dispositivo. Esto resulta útil tanto para probar cómo se comporta una app en diferentes configuraciones como para optimizar rendimiento en móviles más modestos.
5. Transferencia de archivos y aplicaciones entre el teléfono físico y la máquina virtual. Puedes pasar APKs, documentos, fotos o cualquier otro contenido del host al invitado y viceversa, lo que facilita mucho usar la VM como laboratorio de pruebas o caja fuerte de datos.
VMOS dispone de una web oficial (vmosapp.net) y soporte por correo electrónico, lo que ayuda a resolver dudas sobre compatibilidad de dispositivos, problemas de rendimiento o fallos específicos que puedan aparecer al ejecutar ciertas ROMs virtuales.
Usos prácticos de Android dentro de Android: root, doble cuenta y más
Más allá de lo llamativo que resulta ver dos escritorios de Android funcionando a la vez, el verdadero interés de VMOS está en los usos concretos que ofrece frente a un móvil sin virtualización:
Por un lado, permite usar dos cuentas de la misma aplicación sin necesidad de clonadores externos ni funciones especiales del fabricante. Apps como WhatsApp, Facebook, Instagram o juegos que solo aceptan una sesión a la vez pueden ejecutarse en el Android virtual y en el real, cada uno con sus propios datos.
También puedes mantener un espacio completamente separado para fotos, documentos y contactos. Es parecido a las carpetas seguras de Samsung o el espacio privado de Huawei, pero con la ventaja de que aquí se trata de un sistema operativo aparte, con sus propias apps y ajustes, no solo un contenedor parcial dentro del mismo Android.
Uno de los puntos más atractivos para usuarios avanzados es la posibilidad de activar root dentro de la máquina virtual sin tocar el teléfono principal. De fábrica, la ROM de VMOS no suele venir rooteada, pero las opciones de desarrollador incluyen un interruptor llamado “ROOT” que, tras reiniciar la VM, instala la clásica app de superusuario para gestionar permisos.
Ese root se limita al entorno virtual, de modo que no implica perder garantías ni desbloquear el bootloader del móvil. Es ideal para probar aplicaciones que requieren privilegios de superusuario, trastear con módulos, automatizaciones o tweaks de sistema sin miedo a dejar tu dispositivo físico en estado de ladrillo.
Por último, VMOS permite dejar juegos o tareas pesadas corriendo en segundo plano dentro de la VM mientras usas el Android principal para otras cosas. Eso sí, este uso exige bastante potencia, porque el terminal está básicamente moviendo dos sistemas a la vez, uno de ellos emulado.
Rendimiento, permisos y tiempos de arranque en VMOS
La otra cara de la moneda es que una máquina virtual de este tipo tiene un coste importante en recursos. En el caso de VMOS, la ROM que se descarga suele ocupar del orden de unos pocos cientos de megas (por ejemplo, un Android Lollipop 5.1 recortado ronda los 300 MB), lo cual no es dramático, pero sí se nota en móviles con poco almacenamiento.
El primer arranque de la VM puede tardar entre cinco y diez minutos, dependiendo de la potencia del procesador y de la velocidad de la memoria interna del dispositivo. Ese tiempo de espera solo es tan largo la primera vez; los siguientes inicios son mucho más rápidos, aunque nunca tan inmediatos como abrir una app normal.
En cuanto a rendimiento, hay que asumir una cierta caída de fluidez porque el móvil está gestionando dos sistemas operativos a la vez. En la mayoría de pruebas, la experiencia es lo bastante ágil como para usar la VM de forma razonable, pero en juegos pesados o apps que exigen mucha GPU se puede notar lag o bajadas de frames significativas.
Otro punto delicado son los permisos que la app solicita para funcionar. VMOS suele pedir acceso a información sensible, como el IMEI, la ubicación, el almacenamiento completo o incluso el estado del teléfono. Los desarrolladores argumentan que esto es necesario para que el sistema emulado resulte más “realista”, pero conviene ser consciente de qué se está concediendo antes de pulsar Aceptar.
Por eso, aunque VMOS sea una herramienta muy potente, es recomendable usarla en dispositivos relativamente modernos, con suficiente RAM y almacenamiento, y con usuarios que entiendan bien qué implica dar esos permisos extendidos a una aplicación de este tipo.
Android 13 y QEMU: Windows 11 ARM y Linux como máquinas virtuales en el móvil
Con la llegada de Android 13, Google introdujo mejoras internas en el sistema que facilitan mucho la virtualización de sistemas operativos completos aprovechando el hardware ARM de los móviles. Esto ha permitido a desarrolladores avanzados, usando QEMU y otras herramientas, ejecutar sistemas tan pesados como Windows 11 ARM en un teléfono Android moderno.
Un caso muy comentado fue el de un desarrollador que logró levantar Windows 11 ARM en un Google Pixel 6 usando la primera Developer Preview de Android 13. A pesar de que la GPU funcionaba sin aceleración gráfica nativa (es decir, sin soporte de hardware para la parte visual), el sistema resultó “realmente utilizable” según sus propias palabras.
En los vídeos de demostración se veía cómo Windows arrancaba, permitía iniciar sesión y ejecutar aplicaciones típicas, con un rendimiento sorprendentemente fluido dadas las limitaciones. Incluso se daba el capricho de correr Doom dentro de la VM, algo casi obligatorio en cualquier experimento de este tipo.
El mismo mecanismo de virtualización se puede aplicar a distribuciones Linux para arquitectura ARM. Según estas pruebas, muchas distros corren con un rendimiento “casi idéntico al nativo” al menos en modo consola, lo que abre posibilidades interesantes para desarrolladores, administradores de sistemas o curiosos que quieran un entorno Linux completo en el bolsillo.
Si se combina esta capacidad con un dock o adaptador que permita conectar el móvil a monitor externo, teclado y ratón, se pueden imaginar escenarios en los que tu smartphone actúa prácticamente como un PC de sobremesa, ejecutando Windows 11 ARM o Linux en grande mientras sigue siendo un teléfono cuando lo desconectas.
Otras formas de “virtualizar” apps en Android: espacios aislados y sandbox
Además de VMOS y de las VMs “puras” basadas en QEMU, en Android existen soluciones más ligeras que se aproximan al concepto de virtualización de forma parcial. Son aplicaciones o funcionalidades que permiten ejecutar software en un entorno aislado o clonado, sin llegar a ser un sistema operativo completo aparte.
Una opción sencilla es crear otro usuario o perfil de trabajo en el propio sistema. Android soporta varios perfiles en muchos dispositivos, aunque con distintas restricciones de fabricante. Esto te deja instalar apps solo en ese usuario, con sus propios datos, pero compartiendo kernel y gran parte del sistema con el perfil principal.
También hay apps tipo espacio aislado o sandbox que se comportan como contenedores para ejecutar APKs de forma “virtual”. Sirven para probar aplicaciones, evitar que una app tenga acceso directo al resto del sistema o tener múltiples sesiones de una misma herramienta, todo ello sin levantar una VM completa.
Estas alternativas consumen menos recursos que una máquina virtual completa y son adecuadas para quien solo necesita un poquito de aislamiento o duplicar algunas apps concretas sin llegar al despliegue de un sistema operativo invitado entero.
Android Emulator: la máquina virtual oficial para desarrollo (en PC)
Si tu objetivo principal es desarrollar y probar aplicaciones Android, la opción más poderosa y flexible sigue siendo el emulador oficial de Google, Android Emulator, que forma parte de Android Studio. Aquí, en lugar de correr la VM en el móvil, la ejecutas en tu ordenador, pero el concepto de máquina virtual es el mismo.
Android Emulator lanza lo que se denomina un dispositivo virtual Android o AVD (Android Virtual Device). Cada AVD contiene la pila completa de software Android (kernel, framework, apps de sistema) y se comporta como si fuera un dispositivo físico, con su propia resolución, cantidad de RAM, versión de Android y hasta sensorística simulada.
El primer paso para usar imágenes personalizadas en el emulador pasa por descargar el código fuente de Android y prepararte un entorno de compilación. Esto implica crear un directorio para el proyecto, inicializar el repositorio y sincronizar todas las ramas necesarias, algo que suele hacerse con los comandos repo init y repo sync dentro de un árbol AOSP.
Una vez tienes el código, puedes compilar una imagen de sistema para un AVD concreto. Por ejemplo, para un AVD x86 de 64 bits es habitual cargar los scripts de entorno, elegir un target como sdk_phone_x86_64 mediante lunch y luego ejecutar una compilación con make usando varios hilos. El proceso puede llevar bastante tiempo según la potencia del equipo.
Cuando finaliza la compilación, basta con arrancar el emulador con el comando correspondiente (emulator) para que la imagen personalizada se ejecute dentro de Android Emulator, permitiéndote probar tus apps en un entorno prácticamente idéntico a un dispositivo físico pero con herramientas extra para depurar.
Compartir imágenes de AVD personalizadas con otros usuarios
En entornos de empresa o equipos de desarrollo grandes es habitual querer que varias personas usen la misma imagen de sistema Android en sus emuladores, para asegurar que todos prueban y depuran sobre un entorno idéntico.
Para conseguirlo, AOSP permite generar paquetes especiales tipo sdk y sdk_repo. En versiones recientes (Android 13 y superiores), se usa una tarea llamada emu_img_zip que empaqueta la imagen de sistema del AVD en un archivo comprimido con un nombre del estilo sdk-repo-linux-system-images-eng..zip.
En versiones anteriores (Android 12 hacia atrás), se recurre al comando make sdk sdk_repo, que genera tanto el zip de imágenes como un archivo XML (repo-sys-img.xml) en la ruta de salida del SDK. Ese XML describe el repositorio de imágenes y se puede modificar para apuntar a la URL desde la que otros desarrolladores las descargarán.
El siguiente paso es alojar el archivo zip (y, si aplica, el XML) en algún servidor accesible y configurar en Android Studio un sitio de actualización personalizado. Así, el SDK Manager detecta la imagen del sistema personalizada y la muestra junto al resto de imágenes oficiales disponibles.
A partir de ahí, cada desarrollador puede crear un nuevo AVD seleccionando esa imagen, de modo que todos trabajen sobre el mismo entorno virtual sin tener que compilar AOSP por su cuenta, lo que ahorra mucho tiempo y dolores de cabeza.
Soporte de varias pantallas en el emulador
Android 10 introdujo mejoras importantes en el modo multipantalla y los escenarios de escritorio, algo muy relevante en un contexto donde empiezan a aparecer plegables, dispositivos con pantallas externas y modos tipo “PC” al conectar el móvil a un monitor.
Android Emulator incorpora la posibilidad de simular varias pantallas en un solo AVD, permitiendo que desarrolladores prueben cómo se comporta su aplicación cuando se arrastra a un segundo monitor virtual, se expande a un área extra o cambia de orientación y tamaño de forma dinámica.
Para habilitar este soporte en una build personalizada, es necesario incluir en los ficheros de producto ciertas bibliotecas y paquetes relacionados con el proveedor de multipantalla, como las librerías nativas libemulator_multidisplay_jni (en 32 y 64 bits) y el apk MultiDisplayProvider dentro de la partición /system/priv-app.
Además, hay que activar una marca de función específica en el archivo de configuración avanzada (advancedFeatures.ini), normalmente con una línea que pone algo como MultiDisplay = on. Con esto, el emulador entiende que la imagen soporta multipantalla y ofrece los controles correspondientes.
De esta manera, se puede probar cómo responde la app a ventanas redimensionables, cambios de pantalla activa, presentaciones en segundo monitor y otros escenarios que en un solo móvil físico serían mucho más complejos o caros de reproducir.
Instalar Android como máquina virtual en VMware y VirtualBox
Otra cara de la moneda, muy útil si programas o haces pruebas de forma intensiva, es instalar Android como sistema operativo invitado en una VM de escritorio usando VMware Workstation, VMware Player, ESXi o VirtualBox. Aquí el host es tu PC o servidor y Android actúa como huésped.
Este enfoque aporta ventajas claras: puedes crear instantáneas, clonar máquinas virtuales, hacer backups completos, migrar VMs entre hosts y, en general, tratar Android como cualquier otra VM de laboratorio o producción, con toda la flexibilidad que ofrecen los hipervisores de VMware o VirtualBox.
Para montar este entorno, lo habitual es descargar una imagen de Android-x86 o similar, preparada para arquitecturas x86-64 en lugar de ARM. Aunque la mayoría de móviles usan ARM o ARM64, hay builds específicas para correr en PCs con CPU de escritorio que se adaptan mejor al hardware típico de un servidor o portátil.
En un escenario con ESXi 6.5 gestionado por vCenter, el proceso pasa por subir la imagen ISO de Android al datastore del host, crear una nueva máquina virtual indicando Linux como familia de sistema invitado (por ejemplo, “Otro 3.x o Linux posterior de 64 bits”) y ajustar los recursos: 1 vCPU, 2 GB de RAM y un disco virtual de unos 8 GB o más suelen bastar para pruebas básicas.
Durante el asistente de creación de la VM se asocia la unidad de CD/DVD virtual al archivo ISO de instalación de Android, marcando la opción de conectar al encender para que la máquina arranque directamente desde el instalador cuando se encienda.
Proceso de instalación de Android en VMware paso a paso
Una vez creada la máquina virtual y arrancada desde la ISO de Android-x86, el instalador ofrece una opción tipo “Installation – Install Android-x86 to harddisk” que debes seleccionar para empezar el proceso de instalación en el disco virtual.
El siguiente paso es gestionar las particiones del disco virtual. Normalmente se utiliza una herramienta como cfdisk, desde la cual se crea una nueva partición primaria ocupando todo el espacio de los 8 GB, se marca como bootable (arrancable) y se escriben los cambios en el disco confirmando con un “sí” cuando lo pida.
Tras salir de la utilidad de particionado, el instalador ya detecta la partición recién creada (por ejemplo, sda1) y permite seleccionarla para formatear con sistema de archivos ext4. Conviene aceptar también la instalación del gestor de arranque GRUB y la posibilidad de montar el directorio /system en modo lectura-escritura para tener mayor flexibilidad a la hora de modificar el sistema.
Al finalizar, el asistente indica que Android-x86 se ha instalado correctamente y propone reiniciar la VM. Al hacerlo, se mostrará el menú de GRUB con distintas opciones de arranque para el sistema recién instalado.
En algunos casos, Android no termina de arrancar correctamente con la configuración por defecto y te deja en un prompt sencillo. La solución típica consiste en editar la entrada de arranque seleccionada (con la tecla e en GRUB) y sustituir el parámetro quiet por nomodeset xforcevesa en la línea del kernel, de forma que el comando incluya estos flags para forzar un modo de vídeo compatible.
Ajustar GRUB de forma permanente y primeros pasos en la VM Android
Después de cambiar los parámetros de arranque y arrancar Android con éxito, verás la interfaz gráfica del sistema y el asistente de configuración inicial: elección de idioma, conexión de red, cuenta de Google, fecha y hora, etc., igual que en un teléfono o tablet, aunque aquí el hardware es virtualizado.
Uno de los puntos curiosos es la detección de redes. Android está pensado para móviles sin puerto Ethernet, así que al ejecutar en una VM el sistema tiende a esperar redes Wi-Fi. En un entorno VMware, suele aparecer una red llamada algo como VirtWiFi, que representa la conexión del adaptador virtual Ethernet hacia la red real del host.
Si necesitas Wi-Fi real, existe la opción de conectar un adaptador USB inalámbrico directamente a la VM haciendo passthrough desde el hipervisor, de manera parecida a lo que se hace en entornos con Kali Linux u otras distros orientadas a auditoría.
Una vez configurado todo, Android arranca a su pantalla principal. En ese momento conviene hacer persistentes los cambios en GRUB para no tener que editar los parámetros a mano cada vez. Para ello, puedes cambiar a una consola de texto con una combinación de teclas (Alt+F1) y ejecutar comandos para montar el disco donde está la configuración del cargador de arranque.
El esquema típico pasa por crear un directorio de montaje (por ejemplo, /mnt/sda), montar la partición sda1 ahí y luego editar el archivo de configuración menu.lst de GRUB con un editor de texto como vi, sustituyendo definitivamente quiet por nomodeset xforcevesa en la primera entrada de arranque.
Tras guardar cambios y reiniciar, la VM de Android debe arrancar correctamente sin intervención manual. A partir de ahí puedes ajustar cosas como el tiempo de reposo de la pantalla en Ajustes > Pantalla > Reposo, activar la aceleración 3D en la configuración de la VM del hipervisor (si está disponible) o preparar instantáneas antes de instalar apps y hacer experimentos.
Virtualizar Linux en Android con Limbo y otras herramientas
Más allá de correr Android dentro de Android o Android dentro de un PC, también es posible levantar distribuciones Linux completas como máquinas virtuales en el propio móvil. Una de las aplicaciones más conocidas para esto es Limbo, un frontend para QEMU adaptado a Android.
El flujo básico con Limbo consiste en instalar la app, descargar una imagen ISO de la distribución Linux que quieras virtualizar (cuanto más ligera, mejor) y crear una nueva máquina seleccionando esa ISO como medio de arranque. Por ejemplo, una distro como Damn Small Linux (DSL), que apenas pesa 50 MB, encaja muy bien para estos experimentos.
Desde la interfaz de Limbo puedes definir parámetros como cantidad de RAM asignada, tipo de CPU emulada, tamaño del disco virtual y demás opciones de QEMU, adaptándolas a lo que soporte tu teléfono sin volverse loco. Un hardware modesto exigirá configuraciones muy contenidas.
El resultado es una terminal Linux completa corriendo como invitada dentro de Android, ideal para lanzar scripts, herramientas de administración, compilar pequeñas utilidades o practicar en un entorno similar a un PC, pero desde el propio smartphone.
Eso sí, hay que tener claro que la emulación de CPU y el entorno gráfico completo pueden ir justitos en muchos móviles, sobre todo si la distro no está muy optimizada o si se pretende ejecutar entornos de escritorio pesados. La clave es apostar por imágenes ligeras y asumir que el rendimiento será limitado en comparación con un PC real.
El ecosistema actual ofrece un abanico muy amplio de formas de usar máquinas virtuales relacionadas con Android: desde tener otro Android dentro de tu teléfono con VMOS y root aislado, a correr Windows 11 ARM o distros Linux en móviles potentes con Android 13, pasando por el uso profesional del emulador oficial en PC o la instalación de Android-x86 en VMware y VirtualBox. Cada opción tiene sus pros, contras y requisitos, pero todas comparten la misma idea de fondo: aprovechar la virtualización para experimentar, desarrollar y separar entornos sin poner en riesgo tu sistema principal.
