-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Events not stored correctly (and therefore not reported correctly either) #39
Comments
Very nicely investigated! One question I have is do we really need to consider the Here I've printed the event types in order:
From this small sample, it seems that 2 ( I also noticed that sometimes there are events with type 1 or 2 in succession, which was unexpected to me. Lets do some further investigation, but include timestamps:
Here we have one case of a 16 being triggered without an immediately following 2, possibly due to a quick lock/unlock. |
Here are some logs with more info:
It seems to me like we can drop the 15 and 16 events. But it looks like that won't solve the issue entirely as there can still be consecutive 1 and 2 events, maybe that's non-problematic though. |
Storing the varying |
@ErikBjare seems like in my excitement I missed the obvious choice :)) I think ignoring Regarding Regarding your logs: They're really surprising to me, because we get events in very different orders (I'm on Android 9, on a OnePlus 3). In my logs, consecutive events are almost always in the form 1-2, which makes a lot of sense to me, since you will stop an existing activity(event 2) before you start a new one(event 1). If I launch ActivityWatch, then launch Chrome. I'll get Your events seem to be in an order which will actually avoid merging, and report both ActivityWatch and Chrome with time 0 |
A couple of other follow-up notes: With the PR applied, AW reports durations with exact or very similar accuracy to SmarterTime and ActionDash, so it seems like ignoring There are a couple of instances when the time still varies (now by a lot less) by at most a couple of minutes in my tests, where AW underestimates some durations compared to other apps |
Fixed in #40, some small discrepancies might still exist but should be good enough for now. |
It seems like I still have some significant discrepancies, so we probably need to to do something about the consecutive 1 and 2 events. |
@ErikBjare do the discrepancies you experience occur consistently, or
have you noticed that around some specific actions? I haven't noticed
anything wrong on my reports. Wondering if this is a difference due to
different Android versions
…On Mon, Aug 17, 2020 at 08:17, Erik Bjäreholt ***@***.***> wrote:
Reopened #39 <#39>.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJMED6AFHM5PH5FVLW2THQDSBFCZPANCNFSM4N5P2ERA>.
|
@nicolae-stroncea I think it's due to the out-of-order events, but not sure. I still have a lot of 0-duration events and unexpected gaps in the timeline. |
@brayo-pip will investigate this. |
Has there been any progress on this issue? I run into this issue as well, with a lot of apps showing "0.0" as duration in the JSON export, while I know I have used them longer. Other activity apps are able to show them correctly on my Pixel 7. I'm a java backend dev normally, so it's a bit hard for me to help out in an Android/kt environment. |
@EvertJanDeBruin I'm just getting around to this. Will have a fix or at least determine the cause of this soon. Will update the issue when I do. |
@brayo-pip Have you determined the cause of the issue? I am happy to help, but when I try to build & run the app from Android Studio, after having included the rust library, the app crashes. Logcat shows the following:
And further in the stacktrace it turns out the call to RustInterface.setDataDir() causes the crash. Any idea what might be wrong? |
I ran into the same issues. The best workaround I have at the moment is using the github actions for all the build process. Then testing the app locally. Also I hope you have joined the discord. |
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 amove_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
andscreen_non_interactive
. Whenever you're in an application, and the screen goes to sleep, or you lock the screen, thescreen_non_interactive
event shoots first, only then followed by amove_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 amove_to_foreground
when you start Firefox, you spend 20 minutes, and then lock the screen. Android sends ascreen_non_interactive
, then amove_to_background
. As a result both Firefox events have duration 0 instead of 20 minutes.Here's an example:
Look at the timestamps of
Firefox
andAndroid System
for confirmation:2020-06-14T00:00:45.523Z
and2020-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 minutesThis 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
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 isscreen_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, processscreen_non_interactive
. Everything else should be the sameTo 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
The text was updated successfully, but these errors were encountered: