daily-notification-plugin/docs/alarms/PHASE2-VERIFICATION.md

Phase 2 – Force Stop Recovery Verification

Plugin: Daily Notification Plugin
Scope: Force stop detection & recovery (App ID: com.timesafari.dailynotification)
Related Docs:

• android-implementation-directive-phase2.md
• 03-plugin-requirements.md (Force Stop & App Termination behavior)
• PHASE2-EMULATOR-TESTING.md
• 000-UNIFIED-ALARM-DIRECTIVE.md

---

1. Objective

Phase 2 verifies that the Daily Notification Plugin:

1. Correctly detects force stop conditions where alarms may have been cleared.
2. Reschedules future notifications when schedules exist in the database but alarms are missing.
3. Avoids heavy recovery when alarms are intact (no false positives).
4. Does not misfire force-stop recovery on first launch / empty database.

Phase 2 builds on Phase 1, which already covers:

• Cold start detection
• Missed notification marking
• Basic alarm verification

---

2. Test Method

Verification is performed using the emulator test harness:

cd test-apps/android-test-app
./test-phase2.sh

This script:

• Builds and installs the debug APK (app/build/outputs/apk/debug/app-debug.apk).
• Guides the tester through UI steps for scheduling notifications and configuring the plugin.
• Simulates:
  • force-stop behavior via adb shell am force-stop ...
  • "Soft stop" / process kill via adb shell am kill ...
  • First launch / empty DB via uninstall + reinstall
• Collects and parses DNP-REACTIVATION log lines, extracting:
  • scenario
  • missed
  • rescheduled
  • verified
  • errors

Detailed steps and expectations are documented in PHASE2-EMULATOR-TESTING.md.

---

3. Test Matrix

ID	Scenario	Method / Script Step	Expected Behavior	Result	Notes
2.1	Force stop clears alarms	test-phase2.sh – TEST 1: Force Stop – Alarms Cleared	scenario=FORCE_STOP, rescheduled>0, errors=0	☐
2.2	Force stop / process stop with alarms intact	test-phase2.sh – TEST 2: Soft Stop – Alarms Intact	scenario != FORCE_STOP, rescheduled=0, errors=0	☐
2.3	First launch / empty DB (no schedules present)	test-phase2.sh – TEST 3: First Launch / No Schedules	Either no recovery logs or scenario=NONE (or equivalent) and rescheduled=0, errors=0	☐

Fill in Result and Notes after executing the script on your baseline emulator/device.

---

4. Expected Log Patterns

4.1 Force Stop – Alarms Cleared (Test 2.1)

Typical expected DNP-REACTIVATION log patterns:

DNP-REACTIVATION: Detected scenario: FORCE_STOP
DNP-REACTIVATION: Rescheduled alarm: daily_<id> for <time>
DNP-REACTIVATION: Rescheduled missing alarm: daily_<id> at <time>
DNP-REACTIVATION: Force stop recovery completed: missed=1, rescheduled=1, verified=0, errors=0

The script will report:

✅ TEST 1 PASSED: Force stop detected and alarms rescheduled (scenario=FORCE_STOP, rescheduled=1).

4.2 Soft Stop – Alarms Intact (Test 2.2)

Typical expected patterns:

DNP-REACTIVATION: Detected scenario: COLD_START
DNP-REACTIVATION: Cold start recovery completed: missed=0, rescheduled=0, verified>=0, errors=0

The script should not treat this as a force-stop recovery:

✅ TEST 2 PASSED: No heavy force-stop recovery when alarms are intact (scenario=COLD_START, rescheduled=0).

(Adjust scenario name to match your actual implementation.)

4.3 First Launch / Empty DB (Test 2.3)

Two acceptable patterns:

1. No recovery logs at all (DNP-REACTIVATION absent), or
2. Explicit "no schedules" scenario, e.g.:

DNP-REACTIVATION: No schedules present — skipping recovery (first launch)

or

DNP-REACTIVATION: Detected scenario: NONE

Script-level success message might be:

✅ TEST 3 PASSED: NONE scenario detected with no rescheduling.

or:

✅ TEST 3 PASSED: No recovery logs when there are no schedules (safe behavior).

---

5. Latest Known Good Run (Emulator) – Placeholder

Update this section after your first successful run.

Environment

• Device: Pixel 8 API 34 (Android 14)
• App ID: com.timesafari.dailynotification
• Build: Debug app-debug.apk from commit <GIT_HASH>
• Script: ./test-phase2.sh
• Date: 2025-11-XX

Observed Results

• ☐ 2.1 – Force Stop / Alarms Cleared

  • scenario=FORCE_STOP
  • missed=1, rescheduled=1, verified=0, errors=0

• ☐ 2.2 – Soft Stop / Alarms Intact

  • scenario=COLD_START (or equivalent non-force-stop scenario)
  • rescheduled=0, errors=0

• ☐ 2.3 – First Launch / Empty DB

  • scenario=NONE (or no logs)
  • rescheduled=0, errors=0

Conclusion:

To be filled after first successful emulator run.

---

6. Overall Status

To be updated once the first emulator pass is complete.

• Implementation Status: ☐ Pending / ✅ Implemented in ReactivationManager (Android plugin)
• Test Harness: ✅ test-phase2.sh in test-apps/android-test-app
• Emulator Verification: ☐ Pending / ✅ Completed (update when done)

Once all boxes are checked:

Overall Status: ✅ VERIFIED – Phase 2 behavior is implemented, emulator-tested, and aligned with 03-plugin-requirements.md and android-implementation-directive-phase2.md.

---

7. Related Documentation

• Phase 2 Directive - Implementation details
• Phase 2 Emulator Testing - Test procedures
• Phase 1 Verification - Prerequisite verification
• Plugin Requirements - Requirements this phase implements
• Platform Capability Reference - OS-level facts

---

Status: ☐ PENDING – Phase 2 implementation and testing pending
Last Updated: November 2025