Skip to content

Local server stops after swipe-away until app is reopened #252

Description

@TimeToBuildBob

Problem

On a OnePlus 7 / Android 12 running v0.14.0b2, the local server at localhost:5600 stops exposing newly recorded Android activity after the app is removed from recents. Reopening the app starts the server and backfills the missing interval from Android UsageStats, so the data was available to import but was not persisted or queryable while the app process was down.

The source report also mentions force-stop. Android deliberately prevents all app components, alarms, and sticky-service restarts after a force-stop until the user launches the app again; that case cannot provide an always-live local API. Swipe-away is distinct and should be investigated separately.

Source report: #247

Current implementation

In v0.14.0b2 and current master:

  • BackgroundService is a foreground service and returns START_STICKY.
  • The manifest leaves android:stopWithTask at its default (false).
  • The activity starts the service and schedules hourly event parsing.
  • There is no onTaskRemoved instrumentation or explicit restart fallback, so the report does not yet tell us whether OxygenOS destroys the service, suppresses the sticky restart, or only stops the native server.

Scope

  • Reproduce swipe-away separately from force-stop on Android 12 / OxygenOS.
  • Capture BackgroundService lifecycle and process-exit evidence around removal from recents.
  • Keep the local server/API available after a normal swipe-away, or restart it automatically when Android permits.
  • Document the unavoidable force-stop boundary rather than presenting it as recoverable.

Acceptance criteria

  • Swiping ActivityWatch away from recents does not permanently stop localhost:5600; if the process is killed, service/server recovery is verified without reopening the activity.
  • Activity events recorded after swipe-away become queryable without reopening the app.
  • The behavior is tested on Android 12, with OnePlus/OxygenOS battery-management behavior recorded.
  • Force-stop behavior is documented as an Android platform limitation.
  • Any restart fallback avoids a tight crash/restart loop and follows Android foreground-service restrictions.

Diagnostic request

For an affected device, capture the persistent-notification state and filtered logs while reproducing swipe-away only:

adb logcat -c
adb logcat -v time BackgroundService:I RustInterface:I ActivityManager:I AndroidRuntime:E '*:S'

The key distinction is whether BackgroundService destroyed appears, whether the process exits, and whether BackgroundService created / Starting server... follows without opening the activity.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions