ActivityWatch / aw-android

ActivityWatch for Android, using aw-server-rust as backend.
Mozilla Public License 2.0
168 stars 29 forks source link

Internet browsing history? #29

Open miguelrochefort opened 4 years ago

miguelrochefort commented 4 years ago

Here's more information: https://krtkush.com/2018/08/04/android-accessibility-grab-url.html

ErikBjare commented 4 years ago

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.

miguelrochefort commented 4 years ago

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 notifications@github.com 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 .

ErikBjare commented 4 years ago

Ah, that's good to know! I'll look into it when we get to it.

ErikBjare commented 4 years ago

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 :)

nicolae-stroncea commented 4 years ago

@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

  1. 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.

  2. 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.

nicolae-stroncea commented 4 years ago

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)

ErikBjare commented 4 years ago

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.

miguelrochefort commented 4 years ago

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, notifications@github.com 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 .

nicolae-stroncea commented 4 years ago

@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