PluginBench
Skill
Pass
Audit score 90

developer-device-platform-basics

google/skills

Manage remote Android devices on Google's Developer Device Platform for testing and development.

What is developer-device-platform-basics?

Developer Device Platform (DDP) is Google's managed infrastructure for accessing physical and virtual Android devices remotely. Use this skill to reserve devices, establish ADB connections, check session status, and manage device leases. Currently in Preview and requires Google Cloud authentication.

  • Reserve remote Android devices with specified model and OS version
  • Establish ADB connection tunnels to interact with reserved devices
  • Check device availability and session status in real-time
  • Extend or cancel active device sessions with billing awareness
  • List available device models and retrieve detailed device specifications
  • View device screen and manually control reserved devices

How to install developer-device-platform-basics

npx skills add https://github.com/google/skills --skill developer-device-platform-basics
Prerequisites
  • Google Cloud project with billing enabled
  • gcloud CLI installed and authenticated
  • Application Default Credentials (ADC) configured
  • APIs enabled: devicerun.googleapis.com, devicestreaming.googleapis.com, testing.googleapis.com
  • gcloud beta component installed
  • Python environment for ADB forwarder (optional, for advanced usage)
Claude Code
Cursor
Windsurf
Cline

How to use developer-device-platform-basics

  1. 1.Authenticate with Google Cloud using gcloud auth login and gcloud auth application-default login
  2. 2.Enable required APIs with gcloud services enable command
  3. 3.Set PROJECT_ID and ACCESS_TOKEN environment variables
  4. 4.List available devices using gcloud beta device-run devices list
  5. 5.Describe a specific device model to check deviceStreaming support
  6. 6.Request device reservation with explicit billing confirmation
  7. 7.Poll session status until state becomes ACTIVE
  8. 8.Start ADB forwarder to establish connection tunnel

Use cases

Good for
  • Testing Android apps on real devices without local hardware
  • Running automated tests across multiple Android OS versions and device models
  • Debugging app behavior on specific Pixel or other Android devices
  • Validating app compatibility before release across device variants
  • Temporary device access for CI/CD pipelines or remote development teams
Who it's for
  • Android app developers
  • QA engineers testing on physical devices
  • Mobile app CI/CD pipeline operators
  • Teams needing remote device access without purchasing hardware

developer-device-platform-basics FAQ

What devices are available on DDP?

DDP provides access to various Android physical and virtual devices. Use 'gcloud beta device-run devices list' to see available models and their OS versions. Each device has a CATALOG_ID (e.g., shiba-34 for Pixel 8 on SDK 34) and must support 'deviceStreaming' to be reservable.

Does reserving a device cost money?

Yes, reserving a device incurs billing charges on your active Google Cloud project. The skill requires explicit user confirmation before any reservation, and warns about costs when extending sessions.

How long can I keep a device reserved?

Each device session has an expiration time set at reservation. You can extend the expiration by requesting a session update, which also requires explicit billing confirmation.

Can I use this for iOS devices?

No, DDP and this skill are for Android devices only. For iOS testing, use alternative platforms or local devices.

What if my device session doesn't become active?

If the session doesn't reach ACTIVE state within 2 minutes, the skill will report failure and automatically cancel the session to avoid unnecessary charges.

Full instructions (SKILL.md)

Source of truth, from google/skills.


name: developer-device-platform-basics description: >- Provides guidance and instructions on managing remote devices on Developer Device Platform (DDP). Use when reserving remote Android devices, establishing connection tunnels, checking session status, or extending/cancelling leases. Don't use for iOS or local device/hardware inquiries. metadata: version: "0.5.0" category: CloudInfrastructureAndServices

Developer Device Platform

Developer Device Platform (DDP) is a Google fully managed, global infrastructure providing access to a wide variety of physical and virtual devices.

[!WARNING] Developer Device Platform (DDP) is currently at Preview.

[!IMPORTANT] For all devicerun and devicestreaming API operations (reserving, status checking, stopping/canceling, updating, or listing a session), always verify and use the exact instructions and curl commands provided in the linked reference .md files.

Authentication & Setup

CRITICAL: Before running any requests, you MUST ensure the environment is correctly initialized by following these steps:

Before running any requests, verify if the gcloud executable is present. If missing, refer to the official Google Cloud CLI Installation Guide to install it on the current platform (Linux, macOS, Windows, etc.).

  1. Google Cloud Authentication: Authenticate with your Google Cloud credentials and configure active Application Default Credentials (ADC) for the Developer Device Platform:

    gcloud auth login --no-browser
    gcloud auth application-default login --no-browser
    
  2. Enable APIs (if not already enabled):

    gcloud services enable devicerun.googleapis.com devicestreaming.googleapis.com testing.googleapis.com --quiet
    

[!NOTE] Cloud Testing API is needed for Device Streaming API during Preview.

  1. Enable gcloud beta component:

    gcloud components install beta
    
  2. Setup Environment Variables: Set up the required project variable and access token:

    export PROJECT_ID=$(gcloud config get project)
    export ACCESS_TOKEN=$(gcloud auth application-default print-access-token 2>/dev/null)
    
  3. Python Environment: For instructions on setting up the python virtual environment, see start_adb_forwarder.md.

Listing Available Devices

To find the correct modelCode and osVersion to use when starting a session, you can list the available devices:

  1. List Models: Run the following command to list available Android device models:

    gcloud beta device-run devices list
    

    Use the ID column to find the value for the CATALOG_ID parameter to describe a specific device (e.g., shiba-36).

  2. Describe a Model: Run the API request to get more details about a specific model (e.g., supportedProducts, resolution). Always rely on the exact curl command and instructions provided in describe_device.md.

Starting a Device Session

When the user asks to reserve or connect to a device:

  1. Check Device Availability:

    Look up CATALOG_ID of the device using Listing Available Devices instructions. Check the device availability of the CATALOG_ID by using the exact curl command and instructions provided in describe_device.md. The device MUST contain "deviceStreaming" in "supportedProducts" to be reserved.

    If no specific device is specified, use CATALOG_ID=shiba-34 (Pixel 8 on SDK 34).

    If OS_VERSION was not specified by the user, ask the user to select a version from the device list (preferring the version with the highest availability {"available": "AVAILABILITY_HIGH" }).

    If OS_VERSION is unavailable for deviceStreaming, do not reserve one. Prompt the user for an alternative OS_VERSION.

  2. Extract Parameters:

    • model_id: modelCode from device details. Required.
    • version_id: osVersion from device details. Required.
  3. Reserve Device:

    Rule: Explicit User Confirmation Required. Reserving a device incurs billing charges and creates cloud resources. The agent MUST ALWAYS warn the user explicitly about the billing costs that will be incurred on the active Google Cloud project (e.g., ${PROJECT_ID}). You MUST STOP and ask for explicit approval before proceeding with any session creation commands.

    Then, run the API request with model_id and version_id to reserve the device. Always rely on the exact curl command and instructions provided in reserve_device.md.

    Parse the response to get session_name (the session name, e.g., projects/${PROJECT_ID}/deviceSessions/session-xxxxxx). If reservation fails, report the error.

  4. Wait for Session to be Active:

    While waiting for the device session to be provisioned, poll the session status until "state" is "ACTIVE". See session_status.md for the exact curl command.

    Repeat this check every 5 seconds to prevent hitting API rate limit. If it does not become active within 2 minutes (typically under 1 minute), report failure and cancel the session. Once active, extract expireTime from the session JSON response and convert it to the user's local time in a human-readable format (e.g., "June 9, 2026 at 2:44 PM PDT").

  5. Start Connection Forwarder: Start the ADB forwarder script to forward connection to the remote device. Always rely on the exact command and instructions provided in start_adb_forwarder.md. Ensure you record the Command ID.

  6. Wait for Online and Parse Port: Wait for the forwarder to be online and extract the listening port. Always rely on the exact logic and instructions provided in start_adb_forwarder.md.

  7. Provide Instructions to User:

    Once online, run adb -s localhost:{port} shell getprop ro.product.model to retrieve the device model name. Then, print a message directly to the user in the chat (do NOT create any artifact file) with the following instructions:

    Device is ready!

    Device Model: {device_model}
    OS Version: {version_id}
    ADB Address: localhost:{port}
    Session Expiration: {expire_time_human_readable_local}
    
  8. Save Session State: Save the {session_name} and {command_id} in your conversation memory/context so you can clean it up later.

Viewing the Device Screen of a Reserved Device

The coding agent can directly interact with the remote device using adb. Users may use a utility to display the screen and manually control the reserved device in DDP. See view_device.md for an example utility.

Stopping a Device Session

When the user asks to stop, cleanup, or release the device:

  1. Identify Session: Retrieve the active {session_name} and {command_id} from your context. If you don't have them, list active sessions first (see helper command below) to find the session name.

  2. Cancel Session via API: Cancel the session via the API. Always rely on the exact curl command and instructions provided in cancel_session.md.

  3. Terminate Connection Forwarder: Terminate the background process matching {command_id} using your environment's process management capability.

  4. Confirm: Confirm to the user that the session has been cancelled and resources released.

Change Device Session Expiration Time

When the user asks to change the expiration time of an active device session:

Rule: Explicit User Confirmation Required. Extending a device session incurs additional billing charges and creates cloud resources. The agent MUST ALWAYS warn the user explicitly about the extra billing costs that will be incurred on the active Google Cloud project (e.g., ${PROJECT_ID}). You MUST STOP and ask for explicit approval before proceeding with any session extension commands.

  1. Extract Parameters:

    • session_name: The active session name.
    • ttl: The new remaining duration (e.g., 3600s). Derive the ttl if it's provided in another format.
  2. Change Session via API: Change the session via the API using updateMask=ttl. Always rely on the exact curl commands and instructions provided in update_session_expiration.md.

  3. Restart Connection Forwarder:

    • Run adb disconnect localhost:{port} to ensure the old forwarder connection is closed.
    • Stop the old connection forwarder corresponding to {command_id}.
    • Start a new connection forwarder by following Step 5 in "Starting a Device Session" (calculating the new --ttl duration in seconds and storing the newly returned Command ID).
  4. Confirm: Confirm to the user that the session duration has been updated and the connection forwarder has been restarted with the new TTL.

Helper: List Active Sessions

To find active sessions if you lost context, always rely on the curl command and instructions provided in list_sessions.md.

References