I installed the CWA at the day of availability and opened it every day.
The counter how many days I use it correctly increased each day.
On Monday (29.6.), I correctly reached "13 of 14".
On Tuesday (30.6.), I stayed at "13 of 14".
And today (1.7.), it still shows the same.
14 of 14 days.
In the iOS world, similar issues were reported (https://github.com/corona-warn-app/cwa-app-ios/issues/804, https://github.com/corona-warn-app/cwa-app-ios/issues/815).
Honor 10, Android 10
I have the same issue
Same issue on BQ Aquaris X with Android 8.1.

We can replicate and are investigating the issue.
I'm also experiencing this on a OnePlus 7 Pro running OxygenOS 10 (Android 10)
First off, your risk score calculation is NOT affected, this is only a display behaviour due to the Inactive Tracing Intervals reducing the tracing time and being rounded down.
Hi all,
We identified the issue that is causing the confusion.
The problem is that tracing was disabled for more than 1 millisecond in the retention period (the last 14 days).
In our current implementation we sum up the inactive tracing milliseconds in the last 14 days and subtract it from the 14 day time window.
Here is an example:
Day | Hours of tracing | 聽
-- | -- | --
1 | 24 | 聽
2 | 24 | 聽
3 | 24 | 聽
4 | 24 | 聽
5 | 24 | 聽
6 | 24 | 聽
7 | 24 | 聽
8 | 24 | 聽
9 | 24 | 聽
10 | 20 | 聽
11 | 24 | 聽
12 | 24 | 聽
13 | 24 | 聽
14 | 24 | 聽
15 | 24 | 聽
16 | 24 | 聽
17 | 24 | 聽
聽 | 332 | 13,8333333
聽 | Hours of tracing in the last 14 days | 聽Number of days
Because on day 10 tracing was disabled for 4 hours the total sum of traced hours is only 332 which means 13.833 days -> this will get rounded to 13 days.
So in fact the calculation is correct (you only traced 13.8 days in the last 14 days) and therefore it will only show the the 13 days. But the label is somewhat misleading of the actual meaning and it is not clear what you have to do in order to get the 14 out of 14 days.
In order to get 14 out of 14 days you would have to wait until day 10 is out of the retention period and do not disable tracing for any number of ms in the upcoming 14 days.
We are currently looking into possible changes in order to address this.
My suggestion would be to consider a "day" (counted from midnight to midnight according to the local device time) as "traced" when it has at least one period of active tracing (irrespective of how long it was). Only then the terminology of "days" makes sense.
If you however really want to make visible the distinction between "tracing on" and "tracing off" in this status, you could switch to a "%" notion.
Thanks for your suggestion. However, with this in mind, then even 10 minutes of active tracing would count as an active day, which is obviously also counter-intuitive. There are multiple possibilities in mind so we would ask for some patience until we have decided on the way forward. We will update here once we have progress to report.
@pwoessner Using your example https://github.com/corona-warn-app/cwa-app-android/issues/796#issuecomment-652381709, taking the first 10 days from your example:
10 days of tracing overall
9 days of 24 hours + 1 day of 20 hours = 236 hours
number of days active = 236 hours / (24 hours/day) = 9.83 days --> rounded to 9 days
So this would mean that in your example already on the 10th day after installation, when it should show 10 of 14 days active the app would actually show 9 of 14 days active. So this would get noticed directly on the day after missing some tracing time if the app is opened every day.
:arrow_right: That means if we all specifically start noticing a wrong 13 of 14 days active that we all missed that chunk of tracing time on the 13th day after installation (day 14 if counting the day of installation as day 1). So that on the 14th day after installation we all see the missing increment in days. Wouldn't that be a big coincidence?
Also how do these points fit into the picture?
I installed CWA in the afternoon on 16 June 2020. That means already on 17 June internally I didn't have a full day in the morning opening the app. Days active is displayed for the first time after 3 days, so latest then I should have seen a day missing, but on 20 June in the morning I saw 4 of 14 days active for the 4 days of 16th to 19th June. I saw days active steadily increase until it reached 13 of 14 days active on 29 June 2020 as expected. It did for the first time not increment on 30 June 2020 (possibly prevented by #788) and is since then stuck at 13 of 14 days active.
:arrow_right: Why doesn't the day of installation cause rounding down of the number of days?
I also switched tracing off and on in CWA for testing purposes a couple of times long before 30 June 2020, and still I saw days active incrementing steadily and as expected until the 30 June 2020 came.
:arrow_right: Why was there no rounding down of days before 30 June?
Hi @aurisnoctis ,
the days will indeed be incremented just with a delay of the time the tracing was disabled. Example:
Next day (02.06.):
I don't think that this will be clearly visible to the user that the counter gets delayed by the amount of time the tracing was disabled (especially if the disabled tracing time were just a few minutes). But if you are unable to get the full 14 out of 14 days this will stand out to more users.
I cannot fully deny/confirm the behaviour that you had on your app because I don't think you can give me accurate times when you installed, activated/deactivated tracing and at which point in time the count switched the number of days.
But I was able to reproduce the behaviour I described above on a device with changing the time on the device (not recommended on a private/prod device).
Every night between about 0:00 and 8:00, I shut down my phone completely (Power Off). During this time, there is obviously also no tracing. According to the calculations above, I should have never reached "13 days" until now, but should be in the area of 9 days.
Obviously, in the calculation above, the status "tracing off" does not count this state, which makes the attempt to use this time for the final UX representation even more confusing.
One more remark: In the Google Play Store reviews from yesterday, I found some more users with exactly this "13 of 14". None with other numbers than "13". This is also not understandable then.
I am still stuck at 13 of 14 days active as of today, with the Google API(20) #788 and Google API(10) #737 errors alternating until the Google API(39508) timeout error makes an end to that for the day. It should have been 14 of 14 days active starting on 30 June 2020.
I had a steadily increasing number of days active starting on the day after CWA installation (17 June 2020) to the day it first and correctly showed 13 of 14 days active on 29 June 2020. On 30 June 2020, the days the Google API(20) error started, it didn't increase for the first time.
Update: To clarify: I switched tracing off and on in the CWA settings during the first days after installation and never saw a number of days active below what I expected before 30 Jun 2020.
@jkrwdf Unfortunately we can only track the tracing duration when the tracing state is changed inside of the CWA app. So we are unable to record the deactivated tracing time when you turn off the phone because the app does not get the event. This is the same for disabling the tracing in the OS settings (we do not get an event that you deactivated tracing and therefore the app thinks you are still tracing).
@aurisnoctis
You are stuck at 13 out of 14 days active because as you mentioned in https://github.com/corona-warn-app/cwa-app-android/issues/796#issuecomment-652502040 you have deactivated tracing multiple times for more than 1 ms. This causes the calculation to have a sum of 13.X days of active tracing which will be round to 13 days (described here: https://github.com/corona-warn-app/cwa-app-android/issues/796#issuecomment-652381709)
Days are incrementing to the 13 days because of the behaviour I described in https://github.com/corona-warn-app/cwa-app-android/issues/796#issuecomment-652807750
The increment will just be delayed by the amount of the deactivated tracing time but nevertheless the tracing time will be incremented.
I think the most important thing to understand is that we do not track if you had tracing on/off for x hours on a certain day. But instead we only track the amount of time that you have deactivated tracing (as long as you deactivate it directly in the CWA app). And then we take the time of active tracing (max. 14 days) and subtract the inactive time. That way we get an amount of hours which we will convert into days.
@pwoessner It only appeared on day 14 after installing CWA. The missing time (rounding down effect) never showed before. As explained in comment https://github.com/corona-warn-app/cwa-app-android/issues/796#issuecomment-652502040:
That means if we all specifically start noticing a wrong 13 of 14 days active that we all missed that chunk of tracing time on the 13th day after installation (day 14 if counting the day of installation as day 1). So that on the 14th day after installation we all see the missing increment in days. Wouldn't that be a big coincidence?
I deactived tracing via CWA settings sometimes for brief periods of time starting on the day of installation. So I should have noticed days active to be missing a day during those other 13 days after installation, but this was not the case. The first time days active seemed to be stuck / rounded down was on 30 June when it showed 13 of 14 days active but should have been 14 of 14 days active. Before that - even though I disabled tracing before for some minutes at a time - there was no rounding down.
@aurisnoctis yes because you were not able to recognise the rounding down effect because the time of initial tracing activation was shorter than the retention period (14 days). In that case the only thing that is happening is that the days are increased with a delay of the deactivated time as explained in https://github.com/corona-warn-app/cwa-app-android/issues/796#issuecomment-652807750.
Until the moment when you do exceed the retention period (initial tracing started more than 14 days ago) you will not see the rounding down effect but the delay effect (the increment of the day is delayed).
Only when you hit that point in time when the initial tracing activation was more than 14 days ago the rounding down effect will appear because there is no longer an increment of the active tracing time but this time is static (retention period = 14 days). An then every ms that you had deactivated tracing during that retention period will get subtracted from the 14 days and you will see the rounding effect.
Here is an example:
Calculated Tracing time after installation (still in retention period)
Day | Hours of tracing | 聽
-- | -- | --
1 | 20 | 聽
2 | 2 |
聽 | 22 | 0,9166666667
聽 | Hours of tracing in the last 14 days | Number of days
--> App will display 0 out of 14 days
Day | Hours of tracing | 聽
-- | -- | --
1 | 20 | 聽
2 | 4 |
聽 | 24 | 1
聽 | Hours of tracing in the last 14 days | Number of days
--> App will display 1 out of 14 days
Instead of switching to 1 out of 14 days at midnight of the first day the switch to 1 out of 14 days gets delayed by the missing hours of day 1. This means the switch to 1 out of 14 days occurs at 4am on day 2.
Day | Hours of tracing | 聽
-- | -- | --
1 | 20 | 聽
2 | 24 |
聽 | 44 | 1,8333333333
聽 | Hours of tracing in the last 14 days | Number of days
--> App will display 1 out of 14 days
Day | Hours of tracing | 聽
-- | -- | --
1 | 20 | 聽
2 | 24 | 聽
3 | 24 | 聽
4 | 24 | 聽
5 | 24 | 聽
6 | 24 | 聽
7 | 24 | 聽
8 | 24 | 聽
9 | 24 | 聽
10 | 24 | 聽
11 | 24 | 聽
12 | 24 | 聽
13 | 24 | 聽
聽 | 308 | 12,8333333333
聽 | Hours of tracing in the last 14 days | Number of days
--> App will display 12 out of 14 days
Day | Hours of tracing | 聽
-- | -- | --
1 | 20 | 聽ignored because it is not in the retention period
2 | 24 | 聽
3 | 24 | 聽
4 | 24 | 聽
5 | 24 | 聽
6 | 24 | 聽
7 | 24 | 聽
8 | 24 | 聽
9 | 24 | 聽
10 | 24 | 聽
11 | 24 | 聽
12 | 24 | 聽
13 | 24 | 聽
14 | 24 | 聽
15 | 24 | 聽
聽 | 336 | 14
聽 | Hours of tracing in the last 14 days | Number of days
--> App will display 14 out of 14 days
FYI: with the change implemented this behaviour will change and as soon as you have _X_,5 days of tracing it will be displayed as one day. As a result if your tracing was deactivated for less than 12 hours in the last 14 days you will see the 14 out of 14 days.
@pwoessner Thanks, also for taking the time to explain it so well, much appreciated :+1:
I do not have screenshots to prove it, but I do have the following: firstInstallTime=2020-06-16 11:19:14 via adb and you have my word that I opened the app for instance on 25 June between 8 and 9 in the morning and saw a 9 days active, i.e. when it should have been only 8 according to your explanation: only 8 days plus less than 24 hours had passed since installation plus I had briefly inactivated the tracing during the first days, which further reduces the time tracing was active. With some exceptions I generally open the app between 8 and 9 for the first time on a given day, and in fact on any given day it showed the expected increase of a full day with respect to the day before until it did not switch from 13 to 14 on 30 Jun 2020. Again: in my case it should have been rounded down before according to your well-done explanation.
I am nonetheless looking forward to the new app version! Thanks again for taking time and being clear about the concepts!
The issue still exists in iOS!
I have updated the app days ago and it still shows 13 of 14 days.
Maybe this issue should be reopened?
The issue still exists in iOS!
Yes, that's why https://github.com/corona-warn-app/cwa-app-ios/issues/804 is still open...
Someone reported in a duplicate issue that the 13/14 issue is now fixed for their device https://github.com/corona-warn-app/cwa-app-android/issues/808#issuecomment-656173043
Issue is fixed in newest version. :+1:
(I can't confirm yet. After installing CWA 1.0.5 yesterday, the error mentioned in #737 continued blocking the risk update yesterday and today.)
The observation which I reported in this issue is not repeat not fixed with the current version 1.0.5
According to how the algorithm has been explained by the developers I assume that for the person who reported it being fixed the day where tracing was switched off for short time has moved out of the 14 day period.
Most helpful comment
Hi all,
We identified the issue that is causing the confusion.
The problem is that tracing was disabled for more than 1 millisecond in the retention period (the last 14 days).
In our current implementation we sum up the inactive tracing milliseconds in the last 14 days and subtract it from the 14 day time window.
Here is an example:
Day | Hours of tracing | 聽
-- | -- | --
1 | 24 | 聽
2 | 24 | 聽
3 | 24 | 聽
4 | 24 | 聽
5 | 24 | 聽
6 | 24 | 聽
7 | 24 | 聽
8 | 24 | 聽
9 | 24 | 聽
10 | 20 | 聽
11 | 24 | 聽
12 | 24 | 聽
13 | 24 | 聽
14 | 24 | 聽
15 | 24 | 聽
16 | 24 | 聽
17 | 24 | 聽
聽 | 332 | 13,8333333
聽 | Hours of tracing in the last 14 days | 聽Number of days
Because on day 10 tracing was disabled for 4 hours the total sum of traced hours is only 332 which means 13.833 days -> this will get rounded to 13 days.
So in fact the calculation is correct (you only traced 13.8 days in the last 14 days) and therefore it will only show the the 13 days. But the label is somewhat misleading of the actual meaning and it is not clear what you have to do in order to get the 14 out of 14 days.
In order to get 14 out of 14 days you would have to wait until day 10 is out of the retention period and do not disable tracing for any number of ms in the upcoming 14 days.
We are currently looking into possible changes in order to address this.