Is your request related to a specific issue? | 你的请求是否与某个问题相关？
Yes. Currently, APatch automatically disables all modules when the device enters safe mode, recovery mode, or fails to boot properly (partial or full boot failure). While this anti-bootloop protection is useful for preventing problematic modules from bricking the device, there are scenarios where this behavior is undesirable.
For example:
-
A module that intentionally modifies the boot process may be falsely detected as causing a bootloop
-
Users who intentionally reboot into safe mode for troubleshooting unrelated issues lose all module functionality and must manually re-enable everything
-
Modules that are critical for device functionality (e.g., accessibility, device-specific fixes) get disabled unexpectedly, potentially causing more issues than they prevent
-
On some devices, partial boot failures (e.g., system UI crashes but kernel boots fine) trigger the anti-bootloop mechanism unnecessarily
Describe the solution you'd like | 描述你想要的解决方案
Add a configurable option (toggle/setting) that allows users to disable the automatic module deactivation behavior. The implementation could include:
A global toggle in APatch settings — "Disable Anti-Bootloop Protection" or "Keep modules enabled on unsafe boot"
When enabled, modules would persist and remain active regardless of boot mode (safe mode, recovery, boot failures)
Default state should remain as current behavior (protection ON) to prevent inexperienced users from bricking their devices
Per-module persistence flag — optionally, a more granular approach where specific modules can be marked as "persistent" and survive boot failures, while other modules still get disabled
Graceful recovery mechanism — if the toggle is enabled and the device truly enters a bootloop, a method to regain control (e.g., volume key combo during boot to force-disable modules, or a flashable rescue zip)
The setting should be clearly labeled with appropriate warnings about the risks of disabling this protection.
Describe the alternatives you've considered | 描述您考虑过的备选方案
Manually re-enabling modules after each incident — tedious and impractical, especially if boot failures happen frequently or unexpectedly
Using a companion module that re-enables other modules on boot — this is a hacky workaround and defeats the purpose of having a clean solution; it also may not work reliably if the companion module itself gets disabled
Modifying APatch source code directly — requires recompiling APatch for every update, not viable for regular users
Volume key selector during boot — similar to how some custom recoveries prompt for actions, a prompt during boot asking whether to disable modules or keep them, but this adds complexity and requires user interaction on every problematic boot
Other information | 其他信息
This feature would be particularly useful for:
-
Users with devices that have known quirks triggering false-positive boot failure detection
-
Developers testing modules who frequently reboot into different modes
-
Users who rely on critical modules for accessibility or device-specific hardware support
The implementation should ideally store the preference in a persistent location (e.g., /data/adb/apatch/ config file) so it survives across reboots and APatch updates. A clear warning dialog when enabling this option is strongly recommended to ensure users understand the risks.
Thank you for considering this feature!
Is your request related to a specific issue? | 你的请求是否与某个问题相关？
Yes. Currently, APatch automatically disables all modules when the device enters safe mode, recovery mode, or fails to boot properly (partial or full boot failure). While this anti-bootloop protection is useful for preventing problematic modules from bricking the device, there are scenarios where this behavior is undesirable.
For example:
A module that intentionally modifies the boot process may be falsely detected as causing a bootloop
Users who intentionally reboot into safe mode for troubleshooting unrelated issues lose all module functionality and must manually re-enable everything
Modules that are critical for device functionality (e.g., accessibility, device-specific fixes) get disabled unexpectedly, potentially causing more issues than they prevent
On some devices, partial boot failures (e.g., system UI crashes but kernel boots fine) trigger the anti-bootloop mechanism unnecessarily
Describe the solution you'd like | 描述你想要的解决方案
Add a configurable option (toggle/setting) that allows users to disable the automatic module deactivation behavior. The implementation could include:
A global toggle in APatch settings — "Disable Anti-Bootloop Protection" or "Keep modules enabled on unsafe boot"
When enabled, modules would persist and remain active regardless of boot mode (safe mode, recovery, boot failures)
Default state should remain as current behavior (protection ON) to prevent inexperienced users from bricking their devices
Per-module persistence flag — optionally, a more granular approach where specific modules can be marked as "persistent" and survive boot failures, while other modules still get disabled
Graceful recovery mechanism — if the toggle is enabled and the device truly enters a bootloop, a method to regain control (e.g., volume key combo during boot to force-disable modules, or a flashable rescue zip)
The setting should be clearly labeled with appropriate warnings about the risks of disabling this protection.
Describe the alternatives you've considered | 描述您考虑过的备选方案
Manually re-enabling modules after each incident — tedious and impractical, especially if boot failures happen frequently or unexpectedly
Using a companion module that re-enables other modules on boot — this is a hacky workaround and defeats the purpose of having a clean solution; it also may not work reliably if the companion module itself gets disabled
Modifying APatch source code directly — requires recompiling APatch for every update, not viable for regular users
Volume key selector during boot — similar to how some custom recoveries prompt for actions, a prompt during boot asking whether to disable modules or keep them, but this adds complexity and requires user interaction on every problematic boot
Other information | 其他信息
This feature would be particularly useful for:
Users with devices that have known quirks triggering false-positive boot failure detection
Developers testing modules who frequently reboot into different modes
Users who rely on critical modules for accessibility or device-specific hardware support
The implementation should ideally store the preference in a persistent location (e.g., /data/adb/apatch/ config file) so it survives across reboots and APatch updates. A clear warning dialog when enabling this option is strongly recommended to ensure users understand the risks.
Thank you for considering this feature!