canonical: https://jentic.com/apis/googleapis.com/androidmanagement

# Google Android Management API

The Android Management API provides remote enterprise management of Android devices and apps. Administrators define policies, enroll devices via enrollment tokens, push apps from managed Google Play, and issue commands such as lock, reboot, and wipe. The API also exposes web apps, web tokens for managed Play iframes, and operation handles for long-running device commands.

## For AI agents

Define policies, enroll devices, push apps, and issue remote commands on Android Enterprise devices. Useful for agents building or operating an EMM on top of Google's hosted Android management stack.

## Scope

Does not handle Android app build uploads, in-app purchases, or consumer device backup - use for enterprise device policy, enrollment, and command management only.

## Capabilities

- Define and update Android device policies
- Generate enrollment tokens to add devices to an enterprise
- Issue remote commands to lock, reboot, or wipe a device
- Push managed apps and configurations to enrolled devices
- Generate web tokens for embedding the managed Play iframe
- Track long-running device operations through to completion

## Use cases

### Hosted EMM build for SMBs

An ISV builds an Android EMM product on top of Android Management instead of running a self-hosted EMM partner. Policies, enrollment, app distribution, and commands all run through Google's hosted backend, so the ISV ships features faster and offloads infrastructure to Google.

Example prompt: Create policy 'kiosk-v1' with kioskCustomLauncherEnabled true under enterprise enterprises/E-1234, then create an enrollment token referencing that policy.

### Lost or stolen device response

When an end user reports a missing device, the help desk issues a lock command and, if not recovered, a remote wipe. Both operations return a long-running operation handle the agent polls until the command lands on the device, providing audit-grade confirmation.

Example prompt: Issue a LOCK command on enterprises/E-1234/devices/D-99 and poll the returned operation under /v1/{+name} until it reports done.

### Bulk policy rollout for new device cohort

When a department expands, IT mints a new enrollment token, updates the assigned policy with the relevant Wi-Fi profile and app set, and distributes the QR code to staff. Devices enroll on first boot and immediately apply the policy, replacing manual provisioning.

Example prompt: Patch policy enterprises/E-1234/policies/sales with the corp Wi-Fi profile, then create an enrollment token bound to that policy.

### AI agent device operations through Jentic

An AI agent automates ticket triage for a managed mobility help desk. Tickets like 'phone lost' or 'reset device' map to policy patches and command issuance through Jentic, with the agent never holding the underlying service account key.

Example prompt: Read open tickets tagged 'lost-device', issue LOCK followed by RESET_PASSWORD on each affected device, and post the resulting operation IDs back to the ticket.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /v1/enterprises | List enterprises owned by the caller |
| POST | /v1/signupUrls | Create a signup URL for a new enterprise |
| POST | /v1/{+name}:issueCommand | Issue a command (LOCK, RESET_PASSWORD, etc.) on a device |
| GET | /v1/{+parent}/devices | List devices in an enterprise |
| GET | /v1/{+parent}/enrollmentTokens | List enrollment tokens |
| DELETE | /v1/{+name} | Delete a resource (device, policy, token) |

## Key resources

- **Enterprises** — Manage enterprise records that own devices and policies
- **Policies** — Define device, app, and password policies applied at enrollment
- **Devices** — Inspect and issue commands on enrolled devices
- **EnrollmentTokens** — Mint tokens that bind a device to an enterprise and policy at enrollment
- **WebApps** — Publish web app shortcuts to managed devices
- **Operations** — Track long-running device command and policy operations

## Why Jentic

- **Setup:** Wiring the Android Management API by hand means configuring Google OAuth 2.0 from a service account, minting short-lived scoped access tokens, and pointing policy and device calls at the androidmanagement.googleapis.com host. Through Jentic you install once, import the Android Management API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** Android Management puts the enterprise and device resources in the URL path (/v1/{+parent}/devices, /v1/{+name}:issueCommand), so a rule can pin your agent to one enterprise: it can list its devices and enrollment tokens and nothing else. You choose the operations it may call, so actions like issueCommand or deleting a resource are not included unless you add them.
- **Credential handling:** Your Google service account credential is stored once, encrypted, by your own Jentic One instance and exchanged for short-lived scoped access tokens at execution time. The key never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'lock an Android device' or 'create an enrollment token', and Jentic returns the matching Android Management operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Google Play EMM API** — Self-hosted EMM partner surface for managed Google Play distribution.
- **Android Device Provisioning Partner API** — Claims devices for zero-touch enrollment before they call into Android Management.
- **Google Play Android Developer API** — Publishes the apps later distributed by Android Management policies.

## FAQ

### What authentication does the Android Management API use?

It uses OAuth 2.0, generally with a service account granted access to the enterprise. Through Jentic the service account credentials are vaulted and exchanged for scoped access tokens at execution time.

### Can I issue remote lock and wipe commands with this API?

Yes. The devices issueCommand operation under /v1/{+name}:issueCommand accepts LOCK, RESET_PASSWORD, and other command types. It returns a long-running operation that you poll under /v1/{+name} until done.

### What are the rate limits for the Android Management API?

Google enforces per-project quotas in Cloud Console rather than fixed per-second limits. Long-running command operations consume quota only at issuance, not while you poll, so polling cadence is not the main constraint.

### How do I enroll a device through Jentic?

Search Jentic for 'create android enrollment token', load the schema for enterprises.enrollmentTokens.create, and execute it with the enterprise name and target policyName. Render the returned token as a QR code; the device scans it during setup.

### Is the Android Management API free?

The API itself is free. Each enterprise has a quota of devices it can manage, and large fleets may require working with Google to lift quotas.

### What is the difference between Android Management and the Google Play EMM API?

Android Management is Google-hosted: policies, enrollment, and commands all run through Google's backend. The Play EMM API is a partner contract surface that lets self-hosted EMMs distribute managed apps. Pick Android Management for new builds; pick Play EMM when integrating with an existing self-hosted EMM.

### Can I limit what my agent is allowed to do with the Android Management API?

Yes. Because you self-host Jentic One, your own rules decide which Android Management operations and credentials the agent may use. Since the API puts the enterprise and device resources in the URL path (for example /v1/{+parent}/devices and /v1/{+name}:issueCommand), you can pin the agent to a single enterprise so it only lists that enterprise's devices and enrollment tokens. You also choose the exact operations it may call, so destructive actions like issueCommand (LOCK, RESET_PASSWORD) or deleting a resource stay off the table unless you explicitly allow them.
