Yet Another Bootloop Protector watches for repeated Android boot failures caused by Magisk, KernelSU, or APatch modules. When its failure threshold is reached, it disables installed modules and general boot scripts so the next startup has a chance to complete.
Automatic Recovery from Module Failures
Marker-based boot tracking, a timeout, and optional SystemUI monitoring cover several common failure patterns.
Failure Markers
Successive incomplete boots create three markers. At the threshold, the module treats the sequence as a bootloop and disables modules.
Boot Timeout
Checks boot completion every five seconds and, by default, acts after two minutes without a completed startup.
SystemUI Monitor
An optional monitor reacts when SystemUI remains absent for more than 25 seconds or crashes repeatedly after boot.
What Happens During Recovery
The module creates a disable file in each root-module directory and changes general scripts under /data/adb/service.d, post-fs-data.d, post-mount.d, and boot-completed.d to non-executable mode. It then reboots so Android can start without those additions.
Modules and scripts listed in /data/adb/YABP/allowed-modules.txt and allowed-scripts.txt are exempt. After identifying the culprit, modules can be re-enabled individually or through the module action button, which also restores executable permissions to the general scripts.
SystemUI and Recovery Use
Create /data/adb/systemui.monitor.disable to turn off SystemUI monitoring for the next boot; remove the file to enable it again. Runtime logs are written to /data/local/tmp/service.log.
Flashing this package from custom recovery is an emergency action: if /data is accessible, it disables all supported root modules and general scripts immediately. Upstream warns that this behavior is expected, and not every recovery can provide the required access.
post-fs-data/system.prop failure. It reduces one class of risk; it is not a substitute for backups and a tested recovery route.