Request to claim devices asynchronously in batch. Claiming a device adds the device to zero-touch enrollment and shows the device in the customer’s view of the portal.
A configuration collects the provisioning options for Android devices. Each configuration combines the following: * The EMM device policy controller (DPC) installed on the devices. * EMM policies enforced on the devices. * Metadata displayed on the device to help users during setup. Customers can add as many configurations as they need. However, zero-touch enrollment works best when a customer sets a default configuration that’s applied to any new devices the organization purchases.
Applies a Configuration to the device to register the device for zero-touch enrollment. After applying a configuration to a device, the device automatically provisions itself on first boot, or next factory reset.
Unclaims a device from a customer and removes it from zero-touch enrollment. After removing a device, a customer must contact their reseller to register the device into zero-touch enrollment again.
A record of a device claimed by a reseller for a customer. Devices claimed for zero-touch enrollment have a claim with the type SECTION_TYPE_ZERO_TOUCH. To learn more, read Claim devices for customers.
A DeviceReference is an API abstraction that lets you supply a device argument to a method using one of the following identifier types: * A numeric API resource ID. * Real-world hardware IDs, such as IMEI number, belonging to the manufactured device. Methods that operate on devices take a DeviceReference as a parameter type because it’s more flexible for the caller. To learn more about device identifiers, read Identifiers.
An EMM’s DPC (device policy controller). Zero-touch enrollment installs a DPC (listed in the Configuration) on a device to maintain the customer’s mobile policies. All the DPCs listed by the API support zero-touch enrollment and are available in Google Play.
A generic empty message that you can re-use to avoid defining duplicated empty messages in your APIs. A typical example is to use it as the request or the response type of an API method. For instance: service Foo { rpc Bar(google.protobuf.Empty) returns (google.protobuf.Empty); }
Gets the latest state of a long-running operation. Clients can use this method to poll the operation result at intervals as recommended by the API service.
Creates a customer for zero-touch enrollment. After the method returns successfully, admin and owner roles can manage devices and EMM configs by calling API methods or using their zero-touch enrollment portal. The customer receives an email that welcomes them to zero-touch enrollment and explains how to sign into the portal.
Lists the customers that are enrolled to the reseller identified by the partnerId argument. This list includes customers that the reseller created and customers that enrolled themselves using the portal.
Finds devices claimed for customers. The results only contain devices registered to the reseller that’s identified by the partnerId argument. The customer’s devices purchased from other resellers don’t appear in the results.
Unclaims a batch of devices for a customer asynchronously. Removes the devices from zero-touch enrollment. To learn more, read Long‑running batch operations.
Updates the reseller metadata attached to a batch of devices. This method updates devices asynchronously and returns an Operation that can be used to track progress. Read Long‑running batch operations. Android Devices only.
The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. Each Status message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the API Design Guide.