/

None Action

Action Type: NONE

Enable security threat detection while explicitly disabling any automated response.

Available for: All platforms (Mobile and Desktop)

How It Works

When the None action is configured:

  1. The Monitor detects all security threats as configured
  2. Threat information is logged internally
  3. No response action is taken
  4. The application continues running normally
  5. You retain complete visibility into detected threats

When to Use

Recommended for:

  • Development and testing environments
  • Analyzing detection accuracy
  • Benchmarking threat detection
  • Understanding false positive rates
  • Evaluating protection module sensitivity
  • Initial module configuration validation

Not recommended for:

  • Production environments where threats require response
  • Critical security modules that must take action
  • Final application releases without active protection

Configuration

JSON Configuration

JSON
{
  "protections": [
    {
      "type": "DebuggerDetection",
      "action": "none",
      "interval": 2000
    },
    {
      "type": "MemoryDumpDetection",
      "action": "none",
      "interval": 1000
    }
  ]
}

Code-Based Configuration (Kotlin)

Kotlin
import com.bytehide.monitor.Monitor
import com.bytehide.monitor.core.action.ActionType
import com.bytehide.monitor.core.protection.ProtectionModuleType

Monitor.configure { config ->
    config.addProtection(
        ProtectionModuleType.DEBUGGER_DETECTION,
        ActionType.NONE,
        2000
    )

    config.addProtection(
        ProtectionModuleType.MEMORY_DUMP_DETECTION,
        ActionType.NONE,
        1000
    )
}

Code-Based Configuration (Java)

Java
import com.bytehide.monitor.Monitor;
import com.bytehide.monitor.core.action.ActionType;
import com.bytehide.monitor.core.protection.ProtectionModuleType;

Monitor.configure(config -> {
    config.addProtection(
        ProtectionModuleType.DEBUGGER_DETECTION,
        ActionType.NONE,
        2000
    );

    config.addProtection(
        ProtectionModuleType.MEMORY_DUMP_DETECTION,
        ActionType.NONE,
        1000
    );
});

Code Examples

Even with the None action, all detected threats are reported to the Cloud Panel, where you can review detection patterns and false positive rates.

Comparing Actions Across Modules

Use the None action alongside other actions to compare detection coverage:

Kotlin
Monitor.configure { config ->
    // Module 1: Passive detection only
    config.addProtection(
        ProtectionModuleType.DEBUGGER_DETECTION,
        ActionType.NONE,
        2000
    )

    // Module 2: Logging only
    config.addProtection(
        ProtectionModuleType.NETWORK_TAMPERING,
        ActionType.LOG,
        2000
    )

    // Module 3: Aggressive response
    config.addProtection(
        ProtectionModuleType.TAMPERING_DETECTION,
        ActionType.CLOSE,
        2000
    )

    // Module 4: Custom handling
    config.registerCustomAction("hybrid_response") { threat ->
        if (threat.confidence >= 0.90) {
            System.exit(1)
        }
    }

    config.addProtection(
        ProtectionModuleType.PROCESS_INJECTION,
        "hybrid_response",
        2000
    )
}

This mixed configuration allows you to observe detection patterns on some modules while protecting critical modules.

Performance Impact

The None action has minimal performance overhead:

  • Detection runs at configured intervals
  • No response processing overhead
  • Negligible memory impact
  • Suitable for production monitoring if needed

Development Workflow Best Practices

Step 1: Initial Configuration

Kotlin
// Start all modules with None action
config.addProtection(ProtectionModuleType.DEBUGGER_DETECTION, ActionType.NONE, 2000)
config.addProtection(ProtectionModuleType.NETWORK_TAMPERING, ActionType.NONE, 2000)
config.addProtection(ProtectionModuleType.JAILBREAK_DETECTION, ActionType.NONE, 2000)

Step 2: Run Threat Scenarios Test your application against various threat scenarios while monitoring detection.

Step 3: Analyze Results Review incidents in the Cloud Panel to understand detection patterns and false positive rates.

Step 4: Tune Configuration Adjust module sensitivity and confidence thresholds based on analysis.

Step 5: Transition to Production Switch modules to appropriate actions (Log, Close, Custom) for production deployment.

Best Practices

  • Start with None: Begin all protection module testing with the None action
  • Gradually Enable Actions: Transition modules to appropriate actions after validation
  • Monitor False Positives: Use None action results to identify false positive rates
  • Document Thresholds: Record which confidence levels trigger false positives
  • Review Regularly: Analyze detection logs to improve module configuration
  • Never Deploy Production: Avoid using None action in production for critical protections
  • Collect Baseline Data: Use None action to establish threat detection baselines
  • Test Comprehensively: Run all threat scenarios before transitioning to production actions

Log Action

Record threats and continue running

Close Action

Terminate the application immediately

Custom Action

Execute custom handler logic

Previous
Custom
Next
Overview