Feat: Automated Reliability Testing with CTS Inspired Logic

[KidScripty]

Checklist

• I made sure that there are no existing issues - open or closed - to which I could contribute my information.
• I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
• I have read the FAQs inside the app (Menu -> About -> FAQs), in the README and my problem isn't listed.
• I have taken the time to fill in all the required details. I understand that the request may get dismissed otherwise.
• This issue contains only one feature request.

Which apps should have this feature?

Clock

Feature description

CI Verification of App Survival Logic

Implement critical CI pipeline tests that replicate the logic found in Android’s Compatibility Test Suite (CTS) to verify how the app handles being killed or suppressed. This specifically addresses the "Deep Sleep" and "Restricted" scenarios common in aggressive OEM environments like Samsung's One UI.

• Simulation of App Killing & Deep Sleep: Replicate the logic from modules like CtsAlarmManagerTestCases to test the app’s resilience when the process is terminated or placed into a restricted power state by the OS.
• Exemption Verification (Before/After): Use the CI to verify the state of isIgnoringBatteryOptimizations() and its direct impact on alarm delivery.
  • The "Before" Check: Run survival tests while the app is subject to standard battery optimizations. This documents the failure points where the OS (or aggressive OEM logic) kills the process or delays the alarm.
  • The "After" Check: Programmatically simulate the "Unrestricted" state and verify that the app now successfully "punches through" Doze and Deep Sleep.
• Targeted Survival Testing:
  • Process Resurrection: Verifying that the System Server successfully restarts the app process to deliver an alarm intent even after the process has been force-killed or moved to a "Deep Sleep" state.
  • Idle Punch-Through: Testing the app's ability to wake the CPU from a forced Doze state (simulated via adb shell dumpsys deviceidle force-idle). This mimics the exact point of failure on many Samsung devices where "Battery Protection" prevents standard apps from waking the device.

Why do you want this feature?

It is well-documented that many vendors (Samsung, Xiaomi, etc.) employ non-standard battery optimization managers that kill background processes or ignore standard alarm intents. Specifically, Samsung's "Deep Sleep" can move apps into a state where they are effectively disabled until the user manually interacts with them.

By adopting this verification logic, the project gains:

• A Reliability Baseline: Proof that the app is 100% compliant with standard Android process recovery. By checking isIgnoringBatteryOptimizations(), we can prove that moving to the "Unrestricted" bucket is the only definitive way to bypass OEM-specific killing logic.
• Technical Justification: This provides a data-backed reason to implement the ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS toggle. If the app passes tests only after battery exemptions are applied, it proves the toggle is a required feature for reliability on non-compliant hardware.
• Automated Triage: It allows the project to distinguish between a regression in the app's alarm logic and an external "app-killing" event caused by a specific phone manufacturer's proprietary power management.

Additional information

• Reference: This specifically addresses the "background killing" and "Deep Sleep" behaviors documented by dontkillmyapp.com.

[naveensingh]

Fossify apps don't even have plain unit tests, and you are confusing device/platform compliance with app testing. Adding these test cases will verify the emulator behavior, not how the app behaves on Samsung Galaxy S24+.

Also, both this and this look AI-generated. Please avoid posting AI-generated proposals without doing your own research.

[KidScripty]

Firstly, apologies for this looking like slop!

Although I did use AI to assist with formatting and wording of the issue request, the proposal itself is a result of my own thinking and research after considering the reliability of the clock. I reviewed the output and I believe that the proposal is valid. Apologies if you are against this; I will put more effort into reviewing moving forward as I was a bit hasty previously and have modified the request accordingly to properly explain the proposal.

Adding unit tests would be great in general. I would be happy to offer my time in contributing some. This comment also relates to the other pull request here.

In my opinion, both feature suggestions would be good additions. It is important to acknowledge that a huge number of devices on the market ship with aggressive OEM battery managers that kill apps—the S24+ is just one prominent example. In an ideal world, setExactAndAllowWhileIdle() or setAlarmClock() should be enough, but in reality, these vendor layers often interfere.

Borrowing the logic from specific CTS modules as integration tests could give the app much better coverage against these behaviors. It allows for verification that the app is as resilient as possible even when the system tries to suppress it. By comparing how the app survives these "app-killing" scenarios before and after isIgnoringBatteryOptimizations() is toggled, it can be ensured that the app is actually better prepared for real-world devices. Given how critical alarm reliability is, I believe this survival logic should be covered in a CI pipeline.

The feature request has been updated to reflect this.

[KidScripty]

In practice what this will ultimately do is verify that changing isIgnoringBatteryOptimizations value actually makes the app more resilient.

After that, if the behaviour of the setting of ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS to "unrestricted" doesn't change in android itself then it's questionable how much value there is to constantly run it. However the resilience and success of the alarm functionality itself is directly associated with this behaviour on many devices.

[KidScripty]

Test Case Example: Process Survival Verification

1. Initial State: App is in isIgnoringBatteryOptimizations() == false (Standard/Optimized bucket).
2. Action: Schedule a critical alarm using setAlarmClock() or setExactAndAllowWhileIdle().
3. Suppression: Simulate aggressive OEM power management by force-killing the app process (mimicking "Deep Sleep" or a "Restricted" bucket state).
4. Verification: Trigger the alarm time and check if the Android System Server successfully resurrects the app process to deliver the intent.
5. Comparison: Repeat steps 1–4 with isIgnoringBatteryOptimizations() == true.

On problematic hardware, even though setAlarmClock() is used, the intent is never delivered in the first scenario because the OEM layer prevents the system from waking a killed/frozen process. This proves that the issue isn't the alarm API choice, but the process lifecycle—which is what the "Unrestricted" toggle (via the standard Android API) is designed to solve.