aw-android
aw-android copied to clipboard
ActivityWatch
Internet browsing history?
Here's more information: https://krtkush.com/2018/08/04/android-accessibility-grab-url.html
That would be cool but it's a bit hacky. I personally use Firefox on Android which supports extensions, including aw-watcher-web, but I haven't figured out how to make it able to report back to the app yet.
I'm not sure that's hacky as it's how all other applications (RescueTime, Instant, BlockSite) do it. I think most people use Chrome on Android, and that feature is a must.
On Sun, Jan 26, 2020 at 2:29 PM Erik Bjäreholt [email protected] wrote:
That would be cool but it's a bit hacky. I personally use Firefox on Android which supports extensions, including aw-watcher-web, but I haven't found out how to make it able to report back to the app yet.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ActivityWatch/aw-android/issues/29?email_source=notifications&email_token=AAL363GQGQ2N3ZGT47FYUVDQ7XQCHA5CNFSM4KLYSEA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ53ZKI#issuecomment-578534569, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAL363EQRCVOICE3SYS2JLLQ7XQCHANCNFSM4KLYSEAQ .
Just to keep track of things, @miguelrochefort got it working as he announced on the forum: https://forum.activitywatch.net/t/android-chrome-watcher/466 :tada:
I found your branch with the changes here: https://github.com/miguelrochefort/aw-android-1/tree/dev/miro
The code needs some cleanup (and the commit adding build artifacts from aw-server-rust and aw-webui won't be accepted in a PR) but still really nice work :)
@ErikBjare turns out Firefox already reports back to ActivityWatch if its turned on.
If I'm on Firefox and AW is not turned on I get a notification: "Unable to send event to server". Once I turn on AW, events start getting sent to AW and I can see them in the bucket.
Currently Firefox always sends events if AW is on. I'm not sure what happens if it's off. Does the aw-browser-watcher just throw away the events if it can't send them to a server, or does it save them in localstorage?
Possible implementations
-
Have AW run as a backgorund service (would need to be mindful of battery life), where rust server is just always on, so Firefox is always be able to send events.
-
If AW is off, save events to localstoarge. Then once user opens up AW, Firefox will send all the events it has in the backlog. Firefox already gives a "Unable to send event to server" notification. So link the notification to an intent, so that it launches AW when a user clicks on the notification. This isn't foolproof however: User might clear localstorage before user launches AW, or just never click on notification. Advantage is it saves battery compared to option 1.
Thinking more on this, I'm not actually sure if running AW server as a background service would use that much battery, especially given that the server would be idle 99% of the time. Might be interesting to test how battery is affected by running silently in the background vs consistently restarting it, especially if every single watcher will restart the server(UsageStatsWatcher, ChromeWatcher, FirefoxWatcher, and any other watchers people come up with: NotificationWatchers etc)
I've considered that before, but apparently on Android you can't just run a background service indefinitely however you want: https://developer.android.com/about/versions/oreo/background
The current method of running it (with alarms) might still be suboptimal. I haven't really looked into it.
My current hope is that @miguelrochefort's solution works well and that we could get something similar to work for Firefox.
I'd be curious to quantify the battery usage of AW's server on Android.
I'm currently running a customized version of ActivityWatch (very much in progress and buggy) that tracks notifications, local multimedia sessions, phone/video calls, Chrome browser history, and even Chromecast and Google Home casting sessions. These services run constantly run in the background, using sticky/persistent "foreground" notifications, and via accessibility APIs. I've used the same strategies while experimenting with 24/7 audio recording. My battery drains more quickly than usual, but I haven't measured how much and to what degree each of these watchers influence it. Perhaps I need to add a battery watcher next.
I suspect that my ChromeWatcher implementation uses quite a bit of resources in the way it uses the accessibility service. I can think of a few ways to optimize it, but I won't do that until I establish a baseline for battery consumption.
I do wonder how much power AW's server consumes compared to a SQLite database or a simple log file.
On Fri., Jun. 26, 2020, 14:25 Erik Bjäreholt, [email protected] wrote:
I've considered that before, but apparently on Android you can't just run a background service indefinitely however you want: https://developer.android.com/about/versions/oreo/background
The current method of running it (with alarms) might still be suboptimal. I haven't really looked into it.
My current hope is that @miguelrochefort https://github.com/miguelrochefort's solution works well and that we could get something similar to work for Firefox.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ActivityWatch/aw-android/issues/29#issuecomment-650328188, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAL363ELTH2LYQPYA3RLLLTRYTRYLANCNFSM4KLYSEAQ .
@ErikBjare You're right about running indefinitely, there is afaik no way to do that. The closest you can get is with sticky foreground services, which is what @miguelrochefort is using. The OS tries to keep it alive as long as you need to, and will kill it only if it absolutely has to.
Relevant links: https://android-developers.googleblog.com/2018/12/effective-foreground-services-on-android_11.html https://stackoverflow.com/questions/49637967/minimal-android-foreground-service-killed-on-high-end-phone