Beyond the News
Sign in
Artificial IntelligenceWeb DevelopmentCloud & InfrastructureAI AgentsCloud PlatformsDeveloper Tools Active dossier

Google Cloud opens an agent-ready device farm for mobile testing

Developer Device Platform puts physical devices and high-concurrency emulators behind Google Cloud APIs, CLI workflows and an agent skill so mobile teams can test, debug and optimize apps without maintaining their own device lab.

Reviewed and published by Lars Jansen Updated 5 min read
First published

Key details

  1. Public preview began August 12, 2026.
  2. Supports virtual emulators and real physical devices.
  3. Device Run API is currently v1alpha; Device Streaming provides interactive remote-device access.
  4. The agent skill can orchestrate device sessions from supported coding-agent workflows.
  5. Billing is pay-per-active-minute with different structures for virtual and physical devices.
  6. Google’s device catalog exposes current fleet availability, including low/high availability states that can affect queueing.

What builders should take away

  1. Mobile teams with flaky or hardware-specific bugs can move more compatibility checks into reproducible cloud workflows instead of relying on a few local phones.
  2. If you already use coding agents, test the agent skill on bounded QA tasks first—such as reproducing a visual defect—before allowing automated code changes after device runs.
  3. Budget for both test breadth and concurrency: pay-per-minute pricing makes aggressive sharding faster but can increase spend, while scarce physical-device capacity can still create queues.
  4. Treat the preview APIs and IAM setup as unstable infrastructure. Wrap DDP integrations so v1alpha changes or preview access constraints do not become hard dependencies in release pipelines.

What changed

Google Cloud opened Developer Device Platform to public preview on August 12, 2026. The service combines a device catalog, automated Device Run sessions, physical-device streaming, parallelized test execution and an agent skill intended to let coding agents operate real or virtual mobile devices during development.

Why it matters

Mobile compatibility testing is usually split between local simulators, managed test-lab services and expensive physical-device fleets. DDP turns the device layer into an API-addressable cloud resource that can sit directly inside CI and agentic coding loops, reducing the gap between generated code and evidence from the hardware on which it must run.

A device farm exposed as developer infrastructure

DDP exposes device discovery and test sessions through Google Cloud APIs and the gcloud CLI. Teams can run Android instrumentation tests, shard work across many devices, retrieve results from Cloud Storage and use Device Streaming for interactive access to remote physical hardware. Google positions the service as an evolution of Firebase Test Lab for broader Cloud development workflows.

The agent layer is the distinctive part

Google’s DDP agent skill is designed to let compatible coding agents reserve devices, execute multi-step user journeys, inspect visual artifacts, analyze on-device performance and then modify application code. That does not make the loop self-validating: test quality, permissions, device coverage and review of agent-authored fixes still determine whether automation is trustworthy.

Preview economics and operational limits

During public preview, Google charges by active device minute with separate virtual and physical rates, although the public product page currently directs customers to sales rather than publishing one universal numeric rate card. The APIs are v1alpha/pre-GA, access requires a billed Google Cloud project and relevant IAM roles, and device availability can vary enough that some requests may queue.

What to watch next

  • Numeric public pricing and any free quotas once DDP moves beyond preview.
  • Expansion of device, OS and geography coverage, especially iOS and specialized hardware profiles.
  • Stability guarantees and API changes when Device Run and Device Streaming leave v1alpha/pre-GA status.
  • Whether agent-driven device testing produces measurable reductions in flaky-test triage or simply shifts debugging complexity into agent orchestration.

Still unclear

  • Google has not published a single globally applicable numeric public rate card on the product page; pricing is described structurally and users may need sales/account-specific details.
  • The agent-driven remediation claims are vendor-described preview capabilities; independent evidence on reliability and real-world savings is still limited.
  • Physical-device availability is dynamic and may constrain high-concurrency workloads despite the managed service model.

Sources

Direct reading behind this dossier.

5 sources
Developer Device Platform documentation
Google Cloud Documentation official documentation

Documents preview status and product surfaces including Device Catalog, Device Run, logs, agent skill and pricing resources.

Device Run API
Google Cloud Documentation official API reference

Confirms the v1alpha API surface for devices, sessions and operations.

Continue reading
Artificial Intelligence

Railway Cloud Agents turn coding agents into persistent deployment-adjacent VMs

Railway Cloud Agents are managed, persistent development machines rather than a new model or harness. They reuse developers’ existing agent credentials, sleep when disconnected by default, retain disk state, and live inside Railway project environments—blurring the boundary between remote coding workspace and deployment platform.

Artificial Intelligence

GitLab 19.3 turns plain-English process knowledge into runnable agentic flows

Custom Flows became generally available in GitLab 19.2; 19.3 adds the missing authoring layer. Flow Creator reads current Flow Registry docs, applies known failure rules and generates a runnable flow from plain English. Builders still need to review, register and govern the automation rather than treating generated YAML as trusted infrastructure.

Artificial Intelligence

Cloud Run sandboxes now work inside jobs and worker pools

Cloud Run sandboxes now cover all resource types. The August 5 expansion matters for builders whose agents or automation run in batch jobs or continuously pulling workers rather than HTTP services, while the feature remains pre-GA and shares CPU and memory with the host container.