Clear app data and cache

Tool Name: airdroid_business_clear_app_data_and_cache

Risk Level: 🔴 High Risk

Execution Mode: ⏳ Asynchronous

Category: Security Operations

Quick Start (Copy & Use)

One-liner: Remotely clear data and cache from a specified app on a device

What you need: DeviceId (device ID), PkgId (app package name), Confirm (must be set to true), Reason (reason for the operation)

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",
  "PkgId": "com.facebook.katana",
  "Confirm": true,
  "Reason": "User requested data reset for troubleshooting"
}

Minimal response example:

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

Recipes (Common Recipes)

Recipe 1: Clear app data for troubleshooting

Scenario: An app on a field device is malfunctioning — clear its data and cache to reset it

{
  "DeviceId": "fa6edcff65ab444e8b5e0eb08df4175d",
  "PkgId": "com.example.fieldapp",
  "Confirm": true,
  "Reason": "App crashing repeatedly, clearing data to reset"
}

Recipe 2: Clear browser data for security

Scenario: A shared kiosk device needs its browser data cleared for security compliance

{
  "DeviceId": "abc123def456",
  "PkgId": "com.android.chrome",
  "Confirm": true,
  "Reason": "Periodic browser data cleanup for security compliance"
}

Recipe 3: Track clear data status with Pid

Scenario: After clearing app data, confirm whether the operation completed successfully

1. Call Clear App Data and Cache 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" → data cleared successfully
• Progress = "Failure" → check the FailReason field

1. Overview

1.1 Description

Remotely clear data and cache from a specified app on a device managed by AirDroid Business. This operation permanently deletes the app's local data including user settings, cached files, login sessions, and locally stored content.

1.2 When to Use

• App troubleshooting: Clear corrupted app data to resolve crashes or malfunctions
• Security compliance: Periodically clear sensitive data from shared or kiosk devices
• User reset: Reset an app to its initial state (e.g., after employee departure on a shared device)
• Storage management: Free up device storage by clearing large app caches

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
• Critical: All app local data (settings, cache, login sessions) will be permanently deleted and cannot be recovered

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, specifying the target device.

• 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"

`PkgId`

Android app package name identifying the target app whose data and cache should be cleared.

• Type: string
• Format: Android package name format (e.g., com.facebook.katana, com.android.chrome)
• Source:
  1. Obtained via the Get All Device Apps tool; use the package_name field from the response
  2. Obtained via the Get a Device App by Name tool for app name lookup
• How to fill in a GI node:
  • Constant: Enter the package name directly, e.g. com.facebook.katana
  • Upstream reference: Map from the Get All Device Apps node output
• Example:

  "com.facebook.katana"

`Confirm`

Safety confirmation parameter. This is a guardrail parameter for high-risk operations, preventing accidental execution of destructive actions.

• Type: bool
• Default: false (will not execute)
• Must be set to true to execute: If false, the operation will be rejected with an error
• How to fill in a GI node:
  • Constant: Only set to true after receiving explicit user consent
• Example:

  true

⚠️ Important: The agent must ask the user for confirmation before calling this tool. Only set this parameter to true after receiving explicit user approval.

`Reason`

Reason for clearing app data and cache.

• 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. "User requested data reset for troubleshooting"
  • Upstream reference: Obtain from user input or a ticketing system
• Example:

  "User requested data reset for troubleshooting"

⚠️ Important: The Reason parameter must be provided by the user. The agent should not fabricate reasons.

2.3 Parameter Combination Logic

• All four 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 set to true to execute this destructive operation."
}

Missing reason response:

{
  "Pid": "",
  "StatusCode": 200,
  "ErrorMessage": "Reason is required for audit trail."
}

Parameter error response:

{
  "Pid": "",
  "StatusCode": -1,
  "ErrorMessage": "Invalid device_id. Obtain via 'Get All Devices' or 'Get a Device by Name' tool."
}

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: Clear app data for troubleshooting

Request:

{
  "DeviceId": "fa6edcff65ab444e8b5e0eb08df4175d",
  "PkgId": "com.facebook.katana",
  "Confirm": true,
  "Reason": "User requested data reset for troubleshooting"
}

Response:

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

4.2 Advanced Example: Look up app, then clear data

Step 1: Call Get a Device App by Name to find the app's package name

{
  "DeviceId": "fa6edcff65ab444e8b5e0eb08df4175d",
  "AppName": "Chrome"
}

Response (simplified):

{
  "Apps": [
    {
      "app_name": "Chrome",
      "package_name": "com.android.chrome"
    }
  ]
}

Step 2: Ask user for confirmation first, then call Clear App Data and Cache

{
  "DeviceId": "fa6edcff65ab444e8b5e0eb08df4175d",
  "PkgId": "com.android.chrome",
  "Confirm": true,
  "Reason": "Browser data cleanup for security compliance"
}

Step 3: Use the returned Pid to track status

{
  "Pid": "1770854462319857000"
}

4.3 Error Example: Confirmation not provided

Request:

{
  "DeviceId": "fa6edcff65ab444e8b5e0eb08df4175d",
  "PkgId": "com.facebook.katana",
  "Confirm": false,
  "Reason": "Test operation"
}

Response:

{
  "Pid": "",
  "StatusCode": 200,
  "ErrorMessage": "Confirm must be set to true to execute this destructive operation."
}

4.4 Error Example: Invalid device ID

Request:

{
  "DeviceId": "invalid_device_id",
  "PkgId": "com.facebook.katana",
  "Confirm": true,
  "Reason": "Clear app data"
}

Response:

{
  "Pid": "",
  "StatusCode": -1,
  "ErrorMessage": "Invalid device_id. Obtain via 'Get All Devices' or 'Get a Device by Name' tool."
}

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 clearing data to avoid sending commands to offline devices
• Verify app exists: Use Get All Device Apps to confirm the app is installed before attempting to clear data
• Batch operation intervals: When clearing data on multiple devices, add a 2-3 second delay between each call

6.2 Security Considerations

⚠️ High-Risk Operation Warning: This operation will permanently delete the app's local data including user settings, cached files, login sessions, and locally stored content. This action cannot be undone.

Pre-execution checklist:

1. ☐ Confirm the device is online
2. ☐ Confirm the correct target device and app (avoid clearing the wrong app's data)
3. ☐ Verify the app package name is correct
4. ☐ Notify the device holder (if applicable)
5. ☐ Understand that app login sessions, settings, and local data will be lost
6. ☐ Back up any important data within the app if possible

6.3 Idempotency

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

• Repeated calls will re-clear the app data (though subsequent calls may have no visible effect if the app has no new data)
• 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: 12 (approx. 1-2 minutes)
• 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 App Troubleshooting Pattern

Scenario: An app on a device is malfunctioning — look up the app, clear its data, and verify

Tool chain:

Get a Device by Name → Get All Device Apps → Clear App Data and Cache → Get an Activity Log (poll)

Steps:

1. Call Get a Device by Name to find the device's device_id
2. Call Get All Device Apps to get the list of installed apps and find the target package_name
3. Ask the user for confirmation before proceeding
4. Call Clear App Data and Cache with the DeviceId and PkgId
5. Use Get an Activity Log with the Pid to confirm the operation completed

8.2 Shared Device Security Cleanup Pattern

Scenario: Periodically clear browser data from shared kiosk devices for security compliance

Tool chain:

Get All Devices (filter kiosk group) → [Loop] Clear App Data and Cache → Get an Activity Log

Steps:

1. Call Get All Devices with Keyword={"group_name":"kiosk-devices"} to get all kiosk devices
2. Ask the user for confirmation for the entire batch
3. Iterate through devices and call Clear App Data and Cache for each (PkgId = com.android.chrome)
4. Collect all Pid values and batch-track using Get an Activity Log

8.3 Employee Departure Device Cleanup Pattern

Scenario: An employee has left — clear sensitive app data from their assigned device

Tool chain:

Get a Device by Name → Get All Device Apps → [Loop] Clear App Data and Cache → Get an Activity Log

Steps:

1. Call Get a Device by Name to find the departing employee's device
2. Call Get All Device Apps to identify apps with sensitive data (e.g., email, messaging, browser)
3. Ask the user for confirmation, listing the apps to be cleared
4. Call Clear App Data and Cache for each target app
5. Track all operations via Get an Activity Log

Appendix Reference:

• Field Reference: https://www.goinsight.ai/tools/field-reference/
• Error Code Quick Reference: https://www.goinsight.ai/tools/error-codes/