Reboot device

Tool Name: airdroid_business_reboot_device

Risk Level: 🔴 High Risk

Execution Mode: ⏳ Asynchronous

Category: Remote Commands

Quick Start (Copy & Use)

One-liner: Remotely reboot a specified device

What you need: DeviceId (device ID), Confirm (must be set to true), Reason (reboot reason)

Success criteria: StatusCode = 200 and ErrorMessage is an empty string; returns Pid for tracking

What to do next: Use Get an Activity Log with the Pid to poll execution status

Minimal request example:

{
  "DeviceId": "fa6edcff65ab444e8b5e0eb08df4175d",
  "Confirm": true,
  "Reason": "Device unresponsive, requires restart"
}

Minimal response example:

{
  "Pid": "1770854462319857000",
  "StatusCode": 200,
  "ErrorMessage": ""
}

Recipes (Common Recipes)

Recipe 1: Reboot an unresponsive device

Scenario: Device is frozen or apps are unresponsive, requires remote reboot to recover

{
  "DeviceId": "fa6edcff65ab444e8b5e0eb08df4175d",
  "Confirm": true,
  "Reason": "Device unresponsive, requires restart"
}

Recipe 2: Scheduled maintenance reboot

Scenario: Batch reboot devices during maintenance windows to apply updates

{
  "DeviceId": "abc123def456",
  "Confirm": true,
  "Reason": "Scheduled maintenance reboot for system updates"
}

Recipe 3: Track reboot status with Pid

Scenario: After issuing a reboot, confirm whether the device has successfully rebooted

1. Call Reboot Device to get the Pid
2. Use the Get an Activity Log tool to query status:

{
  "Pid": "1770854462319857000"
}

Polling logic:

• Progress = "Executing" → continue polling (interval 5-10 seconds)
• Progress = "Success" → reboot succeeded
• Progress = "Failure" → check the FailReason field

1. Overview

1.1 Description

Remotely reboot a device managed by AirDroid Business. Applicable to scenarios such as unresponsive devices, applying system updates, or routine maintenance.

1.2 When to Use

• Device fault recovery: Device is frozen or apps are unresponsive; recover via remote reboot
• System maintenance: Reboot devices during scheduled maintenance windows to apply updates
• Performance optimization: Periodic reboots to clear memory and release resources

1.3 Execution Mode & Response

This operation is asynchronous — after the command is sent, the device may take seconds to minutes to respond.

• Return value: Pid (activity log ID)
• Tracking method: Use the Get an Activity Log tool with the Pid to query execution status
• Prerequisite: The device must be online to receive the command
• Typical duration: The device reboot process takes about 1-3 minutes; the device is offline during reboot

1.4 Prerequisites

1.5 Prerequisite Tools

1.6 Comparison with Similar Tools

2. Inputs

2.1 Parameter List

2.2 Parameter Details

`DeviceId`

Device unique identifier.

• Type: string
• Format: Non-empty string
• Source:
  1. Obtained via the Get All Devices tool; use the device_id field from the response
  2. Obtained via the Get a Device by Name tool for exact name lookup
• How to fill in a GI node:
  • Constant: Enter the device ID string directly, e.g. fa6edcff65ab444e8b5e0eb08df4175d
  • Upstream reference: Map from the Get All Devices node's Devices[0].device_id field
• Example:

  "fa6edcff65ab444e8b5e0eb08df4175d"

`Confirm`

Safety confirmation parameter.

• Type: bool
• Format: Must be true to execute the reboot operation
• Why required: Prevents accidental reboot triggers; ensures the user explicitly acknowledges and consents
• How to fill in a GI node:
  • Constant: Only set to true after receiving explicit user consent
• Example:

  true

⚠️ Important: If Confirm is false or not provided, the operation will not execute and returns an error.

`Reason`

Reboot reason.

• Type: string
• Format: Non-empty string; a clear description is recommended
• Why required: Logged for auditing purposes to support tracking and compliance
• How to fill in a GI node:
  • Constant: e.g. "Device unresponsive, requires restart"
  • Upstream reference: Obtain from user input or a ticketing system
• Example:

  "Device unresponsive, requires restart"

2.3 Parameter Combination Logic

• All three parameters are required
• Confirm must be true and Reason must be non-empty for the operation to execute
• If Confirm = false, returns StatusCode = 200 with an ErrorMessage indicating confirmation is required

3. Outputs

3.1 Response Examples

Success response:

{
  "Pid": "1770854462319857000",
  "StatusCode": 200,
  "ErrorMessage": ""
}

Confirmation not passed:

{
  "Pid": "",
  "StatusCode": 200,
  "ErrorMessage": "Confirm must be true to execute device reboot."
}

Parameter error response:

{
  "Pid": "",
  "StatusCode": -1,
  "ErrorMessage": "Invalid device_id."
}

Network error response:

{
  "Pid": "",
  "StatusCode": 500,
  "ErrorMessage": "Request timeout after 60 seconds."
}

3.2 Field Descriptions

3.3 Pid Tracking

Use the returned Pid with the Get an Activity Log tool to track execution status:

4. Examples

4.1 Basic Example: Reboot an unresponsive device

Request:

{
  "DeviceId": "fa6edcff65ab444e8b5e0eb08df4175d",
  "Confirm": true,
  "Reason": "Device unresponsive, requires restart"
}

Response:

{
  "Pid": "789012",
  "StatusCode": 200,
  "ErrorMessage": ""
}

4.2 Advanced Example: Track status after reboot

Step 1: Call the reboot endpoint

{
  "DeviceId": "fa6edcff65ab444e8b5e0eb08df4175d",
  "Confirm": true,
  "Reason": "Scheduled maintenance reboot"
}

Step 2: Use the returned Pid to query the activity log

{
  "Pid": "789012"
}

Step 3: Determine completion based on Progress

• Executing → wait 10 seconds and query again
• Success → reboot complete
• Failure → check FailReason for root cause

4.3 Error Example: Confirmation not provided

Request:

{
  "DeviceId": "fa6edcff65ab444e8b5e0eb08df4175d",
  "Confirm": false,
  "Reason": "Test reboot"
}

Response:

{
  "Pid": "",
  "StatusCode": 200,
  "ErrorMessage": "Confirm must be true to execute device reboot."
}

5. Error Handling

5.1 AB Three-Layer Error Codes

Core principle: AB uses a three-layer error code strategy. The agent should decide how to handle based on StatusCode.

5.2 Common Errors

5.3 Agent Self-Healing Decision Table

6. Best Practices

6.1 Performance Tips

• Confirm device is online: Check device status before rebooting to avoid sending commands to offline devices
• Batch operation intervals: When batch rebooting, add a 2-3 second delay between each call to reduce server load

6.2 Security Considerations

⚠️ Medium Risk Warning: This operation will cause the device to go temporarily offline (approx. 1-3 minutes), which may interrupt ongoing operations.

Pre-execution checklist:

1. ☐ Confirm the device is online
2. ☐ Confirm the correct target device (avoid rebooting the wrong device)
3. ☐ Notify the device holder (if applicable)
4. ☐ Confirm no critical operations are running on the device

6.3 Idempotency

Idempotency: Non-idempotent. Each call triggers a new reboot command.

• If the device is already in the reboot process, a new reboot command will be ignored or overridden
• Avoid blind retries on timeout — instead use Get an Activity Log with the Pid to check status

6.4 Async Operation Tracking

Use the returned Pid with Get an Activity Log to track execution status:

Polling recommendations:

• Interval: 5-10 seconds
• Max polling attempts: 18 (approx. 1.5-3 minutes, accounting for device reboot time)
• On timeout: Prompt the user to manually check device status

7. Related Tools

7.1 Prerequisite Tools

7.2 Follow-up Tools

7.3 Similar Tools Comparison

8. Tool Chains

8.1 Fault Recovery Pattern

Scenario: Device is unresponsive; requires remote reboot to recover

Tool chain:

Get All Devices → Reboot Device → Get an Activity Log (poll) → Get All Devices

Steps:

1. Call Get All Devices to obtain the target device's device_id and confirm it is online
2. Call Reboot Device to send the reboot command and obtain the Pid
3. Use Get an Activity Log with the Pid to poll until Progress = "Success"
4. Call Get All Devices to confirm the device is back online

8.2 Batch Maintenance Reboot Pattern

Scenario: Reboot multiple devices during a maintenance window

Tool chain:

Get All Devices (filter target group) → [Loop] Reboot Device → Get an Activity Log

Steps:

1. Call Get All Devices with Keyword={"group_name":"maintenance-group"} to get the target device list
2. Iterate through devices and call Reboot Device for each (recommended 2-3 second interval)
3. Collect all Pid values and use Get an Activity Log to batch-track status