fix(android): handle rejected foreground service starts

[TimeToBuildBob]

What changed

• catches ForegroundServiceStartNotAllowedException at both Android rejection boundaries: boot-time startForegroundService() and in-service startForeground()
• stops BackgroundService before Rust/server/scheduler initialization when foreground promotion is denied
• changes the service from START_STICKY to START_NOT_STICKY, avoiding illegal background recreation loops
• tags starts as activity, boot, settings, or system-restart in lifecycle logs
• adds unit coverage for origin classification and the non-sticky restart policy

Verification

./gradlew :mobile:testDebugUnitTest \
  --tests net.activitywatch.android.BackgroundServicePolicyTest \
  --tests net.activitywatch.android.MainActivityNavigationTest
BUILD SUCCESSFUL

Local AI review: 5/5, no open findings.

Physical API 34/36 boot and background-recreation verification remains a release/device gate; no Android device is attached to this build host. The code now fails closed instead of crashing on either platform rejection path.

Fixes #255.

[TimeToBuildBob]

🤖 AI code review

Safe to merge — no P0/P1 findings

Confidence 5/5

✅ No findings. The diff looks correct to me on this pass.

_{Reviewed a88ee1bedbe5 · openrouter/deepseek/deepseek-v4-flash-0731 · llm (in-band) engine · 59s · about this reviewer}

_{Maintainer commands}

_{@TimeToBuildBob review (own line) — fresh review · @TimeToBuildBob fix — a worker acts on the findings. Once per comment; 👀 = received.}

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge, with rejection paths terminating cleanly before dependent service state is used.

Summary

• Catches ForegroundServiceStartNotAllowedException at both rejection boundaries.
• Stops startup before Rust and scheduler initialization when promotion fails.
• Adopts START_NOT_STICKY to prevent unsafe background recreation loops.
• Records explicit service-start origins and adds policy-focused unit coverage.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Activity, boot receiver, or settings] --> B[Request BackgroundService start]
    B --> C{Start request accepted?}
    C -- No --> D[Log rejection and remain stopped]
    C -- Yes --> E[BackgroundService.onCreate]
    E --> F{Foreground promotion accepted?}
    F -- No --> G[stopSelf before Rust and scheduler initialization]
    F -- Yes --> H[Initialize Rust interface and scheduler]
    H --> I[Handle start command and log origin]
    I --> J[Return START_NOT_STICKY]

Loading

_{Reviews (1) · Last reviewed commit: "fix(android): handle rejected foreground..."}

[TimeToBuildBob]

All 5 required checks now pass, and Greptile reviewed the current head at 5/5 with no findings. This account has pull-only access, so I cannot merge or formally request a reviewer. Ready for maintainer review/merge; physical API 34/36 boot and background-recreation verification remains the release-device gate.

[TimeToBuildBob]

CI-green and mergeable (Greptile 5/5) — waiting only on a maintainer click.

This PR is ready to merge, but the bot has pull-only access to this repo and can't self-merge — surfacing it here so it isn't lost. The monitoring loop will stop re-flagging it now that this note is posted.