text:
Calculate and display confidence for risk scoring

Feature description
The risk assessment displayed in the app should be accompanied by a confidence scoring based on the amount of corona-warn-app users in the vicinity of the user. If that is not possible, remove "Low Risk" altogether, because it cannot be confidently stated.
If possible, include a mechanism to discern the likelihood of few or many corona-warn-app-contacts to inform this risk score. Compare the corona-warn-app contacts to the absolute number of contacts had by the device. This could be time- or distance-based, as is the main function.

Problem and motivation
The main screen of the app shows a large green "Low Risk" icon. However, display of "Low Risk" is possible in spite of massive contact with Covid-positive individuals, simply if these individuals do not use the app themselves. Showing a low risk to a user who has been in a crowd, of which only few others have used the app, results in overconfidence regarding the low risk, particularly in statistically naive users, and thus to potentially harmful underestimations of one's own infection risk.
If the logging cannot be adjusted to represent a credibility scoring of the low risk, the display of "Low Risk" should be removed altogether, and the app should unambiguously state that it is only valuable in tracking positive contacts and cannot inform about low risk.

Is this something you're interested in working on
I don't have the required mobile technology skills.

Internal Tracking ID: EXPOSUREAPP-2077

For privacy reasons the app is designed in such a way that it cannot know how many (non-positive) contacts you had with other ppl even if they use CWA: https://github.com/corona-warn-app/cwa-wishlist/issues/124#issuecomment-660121125
Regarding the "low risk/green" status: There is some improvement planned at least for those cases where a a "green" risk-contact happened:

https://github.com/corona-warn-app/cwa-backlog/issues/23
https://github.com/corona-warn-app/cwa-wishlist/issues/100

One idea which is currently being discussed is to introduce a "yellow" risk status for such cases: https://github.com/corona-warn-app/cwa-app-android/issues/899#issuecomment-663475550

thank you, daniel
i gather from your answer that the functionality required to infer absence of risk contact or a confidence measure cannot be implemented due to the underlying technology. is that correct?
if so, as referred to in the discussions you mentioned, i think it is not clear to many naïve users that the app is only designed to track positive contacts, and not to infer the inverse, absence of infection risk. i therefore think that the display of "low risk", and particularly on a large green panel, is not warranted by the app's actual functionality.
it would be strongly advised to let this be reflected in the design of the user interface, such that the average user understands that the app can only inform about risk contacts, not about the absence of risk contacts. please consider passing this on to the epidemiologic/public health personnel in your team.

i gather from your answer that the functionality required to infer absence of risk contact or a confidence measure cannot be implemented due to the underlying technology. is that correct?

That is correct. But strictly speaking it's not just a technological limitation: in order to reliably infer absence of risk you would need 100% CWA uptake in the population, 100% compliance with uploading positive keys in case of infection as well as 100% test coverage for all infections.
This is o/c not possible, even if there were no technological barriers at all (which exist for a privacy reasons).
Btw: if you want to get the maximal information possible out of the Exposure Notification Framework (ENF), even bypassing the restriction that you cannot count non-positive RPIs, and you have a rooted device, you might want to check out @mh-'s corona-warn-companion-android 🙂.

i don't really agree on that logic. for computation of a confidence metric you do not need 100% coverage in any of these categories. in fact, if you knew the coverage (as explained in my initial post), you could already infer a lot on the confidence of the risk score. similarly, if you knew the percentage of contacts met that actually do have the app installed, you could say a lot about the confidence of the "low risk" score displayed.
confidence in a statistical sense is always an estimation, a way of saying how much you can trust the result. based on what you have said, the average corona warn app user cannot put any trust in a display of "low risk", and that is why i think the displayed message needs to be changed to something that enables the average user to understand this.
the app does only inform about positive contacts in cases where this happens (and the positively tested user also enters his data into the app), and cannot confidently state a measure of "safety" based on the absence of such contacts.

Yes, in principle you could make a stochastic model which tries to estimate risk by incorporating more data. I don't think this is easy though even if you had information on the number of contacts with the app: what if you have high regional heterogeneity in app uptake? Does the fact that you only encounter few other CWAs now indicate that you're more save? What if you have cross-correlation of app uptake with other behavioral markers like compliance with hygiene rules etc…?
I'm not saying it's impossible, I would just need to see a proper reasoned quantitative analysis on how much more confidence could actually be gained that way to be convinced.
But that's anyway more of a academic debate at this point, as the number of contacts is not available in the first place ^^.

Let me quickly jump in to explain a few but important decisions:
(a) To simplify the usage of the app, from the very beginning the decision was made: There are two colors - green (low risk), red (significant risk).
(b) Every now and then the proposals for introduction of a third color (yellow or light green) come up, but the initial decision stays, at least for now.
(c) As much as I understand the intention of the abstract "confidence" scoring idea, neither incorporation of the number of persons (with or without app), nor incorporation of the "absence" of risk contacts would end this discussion, sorry. "Confidence" is somewhat psychological and based on thresholds, believe, trust, and experience. You could introduce a bunch of other factors that may have influence to this risk level calculation (think about the aerosol discussion, the epidemiological impact of age or medical preconditions...) How do you know, the "confidence score" itself would not be questioned by the users?
(d) You may have reviewed the documentation already, including the sample paper with the math model risk calculation (), where the risk calculation is based on - mainly on two factors: distance and time, with some adjustable parameters. Even the current calculation is way too technical and rational for the "average end user" - that's why the decision (a) was made: To translate the calculated risk into colors.
(e) And yes, I am aware that still with theses two colors there are questions: 1 risk contact, still green? We constantly try to discuss the UI and the "wording" - the phrases regarding "low risk" are currently under investigation and will be tuned.

I would agree with the assumptions that it is not possible to determine any reasonable confidence (-score) for the "green overall low risk" statement for the shared reasons.
It is even worse. There isn´t any proof that the recorded close+long encounters were not with any infected person. (person doesn´t know about infection, not yet tested, decided not to share positive result with app, ...) This is all shown as "green low risk".
From that the alternative proposed by slobentanzer should be adopted: remove the green/low risk statement. Make it simply a "green status" and explain that status accordingly.

let me put it bluntly: it is clear that the app cannot inform about low risk, only about high risk. thus, the phrase "low risk" and all related content should be removed, otherwise you are displaying nonfactual information.
the decision to make it "green and red" was wrong in the first place, and probably made by people who don't know about the technical implications of the actual tracking. if any, it should be "grey and red," if you need a colour coding, to visualise "not enough information vs actual risk." maybe you can consider this stance in your constant discussion of the UI.

I just wanted to add my opinion to this:
It is (imho) ok that the App shows "Low-Risk" because it does say "LOW-Risk" and not "No-Risk", so the App says there is a Risk but it is Low.
That the App only knows what it knows should be made clearer but in these new Texts, shared by @abro1i the App says:

[...]Ihr Infektionsrisiko wird unter Berücksichtigung aller in der Corona-Warn-App vorliegenden Daten dennoch als niedrig eingestuft.[...]

I think this is better than before and

Okay, I Think I understand all your ideas so far. Just let my please clarify:
From the development perspective we are open to your ideas, proposals and the expected concerns and impact. Those thought we definitely consolidate and discuss  with the client. Still, the clear decision so far is:

There will be a color code green (calculated low risk)/red (calculated potential risk).
There will be a kind of wording explaining what the user shall understand with the status text.
This wording is constantly under review.

Thanks for taking it up, GisoSchroederSAP.
Slobentanzer is right, outside the "red status" the app has NO CLUE about any risk. And so that shall be removed.
I found it quite annoying that it required me to exchange a few mails with the RKI-hotline to get it confirmed that "Risiko-Begegnung mit niedrigem Risiko" is no risk at all. RKI even referred me to the Tagesschau-article, which exists as the app fails to provide a decent description. So Ein-Tim, the FAQ is correct. That encounter is no-risk (harmless/unbedenklich), and this is not not compliant with a "low risk statement". For just traced close/long encounters without any related diagnosis key (yet) it is not known whether a it´s a risk or not until a diagnosis key is shared for it. So nothing is known. And so there is also nothing known about any overall risk.
I understand slobentanzers argument. A gray screen is however a bit tricky as it is also used for telling the user that he didn´t behaved well and has no/not enough tracing yet. Formally slobentanzer is right, in both current cases (green&gray) the app has no clue about the user´s real overall risk. Only the red status/risk/screen can be determined as an increased/higher risk (with confidence) by having one or more real-risk-encounters with persons that shared a positive test result.
This issue I brought up alraedy under "backlog #23" where somebody described "App says: "1 Risiko-Begegnung" but the screen says "Niedriges Risiko". I didnt find information, what this exactly means".
As there is more under backlog # 23 it will in best case only result in correcting "Risiko-Begegnung" to "Begegnung".
And I hope the issue of the "overall low risk statement" can be solved here under # 110.
I repeat here what I proposed under https://github.com/corona-warn-app/cwa-documentation/issues/416 (this 416 is a spin-off from backlog# 23). The proposal is:
On the green main screen "n Risikobegegnungen mit niedrigem Risiko" should be changed to "n unbedenkliche Begegnungen" in line with the FAQ.
Further on the green main screen there shouldn´t be any risk statement. So "Niedriges Risiko" should be changed to "Status grün". (or whatever color is preferred)
The klick on the related main screen link should explain the "Status grün" as:
"Ihr Status ist grün da bisher alle aufgezeichneten Begegnungen als unbedenklich erachtet werden.
Etwaig angezeigte "unbedenkliche Begegnungen" sind Begegnungen mit einer positiv getesteten Person. Diese Begegnungen waren jedoch nur kurz oder mit größerem Abstand und sind daher unbedenklich.
Es kann jedoch nicht ausgeschlossen werden, daß ein Infektionsrisiko bestand, da z.B. nicht jeder die CWA benutzt.
Daher sollten sie in jedem Falle die Hygieneregeln befolgen. Auflistung derer."
From the discussion/exchanges so far I got the impression that the RKI sets the criteria for what is considered a "risk" and not neccessarily the developers. From that it might be most fruitful you discuss it with them.

@mf179

I found it quite annoying that it required me to exchange a few mails with the RKI-hotline to get it confirmed that "Risiko-Begegnung mit niedrigem Risiko" is no risk at all.

I don't really think thats true. I'm very confused now, @tkowark, @mtb77,  @svengabr could you pleas make this clearer?

Slobentanzer is right, outside the "red status" the app has NO CLUE about any risk. And so that shall be removed.

But why you want then to show "NO-Risk"/"unbedenklich" for a "Low-Risk" Exposure?

So Ein-Tim, the FAQ is correct. That encounter is no-risk (harmless/unbedenklich), and this is not not compliant with a "low risk statement".

If you reffer to this Issue,  by @daimpi, the discussion there is about the "Verworfen" terminology.

I repeat here what I proposed under https://github.com/corona-warn-app/cwa-documentation/issues/416 (this 416 is a spin-off from backlog# 23). The proposal is:
On the green main screen "n Risikobegegnungen mit niedrigem Risiko" should be changed to "n unbedenkliche Begegnungen" in line with the FAQ.

See the first sentence.

Ok Ein-Tim, for the very specific "Risikobegegnung mit  niedrigem Risiko" the risk is known as harmless. It is a bit confusing as the "overall risk" has no term. I meant no clue about the overall risk.
One solution is to show now "harmless encounters". As stated somewhere else, I think it is good for demonstrating that the app works (finds [harmless] contacts with positiv tested) and perhaps raises awareness. But it doesn´t bring anything for the apps main or even sole function: "breaking the infection chain".
I don´t get what you mean with the reference to the "verworfen issue". To me the wording is just ambigous. It is meant as "the low/no-risk encounters are shown to the user (just for info) and are considered as harmless (not discarded) during the overall risk assessment.

I personally think the green background with the "low risk" statement is fine in case of no encounters.
@mf179

One solution is to show no "harmless encounters"

I disagree with this as I've explained here.

On the green main screen "n Risikobegegnungen mit niedrigem Risiko" should be changed to "n unbedenkliche Begegnungen" in line with the FAQ.

Just changing the term "exposure" to "encounter" like shown in this preview is sufficient imo.
@Ein-Tim regarding your questions whether green encounters actually carry "no risk": in the real world they o/c carry some risk as we have e.g. aerosolized spread and problems with the distance-attenuation mapping of BLE signals (cf.  here and here).
But we could construct an ordering of risk levels vis-a-vis the different possible displays in CWA:

Green (low risk) with no encounters
Green (low risk) with some encounters
Red (increased risk) with some encounters

In this ordering 1. represents the lowest, 2. a higher, and 3. the highest risk level ceteris paribus.

What is an encounter, daimpi? With a positive tested person?
Your 1. Green would then rather mean: no (yet) known encounter with a positive person. Or ? If you don´t get a diagnosis key for a close+long encounter you cannot know whether the encounter is a risk or not. So for 1. you cannot describe any overall risk.
2 includes the same yet unclassified encounters besides those identified as "low/no risk encounter".
In my understanding the target is to avoid false alarms, i.e. a clear distinction between red (be concerned, take actions) and green (be not concerned, don´t overreact). And the differentiation is determined by some parameter setting. Stating about a "low risk" is counterintuitive and counterproductive. It confuses/scares the user. And the "green/low risk" can still not exclude that there was a high risk in reality, which is the main deficiency here.
Seems we are moving in circles.

What is an encounter, daimpi? With a positive tested person?

Yes. The German term is "Begegnung" as you can see in the preview linked above.

Your 1. Green would then rather mean: no (yet) known encounter with a positive person. Or ? If you don´t get a diagnosis key for a close+long encounter you cannot know whether the encounter is a risk or not. So for 1. you cannot describe any overall risk.

Nope. I was intentionally speaking about an ordering of risk levels which is about relative risk and stating that those comparisons are ceteris paribus. So I think my original statement is correct.

In my understanding the target is to avoid false alarms, i.e. a clear distinction between red (be concerned, take actions) and green (be not concerned, don´t overreact). And the differentiation is determined by some parameter setting.

As I've stated above: there are good reasons (e.g. ~50% recall in Fraunhofer IIS testing) to doubt that making such a confident and sharp binary distinction is reasonable.
Also: such a determination profits immensely from additional information that only the user possesses (e.g. it makes a massive difference whether I was mainly outside, or stuck in a crammed room the day of the encounter), which is why I'm pushing to give more info to the user also in case of green encounters.

Stating about a "low risk" is counterintuitive and counterproductive. It confuses/scares the user. And the "green/low risk" can still not exclude that there was a high risk in reality, which is the main deficiency here.

Why do you think this is the case? For me the green "low risk" status is not per se confusing. Do you think some better communication on how the app works would alleviate your concerns?

Let´s take an example.
Persons A and B watch a movie every day, sitting next/close to each other. A gets Covid19, tested postive, but doesn´t share it with the app. What entitels the CWA of B to claim: "you have [just] a low [overall] risk"?
This is a warn app, as the name says. It knows just two states, warning and no-warning. And as such it should be communicated.
color/status gray - not fully operational yet
color/status red - based on the available information it is decided to issue a warning
color/status white - the available information doesn´t cause any warning, but an infection risk cannot be excluded
(white seems to represent the situation best - not enough info [for a warning])
If all or some "low/no risk encounters" are wanted to result in a warning/red, the decision threshold would be modified accordingly.

@mf179
Now I start to really understand your point.
I think it is not necessary to introduce new colors/etc. (And tbh I don't think the RKI will do that)
Just an disclaimer what makes 100% clear that the App just knows what it knows would be good, but I think most of the User already known this...

Green should be changed to white as the green/low-risk lulls the user into a false sense of security. The user needs to be made aware that he should not ignore any symptoms just as the app declares everything is fine "green / low-risk".
And the "green low-risk-encounters" should also not be denoted as risky. Those fall under "white".
The app is made for automating the tracing of infections / breaking the chain and thereby offloading the health authorities, who do that manually. I called it counter-productive as current ambiguous risk statements create load for the health authorities.
I don´t think that an average user can know what the various "green risk statements" mean. I would accept that the people here know it, but those are not average users. Thinking to have some clue about what the app does, I also contacted authorities to know what I shall do with the "low-risk-encounter".

@mf179 ok - so as @Ein-Tim mentioned, I guess now we understood your point, so its mostly about the green color code, you'll never know if you might have a risk, so the app should not weighting you in false security - right?
Sascha
Corona-Warn-App Open Source Team

@mf179 As I stated above: I don't think that the "low risk status" and the green color code "lulls the user into a false sense of security" if there have been no encounters. And the new description of green encounters also explains them nicely, as it clearly states no further actions need to be taken by the user.
I very much disagree with the idea of hiding encounters from the user, unless there is an "expert mode" where this data can be accessed if required.
Something I can get behind is general improved communication on how the app works, so that there is no confusion for average users what the app can and cannot do 🙂.

Yes, Sascha, this about the color green.
But it is also the text that comes for explanation, when clicking on the link for the "green low risk".
It explains: "sie haben ein niedriges Infektionsrisiko, da ..."
So green color and "low [overall] risk" as well as the explanation of what that "green risk" is need to be reconsidered.
I suggest change green to white and explain the "white status" as the app hasn´t determined any warning based on its available data. An infection risk can however not be excluded and so the user should in any case follow the usual (AHA) guidance and not ignore any symptoms.
Daimpi, I have nothing againts showing "no risk encounters", but for info only. It is well understood that there is no zero risk with such encounters. But I think the app wants to make a black-and-white-decision. At the moment there seems no major problem with the capacity of the health system. However the app (environment) seems dimensioned for coping with a few thousand infections per day (https://www.golem.de/news/corona-warn-app-telekom-rechnete-mit-10-000-neuinfizierten-pro-tag-2008-150391.html). We will hopefully/probably not get this. But the app may still need to alert only the users that get the "red status". And all others should not get any hint that might encourage them to bother the health system. Besides of course, that they shall take symptoms serious.

There are currently many discussions regarding green risk status.
See also:
https://github.com/corona-warn-app/cwa-website/issues/307
https://github.com/corona-warn-app/cwa-backlog/issues/23
It was discussed with the RKI to add a 3rd color code beside green and red but it was declined by the RKI. The upcoming version of the app will have a slightly overhaul of the risk status screen.
You can see a preview of the screens how they will most likely look like afterwards:
https://github.com/corona-warn-app/cwa-backlog/issues/23#issuecomment-682485410

The latest information is that there is no plan to add an additional color code like yellow or gray.
Best regards,
SG
Corona-Warn-App Open Source Team

@mf179

Daimpi, I have nothing againts showing "no risk encounters", but for info only. It is well understood that there is no zero risk with such encounters.

I don't fully understand: are you saying that you're fine with hiding encounters from the user? I've mentioned the reasons why this would be a bad idea multiple times above and fortunately CWA is also currently not hiding any encounters from the user.

But I think the app wants to make a black-and-white-decision.

I also don't think that's a great idea for the reasons mentioned above. But in principle I don't think this is as problematic as completely hiding encounters would be. And if the app would show some more real info (e.g. day of encounter) on green encounters I'd be quite happy even if there is no 3rd color.

But the app may still need to alert only the users that get the "red status". And all others should not get any hint that might encourage them to bother the health system.

I see your point wrt not overloading the healthcare system. But I very much disagree with the idea that "hiding encounters" would be a solution. Exactly the opposite: when it comes to triaging resources, more information is important as e.g. the doctors which have to decide whether a test should be performed or not, profit from more info on the potential encounters. When I know my patient had a risk encounter 13 days ago but still doesn't show any symptoms, that might be quite different to a situation where I know the encounter just happened 2 days ago. Not hiding encounters has the added advantage, that we're not hiding the ~50% false negative encounters the app produces (and that's a conservative number for the reasons mentioned above).

Besides of course, that they shall take symptoms serious.

Sure, but if you hide encounters, you prevent the user/ care-provider from making a better informed determination on how to evaluate potential symptoms, especially b/c Covid-19 has symptoms that overlap with other diseases which will become more prevalent as we move into autumn.

sorry to butt in here, but at this point the discussion does not really represent the original issue. in fact, i was advocating for clearly using it only to trace positive contacts (because it can do that, potentially), and make no assumptions about low risk (because it CAN'T).
however, as @svengabr and @GisoSchroederSAP have said above, the decision to show the low risk status, and to do it in green, was made by the RKI independent of whether it makes sense or not. it is also pretty clear to me at this point that there is no interest in amending this, because apparently "the users understand this." which i don't think, but i don't call the shots, obviously.
recent evaluations seem to indicate i may be right, because the agreement with the app in the population sinks quite rapidly, and now more than half of users seem to think we will not benefit from its use. i'm inclined to agree to that, and seeing all the resistance here, i don't really have any hope that this will be resolved. so thanks for your efforts, and i'll retreat from this thread. at least SAP made some money.

I agree with slobentanzer. Further, I assume this is a commercial product and it seems to lack any professional quality management. At least obviously for what is not just software.
The issue discussed here is reported for almost two months. The "Risikobegegnung mit niedrigem Risiko" for more than two months meanwhile. The proposed wording presented as "solution" here and under # 23 is still wrong. It contradicts the correct FAQ.
Last repetition to explain again, also for svengabr: I was rather forced to move to this issue here from # 23  and_ to another issue that was closed with bending the rules as backlog#23 is not seriously caring about the issues discussed here.
This here with its thumbs-up represents the attitude of the discussion on # 23: "
Coronawahn commented 10 days ago: Mir ist diese Wortklauberei ehrlich gesagt ziemlich egal, denn wenn ich eine Info bekomme wie z.B. eine Risiko-Begegnung am XX.XX.XXXX (um XX:XX Uhr), mit X Meter Abstand und einer Länge von X Minuten
brauche ich keine weitere Erklärung."
Discussion under issue # 23 focuses on enhancements that none of the majority of the users needs. If there is a serious interest by the "CWA Team" in fixing the issues, you should make someone responsible for the "risk statments" outside the red status.
It took a week until someone even understood what the issue with the green risk statements is. This is elementary logic, which makes me wonder whether there is a lack of competency regarding this. Now it is restarted. Nobody wants a new color. Current green is wrong and should become white. Current (green) "low risk" statment is a false statement under various conditions.
It turns out to be just a waste of time spending effort here on fixing the CWA.
Now that Google and Apple announced that they integrate also the rest of the warning functionality. it remains to hope that they better understand what they do. And you guys here perhaps start to consider the end-of-life of the product.

@slobentanzer & @mf179
First of all, everything I write here is not against you personally, I don't know you and only want to describe my view on this topic. ❤
I understand that it is frustating for you that your point, which is a good one, is not accepted by the RKI, but please don't just give up but consider how this problem could also be solved!
@slobentanzer

[...]and make no assumptions about low risk (because it CAN'T).

You are right, the App can't really make the statement "Low Risk" because it could be that a person don't upload his Key if he/she is positive or even he/she doesn't use the CWA.
But I still think it is not necessary to indtroduce new colours, etc. An understandable text should make clear that you could have been in (close) conatct with somebody having COVID-19. I, again, beg you to open an Issue dedicated to only this and make an proposal for this Text.

recent evaluations seem to indicate i may be right, because the agreement with the app in the population sinks quite rapidly, and now more than half of users seem to think we will not benefit from its use[...]

This is not completely right, here you can find a German article from the "SZ" with detailed information and a link to a study about Public opinion with regard to the CWA.

and seeing all the resistance here, i don't really have any hope that this will be resolved. so thanks for your efforts, and i'll retreat from this thread. at least SAP made some money.

I think I can speak for the most of us that we we do not reject your proposals from the very beginning, we just all wanted to understand your point. And if everbody understood it and still don't support your idea, than they just think it is not necessary to do that... Thats the good side from open source, you always have min. 2 opinions.

@mf179

The issue discussed here is reported for almost two months. The "Risikobegegnung mit niedrigem Risiko" for more than two months meanwhile. The proposed wording presented as "solution" here and under # 23 is still wrong. It contradicts the correct FAQ.

Could you please explain what is contradictory (if you've done so before just link your comment) thank you!

Last repetition to explain again, also for svengabr: I was rather forced to move to this issue here from # 23 and_ to another issue that was closed with bending the rules as backlog#23 is not seriously caring about the issues discussed here.

That's why I've pleased you from the very beginning to just open an Issue dedicated to 1 point and not do all in one (in other Issues?!?).

Now it is restarted. Nobody wants a third color. Current green is wrong and should become white. Current (green) "low risk" statment is a false statement under various conditions.

Right, the RKI said it doesn't want to change the colour, so I think you are blaming the wrong people here...

Now that Google and Apple announced that they integrate also the rest of the warning functionality. it remains to hope that they better understand what they do. And you guys here perhaps start to consider the end-of-life of the product.

Please see this statement from the Telekom, there you can see that the App will still live on, even with Exposure Notification Express...

Thanks, @Ein-Tim , for the last comment here.
I see, beside some questionable statements, a fruitful discussion here about different opinions in various dimensions. You are discussing and/or questioning

color coding
verbal explanations in the CWA UI
risk calculation (or evaluation)
logical contradictions
the difference between "exposure" and "encounter" and the role of ENF versus the role of the App
and even the professional expertise of those that made the decisions (and/or those that implemented the app?!)

Even when I already stepped in twice to provide a statement, it seems I did not fully reach you.
So, let me try to step back and ask a couple of questions:

Did you already reviewed the mentioned paper "Epidemiological Motivation of the Transmission Risk Level" to accept the difference between transmission risk level & value and total risk score?
Do you believe there is a global acceptance for any color coding, i.e. do you think, this long discussion  would immediately be finished by introducing a third white/grey/yellow color? (Same question would come up for the verbal explanation in the app)
What do you think - do we all share the same idea of the purpose of the CWA app?
Do you at least accept, there might be a good reason to design and implement the app the way it is?

I am just asking, because it looks to me, there are different intentions and different interpretations all over.
From the design perspective, this follows also the RKI intention, @mf179  made a nice note:

red (be concerned, take actions) and green (be not concerned, don´t overreact)

Taking "Guidance for the user based on the knowledge of the local app" as the purpose of the addressed UI element, we constantly review and adjust those verbal explanations with our professional quality management team, with the RKI experts, with community users and even with the BMG (ministry of health).
Looking back to the keywords of this ticket's contributions I totally agree with the summary 4days ago: Yes, we are moving in circles. Therefore, I'd like to thank you for your thoughts and concerns so far. We always will share your valuable input in the communication between the parties, including RKI. Based on this dialogue, please accept:
Decision is made for the binary color code.
Phrases, wording and explanations will be further improved to transport the "intended message".
Thanx.

listen, guys,
to me this is also not at all personal. and i am kind of sorry that you have to deal with this, as you are clearly not the ones responsible for the epidemiological side of things. i am having a hard time explaining what this thread should have been about.
it has always been about confidence, in the particular case of absence of contacts. nothing else. i have no particular quarrel with the binary coding, please don't confuse my statements with those from @mf179. however, it seems you do not realise, or are strongly opposed to acknowledging, the fact that a user of the app will invariably base their decisions on the "risk" you present to them in the app. That's what "Guidance for the user based on the knowledge of the local app" means.
if a user has lots of positive contacts, it is fair to assume that the display of "high risk" has merit in this case. but the opposite is not the case. how is that so difficult to acknowledge? if someone lives in a high-risk environment, such as working in a hospital or nursing home (non-medical staff or anyone not familiar with statistics and epidemiology), or in a small village with a large outbreak, it is never warranted to show them "low risk". in these situations, they are always at high risk, if they do not isolate. i think even the RKI will agree with me on that.
and here is the problem: a potentially asymptomatic or pre-symptomatic infected person may use the judgement in the app (again, "Guidance for the user based on the knowledge of the local app") to decide whether to go to a social gathering, concert, or the likes. where they have the potential to become another super-spreader. to return to my initial argument: there is no confidence (because, as you said, it cannot be implemented) for a display of "low risk."
@GisoSchroederSAP, your advice of reading sebastian wolf's paper also tells me that you do not understand my point. "Epidemiological Motivation of the Transmission Risk Level" only concerns itself with the "positive case," and develops a stochastic model only for estimation of risk based on a positive contact. there isn't even mention of the opposite case. if the app is designed solely for contact tracing, it has no right of telling anyone they are at "low risk." i have been trying to make this very point from the start, and i am simply getting frustrated by now. not that it has any bearing on you, because what can i do?

@slobentanzer, I see you point quite and I acknowledge your conclusions. However, they are based on a different model - I hope you accept this point as well: While you state:

If a user has lots of positive contacts, it is fair to assume that the display of "high risk" has merit in this case. but the opposite is not the case. how is that so difficult to acknowledge?

...I simply disagree with the pure logic. If the app traces multiple contacts for 1min or less with a distance of 5 or more meters (which may happen for cleaning personell in hospitals), the underlying model during risk evaluation will probably rate those contacts as low risk from the transmission risk level perspective.
That's why I referred to the paper: You might be right about a general statement for a "high risk environment" and may warn users according to "potentially high risk clusters". But cluster recognition and evaluation is not the intended design of the app (yet) and cluster information is not part of the transmission risk calculation. In fact, the purpose of the app was clearly mentioned as motivation for the used approach based on transmission risk:

The better we can assess the probability of a transmission from A to B, the more accurate is the combined risk score that is used to warn the user to take further action.

From my perspective these different viewpoints (btw, already commented by @Ein-Tim ) make the statement weak:

if the app is designed solely for contact tracing, it has no right of telling anyone they are at "low risk."

Here we have the point, also mentioned multiple times: The message of the app regarding risk neither told the user whether we recommend to take action or not, nor did it explain why the risk status is green or red. Therefore, the wording was improved and verified by all parties with the clear message: Based on the math model and based on the facts known about the traced contacts, it is not likely[=green] or likely [=red] the user got infected via transmission from A to B.
I am quite convinced, this is a valid message to the user.

We got an official statement from the Robert Koch Institute:
German

Als Herausgeber der Corona-Warn-App bedankt sich das Robert Koch-Institut für die vielen Rückmeldungen zur Risikostatusanzeige auf dem HomeScreen. Diesem Dank schließen wir uns als Entwicklerteam der App an. Nach Abwägung aller Argumente und in Abstimmung mit dem Bundesministerium für Gesundheit hat das RKI entschieden, die zweistufige Risikodarstellung (grün und rot) beizubehalten.

Die App muss möglichst einfach und allgemeinverständlich in der Anwendung sein. Durch die Unterscheidung von niedrigem und erhöhtem Risiko können den Nutzerinnen und Nutzern auf ihren Risikostatus abgestimmte Handlungsempfehlungen gegeben werden. Die zusätzliche Anzeige von Begegnungen, die bestimmte Kriterien erfüllen, erhöht die Transparenz. Für alle diejenigen, die sich mit der Risikobewertung und ihren Parametern eingehender beschäftigen möchten, haben RKI und Entwicklerteam detaillierte Beschreibungen auf GitHub zur Verfügung gestellt.

Die Texte in der Corona-Warn-App werden wir unter Berücksichtigung Ihres Feedbacks weiter anpassen. Mit einem anstehenden Update werden wir weitere Erläuterungen zum besseren Verständnis der angezeigten Risikobegegnungen geben. Zudem wird geprüft, ob mit einem späteren Update eine Risikobegegnungshistorie in der App dargestellt werden kann.

Auch zukünftig werden wir Anregungen und Vorschläge zur Verbesserung der Corona-Warn-App aufgreifen, diskutieren und, soweit sinnvoll und möglich, umsetzen. Wir freuen uns, wenn Sie sich weiter mit konstruktivem Feedback beteiligen.

English

As the publisher of the Corona-Warn-App, the Robert Koch-Institute as well as the development team would like to thank you for the many feedbacks on the risk status display on the HomeScreen. After weighing up all arguments and in coordination with the Federal Ministry of Health, the RKI has decided to keep the two-level risk display (green and red).

The app must be as simple and generally understandable as possible in its application. By differentiating between low and increased risk, users can be given recommendations for action based on their risk status. The additional display of encounters that meet certain criteria increases transparency. For those who want to take a closer look at risk assessment and its parameters, RKI and the development team have provided detailed descriptions on GitHub.

We will further improve the texts in the Corona-Warn-App and we will continue to listen for feedback of the community. With an upcoming update, we will provide further explanations to help you better understand the risk encounters displayed. In addition, we will check whether a later update will allow a risk encounter history to be displayed in the app.

In the future, we will continue to take up, discuss and, where reasonable and possible, implement suggestions and proposals for improving the Corona Warning App. We would be pleased if you continue to contribute with constructive feedback.

Further text improvements are being introduced in the upcoming hotfix release 1.3.1.
RC1 of 1.3.1 is already available:
https://github.com/corona-warn-app/cwa-app-android/releases/tag/1.3.1-SNAPSHOT-RC1
https://github.com/corona-warn-app/cwa-app-ios/releases/tag/v1.3.1-RC1
Since the decision from the RKI is final, I will close this issue now.
Best regards,
SG
Corona-Warn-App Open Source Team

authors: Ein-Tim GisoSchroederSAP daimpi mf179 mtb77 slobentanzer svengabr

repo: corona-warn-app/cwa-wishlist


text:
Late warning about increased risk

A friend of mine was Corona positive and reported - conscientiously as he is - the whole thing via the Corona-Warn-App (on a Samsung S10 with Android 10) and after the hotline had given him a TAN, the test was also shown as positive.
His wife (Corona negative) was told 2.5 days later about an increased risk via the app (although she checked several times).
I would have expected her to get a warning within 24 hours after he reported positive.
What is the reason for this late warning? And can this be improved?

Internal Tracking ID: EXPOSUREAPP-1883

I just received report of a similar case.
The situation is the following Person A & B are living in a household together i.e. have continuous contact.
The timeline looked like this:

17.10. person A got their positive test result and submitted their DKs in CWA. This submission happened around midnight (CEST), but before 02:00 CEST.
18.10. checks performed on B's phone on the 18th at 02:33 didn't yield any matches.
19.10. checks performed at 08:26 find matches and yield an increased risk (last contact 3 days ago):

Why wasn't Person B already warned on the 18th? Shouldn't DKs uploads before 02:00 CEST (00:00 UTC) still go into the package for the upcoming day?

Log: PersonB-log.txt

Does someone know what the latest point in time is for when DKs uploaded on day 1 will still be added to the daily package which becomes available on the following day?
@christian-kirschnick @Tho-Mat @EvgeniiSkrebtcov maybe? 🙂

I guess with 1.7.1 out we can close this issue?

HI @weso0013, as @cfritzsche suggests, with the new updating schedule of CWA version 1.7.1 this issue becomes obsolete. Do you agree to close this issue? Thanks for the feedback.  Best wishes,
DS

Corona-Warn-App Open Source Team

@dsarkar Yes, for sure!
Thanks!

@weso0013, thanks for contributing! Best wishes, DS

Corona-Warn-App Open Source Team

source: gharchive/issue

authors: cfritzsche daimpi dsarkar weso0013

license_type: permissive

license_source: github-api


text:
Deactivate RAT proof feature if test center does not transmit a sample collected (SC) timestamp instead of using the time of the test registration for the countdown

Current Implementation
If the test center doesn't transmit a timestamp when the RAT sample was collected, the app just uses the time when the user registered their test inside of the app. This is a problem, see https://github.com/corona-warn-app/cwa-documentation/issues/661.
Suggested Enhancement
Deactivate the RAT proof feature if the app doesn't know when the test sample was collected.
Expected Benefits
Users aren't confused why the app does not show the right timestamp & moreover users can't try to trick people who are checking for RATs which were taken >48h ago.

Internal Tracking-ID: EXPOSUREAPP-8994

As the CWA project went into ramp-down mode, I don't expect this feature to be implemented. I'm therefore closing this issue.


text:
ERROR: Build Failed: Error code: 256

Self help steps before reporting the issue:
[ ] Check Solar2D forums for a solution
[ ] If Android: make sure Java8 is installed and reported when running java -version and javac -version if not, download and install Java 8
Before reporting
Android build failed (256) after 11 seconds
Aug 17 11:36:46.585 ERROR: Build Failed: Error code: 256
Platforms involved
Building on: macOS Sonoma 14.5
Building for: Android
Attach your build.settings
settings = {
  window =
  {
      --defaultMode = "fullscreen",
      defaultMode = "normal",
      defaultViewWidth = 360,
      defaultViewHeight = 480,
      titleText = {
        default = "TROYIS™ - The Knight Challenge"
      }
  },

    splashScreen =
    {
        enable = false
    },

 android =
 {
            versionName = "2.4.6",
            versionCode = "310",
            --googlePlayGamesAppId = "884218881470", -- TROYIS Google Play Game Services (España)
            googlePlayGamesAppId = "1044276391152", -- TROYIS Google Play Game Services (Estonia)

            -- 1044276391152-3abmdc8396soi9t4091fcq164g28slf7.apps.googleusercontent.com
            facebookAppId = "217131015323350",

            usesPermissions=
            {
                "android.permission.VIBRATE",
                --"android.permission.READ_PHONE_STATE",

                "android.permission.INTERNET",                  -- Para Facebook v4a
                --"android.permission.WRITE_EXTERNAL_STORAGE",    -- desactivado en init de appodeal
                "android.permission.ACCESS_NETWORK_STATE",      -- Vungle

                "com.android.vending.BILLING",                  -- Compras
                "com.android.vending.CHECK_LICENSE",            -- Key de compras

                "android.permission.ACCESS_WIFI_STATE",
                "com.google.android.gms.permission.AD_ID",

                --"android.permission.ACCESS_COARSE_LOCATION",    -- opcional para appodeal ?
                --"android.permission.ACCESS_FINE_LOCATION",      -- opcional para appodeal ?

                --"android.permission.GET_ACCOUNTS"               -- opcional para appodeal

                -- Hacer foto del record!!!!

            },

            usesFeatures =
            {
                 { name = "android.hardware.screen.portrait", required = false },
                 { name = "android.hardware.screen.landscape", required = false },
            },

            supportsScreens =
            {
                smallScreens = true,
                normalScreens = true,
                largeScreens = true,
                xlargeScreens = true,
            },
            applicationChildElements =
            {
                [[
                    <meta-data android:name="com.google.android.gms.ads.APPLICATION_ID"
                        android:value="ca-app-pub-1637719964938471~1524950722"/>
                ]],
            },

 },

plugins =
{

    ["plugin.facebook.v4a"] =
    {
        publisherId = "com.coronalabs"
    },

--[[
-- Base
    ['plugin.appodeal.beta.base'] = { publisherId = 'com.coronalabs' },
    ['plugin.appodeal.beta.GoogleAdMob'] = { publisherId = 'com.coronalabs' },
    --['plugin.appodeal.StartApp'] = { publisherId = 'com.coronalabs' },

]]
--["plugin.appodeal.GoogleAdMob"] = { publisherId = "com.coronalabs",},
--[[
-- IMPORTANTE: cargar con iOS
    ["CoronaProvider.gameNetwork.apple"] =
    {
        publisherId = "com.coronalabs",
        supportedPlatforms = { iphone=true, ["iphone-sim"]=true },
    },

]]
--[[ ]]
-- IMPORTANTE: Cargar para las versiones de ANDROID
    ["plugin.google.iap.billing.v2"] = {
        publisherId = "com.solar2d",
    },

--[[
-- IMPORTANTE: Cargar para las versiones de AMAZON
        -- key is the name passed to Lua's 'require()'
    ["plugin.amazon.iap"] =
    {
        -- required
        publisherId = "com.amazon",
    },

]]
--[[
    ["plugin.vungle.v6"] =
    {
        publisherId = "com.solar2d"
    },

    -- ***** NECESARIA PARA GOOGLE PLAY SERVICES *****

    -- PLUGIN GOOGLE PLAY GAMES SERVICES

    ["plugin.gpgs.v2"] = {
        publisherId = "com.coronalabs",
        supportedPlatforms = { ["android"] = true }
    },

    -- CON PROBLEMAS EN LA APP STORE

    -- CREO QUE NO FUNCIONABA BIEN...

    ['plugin.vibrator'] =
    {
        publisherId = 'com.spiralcodestudio'
    },

    -- **********************
    -- NO USADAS HACE TIEMPO

    ["plugin.google.play.services"] =
    {
        publisherId = "com.coronalabs",
        supportedPlatforms = { android=true }
    },

    ["CoronaProvider.native.popup.social"] =
    {
        publisherId = "com.coronalabs"
    },

    ["plugin.fbAudienceNetwork"] =
    {
        publisherId = "com.coronalabs",
        supportedPlatforms = { iphone=true, android=true }

    },

    -- key is the name passed to Lua's 'require()'
    ["CoronaProvider.gameNetwork.google"] =
    {
        -- required
        publisherId = "com.coronalabs",
        supportedPlatforms = { android = true }
    },

]]
},

orientation =
{
default = "portrait",
supported =
{
"portrait", "portraitUpsideDown"
},
},
iphone =
{
xcassets = "Images.xcassets",
plist=
{
UILaunchStoryboardName = "LaunchScreen",
        -- Intentando resolver warnging

        UIRequiredDeviceCapabilities = {"location-services" },
        NSLocationWhenInUseUsageDescription = "This app uses the GPS when active to determine where to report weather for.",
        NSBluetoothAlwaysUsageDescription = "This app would like to access bluetooth.", NSLocationAlwaysUsageDescription = "This app would like to use location services.",

        CFBundleIconFile = "Icon.png",
        CFBundleVersion = "2.4.2",

        UIStatusBarHidden= true,
        ITSAppUsesNonExemptEncryption=false,
        GADApplicationIdentifier = "ca-app-pub-1637719964938471~3735895686", -- identificador AdMob

        -- UIApplicationExitsOnSuspend = false,

        FacebookAppID = "217131015323350",

        CFBundleURLTypes = {
            {
            CFBundleURLSchemes = { "fb217131015323350", }
            }
        },

        -- Whitelist Facebook apps
        LSApplicationQueriesSchemes =
        {
            "fb",  -- Needed for the facebook-v4a.isFacebookAppEnabled() API
            "fbapi",
            "fbauth2",
            "fb-messenger-api",
            "fbshareextension"
        },

        -- Whitelist Facebook Servers for Network Requests

        NSAppTransportSecurity =
        {
            NSAllowsArbitraryLoads = true,

--[[
NSExceptionDomains =
{
["troyis.com"] =
{
NSIncludesSubdomains = true,
NSThirdPartyExceptionAllowsInsecureHTTPLoads = true,
},
},
]]
},
        UIPrerenderedIcon = "YES",
        UIAppFonts= {
                "KingthingsPetrock.ttf",
        },
        CFBundleLocalizations =
        {
            "English",
            "Spanish",
            "French",
            "German",
            "Italian",
            "Portuguese",
            "Polish",
            "Dutch",
            "Greek",
            "Russian",
            "Japanese",
            "Korean",
            "Arabic",
            "Turkish",
            "Chinese",
            "zh-Hans",
            "zh-Hant",

            "en-US",
            "es-419",
            "es-ES",
            "es-US",
            "fr-FR",
            "de-DE",
            "it-IT",
            "pt-BR",
            "pt-PT",
            "pl-PL",
            "nl-NL",
            "el-GR",
            "ru-RU",
            "ja-JP",
            "ko-KR",
            "ar",
            "tr-TR",
            "zh-CN",
            "zh-TW",
        },

    },
},

}
Full build log
Enable full build log:
On macOS:
defaults write com.coronalabs.Corona_Simulator debugBuildProcess  -int 5

On Windows:
reg ADD "HKEY_CURRENT_USER\Software\Ansca Corona\Corona Simulator\Preferences" /f /v debugBuildProcess /d 5

Before the build clean console and then copy log between backticks below
Using openjdk version "17.0.6" 2023-01-17
                    OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)
                    OpenJDK 64-Bit Server VM (build 17.0.6+0-17.0.6b829.9-10027231, mixed mode)
Aug 17 11:32:10.972 Picked up JAVA_TOOL_OPTIONS: -Duser.language=en
Aug 17 11:32:11.468 Warning:
Aug 17 11:32:11.468 The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /Applications/Corona-3708/Corona Simulator.app/Contents/Resources/debug.keystore -destkeystore /Applications/Corona-3708/Corona Simulator.app/Contents/Resources/debug.keystore -deststoretype pkcs12".
Aug 17 11:36:23.895 Picked up JAVA_TOOL_OPTIONS: -Duser.language=en
Aug 17 11:36:24.376 Warning:
Aug 17 11:36:24.376 The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /Users/guillemdesanpedro/Desktop/onlinegames-keystore.jks -destkeystore /Users/guillemdesanpedro/Desktop/onlinegames-keystore.jks -deststoretype pkcs12".
Aug 17 11:36:24.404 Testing credentials for '/Users/guillemdesanpedro/Desktop/onlinegames-keystore.jks':
Aug 17 11:36:24.431 Picked up JAVA_TOOL_OPTIONS: -Duser.language=en
Aug 17 11:36:25.536 jar signed.
Aug 17 11:36:25.536 Warning:
Aug 17 11:36:25.539 The signer's certificate is self-signed.
Aug 17 11:36:25.539
Aug 17 11:36:25.539 The timestamp will expire on 2031-11-09.
Aug 17 11:36:34.376 Using openjdk version "17.0.6" 2023-01-17
                    OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)
                    OpenJDK 64-Bit Server VM (build 17.0.6+0-17.0.6b829.9-10027231, mixed mode)
Aug 17 11:36:37.328 BUILD SUCCESSFUL
                    Total time: 1 second
Aug 17 11:36:46.275 FAILURE: Build failed with an exception.

                    * What went wrong:
                    Could not resolve all artifacts for configuration 'classpath'.
                    > Could not find com.beust:klaxon:5.0.1.
                      Searched in the following locations:
                        - https://dl.google.com/dl/android/maven2/com/beust/klaxon/5.0.1/klaxon-5.0.1.pom
                        - https://jcenter.bintray.com/com/beust/klaxon/5.0.1/klaxon-5.0.1.pom
                      Required by:
                          unspecified:unspecified:unspecified

                    * Try:
                    > Run with --stacktrace option to get the stack trace.
                    > Run with --info or --debug option to get more log output.
                    > Run with --scan to get full insights.
                    > Get more help at https://help.gradle.org.

                    BUILD FAILED in 7s
Aug 17 11:36:46.294 Android build failed (256) after 11 seconds
Aug 17 11:36:46.585 ERROR: Build Failed: Error code: 256

Using openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)
OpenJDK 64-Bit Server VM (build 17.0.6+0-17.0.6b829.9-10027231, mixed mode)
Aug 18 11:06:55.120 Picked up JAVA_TOOL_OPTIONS: -Duser.language=en
Aug 18 11:06:55.575 Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /Users/guillemdesanpedro/Desktop/onlinegames-keystore.jks -destkeystore /Users/guillemdesanpedro/Desktop/onlinegames-keystore.jks -deststoretype pkcs12".
Aug 18 11:06:55.587 Testing credentials for '/Users/guillemdesanpedro/Desktop/onlinegames-keystore.jks':
Aug 18 11:06:55.606 Picked up JAVA_TOOL_OPTIONS: -Duser.language=en
Aug 18 11:06:56.664 jar signed.
                Warning:

Aug 18 11:06:56.667 The signer's certificate is self-signed.
Aug 18 11:06:56.667 The timestamp will expire on 2031-11-09.
Aug 18 11:07:00.784 Using openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)
OpenJDK 64-Bit Server VM (build 17.0.6+0-17.0.6b829.9-10027231, mixed mode)
Aug 18 11:07:01.661 Prepackage: Compiling Lua ...
Aug 18 11:07:01.707 Prepackage: Building server data file
Aug 18 11:07:01.708 Prepackage: running: "/usr/bin/java" -Djava.class.path='/Applications/Corona-3708/Corona Simulator.app/Contents/Resources/ant.jar:/Applications/Corona-3708/Corona Simulator.app/Contents/Resources/ant-launcher.jar:/Applications/Corona-3708/Corona Simulator.app/Contents/Resources/AntLiveManifest.jar' org.apache.tools.ant.launch.Launcher -d -DTEMP_DIR='/var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T//CLtmp2U4fM8' -DSRC_DIR='/Users/guillemdesanpedro/Library/CloudStorage/GoogleDrive-guillembrasil@gmail.com/Mi unidad/Apps/TROYIS HTML5' -DBUNDLE_DIR='/Applications/Corona-3708/Corona Simulator.app/Contents/Resources' -DLIVE_BUILD=NO -DLIVE_BUILD_MANIFEST_FILE= -f '/Applications/Corona-3708/Corona Simulator.app/Contents/Resources'/build.xml build-input-zip
Aug 18 11:07:01.892 Apache Ant version 1.8.1 compiled on April 30 2010
Aug 18 11:07:01.899 Buildfile: /Applications/Corona-3708/Corona Simulator.app/Contents/Resources/build.xml
Aug 18 11:07:01.909 Adding reference: ant.PropertyHelper
Aug 18 11:07:01.910 Detected Java version: 1.6 in: /Applications/Corona-3708/Corona Simulator.app/Contents/jre/jdk/Contents/Home
Aug 18 11:07:01.910 Detected OS: Mac OS X
Aug 18 11:07:01.914 Adding reference: ant.ComponentHelper
Aug 18 11:07:01.928 Setting ro project property: LIVE_BUILD -> NO
Aug 18 11:07:01.929 Setting ro project property: BUNDLE_DIR -> /Applications/Corona-3708/Corona Simulator.app/Contents/Resources
Setting ro project property: TEMP_DIR -> /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T//CLtmp2U4fM8
Setting ro project property: SRC_DIR -> /Users/guillemdesanpedro/Library/CloudStorage/GoogleDrive-guillembrasil@gmail.com/Mi unidad/Apps/TROYIS HTML5
Aug 18 11:07:01.929 Setting ro project property: LIVE_BUILD_MANIFEST_FILE ->
Setting ro project property: ant.file -> /Applications/Corona-3708/Corona Simulator.app/Contents/Resources/build.xml
Setting ro project property: ant.file.type -> file
Aug 18 11:07:01.943 Adding reference: ant.projectHelper
Aug 18 11:07:01.946 Adding reference: ant.parsing.context
Aug 18 11:07:01.946 Adding reference: ant.targets
Aug 18 11:07:01.994 parsing buildfile /Applications/Corona-3708/Corona Simulator.app/Contents/Resources/build.xml with URI = file:/Applications/Corona-3708/Corona%20Simulator.app/Contents/Resources/build.xml
Aug 18 11:07:01.998 Setting ro project property: ant.project.name -> Corona Client Build
Aug 18 11:07:01.998 Adding reference: Corona Client Build
Aug 18 11:07:01.998 Setting ro project property: ant.project.default-target -> none
Aug 18 11:07:01.999 Setting ro project property: ant.file.Corona Client Build -> /Applications/Corona-3708/Corona Simulator.app/Contents/Resources/build.xml
Aug 18 11:07:01.999 Setting ro project property: ant.file.type.Corona Client Build -> file
Project base dir set to: /Applications/Corona-3708/Corona Simulator.app/Contents/Resources
+Target:
Aug 18 11:07:02.003  +Target: generate-live-build-manifest
Aug 18 11:07:02.003  +Target: check-gradle-bundle
Aug 18 11:07:02.004  +Target: setup-gradle-builds
Aug 18 11:07:02.004  +Target: build-input-zip
Aug 18 11:07:02.005  +Target: unzip-apk-template
Aug 18 11:07:02.005  +Target: find-main-application-icons
Aug 18 11:07:02.006  +Target: find-main-application-banner
Aug 18 11:07:02.006  +Target: find-ouya-application-icon
Aug 18 11:07:02.007  +Target: find-ouya-xiaomi-application-icon
Aug 18 11:07:02.007  +Target: find-default-notification-icons
Aug 18 11:07:02.009  +Target: copy-file
Aug 18 11:07:02.009  +Target: can-copy-file
Aug 18 11:07:02.010  +Target: delete-file
Aug 18 11:07:02.012  +Target: can-delete-file
Aug 18 11:07:02.015  +Target: insert-main-application-icons
Aug 18 11:07:02.015  +Target: insert-main-application-banner
Aug 18 11:07:02.015  +Target: insert-ouya-application-icon
Aug 18 11:07:02.016  +Target: insert-ouya-xiaomi-application-icon
Aug 18 11:07:02.016  +Target: insert-default-notification-icons
Aug 18 11:07:02.016  +Target: insert-assets-multi-icon
Aug 18 11:07:02.016  +Target: copy-apk-assets
Aug 18 11:07:02.016  +Target: copy-files-to-apk
Aug 18 11:07:02.017  +Target: sign-apk
Aug 18 11:07:02.022  +Target: sign-apk-md5
Aug 18 11:07:02.024  +Target: sign-apk-sha1
Aug 18 11:07:02.027  +Target: sign-apk-auto
Aug 18 11:07:02.032  +Target: build-unsigned-apk
Aug 18 11:07:02.037  +Target: build-signed-apk
Aug 18 11:07:02.037  +Target: build-expansion-file
Aug 18 11:07:02.038  +Target: copy-apk-to
Aug 18 11:07:02.038  +Target: copy-to
Aug 18 11:07:02.038  +Target: build
Aug 18 11:07:02.038  +Target: test-sign
Aug 18 11:07:02.042 Adding reference: ant.LocalProperties
Aug 18 11:07:02.190 parsing buildfile jar:file:/Applications/Corona-3708/Corona%20Simulator.app/Contents/Resources/ant.jar!/org/apache/tools/ant/antlib.xml with URI = jar:file:/Applications/Corona-3708/Corona%20Simulator.app/Contents/Resources/ant.jar!/org/apache/tools/ant/antlib.xml from a zip file
Aug 18 11:07:02.236  [property] Loading /Applications/Corona-3708/Corona Simulator.app/Contents/Resources/build.properties
Aug 18 11:07:02.240 Setting project property: ANDROID_API_VERSION -> android-8
Aug 18 11:07:02.240 Setting project property: ANDROID_ROOT -> /usr/local/bin/android-sdk-mac_x86
Setting project property: USER_ACTIVITY_PATH -> com/ansca/test/analyticstest
Aug 18 11:07:02.240 Setting project property: ANDROID_VERSION -> android-8
Setting project property: USER_ACTIVITY_PACKAGE -> com.ansca.test.analyticstest
Setting project property: ANDROID_MIN_SDK_INTEGER_VERSION -> 8
Aug 18 11:07:02.240 Setting project property: CORONA_ROOT -> /Volumes/Ansca/code/main
Aug 18 11:07:02.240 Setting project property: USER_APP_DISPLAY_NAME -> analyticstest
Override ignored for property "SRC_DIR"
Aug 18 11:07:02.241 Setting project property: APK_APP_NAME -> MyCoronaActivity
Aug 18 11:07:02.250 Class org.apache.tools.ant.taskdefs.condition.Os loaded from parent loader (parentFirst)
Aug 18 11:07:02.254 Condition false; not setting SCRIPT_EXT
Aug 18 11:07:02.254 Setting project property: SCRIPT_EXT -> sh
Aug 18 11:07:02.255 Condition false; not setting USE_OLD_TOUCH
Aug 18 11:07:02.255 Condition false; not setting onWindows
Aug 18 11:07:02.258 Class org.apache.tools.ant.taskdefs.condition.Equals loaded from parent loader (parentFirst)
Aug 18 11:07:02.259 Condition false; not setting live.build
Aug 18 11:07:02.281 Adding reference: asset.fileset
Aug 18 11:07:02.283 [available] Unable to find /Applications/Corona-3708/Corona Simulator.app/Contents/Native/Corona/android
Aug 18 11:07:02.283 Condition false; not setting corona.native.android
Aug 18 11:07:02.284 [available] Found: /Applications/Corona-3708/Native/Corona/android
Aug 18 11:07:02.284 Condition true; setting corona.native.android to /Applications/Corona-3708/Corona Simulator.app/Contents/Resources/../../../Native/Corona/android
Setting project property: corona.native.android -> /Applications/Corona-3708/Corona Simulator.app/Contents/Resources/../../../Native/Corona/android
Aug 18 11:07:02.284 [available] Unable to find /android
Condition false; not setting corona.native.android
Aug 18 11:07:02.284 [available] Unable to find /Users/guillemdesanpedro/Library/Application Support/Corona/Native/Corona/android
Aug 18 11:07:02.285 Condition false; not setting corona.native.android
Aug 18 11:07:02.285 [available] Unable to find Native/Corona/android
Aug 18 11:07:02.285 Condition false; not setting corona.native.android
Aug 18 11:07:02.290  +Datatype copy-res-file org.apache.tools.ant.taskdefs.MacroInstance
Aug 18 11:07:02.290  [macrodef] creating macro  copy-res-file
Aug 18 11:07:02.293  +Datatype copy-drawable-file org.apache.tools.ant.taskdefs.MacroInstance
Aug 18 11:07:02.293  [macrodef] creating macro  copy-drawable-file
Aug 18 11:07:02.294  +Datatype copy-mipmap-file org.apache.tools.ant.taskdefs.MacroInstance
Aug 18 11:07:02.294  [macrodef] creating macro  copy-mipmap-file
Aug 18 11:07:02.295  +Datatype copy-notification-icon org.apache.tools.ant.taskdefs.MacroInstance
Aug 18 11:07:02.295  [macrodef] creating macro  copy-notification-icon
Aug 18 11:07:02.295 Setting ro project property: ant.project.invoked-targets -> build-input-zip
Aug 18 11:07:02.296 Attempting to create object of type org.apache.tools.ant.helper.DefaultExecutor
Aug 18 11:07:02.296 Adding reference: ant.executor
Aug 18 11:07:02.297 Build sequence for target(s) `build-input-zip' is [generate-live-build-manifest, check-gradle-bundle, setup-gradle-builds, build-input-zip]
Aug 18 11:07:02.298 Complete build sequence is [generate-live-build-manifest, check-gradle-bundle, setup-gradle-builds, build-input-zip, can-delete-file, unzip-apk-template, build-unsigned-apk, sign-apk-md5, sign-apk-sha1, can-copy-file, build-signed-apk, copy-files-to-apk, copy-apk-assets, test-sign, find-ouya-xiaomi-application-icon, insert-ouya-xiaomi-application-icon, copy-apk-to, sign-apk-auto, sign-apk, find-main-application-banner, insert-main-application-banner, find-main-application-icons, insert-main-application-icons, find-default-notification-icons, insert-default-notification-icons, insert-assets-multi-icon, build-expansion-file, copy-to, build, find-ouya-application-icon, insert-ouya-application-icon, copy-file, , delete-file]
Aug 18 11:07:02.298 generate-live-build-manifest:
Aug 18 11:07:02.298 Skipped because property 'live.build' not set.
                check-gradle-bundle:

Aug 18 11:07:02.298 [available] Found: /Applications/Corona-3708/Native/Corona/android/resource/android-template.zip
Aug 18 11:07:02.298 Setting project property: gradle.bundle.exists -> true
                setup-gradle-builds:

Aug 18 11:07:02.307     [unzip] Expanding: /Applications/Corona-3708/Native/Corona/android/resource/android-template.zip into /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8
Aug 18 11:07:02.312     [unzip] extracting template/gradlew.bat
Aug 18 11:07:02.313     [unzip] expanding template/gradlew.bat to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/gradlew.bat
Aug 18 11:07:02.315     [unzip] extracting template/setup.sh
Aug 18 11:07:02.316     [unzip] expanding template/setup.sh to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/setup.sh
Aug 18 11:07:02.316     [unzip] extracting template/gradle.properties
Aug 18 11:07:02.316     [unzip] expanding template/gradle.properties to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/gradle.properties
Aug 18 11:07:02.316     [unzip] extracting template/app/
Aug 18 11:07:02.316     [unzip] expanding template/app/ to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app
Aug 18 11:07:02.316     [unzip] extracting template/app/build.gradle.kts
[unzip] expanding template/app/build.gradle.kts to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/build.gradle.kts
Aug 18 11:07:02.317     [unzip] extracting template/gradle/wrapper/gradle-wrapper.properties
Aug 18 11:07:02.318     [unzip] expanding template/gradle/wrapper/gradle-wrapper.properties to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/gradle/wrapper/gradle-wrapper.properties
Aug 18 11:07:02.319     [unzip] extracting template/app/src/main/
Aug 18 11:07:02.320     [unzip] expanding template/app/src/main/ to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/src/main
Aug 18 11:07:02.320     [unzip] extracting sdk/licenses/android-sdk-license
Aug 18 11:07:02.320     [unzip] expanding sdk/licenses/android-sdk-license to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/sdk/licenses/android-sdk-license
Aug 18 11:07:02.320     [unzip] extracting template/app/buildTools/strings.xml
Aug 18 11:07:02.320     [unzip] expanding template/app/buildTools/strings.xml to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/buildTools/strings.xml
Aug 18 11:07:02.321     [unzip] extracting template/app/_corona_splash_screen.png
Aug 18 11:07:02.321     [unzip] expanding template/app/_corona_splash_screen.png to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/_corona_splash_screen.png
Aug 18 11:07:02.322     [unzip] extracting template/app/src/main/res/values/
Aug 18 11:07:02.322     [unzip] expanding template/app/src/main/res/values/ to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/src/main/res/values
Aug 18 11:07:02.322     [unzip] extracting template/
Aug 18 11:07:02.322     [unzip] expanding template/ to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template
Aug 18 11:07:02.323     [unzip] extracting sdk/
Aug 18 11:07:02.323     [unzip] expanding sdk/ to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/sdk
[unzip] extracting template/gradlew
[unzip] expanding template/gradlew to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/gradlew
Aug 18 11:07:02.323     [unzip] extracting template/app/proguard-rules.pro
Aug 18 11:07:02.323     [unzip] expanding template/app/proguard-rules.pro to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/proguard-rules.pro
Aug 18 11:07:02.324     [unzip] extracting template/app/buildTools/update_manifest.lua
Aug 18 11:07:02.324     [unzip] expanding template/app/buildTools/update_manifest.lua to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/buildTools/update_manifest.lua
Aug 18 11:07:02.324     [unzip] extracting template/preloadedAssets/build.gradle.kts
Aug 18 11:07:02.325     [unzip] expanding template/preloadedAssets/build.gradle.kts to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/preloadedAssets/build.gradle.kts
Aug 18 11:07:02.325     [unzip] extracting template/app/buildTools/convert_metadata.lua
Aug 18 11:07:02.325     [unzip] expanding template/app/buildTools/convert_metadata.lua to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/buildTools/convert_metadata.lua
Aug 18 11:07:02.325     [unzip] extracting template/app/src/main/res/
Aug 18 11:07:02.325     [unzip] expanding template/app/src/main/res/ to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/src/main/res
Aug 18 11:07:02.325     [unzip] extracting template/gradle/wrapper/
Aug 18 11:07:02.325     [unzip] expanding template/gradle/wrapper/ to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/gradle/wrapper
Aug 18 11:07:02.325     [unzip] extracting template/gradle/wrapper/gradle-wrapper.jar
[unzip] expanding template/gradle/wrapper/gradle-wrapper.jar to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/gradle/wrapper/gradle-wrapper.jar
Aug 18 11:07:02.327     [unzip] extracting template/settings.gradle.kts
Aug 18 11:07:02.328     [unzip] expanding template/settings.gradle.kts to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/settings.gradle.kts
Aug 18 11:07:02.328     [unzip] extracting template/app/src/
[unzip] expanding template/app/src/ to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/src
[unzip] extracting template/PAD.kts.template
[unzip] expanding template/PAD.kts.template to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/PAD.kts.template
Aug 18 11:07:02.328     [unzip] extracting template/gradle/
Aug 18 11:07:02.328     [unzip] expanding template/gradle/ to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/gradle
Aug 18 11:07:02.328     [unzip] extracting template/app/src/main/res/values/strings.xml
Aug 18 11:07:02.328     [unzip] expanding template/app/src/main/res/values/strings.xml to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/src/main/res/values/strings.xml
Aug 18 11:07:02.329     [unzip] extracting template/app/buildTools/
Aug 18 11:07:02.329     [unzip] expanding template/app/buildTools/ to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/buildTools
[unzip] extracting template/build.gradle.kts
[unzip] expanding template/build.gradle.kts to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/build.gradle.kts
[unzip] extracting template/app/libs/licensing-google.jar
Aug 18 11:07:02.329     [unzip] expanding template/app/libs/licensing-google.jar to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/libs/licensing-google.jar
Aug 18 11:07:02.330     [unzip] extracting template/app/buildTools/AndroidManifest.template.xml
Aug 18 11:07:02.330     [unzip] expanding template/app/buildTools/AndroidManifest.template.xml to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/buildTools/AndroidManifest.template.xml
Aug 18 11:07:02.330     [unzip] extracting template/app/libs/
Aug 18 11:07:02.330     [unzip] expanding template/app/libs/ to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/libs
Aug 18 11:07:02.331     [unzip] extracting sdk/licenses/
Aug 18 11:07:02.331     [unzip] expanding sdk/licenses/ to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/sdk/licenses
Aug 18 11:07:02.331     [unzip] extracting template/setup.bat
Aug 18 11:07:02.331     [unzip] expanding template/setup.bat to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/setup.bat
Aug 18 11:07:02.331     [unzip] extracting template/preloadedAssets/
Aug 18 11:07:02.331     [unzip] expanding template/preloadedAssets/ to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/preloadedAssets
Aug 18 11:07:02.331     [unzip] extracting template/app/src/main/AndroidManifest.xml
Aug 18 11:07:02.332     [unzip] expanding template/app/src/main/AndroidManifest.xml to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/src/main/AndroidManifest.xml
Aug 18 11:07:02.333     [unzip] expand complete
Aug 18 11:07:02.348 FileSet: Setup scanner in dir /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template with patternSet{ includes: [gradlew] excludes: [] }
Aug 18 11:07:02.351     [chmod] Executing 'chmod' with arguments:
[chmod] 'a+x'
[chmod] '/var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/gradlew'
[chmod]
[chmod] The ' characters around the executable and arguments are
[chmod] not part of the command.
Aug 18 11:07:02.351 Execute:Java13CommandLauncher: Executing 'chmod' with arguments:
'a+x'
'/var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/gradlew'
                The ' characters around the executable and arguments are
                not part of the command.

Aug 18 11:07:02.795     [chmod] Applied chmod to 1 file and 0 directories.
Aug 18 11:07:02.800 FileSet: Setup scanner in dir /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template with patternSet{ includes: [setup.sh] excludes: [] }
Aug 18 11:07:02.802     [chmod] Executing 'chmod' with arguments:
[chmod] 'a+x'
[chmod] '/var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/setup.sh'
[chmod]
[chmod] The ' characters around the executable and arguments are
[chmod] not part of the command.
Aug 18 11:07:02.803 Execute:Java13CommandLauncher: Executing 'chmod' with arguments:
'a+x'
'/var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/setup.sh'
                The ' characters around the executable and arguments are
                not part of the command.

Aug 18 11:07:03.234     [chmod] Applied chmod to 1 file and 0 directories.
Aug 18 11:07:03.241 fileset: Setup scanner in dir /Applications/Corona-3708/Native/Corona/android/lib/gradle with patternSet{ includes: [] excludes: [] }
Aug 18 11:07:03.260      [copy] Corona.aar added as Corona.aar doesn't exist.
Aug 18 11:07:03.262      [copy]  omitted as /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/libs is up to date.
Aug 18 11:07:03.262      [copy] Copying 1 file to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/libs
Aug 18 11:07:03.262      [copy] Copying /Applications/Corona-3708/Native/Corona/android/lib/gradle/Corona.aar to /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/template/app/libs/Corona.aar
Aug 18 11:07:03.323 build-input-zip:
Aug 18 11:07:03.331 Setting project property: USER_ZIP -> /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T//CLtmp2U4fM8/input.zip
Aug 18 11:07:03.350 fileset: Setup scanner in dir /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8 with patternSet{ includes: [] excludes: [resource.car] }
Aug 18 11:07:03.362       [zip] Building zip: /var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T/CLtmp2U4fM8/input.zip
Aug 18 11:07:03.369       [zip] adding directory sdk/
Aug 18 11:07:03.371       [zip] adding directory sdk/licenses/
Aug 18 11:07:03.372       [zip] adding directory template/
Aug 18 11:07:03.372       [zip] adding directory template/app/
Aug 18 11:07:03.372       [zip] adding directory template/app/buildTools/
Aug 18 11:07:03.372       [zip] adding directory template/app/libs/
Aug 18 11:07:03.373       [zip] adding directory template/app/src/
Aug 18 11:07:03.374       [zip] adding directory template/app/src/main/
Aug 18 11:07:03.374       [zip] adding directory template/app/src/main/res/
Aug 18 11:07:03.375       [zip] adding directory template/app/src/main/res/values/
Aug 18 11:07:03.375       [zip] adding directory template/gradle/
Aug 18 11:07:03.375       [zip] adding directory template/gradle/wrapper/
Aug 18 11:07:03.375       [zip] adding directory template/preloadedAssets/
Aug 18 11:07:03.376       [zip] adding entry admediator_admob.lu
Aug 18 11:07:03.378       [zip] adding entry alertcounter.lu
Aug 18 11:07:03.378       [zip] adding entry bannernivel.lu
Aug 18 11:07:03.378       [zip] adding entry bannersnivel.lu
Aug 18 11:07:03.379       [zip] adding entry barra.lu
Aug 18 11:07:03.380       [zip] adding entry boton.lu
Aug 18 11:07:03.380       [zip] adding entry build.properties
Aug 18 11:07:03.381       [zip] adding entry caballo.lu
Aug 18 11:07:03.381       [zip] adding entry closebutton.lu
Aug 18 11:07:03.381       [zip] adding entry config.lu
Aug 18 11:07:03.382       [zip] adding entry connection.lu
Aug 18 11:07:03.383       [zip] adding entry cuadro.lu
Aug 18 11:07:03.384       [zip] adding entry ele.lu
Aug 18 11:07:03.384       [zip] adding entry escaparate.lu
Aug 18 11:07:03.385       [zip] adding entry excludesfile.properties
Aug 18 11:07:03.385       [zip] adding entry felicidades.lu
Aug 18 11:07:03.385       [zip] adding entry fondo.lu
Aug 18 11:07:03.388       [zip] adding entry fotofb.lu
Aug 18 11:07:03.389       [zip] adding entry gema.lu
Aug 18 11:07:03.389       [zip] adding entry herraduras.lu
Aug 18 11:07:03.389       [zip] adding entry iconloading.lu
Aug 18 11:07:03.390       [zip] adding entry idiomas.lu
Aug 18 11:07:03.393       [zip] adding entry llaves.lu
Aug 18 11:07:03.393       [zip] adding entry logro.lu
Aug 18 11:07:03.394       [zip] adding entry logros-vertical.lu
Aug 18 11:07:03.395       [zip] adding entry logros.lu
Aug 18 11:07:03.396       [zip] adding entry main.lu
Aug 18 11:07:03.413       [zip] adding entry moneda.lu
Aug 18 11:07:03.414       [zip] adding entry movieclip.lu
Aug 18 11:07:03.414       [zip] adding entry nublado.lu
Aug 18 11:07:03.414       [zip] adding entry players.lu
Aug 18 11:07:03.414       [zip] adding entry ranking.lu
Aug 18 11:07:03.415       [zip] adding entry sdk/licenses/android-sdk-license
Aug 18 11:07:03.416       [zip] adding entry sello.lu
Aug 18 11:07:03.416       [zip] adding entry share.lu
Aug 18 11:07:03.417       [zip] adding entry simpleDB.lu
Aug 18 11:07:03.417       [zip] adding entry sparkle.lu
Aug 18 11:07:03.417       [zip] adding entry storeMod.lu
Aug 18 11:07:03.418       [zip] adding entry strtabla.lu
Aug 18 11:07:03.418       [zip] adding entry tablero.lu
Aug 18 11:07:03.419       [zip] adding entry template/PAD.kts.template
Aug 18 11:07:03.420       [zip] adding entry template/app/_corona_splash_screen.png
Aug 18 11:07:03.420       [zip] adding entry template/app/build.gradle.kts
Aug 18 11:07:03.421       [zip] adding entry template/app/buildTools/AndroidManifest.template.xml
Aug 18 11:07:03.421       [zip] adding entry template/app/buildTools/convert_metadata.lua
Aug 18 11:07:03.421       [zip] adding entry template/app/buildTools/strings.xml
Aug 18 11:07:03.421       [zip] adding entry template/app/buildTools/update_manifest.lua
Aug 18 11:07:03.423       [zip] adding entry template/app/libs/Corona.aar
Aug 18 11:07:03.719       [zip] adding entry template/app/libs/licensing-google.jar
Aug 18 11:07:03.722       [zip] adding entry template/app/proguard-rules.pro
Aug 18 11:07:03.722       [zip] adding entry template/app/src/main/AndroidManifest.xml
Aug 18 11:07:03.722       [zip] adding entry template/app/src/main/res/values/strings.xml
Aug 18 11:07:03.722       [zip] adding entry template/build.gradle.kts
Aug 18 11:07:03.723       [zip] adding entry template/gradle.properties
Aug 18 11:07:03.723       [zip] adding entry template/gradle/wrapper/gradle-wrapper.jar
Aug 18 11:07:03.725       [zip] adding entry template/gradle/wrapper/gradle-wrapper.properties
Aug 18 11:07:03.726       [zip] adding entry template/gradlew
Aug 18 11:07:03.726       [zip] adding entry template/gradlew.bat
Aug 18 11:07:03.726       [zip] adding entry template/preloadedAssets/build.gradle.kts
Aug 18 11:07:03.726       [zip] adding entry template/settings.gradle.kts
Aug 18 11:07:03.727       [zip] adding entry template/setup.bat
Aug 18 11:07:03.727       [zip] adding entry template/setup.sh
Aug 18 11:07:03.727       [zip] adding entry trofeo.lu
Aug 18 11:07:03.727       [zip] adding entry ui.lu
Aug 18 11:07:03.727       [zip] adding entry ventana.lu
Aug 18 11:07:03.727       [zip] adding entry xml.lu
Aug 18 11:07:03.757 BUILD SUCCESSFUL
Total time: 1 second
Aug 18 11:07:03.863 DeviceBuildData: {"isLaunchPadActive":false,"targetCertType":"distribution","targetPlatformVersion":140300,"debugBuildProcess":5,"targetDevice":0,"splashScreen":{"enable":false},"dailyBuildRevision":3708,"clientPlatform":"Mac OS X","targetAppStore":"google","targetPlatform":1,"clientDeviceId":"5841a817ae628e061419ba2c206901e8","plugins":{"plugin.facebook.v4a":{"publisherId":"com.coronalabs"},"plugin.google.iap.billing.v2":{"publisherId":"com.solar2d"}},"dailyBuildYear":2024,"clientProductId":"basic","appName":"TROYIS"}
Aug 18 11:07:03.864 Build: running: cd '/var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T//CLtmp2U4fM8' && cd template && ./setup.sh && JAVA_VERSION=17 ./gradlew buildCoronaApp --no-daemon -PconfigureCoronaPlugins=YES -PcoronaBuild=2024.3708 -PcoronaResourcesDir='/Applications/Corona-3708/Corona Simulator.app/Contents/Resources' -PcoronaDstDir='/Users/guillemdesanpedro/Desktop' -PcoronaTmpDir='/var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T//CLtmp2U4fM8' -PcoronaSrcDir='/Users/guillemdesanpedro/Library/CloudStorage/GoogleDrive-guillembrasil@gmail.com/Mi unidad/Apps/TROYIS HTML5' -PcoronaAppFileName='TROYIS' -PcoronaAppPackage='com.onlinegames.troyis' -PcoronaVersionCode=310 -PcoronaVersionName='246' -PcoronaKeystore='/Users/guillemdesanpedro/Desktop/onlinegames-keystore.jks' -PcoronaKeystorePassword='XXXXXX' -PcoronaKeyAlias='onlinegames' -PcoronaTargetStore='google' -PcoronaKeyAliasPassword='XXXXXX' -PcoronaBuildData='/var/folders/8k/6wxw__zx4lq31fqp86hy83040000gn/T//CLtmp2U4fM8/build.data' --console=plain
Aug 18 11:07:12.480 Welcome to Gradle 8.7!
                Here are the highlights of this release:
                 - Compiling and testing with Java 22
                 - Cacheable Groovy script compilation
                 - New methods in lazy collection properties

                For more details see https://docs.gradle.org/8.7/release-notes.html

                To honour the JVM settings for this build a single-use Daemon process will be forked. For more on this, please refer to https://docs.gradle.org/8.7/userguide/gradle_daemon.html#sec:disabling_the_daemon in the Gradle documentation.
                Daemon will be stopped at the end of the build

                FAILURE: Build failed with an exception.

                * What went wrong:
                Could not resolve all artifacts for configuration 'classpath'.
                > Could not find com.beust:klaxon:5.0.1.
                  Searched in the following locations:
                    - https://dl.google.com/dl/android/maven2/com/beust/klaxon/5.0.1/klaxon-5.0.1.pom
                    - https://jcenter.bintray.com/com/beust/klaxon/5.0.1/klaxon-5.0.1.pom
                  Required by:
                      unspecified:unspecified:unspecified

                * Try:
                > Run with --stacktrace option to get the stack trace.
                > Run with --info or --debug option to get more log output.
                > Run with --scan to get full insights.
                > Get more help at https://help.gradle.org.

                Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

                You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

                For more on this, please refer to https://docs.gradle.org/8.7/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

                BUILD FAILED in 7s

Aug 18 11:07:12.513 Android build failed (256) after 11 seconds
Aug 18 11:07:12.794 ERROR: Build Failed: Error code: 256
Aug 18 11:07:12.795

Thanks. I’m working on it

authors: Shchvova play-troyis-puzzle-game

repo: coronalabs/corona

license: MIT


text:
🛑 Catalin.ro is down

In 7cb0427, Catalin.ro (https://catalin.ro) was down:

HTTP code: 403
Response time: 807 ms

Resolved: Catalin.ro is back up in 037356e after 7 minutes.


text:
Calendar block manual refresh inconsistency

Description of the bug
The block calendar is not refreshing neither automatically nor manually.
Reproduction steps

Go to Pages -> Record List for Module -> Page Builder
Edit calendar block
Go to General tab
Set Auto refresh to 10 seconds
Save and close
Save the page
Go to Publick pages
Change a record that is connected to the calendar
Wait the information to be refreshed
Click on the “Refresh block””  icon

Expected behavior
Calendar block should refresh as any other block.
Screenshot/Video
https://user-images.githubusercontent.com/53232926/228260718-de7a9906-64d1-4058-adfc-5430750a9be5.webm
Version
Branch: 2023.3.0-dev.5.1
Reporer: Mariya (Test Fest)
Browser: Chrome

For today: investigate issue and make a plan

For today: discuss this with Jože

authors: Bojan-Svirkov katrinDY

repo: cortezaproject/corteza


text:
Getting user id

I use getOAuthToken to authenticate user. How can i get user id ? API doesn't return user id.
Second question, I wanna permanent access(unless user removes the application from setting in instagram.com) even when user is offline. Is it enough to take access token in order to use it forever ?

Okay i solved it :)

repo: cosenary/Instagram-PHP-API

license_source: bigquery


text:
Slow playback during eclipse

This uses currentFractionEclipsed to adjust the playback rate for locations in totality. It realies on a new package point-in-poly.
the playbackRate is now a computed property so it can be adjusted to whatever seems most pleasing.

I LOVE this!! It's working well on both my phone and computer and I'm wondering if we might want to let time autoplay once the user is finished with all the dialogs.
I did set the speed up to start at > 99% instead of 95% because people are impatient and I think most would find that it's too slow for that stretch.
I will also push another commit that adds an explanation for what's happening.

We can merge this if you think my changes are ok, @johnarban.

source: gharchive/pull-request

authors: johnarban patudom


text:
bug: fix docs links

Overview
Links in the docs are broken now, fix them

Fixed

repo: cosmology-tech/starship


text:
feat: update arabica-11

This Celestia testnet got upgraded to https://github.com/celestiaorg/celestia-app/releases/tag/v2.0.0 recently so I updated the list of versions to reference it. Also the existing explorer link was broken so I replaced it with Celenium.
Tagging @jcstein for review

LGTM with one suggestion. One question for @JeremyParish69 and other reviewers, on whether or not we need both codebase.compatible_versions and versions.compatible_versions ?

Yes, the versions array, if anything, is even more important than the codebase's version data. The version data that shown in the codebase section is just aggregating the latest known data from versions[].
I recommend adding it in both sections.

thank you @JeremyParish69. let's add both suggestions then @rootulp then this should be good to go

Thanks! I think this can merge

authors: JeremyParish69 jcstein rootulp

repo: cosmos/chain-registry


text:
Daniyal/issue#1689 remove get versions

Description

closes: #1689

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[x] Targeted PR against correct branch (see CONTRIBUTING.md)
[x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[x] Code follows the module structure standards.
[ ] Wrote unit and integration tests
[x] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[x] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[x] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

Codecov Report

Merging #2539 (acef7fd) into main (4bd05c6) will increase coverage by 0.04%.
The diff coverage is 66.66%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2539      +/-   ##
==========================================
+ Coverage   78.70%   78.74%   +0.04%
==========================================
  Files         178      178
  Lines       12311    12298      -13
==========================================
- Hits         9689     9684       -5
+ Misses       2195     2190       -5
+ Partials      427      424       -3

Impacted Files
Coverage Δ

modules/apps/29-fee/types/msgs.go
90.43% <ø> (-0.33%)
:arrow_down:

modules/core/02-client/types/msgs.go
75.73% <ø> (ø)

.../27-interchain-accounts/controller/types/params.go
47.82% <33.33%> (ø)

...s/apps/27-interchain-accounts/host/types/params.go
42.10% <33.33%> (ø)

modules/apps/transfer/types/params.go
48.00% <40.00%> (ø)

modules/apps/transfer/ibc_module.go
64.96% <66.66%> (+0.03%)
:arrow_up:

modules/apps/transfer/keeper/msg_server.go
100.00% <100.00%> (ø)

modules/apps/transfer/keeper/relay.go
90.63% <100.00%> (+2.56%)
:arrow_up:

modules/apps/transfer/types/msgs.go
95.12% <100.00%> (-0.12%)
:arrow_down:

modules/apps/transfer/types/packet.go
92.00% <100.00%> (+0.33%)
:arrow_up:

... and 1 more

repo: cosmos/ibc-go


text:
add instructions to start a local testnets with X validators

Description:

Scope:

Create a variable N_VALIDATORS that receives a positive integer to start a local testnet
Update README

what is the motivation for this feature?

do certain actions like redelegation

authors: fedekunze jbibla

repo: cosmos/voyager


text:
cherry-pick from release/0.15.0 to master. Part 3. Python Unittest

Add python unittests that check the compatibility with bytes generated on iOS 17, but OpenSSL 1.1 (#1021)
Checklist

[x] Change is covered by automated tests
[x] The [coding guidelines] are followed

@Lagovas JFYI new pythemis test

I don't understand why we need one more tests? they test any new case or flow? or it's regression test for some incident? then will be great to see what incident caused problems in decryption data from ios app in python code

in https://github.com/cossacklabs/themis/pull/1021 I see that was added tests but also don't see why we did it and for what

that's just an additional test in our suite, it's a good thing

that's just an additional test in our suite, it's a good thing

okay, but what prompted you to add this test?
we already have cross-platform integration tests that encrypt/decrypts data using library from different languages and different OS, and python tested too.
maybe we need extend these tests instead of adding edge case without any reason to add it. it's clear for what if we had incident and it will be regression tests
because now this test hard to maintain (need simulator with specific version and specific openssl) and without knowledge how long we are interested in this test. does it test environment features or themis implementation.

As we discuss the test, iOS 18 is already out. I don't mind forgetting about this test because it is no longer relevant.
There is already a newer version of iOS, and we need to think about making Themis work in it.
Finally, what should I do with the pull request?

Let me explain why I don't like tests like that. These tests looks like we have function
def themis_func(x, y):
  return math_lib.sum(x, y)

We have a themis function that can use some math lib (openssl, boringssl) and returns result. This function can be compiled by different compilers and used by a lot of languages. And we calculated one result on one of the platform and test that it similar on the another platform.
And it looks like we calculated 2+2 on ios15 and check that 2+2 the same on GH runner.
2+2 works similar on all platforms. We only need to check that all the code compiled and started together, math_lib properly imported into the themis, it produced some valid output in the real environment and we compare it with the expected value. We don't test here the algorithm used to calculate because he is similar everywhere.
And this test doesn't test anything related to ios15 instead of it was compiled on one of the real machine and stored. And no one can reproduce it again except Rad, who can probably change own env after the time.

authors: Lagovas radetsky vixentael

repo: cossacklabs/themis


text:
Cant not support Chinese file name.

subprocess.getoutput() cant not execute when the post contains Chinese character.

Show me more detials about the issue, please:

What's your system locale encode type ?
Would you paste the Python error logs here ?

Fixed at 71328bd055d155b010f6ef378cd9f924be0045df.


text:
🛑 Mainnet [TezTools] (eu01-node.teztools.net) is down

In a672a14, Mainnet [TezTools] (eu01-node.teztools.net) (https://eu01-node.teztools.net/chains/main/blocks/head/header) was down:

HTTP code: 502
Response time: 570 ms

Resolved: Mainnet [TezTools] (eu01-node.teztools.net) is back up in 1e17bd6.

repo: cotezos/teznodes


text:
vendor install fails on windows

Just installed CouchApp 0.8.1 using the Windows installer.
Running something like:
couchapp vendor install git://github.com/couchapp/vendor.git
on Windows 7 fails with the following error:
2011-10-12 17:32:24 [CRITICAL] [Error 32] The process cannot access the file because
it is being used by another process: 'c:\\users\\owner\\appdata\\local\\tep\\tmp1cl7mj'

Traceback (most recent call last):
  File "couchapp\dispatch.pyc", line 48, in dispatch
  File "couchapp\dispatch.pyc", line 92, in _dispatch
  File "couchapp\commands.pyc", line 280, in vendor
  File "couchapp\vendors\__init__.pyc", line 10, in vendor_install
  File "couchapp\vendors\base.pyc", line 115, in install
  File "couchapp\vendors\base.pyc", line 85, in fetch_vendor
  File "couchapp\vendors\base.pyc", line 21, in _tempdir
WindowsError: [Error 32] The process cannot access the file because it is being
used by another process: 'c:\\users\\owner\\appdata\\local\\temp\\tmp1cl7mj'

that will be addressed in next release of couchapp on next tuesday. Thanks for the feedback

fixed.

authors: benoitc zaim

repo: couchapp/couchapp