What is the architecture of the cloud devices?

Genymotion’s cloud platform (Genymotion SaaS) is built on a Platform‑as‑a‑Service (PaaS) model that lets you spin up Android virtual devices in the public cloud. Below is a high‑level view of the main components and how they work together:

| Layer | Description | Key Features | |-------|-------------|--------------| | Cloud Infrastructure | Runs on major public clouds (AWS, GCP, Azure, Alibaba Cloud). Each virtual device is an isolated VM/container that shares the underlying physical host. | • Elastic compute (vCPU, RAM) <br>• Region‑aware data locality <br>• Pay‑as‑you‑go or subscription billing | | Genymotion Device Image (PaaS) | A pre‑packaged Android image that includes the Genymotion‑specific kernel, drivers, and runtime. It is what actually runs the virtual device. | • ARM / x86 / x86_64 images <br>• Hot‑plug features (camera, GPS, network) <br>• Dynamic rooting <br>• SDK for API integration | | API & CLI Layer | HTTP REST API and the gmsaas CLI provide programmatic control over instances – create, start, stop, get logs, attach ADB, etc. | • Automation via CI/CD <br>• Scriptable lifecycle management | | Front‑End Dashboard | Web UI in the Genymotion SaaS portal. Lets you browse available Android versions, select device configurations, and monitor instance status. | • Architecture filter (x86, x86_64, arm64) <br>• Instance UUIDs for ADB/CLI use <br>• Instance display in external browser | | Network & Security | Virtual devices are connected through a secure, private network segment of the chosen cloud provider. They can be exposed to the Internet only if you explicitly open ports (e.g., for a remote debugging session). | • Isolated VPC/ENI <br>• TLS for API traffic <br>• IAM‑based access controls |

Typical Workflow

1. Provision – In the SaaS portal, choose a cloud provider, region, instance type, and Android image (e.g., Android 16 on ARM64).

2. Launch – The platform provisions a VM/container with the Genymotion Device Image, attaches the requested resources, and starts the virtual device.

3. Interact – Use the web UI, ADB over the cloud, or the CLI/API to run tests, capture logs, or take screenshots.

4. Scale – Spin up multiple instances in parallel; each instance is fully isolated, allowing parallel test execution.

Key Architectural Points

• Hardware‑agnostic virtualization – The same Genymotion Device Image works on any provider; you simply select the desired CPU architecture.
• Hot‑plug capability – Features such as GPS, camera, network conditions, and battery state can be toggled on‑the‑fly via the API or UI.
• Security isolation – Each virtual device runs in its own VM/container, ensuring that tests or apps run in a sandboxed environment.
• Extensibility – The HTTP API and gmsaas CLI make it straightforward to embed device management into CI/CD pipelines or custom tooling.

For deeper technical details, you can refer to the Genymotion Device Image documentation on our site (e.g., the page that lists ARM64 images and the API reference).

If you’re interested in setting up a specific instance or need help choosing the right architecture (x86 vs ARM64) for your workload, let me know! 😊