How does Auto Rescue determine that the device is in a bootloop?

During early boot (post-fs-data), the module increments a persistent boot attempt counter. If the operating system fails to reach the sys.boot_completed=1 state and reboots repeatedly, the counter exceeds the allowable threshold, triggering an emergency disable routine across all non-whitelisted modules.

Auto Rescue – Download (Magisk/KernelSU/APatch)

Name: Auto Rescue
Author: Fendou Youth

Overview

Auto Rescue (originally authored by Han and Qingfeideyic, maintained by Fendou Youth) is an automated systemless watchdog designed to recover Android devices from soft bricks and bootloops caused by incompatible Magisk, KernelSU, or APatch modules.

When modifying low-level Android framework libraries, audio effects, or system properties, a malfunctioning script can cause the Zygote process to crash or the SystemUI daemon to hang indefinitely. Without custom recovery (TWRP/OrangeFox) or USB debugging enabled, users often face full data wipes to restore booting. Auto Rescue eliminates this risk by executing autonomous health checks during the bootloader handoff and init sequence.

Technical Architecture & How It Works

Auto Rescue divides its supervisory responsibilities across two stages of the Android boot sequence:

1. Early Boot Stage (post-fs-data.sh)

When the root manager executes post-fs-data.sh, the root filesystem is mounted read-write in /data. Auto Rescue inspects its persistent state directory:

Attempt Logging: It reads /data/adb/modules/Automatic_brick_rescue/Number_of_starts.log. If the previous boot never signaled completion, the counter increments.
Crash Threshold Evaluation: If the counter reaches the threshold (typically 2 consecutive interrupted boots), Auto Rescue initiates the fail-safe recovery procedure before late services or Zygote hooks can run.
Selective Disablement: Auto Rescue scans /data/adb/modules/ and creates an empty .disable file in each active module directory. Modules explicitly listed in whitelist.conf (such as core root managers or display drivers) are spared.

2. Late Boot Stage (service.sh)

Once the Android framework initializes, service.sh runs asynchronously in the background:

Completion Polling: The daemon periodically checks system properties using getprop sys.boot_completed.
Counter Reset: Once sys.boot_completed returns 1, Auto Rescue confirms that the user space and graphical interface are healthy. It resets Number_of_starts.log back to 0.
OTA Upgrade Protection: When an Android OS upgrade occurs, the initial startup process can take substantially longer due to ART dexopt compilation and package migration. Auto Rescue detects system updates and injects a 30-minute delay threshold to avoid disabling modules prematurely.

Configuration & Whitelist Management

Auto Rescue provides a local configuration file to protect essential modules:

# Whitelist configuration path
/data/adb/modules/Automatic_brick_rescue/whitelist.conf

Adding Modules to the Whitelist

To ensure specific modules remain operational during a rescue event, append their folder slugs to the file:

# Example whitelist entries:
Automatic_brick_rescue
playintegrityfix
shamiko

Troubleshooting & Diagnostics

Inspect Boot Logs: Review /data/adb/modules/Automatic_brick_rescue/Number_of_starts.log via root shell or termux to inspect recorded startup iterations.
Re-enabling Modules: If a module was disabled during a false alarm, remove the .disable file from /data/adb/modules/<module-slug>/.disable and reboot the device.

Auto Rescue