Conversation
WebWatcher hard-coded audible=false on every aw-watcher-android-web event. aw-webui uses audible browser events as not-AFK evidence, so the field was worthless on Android. BrowserAudibleDetector reports whether the browser package owns a media session in STATE_PLAYING via MediaSessionManager, which is the precise per-app signal but needs the MediaWatcher notification-listener access. Without that access it falls back to AudioManager.isMusicActive(), which is global and can't tell browser audio from a background music app. The result is cached for one second because accessibility events arrive many times a second while scrolling. BrowserSessionTracker now carries audible per session and splits the session when it flips, so each logged event has the right value for its stretch of time (the desktop web watcher likewise starts a new event when data changes). Url, browser and title carry over across the split. incognito is still hard-coded to false; detecting it needs per-browser accessibility-tree heuristics and is left for a follow-up.
|
… fallback handleUrl returned early when the url and browser were unchanged, so an audible transition sampled on a same-page event was discarded and the session logged with a stale value. Same-page calls now route through handleAudible. The AudioManager.isMusicActive() fallback is removed: it is device-wide, so a background music app would have marked silent browser sessions audible, which aw-webui counts as not-AFK evidence. Without notification access audible is now always false, as before this change.
Member
Author
|
@greptile review |
Member
|
@0xbrayo I'm wondering if we should just keep a separate "audible" bucket and not make it browser-only. There is no "AFK" bucket/state on Android anyway to filter by, so it doesn't affect filtering. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
WebWatcherhard-codesaudible=falseon everyaw-watcher-android-webevent (// TODO). aw-webui uses audible browser events as not-AFK evidence (include_audibleinqueries.ts), so the field was worthless on Android.Changes
BrowserAudibleDetector— reports whether the browser package owns a media session inSTATE_PLAYINGviaMediaSessionManager.getActiveSessions(). This is the precise per-app signal (Chrome/Firefox publish a media session for page audio/video) but needs the existing MediaWatcher notification-listener access. Without that access it falls back toAudioManager.isMusicActive(), which is global and can't tell browser audio from a background music app. Result is cached for 1s since accessibility events arrive many times a second while scrolling.BrowserSessionTracker— carriesaudibleper session and splits the session when it flips, so each logged event has the right value for its stretch of time (desktop aw-watcher-web likewise starts a new event when data changes). Url, browser and title carry over across the split.WebWatcher— samples audible on every browser accessibility event and feeds it to the tracker.Known limitations
incognitois still hard-coded tofalse; detecting it needs per-browser accessibility-tree heuristics and is out of scope here.Addresses the
audiblehalf of #106.Validation
:mobile:testStandardDebugUnitTest --tests 'net.activitywatch.android.watcher.*': 39 tests pass (4 new tracker tests, 2 new detector tests). Not yet exercised on a device — draft until I've checked Chrome + Firefox with and without notification access.