# 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:

```bash
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:

```text
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:

```text
✅ 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:

```text
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:

```text
✅ 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.:

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

or

```text
DNP-REACTIVATION: Detected scenario: NONE
```

Script-level success message might be:

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

or:

```text
✅ 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](../android-implementation-directive-phase2.md) - Implementation details
- [Phase 2 Emulator Testing](./PHASE2-EMULATOR-TESTING.md) - Test procedures
- [Phase 1 Verification](./PHASE1-VERIFICATION.md) - Prerequisite verification
- [Plugin Requirements](./03-plugin-requirements.md) - Requirements this phase implements
- [Platform Capability Reference](./01-platform-capability-reference.md) - OS-level facts

---

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