Adds documentation and test harness for Phase 2 (Force Stop Detection & Recovery). Changes: - Add PHASE2-EMULATOR-TESTING.md with detailed test procedures - Add PHASE2-VERIFICATION.md with test matrix and verification template - Add test-phase2.sh automated test harness Test harness features: - 3 test cases: force stop with cleared alarms, intact alarms, empty DB - Automatic force stop simulation via adb - Log parsing for scenario detection and recovery results - UI prompts for plugin configuration and scheduling Related: - Directive: android-implementation-directive-phase2.md - Requirements: docs/alarms/03-plugin-requirements.md §3.1.4 - Testing: docs/alarms/PHASE2-EMULATOR-TESTING.md - Verification: docs/alarms/PHASE2-VERIFICATION.md
196 lines
6.3 KiB
Markdown
196 lines
6.3 KiB
Markdown
# 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
|