what is the architecture of the cloud devices?
**What is the architecture of Genymotion 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)
• Region‑aware data locality
• 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
• Hot‑plug features (camera, GPS, network)
• Dynamic rooting
• 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
• 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)
• Instance UUIDs for ADB/CLI use
• 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
• TLS for API traffic
• 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! 😊