fix: a lot of events that are stored show 0.0 duration (#39).

[EvertJanDeBruin]

Note: I did not build unit-tests (yet) since this requires quite some restructuring. Also, some discussion is required regarding the 'unlock' bucket (it seems total screentime, where each event is an unlock, is perhaps better).

---

🚀	This description was created by Ellipsis for commit b843e45

Summary:

Fixes event duration issue by updating Event and UsageStatsWatcher to handle app activity more accurately, ensuring correct heartbeat timing.

Key points:

• Modified Event.fromUsageEvent in mobile/src/main/java/net/activitywatch/android/models/Event.kt to accept customTimestamp for precise timing.
• Updated SendHeartbeatsTask in mobile/src/main/java/net/activitywatch/android/watcher/UsageStatsWatcher.kt to handle ACTIVITY_RESUMED and ACTIVITY_PAUSED events.
• Added logic to skip launcher events and handle app switching correctly.
• Ensured heartbeats are sent with appropriate pulse times to reflect actual app usage duration.

---

Generated with ❤️ by ellipsis.dev

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to b843e45 in 32 seconds

More details

• Looked at 218 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 4 drafted comments based on config settings.

1. mobile/src/main/java/net/activitywatch/android/watcher/UsageStatsWatcher.kt:247

• Draft comment:
  The heartbeatsSent variable is declared but not used effectively. Consider removing it or using it to track the number of heartbeats sent.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The heartbeatsSent variable is declared but not used effectively. It should be removed or properly utilized.

2. mobile/src/main/java/net/activitywatch/android/watcher/UsageStatsWatcher.kt:288

• Draft comment:
  Ensure activeAppEvent is reset appropriately to avoid incorrect behavior when processing new events.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  The code already resets activeAppEvent to null after processing an ACTIVITY_PAUSED event, which seems to handle the concern raised by the comment. The comment is speculative and asks for verification, which is not allowed by the rules.
  I might be overlooking a scenario where activeAppEvent is not reset correctly, but the current logic seems to handle the reset appropriately.
  The logic for resetting activeAppEvent appears to be correctly implemented, and the comment does not point out a specific issue that needs addressing.
  The comment should be removed as it is speculative and the code already handles the reset of activeAppEvent appropriately.

3. mobile/src/main/java/net/activitywatch/android/watcher/UsageStatsWatcher.kt:266

• Draft comment:
  Ensure logEventDetails is necessary for debugging, as it is only called when logging is enabled. This is good for performance but verify its necessity.
• Reason this comment was not posted:
  Confidence changes required: 30%
  The logEventDetails function is called only if logging is enabled, which is good for performance, but ensure it's necessary for debugging.

4. mobile/src/main/java/net/activitywatch/android/watcher/UsageStatsWatcher.kt:223

• Draft comment:
  Consider making pulseTime configurable instead of using fixed values to allow more flexibility for different use cases.
• Reason this comment was not posted:
  Confidence changes required: 40%
  The sendHeartbeat function uses a fixed pulse time which might not be flexible for all use cases.

Workflow ID: wflow_uy4fcNtvRzGwYnnO

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

AsyncTask is deprecated. Consider using Kotlin coroutines or java.util.concurrent for better performance and maintainability.

[brayo-pip]

We wish to still track the launcher events, so this bit will have to be removed.