Not sure how to run the server to handle the requests, but would be really cool.

Edit: Asked on IRC

https://forum.activitywatch.net/t/android-app-cant-find-web-ui/888

Please make a dark theme of the application.

At the moment, the "Report bugs" button in the App Drawer only shows a placeholder Snackbar.

@Miyou just gave me a tip that it should be possible to sideload normal Android apps onto the Oculus Quest. This might possibly enable the ability to run ActivityWatch on the Oculus Quest!

Did a quick search, and apparently it's possible with a simple adb install and some Android TV app called TvAppRepo (guide: https://uploadvr.com/how-to-sideload-apps-oculus-go/).

The only worry is that the Oculus Quest might not have the UsageStats API (just like Android TV doesn't, see #5). That would suck.

Please make the design of the application in the style of Material Theming (this is an extension of Material Design, which was introduced at Google I/O 2018). Material Theming lets you fine tune Material Design, and I like Material Theming more than the older version of Material Design. Useful links: https://material.io/design/material-theming/overview.html, https://material.io/develop/android/docs/theming-guide/.

Doesn't work right now due to aw-server-rust depending on ring which fails to compile under the old arm architecture.

Would let us support older devices (a significant part of the devices in use).

Version: 0.10.0
Installed From: Playstore
Android Version: 11 (AOSPA)

Scoop app couldn't register any crashes (weirdly), so can't provide logs, but if necessary I can use Matlog or something.

See: https://github.com/tdillon/android

As brought up on the forum many of the events in my aw-android have a duration of 0 seconds. Looking at my event list close to half of my events are a duration of 0 seconds. Not sure if this is actually a bug or what

I realized why there are a lot of duration:0 events in the raw data store. I initially thought this was due to storing the same events twice(#38), however this turned out not to be the case.

Android's default UsageStatsManager should actually produce close to no events of duration 0 for apps with a UI. Every UI app has a move_to_foreground and a move_to_background, so all events should have at least some milliseconds of time on screen if captured correctly.

Here's what's happening:

Android has 2 other events: screen_interactive and screen_non_interactive. Whenever you're in an application, and the screen goes to sleep, or you lock the screen, the screen_non_interactive event shoots first, only then followed by a move_to_background event. Because AW merges events next to each other, this essentially adds an event in the middle, and breaks the chain. Let's say you start Firefox. You get a move_to_foreground when you start Firefox, you spend 20 minutes, and then lock the screen. Android sends a screen_non_interactive, then a move_to_background. As a result both Firefox events have duration 0 instead of 20 minutes.

Here's an example:

                {
                    "id": 60381,
                    "timestamp": "2020-06-14T00:00:45.523Z",
                    "duration": 0.0,
                    "data": {
                        "app": "Firefox",
                        "classname": "org.mozilla.gecko.BrowserApp",
                        "package": "org.mozilla.firefox"
                    }
                },
                {
                    "id": 60380,
                    "timestamp": "2020-06-14T00:00:45.435Z",
                    "duration": 0.0,
                    "data": {
                        "app": "Android system",
                        "package": "android"
                    }
                },
                {
                    "id": 60379,
                    "timestamp": "2020-06-13T23:57:20.015Z",
                    "duration": 0.0,
                    "data": {
                        "app": "Firefox",
                        "classname": "org.mozilla.gecko.BrowserApp",
                        "package": "org.mozilla.firefox"
                    }
                },

Look at the timestamps of Firefox and Android System for confirmation: 2020-06-14T00:00:45.523Z and 2020-06-14T00:00:45.435Z, to see that Android sends them in the order I specified above. Here AW reports I spent 0 time on Firefox, when in reality I spent 3 minutes

This occurs almost every time you lock your phone/your phone goes to sleep by itself, and is probably the main cause for: ActivityWatch/activitywatch/issues/440.

To reproduce

1. Get the Raw data for the Android Bucket
2. Take a look at all of the events with duration: 0. Notice how they're separated by the Android System call.

You can also confirm this order by printing out the events to LogCat as they come, making sure to print the event_type with them.

To fix

In SendHeartbeatsTask, when iterating through the loop of events, if the event type is screen_non_interactive, check if next event has same app name as previous event. If they do, then process next event first, and only after that, process screen_non_interactive. Everything else should be the same

To make debugging easier, it would be good to store 'event_type' directly in data. This would make it a lot easier to later look through the events and make sure the behaviours between all event types are correct.

EDIT: Also related to this: #34

I don't really know what happens behind the scenes, but if I haven't opened the app for a few days, I can basically see the bars in the page appear and grow, until they reach today (tapping the reload button every few seconds). I use a Redmi Note 8 Pro, so performance-wise it should be at least average.
The import process should either be sped up by an order of magnitude, done in the background, or be accompanied by some indicator that the displayed data isn't complete yet, e.g. a progress bar IMHO.

When running the install script install-ndk.sh I get the error

/usr/bin/readlink
readlink: illegal option -f

I believe this is because readlink does not exist on Mac systems, as mentioned in this stackoverflow.

Expected Behavior:
I wanted to use the app on both my main profile and the work profile (created with Island app).

Actual Behavior:
The app on the profile I want to use it crashes and closes if it has been opened already on the other profile. To fix it I've to delete the app data of the other profile and open the one I want. It seems like there's no other way to fix it.

Steps to Reproduce the Problem:
Open app on one of the 2 profiles. Close it and open the the app on the other profile.
I.e. I open the app on main profile. It works. I open the app on work profile. Work profile app crashes, main profile app works.

Specifications:
App Version: 0.10.0
OS: Android 11
Subsystem: Miui 12
Device: Mi 10

As I mentioned in #30 at this comment it would be very interesting to have a watcher that can track how many times the phone is unlocked and/or how many times the screen is turned on (ie to check if you have any notifications). It's a great metric to identify just how often you are checking your phone.

I'm no android developer but a quick look through the intents found several which could be useful
ACTION_SCREEN_ON
ACTION_USER_PRESENT
ACTION_USER_UNLOCKED

Please add app shortcuts support. This would be useful in order to be able to quickly start frequent actions and those actions that would require more than one action. Shortcut example: open Web UI. And do not forget, please, make adaptive icons for app shortcuts. Useful links: https://developer.android.com/guide/topics/ui/shortcuts.html, https://source.android.com/devices/tech/display/app-shortcuts, https://developer.android.com/guide/practices/ui_guidelines/icon_design_adaptive, https://source.android.com/devices/tech/display/adaptive-icons.

I followed all instructions to build the app But stuck here. Also, I have one more confusion about the application. Why we are loading from System? If there is an independent app, How it will work?

System.loadLibrary("aw_server")

Note: I am using Mac, So executed all thing as per Mac not as per Linux

I discovered this bug when building aw-android. I can provide more detail later (currently on my phone).

Seems to be easily solvable by correctly handling Result unwrap, or waiting for the DB to "unlock".

The simple workaround I used was to add a short pause between heartbeats (100ms, could probably go way lower).

Several clients (the ones using aw-client) support to contact a remote server.

There are traces in forums of remote server not being recommended (although reasons are not detailed).
It would be more consistent to support this option for the android app as well.

Could it be considered?

Starting page tells the user to click "Web UI" from the top left menu, but such button doesn't exist.
Should it suggest "Activity" instead?

For some reason, doesn't work without wifi, and on some instances seemed to crash/hang?

I released v0.4.11 yesterday, but turns out the latest aw-server-rust came with a new crash.

Any idea what could cause this @johan-bjareholt?

2019-08-13 10:58:10.951 8330-8360/net.activitywatch.android.debug D/aw-server-rust: thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', src/libcore/result.rs:1084:5
2019-08-13 10:58:10.955 8330-8360/net.activitywatch.android.debug D/aw-server-rust: thread '<unnamed>' panicked at 'Dropped request without responding, programmer error!', /home/erb/.cargo/registry/src/github.com-1ecc6299db9ec823/crossbeam_requests-0.2.0/src/lib.rs:113:13
2019-08-13 10:58:10.955 8330-8360/net.activitywatch.android.debug D/aw-server-rust: stack backtrace:
2019-08-13 10:58:10.955 8330-8360/net.activitywatch.android.debug D/aw-server-rust:    0:       0x7c21079904 - <unknown>
2019-08-13 10:58:10.955 8330-8360/net.activitywatch.android.debug D/aw-server-rust:    1:       0x7c210795cc - <unknown>
2019-08-13 10:58:10.955 8330-8360/net.activitywatch.android.debug D/aw-server-rust:    2:       0x7c21079fa4 - <unknown>
2019-08-13 10:58:10.955 8330-8360/net.activitywatch.android.debug D/aw-server-rust:    3:       0x7c20d5aa00 - <unknown>
2019-08-13 10:58:10.955 8330-8360/net.activitywatch.android.debug D/aw-server-rust:    4:       0x7c20d77920 - <unknown>
2019-08-13 10:58:10.956 8330-8360/net.activitywatch.android.debug D/aw-server-rust:    5:       0x7c20d76e0c - <unknown>
2019-08-13 10:58:10.956 8330-8360/net.activitywatch.android.debug D/aw-server-rust:    6:       0x7c20d7e344 - <unknown>
2019-08-13 10:58:10.956 8330-8360/net.activitywatch.android.debug D/aw-server-rust:    7:       0x7c20d7e7e4 - <unknown>
2019-08-13 10:58:10.956 8330-8360/net.activitywatch.android.debug D/aw-server-rust:    8:       0x7c20ff7e44 - <unknown>
2019-08-13 10:58:10.956 8330-8360/net.activitywatch.android.debug D/aw-server-rust:    9:       0x7c21004ce8 - <unknown>
2019-08-13 10:58:10.956 8330-8360/net.activitywatch.android.debug D/aw-server-rust:   10:       0x7c2100362c - <unknown>
2019-08-13 10:58:10.956 8330-8360/net.activitywatch.android.debug D/aw-server-rust:   11:       0x7c20ff2844 - <unknown>
2019-08-13 10:58:10.956 8330-8360/net.activitywatch.android.debug D/aw-server-rust:   12:       0x7c2100db4c - <unknown>
2019-08-13 10:58:10.957 8330-8360/net.activitywatch.android.debug D/aw-server-rust:   13:       0x7c2100a618 - <unknown>
2019-08-13 10:58:10.958 8330-8360/net.activitywatch.android.debug D/aw-server-rust:   14:       0x7c20fec338 - <unknown>
2019-08-13 10:58:10.959 8330-8360/net.activitywatch.android.debug D/aw-server-rust:   15:       0x7c2107c7c4 - <unknown>
2019-08-13 10:58:10.959 8330-8360/net.activitywatch.android.debug D/aw-server-rust:   16:       0x7c20fdccb4 - <unknown>
2019-08-13 10:58:10.959 8330-8360/net.activitywatch.android.debug D/aw-server-rust:   17:       0x7c2106f268 - <unknown>
2019-08-13 10:58:10.959 8330-8360/net.activitywatch.android.debug D/aw-server-rust:   18:       0x7c2107c130 - <unknown>
2019-08-13 10:58:10.960 8330-8360/net.activitywatch.android.debug D/aw-server-rust:   19:       0x7cbc9c2db0 - <unknown>
2019-08-13 10:58:10.960 8330-8360/net.activitywatch.android.debug D/aw-server-rust:   20:       0x7cbc96478c - <unknown>
2019-08-13 10:58:10.960 8330-8360/net.activitywatch.android.debug D/aw-server-rust:   21:                0x0 - <unknown>
2019-08-13 10:58:10.960 8330-8360/net.activitywatch.android.debug D/aw-server-rust: thread panicked while panicking. aborting.
2019-08-13 10:58:10.960 8330-8391/net.activitywatch.android.debug A/libc: Fatal signal 5 (SIGTRAP), code 1 (TRAP_BRKPT), fault addr 0x7c21079fe8 in tid 8391 (AsyncTask #1), pid 8330 (h.android.debug)
2019-08-13 10:58:11.194 8692-8692/? A/DEBUG: pid: 8330, tid: 8391, name: AsyncTask #1  >>> net.activitywatch.android.debug <<<
2019-08-13 10:58:11.196 8692-8692/? A/DEBUG:     #00 pc 0000000000398fe8  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.196 8692-8692/? A/DEBUG:     #01 pc 00000000000799fc  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.196 8692-8692/? A/DEBUG:     #02 pc 000000000009691c  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.196 8692-8692/? A/DEBUG:     #03 pc 0000000000095e08  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.196 8692-8692/? A/DEBUG:     #04 pc 000000000009d340  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.196 8692-8692/? A/DEBUG:     #05 pc 000000000009d7e0  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.196 8692-8692/? A/DEBUG:     #06 pc 0000000000316e40  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.196 8692-8692/? A/DEBUG:     #07 pc 0000000000323ce4  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.196 8692-8692/? A/DEBUG:     #08 pc 0000000000322628  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.197 8692-8692/? A/DEBUG:     #09 pc 0000000000311840  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.197 8692-8692/? A/DEBUG:     #10 pc 000000000032cb48  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.197 8692-8692/? A/DEBUG:     #11 pc 0000000000329614  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.197 8692-8692/? A/DEBUG:     #12 pc 000000000030b334  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.197 8692-8692/? A/DEBUG:     #13 pc 000000000039b7c0  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.197 8692-8692/? A/DEBUG:     #14 pc 00000000002fbcb0  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.197 8692-8692/? A/DEBUG:     #15 pc 000000000038e264  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.197 8692-8692/? A/DEBUG:     #16 pc 000000000039b12c  /data/app/net.activitywatch.android.debug-0fXhC8ipjwqoQuC4H-KlhA==/lib/arm64/libaw_server.so
2019-08-13 10:58:11.424 2960-4663/? D/PerfShielderService: net.activitywatch.android.debug|net.activitywatch.android.debug/net.activitywatch.android.MainActivity|150|146843333953930|150|0|1
2019-08-13 10:58:11.428 4511-4522/? W/MiuiPerfServiceClient: interceptAndQueuing:8330|net.activitywatch.android.debug|150|150|unknown|null|net.activitywatch.android.debug/net.activitywatch.android.MainActivity|146843333953930|Slow main thread|1
2019-08-13 10:58:12.215 2960-8696/? W/ActivityManager:   Force finishing activity net.activitywatch.android.debug/net.activitywatch.android.MainActivity
2019-08-13 10:58:12.345 2960-4074/? I/AutoStartManagerService: MIUILOG- Reject RestartService packageName :net.activitywatch.android.debug uid : 10269
2019-08-13 10:58:12.376 2960-3238/? W/InputDispatcher: channel '63c48b0 net.activitywatch.android.debug/net.activitywatch.android.MainActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
2019-08-13 10:58:12.376 2960-3238/? E/InputDispatcher: channel '63c48b0 net.activitywatch.android.debug/net.activitywatch.android.MainActivity (server)' ~ Channel is unrecoverably broken and will be disposed!

I think we've had this issue since versionCode 9. Lots of verifying reports on the Google Play Store.

It's usually fine, but then starts crashing on every reboot. Haven't reproduced in the emulator yet though, but in production on two different phones.

I updated to Android 10 yesterday, and apparently that leads the app crashing after a minute or so, with no Activity being logged (as far as I can tell).

Apparently you need to supply a x86_64 binary for all apps on the Play Store before the deadline on the 1st of August if you want to be able to update your app: https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html

According to a Google email I just received, this is apparently not the case for the Android app. It might just be as easy as to copy the library into a x86_64 folder.

Thanks for working on ActivityWatch, really an amazing project!

In addition to #35 I'd find it useful and interesting to also have a bucket that tracks the screen going into interactive state. Often enough phones are checked by waking the display but not actually unlocking.

Based on the description I'd assume this should be covered by SCREEN_INTERACTIVE. If this would be considered in general, I'd also be interested in working on it.

Hey, Great work on the app and the software.

Can I set my activitywatch server running on desktop as the target for the android client, and some way to make the android client send all the data to the server on my laptop in the same wifi network?

Has anyone thought about hooking in Android location logging info into this app? There's a lot of useful activity data from my life that is strongly tied to location (but not my phone app activity). It would be awesome if this data could be collected by this app just like app data is!

I am confused as to how to use this - does it run completely standalone? Can't I integrate it with AW-desktop?

Hello.
I sideloaded this app into a Kindle Fire HDX7 running a custom Nougat but it keeps crashing upon launch. Is it because it's an ARM device?

One major device I spent time on that's currently not tracked is my TV which is connected to a Mi Box. As far as I know, there are no time-tracking apps for Android TV, which is a real shame since I sometimes spend a decent amount of time by the TV in the evenings (I've even noticed that I'm avoiding the TV since it doesn't get tracked...).

Found this on SO which seems to indicate UsageStatsManager isn't available on Android TV. After thinking about it that kind of makes sense, as there's likely a lot of active screentime that isn't actually active time, or usage (let's say I let it sit on the home screen, or Spotify being playing/paused for a long time).

Still, I would like some type of tracking of it, just not sure how. Until then I'll have to track the play history in the apps themselves (aw-watcher-spotify, LastFM, YouTube history, Plex + Trakt).

Please update your icon on the Google Play Market in accordance with the new specifications. What is wrong with your icon is written in the paragraph Brand adaptation: "If possible, pick a background color for your asset that's appropriate for your brand and doesn't include any transparency. Transparent assets will display the background color of Google Play UI".

Dropping some links so I don't lose them.

• https://mozilla.github.io/firefox-browser-architecture/experiments/2017-09-21-rust-on-android.html
• https://www.reddit.com/r/rust/comments/93g8uc/is_it_possible_to_write_an_android_app_using_rust/
• https://github.com/Dushistov/rust_swig/tree/master/android-example

It should be possible. Would complicate the toolchain and dependency a fair bit but definitely worth a shot.

Guide: https://gitlab.com/fdroid/fdroiddata/blob/master/CONTRIBUTING.md

When you open the Web UI and rotate the screen, a text overlay from the Home screen appears.
v. 0.4.9.

As discussed on the forum the aw-server-rust version in the android app is an older version in which a bug prevents the use of queries. A simple query like this

events = query_bucket(find_bucket("aw-watcher-android-test"));
RETURN = events;

results in a parsing error

ParsingError("(Some((Semi, Span { lo: 80, hi: 81, line: 3 })), \"expectedBool,Ident,If,LBrace,LBracket,LParen,Number,RBrace,Return,String, or end of file\")")

Is the database saved as a sqlite file somewhere on the device I could get access to? I'm looking for a way to automatically backup my usage data from my phone without having to manually use the export feature. I have another app that lets me sync specific directories on my phone to the cloud; I'd like to feed it the AW data directory.

Does this make sense or is there a better way to achieve what I'm looking for?

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

Not sure what's the cause of this, but it seems like aw-server-rust is panicking.

Only happens on real arm64 devices, not in my x86 emulator.

Also only seems to happen after the first sync.

Things I never completed in #3

To reproduce.

1. Start in default portrait orientation
2. Go to timeline.
3. Switch to horizontal orientation

Results: view is restarted to the default activity view.
Expectations: screen is rotated, and I'm still in the timeline

Looking online, the fix seems pretty straighforward, either adding a line in the manifest file android:configChanges="orientation|screenSize"link or saving the instance in the activity lifecycle

• Lineage-OS 16 on a OnePlus 5
• AW-Android v0.4.6

The first time I hit the "log" button it sent me off to grant permissions (which I did).

The second and all subsequent times it does nothing. In the "buckets" panel I only ever have a single entry dated the first launch of the app.

P.S. Really looking forward to this. I've tried a number of proprietary systems but they are so invasive I eventually gave up trusting them with my computer, phone, and web browser usage. There does not seem to be any open source solution that covers all three areas that I can trust, and cobbling something together from different solutions for each platform was too much trouble and I gave it up. I'll be happy to have this working eventually!

Currently the app has 2 hamburger menus (one from web-ui, the other one specifically for Android) which leads to very confusing UX.

I'm not sure what the purpose of the Android menu is, since the aw-webui menu already contains all of the information, so an easy fix might be to just remove the Android one.

Any UI customizations that the android menu has, can be done directly on the web-ui with a media query that only executes for certain screen widths(i.e mobile).

@media only screen and (max-width: 768px) {

    #hamburger-menu {
        position: sticky;
        top: 0;
    }

}

Data doesn't seem to be logged correctly right now, I'm probably not handling the UsageEvents correctly.

Looks like with the last version, APK size increased by factor 6 – due to the libaw_server.so having increased by factor 18 (from around 5M to 90M). As that exceeds the limits in my repo by factor 3 (max space per app is 30M), I had to remove v0.10 and disable auto-update.

Is there any chance to decrease APK-Size again? I don't know if whatever blew up that library could be reverted – but e.g. an armeabi-v7 only build would just fit in 30M. Should none of the two be possible, I guess it's best to remove ActivityWatch from my repo, as providing an outdated version is not a good idea.

The following are not classified as UI apps, but could still give important information to track:

• Music, Podcasts, audio books, etc.

I think they're foreground services and could just be sent to a foreground bucket.

It seems it doesn't work for me(Honor 9x).
The app is allowed to see my log history, but I still see

I am not an android dev, please, show me the way how I could debug it or collect needed logs.

It seems to not log calls if your display is off (speakerphone worked).