Get an activity log

Tool Name: airdroid_business_get_activity_log

Risk Level: 🟢 Low Risk

Execution Mode: ⚡ Synchronous

Category: Reports & Analytics

Quick Start (Copy & Use)

In one sentence: Track the execution status of asynchronous device operations (e.g., reboot, lock screen, lost mode)

What you need: DeviceId (device ID) + Pid (process ID returned by the async operation)

Success criteria: StatusCode == 200 and ErrorMessage is empty; check ActivityLog.Progress to determine execution status

What to do next: Decide whether to continue polling or the task is complete based on the Progress status

Minimal request example:

{
  "DeviceId": "abc123def456ghi789jkl012mno345pq",
  "Pid": "550e8400-e29b-41d4-a716-446655440000"
}

Minimal response example:

{
  "ActivityLog": {
    "DeviceId": "abc123def456ghi789jkl012mno345pq",
    "DeviceName": "Samsung Galaxy S24",
    "Action": "device_reboot",
    "Progress": "Success",
    "FailReason": ""
  },
  "StatusCode": 200,
  "ErrorMessage": ""
}

Recipes (Common Recipes)

Recipe 1: Check Reboot Command Status

Scenario: Track execution result after calling Reboot Device

{
  "DeviceId": "abc123def456ghi789jkl012mno345pq",
  "Pid": "550e8400-e29b-41d4-a716-446655440000"
}

Recipe 2: Check Lock Screen Command Status

Scenario: Track execution result after calling Lock a Device

{
  "DeviceId": "device_id_from_lock_command",
  "Pid": "pid_from_lock_response"
}

Recipe 3: Poll Until Completion

Scenario: The async operation returns Executing and needs polling

Polling strategy:

1. After the first query, if Progress == "Executing", wait 5-10 seconds
2. Call this tool again to check the status
3. Repeat until Progress becomes Success, Failure, or Overridden
4. Recommended maximum polling count: 12 times (approximately 1-2 minutes)

{
  "DeviceId": "abc123def456ghi789jkl012mno345pq",
  "Pid": "550e8400-e29b-41d4-a716-446655440000"
}

1. Overview

1.1 Description

This tool queries the execution status of asynchronous device operations. After executing async commands such as reboot, lock screen, or enable lost mode, use this tool to track whether the command was successfully delivered to the device and executed.

1.2 When to Use

• Track async operation results: After executing Reboot Device, Lock a Device, Enable Lost Mode, etc., use this tool to check execution status
• Confirm command completion: Use in workflows that require confirmation of successful command execution before proceeding to the next step
• Troubleshoot operation failures: When an operation fails, obtain the failure reason via the FailReason field

1.3 Execution Mode & Response

This is a synchronous operation that returns the current activity log status immediately upon invocation.

• Return value: Contains an ActivityLog object describing the current operation status
• Key fields: Progress (execution progress) and FailReason (failure reason)

1.4 Prerequisites

1.5 Prerequisite Tools

2. Inputs

2.1 Parameter List

2.2 Parameter Details

`DeviceId`

Device unique identifier.

• Type: string
• Format: Non-empty string, 32-character hexadecimal
• How to obtain:
  1. From the input parameters of async operations (e.g., Reboot Device)
  2. Via the Get All Devices tool, using the device_id field from results
  3. Via the Get a Device by Name tool for exact name lookup
• How to fill in GI nodes:
  • Constant value: Enter the device ID string directly, e.g., abc123def456ghi789jkl012mno345pq
  • Reference upstream output: Take the value from the upstream node's DeviceId output field
• Example:

  "abc123def456ghi789jkl012mno345pq"

`Pid`

Process ID, the unique identifier for an asynchronous device operation task.

• Type: string
• Format: Non-empty string
• How to obtain: From the response of device operation tools, for example:
  • Reboot Device → returned Pid
  • Lock a Device → returned Pid
  • Enable Lost Mode → returned Pid
  • Disable Lost Mode → returned Pid
  • Power off a Device → returned Pid
• How to fill in GI nodes:
  • Constant value: Enter the Pid string directly
  • Reference upstream output: Take the value from the Pid output field of the upstream async operation node (recommended)
• Example:

  "550e8400-e29b-41d4-a716-446655440000"

2.3 Parameter Combination Logic

DeviceId and Pid must both be provided and must match (i.e., the Pid must have been returned when executing an operation on that DeviceId).

3. Outputs

3.1 Response Examples

Success response (operation completed successfully):

{
  "ActivityLog": {
    "DeviceId": "abc123def456ghi789jkl012mno345pq",
    "DeviceName": "Samsung Galaxy S24",
    "Action": "device_reboot",
    "Progress": "Success",
    "FailReason": ""
  },
  "StatusCode": 200,
  "ErrorMessage": ""
}

Success response (operation still executing):

{
  "ActivityLog": {
    "DeviceId": "abc123def456ghi789jkl012mno345pq",
    "DeviceName": "Samsung Galaxy S24",
    "Action": "device_reboot",
    "Progress": "Executing",
    "FailReason": ""
  },
  "StatusCode": 200,
  "ErrorMessage": ""
}

Success response (operation failed):

{
  "ActivityLog": {
    "DeviceId": "abc123def456ghi789jkl012mno345pq",
    "DeviceName": "INFINIX 1",
    "Action": "device_reboot",
    "Progress": "Failure",
    "FailReason": "Unable to reboot the device. This device needs to be improved compatibility or it has a reboot slider function"
  },
  "StatusCode": 200,
  "ErrorMessage": ""
}

Error response (invalid parameters):

{
  "ActivityLog": {
    "DeviceId": "",
    "DeviceName": "",
    "Action": "",
    "Progress": "",
    "FailReason": ""
  },
  "StatusCode": -1,
  "ErrorMessage": "Invalid device_id."
}

3.2 Field Descriptions

3.3 Status Code / Enum Value Mapping

Progress Status Values (Important)

Action Code Values

4. Examples

4.1 Basic Example: Check Reboot Operation Status

Scenario: Check whether the reboot was successful after calling Reboot Device

Request parameters:

{
  "DeviceId": "abc123def456ghi789jkl012mno345pq",
  "Pid": "550e8400-e29b-41d4-a716-446655440000"
}

Response:

{
  "ActivityLog": {
    "DeviceId": "abc123def456ghi789jkl012mno345pq",
    "DeviceName": "Samsung Galaxy S24",
    "Action": "device_reboot",
    "Progress": "Success",
    "FailReason": ""
  },
  "StatusCode": 200,
  "ErrorMessage": ""
}

4.2 Advanced Example: Handling Executing Status

Scenario: Command was just sent and the device has not yet completed execution

Request parameters:

{
  "DeviceId": "abc123def456ghi789jkl012mno345pq",
  "Pid": "550e8400-e29b-41d4-a716-446655440000"
}

Response:

{
  "ActivityLog": {
    "DeviceId": "abc123def456ghi789jkl012mno345pq",
    "DeviceName": "Samsung Galaxy S24",
    "Action": "lock_device",
    "Progress": "Executing",
    "FailReason": ""
  },
  "StatusCode": 200,
  "ErrorMessage": ""
}

Handling: Wait 5-10 seconds and call again until Progress is no longer Executing

4.3 Error Example: Invalid Device ID

Request parameters:

{
  "DeviceId": "",
  "Pid": "550e8400-e29b-41d4-a716-446655440000"
}

Response:

{
  "ActivityLog": {
    "DeviceId": "",
    "DeviceName": "",
    "Action": "",
    "Progress": "",
    "FailReason": ""
  },
  "StatusCode": -1,
  "ErrorMessage": "Invalid device_id."
}

5. Error Handling

5.1 AB Three-Layer Error Codes

Core principle: AB uses a three-layer error code strategy. The Agent should determine the handling approach based on the StatusCode.

5.2 Common Errors

5.3 Agent Self-Healing Decision Table

6. Best Practices

6.1 Performance Optimization

• Avoid unnecessary polling: Only continue polling when Progress == "Executing"
• Set reasonable polling intervals: Recommended 5-10 seconds; overly frequent queries are pointless
• Set a maximum polling count: Recommended 12 times (approximately 1-2 minutes); prompt the user to check manually after timeout

6.2 Security Notes

🟢 Read operation: This tool only queries status and has no special security requirements.

6.3 Polling Best Practices

Recommended polling workflow:

1. Execute async operation (e.g., Reboot Device) → Obtain Pid
2. Call Get an Activity Log to check status
3. Evaluate Progress:
   - "Executing" → Wait 5-10 seconds, go back to step 2
   - "Success" → Operation complete, proceed with subsequent workflow
   - "Failure" → Operation failed, check FailReason
   - "Overridden" → Overridden by a new command, no action needed
4. If polling exceeds 12 times and still "Executing", prompt user to check manually

7. Related Tools

7.1 Prerequisite Tools

7.2 Follow-up Tools

7.3 Similar Tools Comparison

8. Tool Chains

8.1 Async Operation Tracking Pattern

Scenario: Execute an async device operation and confirm completion

Tool chain:

Reboot Device → Get an Activity Log (polling)

Steps:

1. Call Reboot Device to perform reboot, obtain the returned Pid
2. Call Get an Activity Log with DeviceId and Pid to check status
3. If Progress == "Executing", wait 5-10 seconds and repeat step 2
4. When Progress is Success/Failure/Overridden, operation tracking is complete

8.2 Batch Device Operation Tracking Pattern

Scenario: Execute operations on multiple devices and track all operation statuses

Tool chain:

Get All Devices → Lock a Device (batch) → Get an Activity Log (parallel polling)

Steps:

1. Call Get All Devices to get the target device list
2. Call Lock a Device for each device and collect all returned Pid values
3. Call Get an Activity Log in parallel to track each operation's status
4. Aggregate all operation results

8.3 Post-Confirmation Execution Pattern

Scenario: Ensure operation success before executing subsequent operations

Tool chain:

Enable Lost Mode → Get an Activity Log (wait for success) → Send notification

Steps:

1. Call Enable Lost Mode to enable lost mode
2. Use Get an Activity Log to poll until Progress == "Success"
3. After confirmation, execute follow-up actions (e.g., send notification)