Corona-Warn wird wiederholt beendet

[creiser-jambit]

Avoid duplicates

• [ X ] Bug is not mentioned in the FAQ
• [ X ] Bug is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in the documentation repository
• [ X ] Bug is not already reported in another issue

Describe the bug

I use the Warn app for ~2 Month now. I had not issues until recently. Unfortunately now it is no longer possible to open the app. When trying to open the app i get the message "Corona Warn app is beeing terminated repeatedly".

Expected behaviour

When launching the app by selecting the icon, the app should be displayed on the screen

Steps to reproduce the issue

1. Launch the app by pressing the app icon in the app list.
2. App crashes

Technical details

• Mobile device: Google Pixel 2
• Android version: 10 (Build QQ3A.200805.001

Possible Fix

Delete all app Data. I have not tried, since I would prefer not to loose my contact history.

Additional context

---

Internal Tracking ID: EXPOSUREAPP-2571

[Marco2907]

Hi @creiser-jambit, thanks for sharing your content. I will keep this issue and will discuss this internally with our development team. I will come back to you as soon as possible.

Thanks,
MP

Corona-Warn-App Open Source Team

---

Internal Tracking ID: EXPOSUREAPP-2571

[daimpi]

A similar problem has been reported in #642 (comment) by @Annie-G (with a possible workaround described below).

This issue could also be related to #1053.

[creiser-jambit]

Dear @daimpi ,
Workaround would be deleting app data - I guess this will work for me, but will make it harder to find the real issue. Issue #1053 might be the same, but without debug data I cannot judge, whether it really is the same...

[alois31]

I'm having this crash now as well on my P8 lite with Android 6.0.1. I would provide detailed logs if you think they'd help for debugging, but I would prefer not posting them in public.

[svengabr]

Thank you for your efforts @alois31

This bug might be also related to #933 (comment)

[vaubaehn]

Hi @alois31 ,
@svengabr referred to a firmware update, that sets CWA to a Huawei internal white list, to excempt CWA from aggressive battery optimization of Huawei devices, that can be related to this app crash.
The Huawei blog states, that the firmware update seems to be available for EMUI 10. As you probably have EMUI 4, it might be not available for you, but anyway it's worth checking.

I'll try to compile some first-aid instructions related to the app crash in issue #1053 during the next hours. I'll also add instructions for additional settings especially for Huawei P8 lite in that same issue. Will notify you from here, when it's finished.

[vaubaehn]

Hi @alois31 ,
I now compiled the above mentioned information here: #1053 (comment)

But when you're able to provide debug logs, you might not need such information on how to reset CWA 😉. Anyway, some of the additional Huawei settings might be of interest for you (one comment below that linked one).

If you still want to provide your debug logs, you can contact me on slack:
corona-warn-app/cwa-documentation#379

[alois31]

Regarding the comment by @svengabr, my issue might be related in the sense that it's caused by aggressive background termination (until the crashes started, background update worked though; I had to reset the apps multiple times already because of #642). I had the same stack trace as the reporter on the Pixel in this issue (ignoring line number differences because the Android version is different), so I thought to post here.

I have now added CWA to the protected apps list as suggested by @vaubaehn (I doubt that Huawei will roll out an update to my phone, given that it didn't receive any updates for ~2y now). I didn't find the usage data setting, but that seems to be a red herring because the NPE happens only after CWA has crashed (presumably the LogCollectManager would be like to show a stack trace screen like in this issue report).

I have provided logs to @vaubaehn and will reset CWA now. If the issue happens again despite CWA being protected, I will report back.

[vaubaehn]

Hi @alois31 ,

I have now added CWA to the protected apps list as suggested by @vaubaehn (I doubt that Huawei will roll out an update to my phone, given that it didn't receive any updates for ~2y now).

👍

I didn't find the usage data setting,

Could you do me a favor and try to find out, where it is located (not having a EMUI 4 phone here...)?
You may also find that setting via Settings > Security > Usage Data Access (Apps mit Nutzungsdatenzugriff) or Settings > Apps > Apps > Permissions or Settings > Security > Permissions ... or similar. If you could provide the path on how to navigate to that setting, would be wonderful.

but that seems to be a red herring because the NPE happens only after CWA has crashed (presumably the LogCollectManager would be like to show a stack trace screen like in this issue report).

I understand your concern here, and I am also not sure, if crashes can be avoided by deactivating logging of LogCollectManager.
But the reason, why I am still stucked on the hypothesis, that the LogCollectManager could provocate crashes of CWA:

• searching for similar problems reveals some reports, where developers experience crashes of their apps on Huawei devices only in context of LogCollectManager, e. g. here or here
• The other way round, while especially older Huawei devices have problems with crashes resulting in database access corrupted, non-Huawei devices face these problems much more rarely. While the underlying root cause for the inital crash may differ widely (killed process by battery optimization, incompatibility of handling IO settings for BT, network, location between manufacturer OS and Google's ENF -> Sony Xperia, timeouts due to different reasons, etc.), the LogCollectManager may be one of them.

However, if that was true, I assume a bug in CWA to be the reason to crash the hooking LogCollectManager, without the bug having any effect on JVM at the runtime on other devices. One reason why the crash is occuring occasionally, is that LogCollectManager may randomly analize user behavior, or there needs to be a specific context to trigger that crash -> for example, when CWA's playbook gets active from time to time!
So, I'm not so sure whether this is a red herring.

I have provided logs to @vaubaehn and will reset CWA now. If the issue happens again despite CWA being protected, I will report back.

Thank you very much for your support and trust! I will handle them with care. Not sure if I find time today to have a look, but during the next week should be possible to have a peek.

See you!

Edit: Everything I wrote above about LogCollectManager has the following pre-assumption:

1. CWA works without problems first.
2. LogCollectManager crashes (initial crash).
3. Open Database and/or EncryptedSharedPreferences get corrupted or altered.
4. Next start of CWA: EncryptedSharedPreferences not accessible => Immediate app crash or exception 9002

[creiser-jambit]

Dear all,
since I got the impression that it might be impossible to restore/recover the corrupted data and I want to have the CWA running, I deleted the app data and now it works again.

[alois31]

Okay, I have found the usage data setting now: "Einstellungen" > "Einstellungen" [sic] > "Sicherheit" > "Apps mit Nutzungsdatenzugriff". I didn't find "Huawei Mobile Services" there, but it was already off for "HMS Core" and "Huawei Services Framework".

CWA crashes again now with the same stack trace. My theory what's happening is the following:

1. Assumption: CWA or a library it uses does not employ robust file operations when writing encrypted data.
2. CWA writes to the EncryptedSharedPreferences (this bug) or the encrypted database (Cause 9002: file is not a database: , while compiling: select count(*) from sqlite_master; #642).
3. CWA gets killed during the write, e.g. because of battery optimization, low memory or user request (force stop).
4. The next time CWA opens, the encrypted data are corrupted because they were partially written to. Both EncryptedSharedPreferences and the database refuse to operate on corrupt ciphertext.
5. • In the case of Cause 9002: file is not a database: , while compiling: select count(*) from sqlite_master; #642, CWA catches the exception and the dialog appears.
   • In the case of the present bug, CWA does not catch the exception and crashes.
6. LogCollectManager is notified of the crash, presumably to present a screen similar to what's shown in the screenshots in this report.
7. LogCollectManager is buggy and crashes itself with the NPE.

The P8 lite is probably a low-end phone by today's standards, and Huawei is known to employ aggressive battery optimizations. Do bugs #642 and this one also occur more frequently on low-end phones from other manufacturers that employ aggressive battery optimization?

I have also found another setting now: "Einstellungen" > "Apps" > "Erweitert" > "Optimierungen ignorieren", which was not allowed for CWA, and I had to set first re-set it to not allowed before I could toggle it to allowed. I have set it to allowed now and reset CWA again.

[daimpi]

A potential fix is coming with PR #1235 (targeted for CWA 1.4) 🙂.

[svengabr]

Relates to #642

[creiser-jambit]

As I wrote on September 11th, i reset the app. Unfortunately the issue seems to be present again - with a slightly different Stacktrace. But I guess, this is the same issue...
It worked for quite a while now (Data Reset on September, 11th). Last Thursday I had a crash of the phone (I guess it is a problem with my battery) - phone turned of instantly during listening loud audio. Since this point in time I am no longer able to start the App. I get the notice "Corona-Warn wird wiederholt beendet" again.

Stacktrace looks little different, so I re-attach. Might be due to updated version and/or OS.

Obviously I am a lucky guy... I will re-reset the data tomorrow noon, since I guess there is no information on my device which could help anybody to analyse the issue...

[d4rken]

@creiser-jambit Thank you for sharing your stacktrace. The stacktrace looks different due to changes I made to the encryption related code (#1235). It retries a few times until surfacing the original cause (note the Permanently failed to... in the stack trace).

Do you know whether the error condition existed before you upgraded to 1.5.0+? The new code should prevent it from happening on 1.5.0+, but it's not a state that can be recovered from if pre-existing.

(There should have been an automatic reset but there's a bug in that due to a mistake I made (see #1433).)

So if the error state existed before the upgrade, then this is working as expected, but if you already were on 1.5.0 and there was no error initially, then this is a new issue.

[creiser-jambit]

The crash took place last thursday - 15.10.2020. When looking in the play store app, it states "update 8 hours ago" (I use auto-updating). Unfortunately I am not able to find a release-history/changelog.

[vaubaehn]

Hi @creiser-jambit , just to give you some additional information:
There is a quite complex bug outside of CWA (buggy interaction between another security extension and the Android KeyStore), but as a consequence in some cases the encrypted storage of CWA remains inaccessable. In your case it looks like, the sudden shutdown while listening to music and the subsequent reboot shook through the Android KeyStore, so that CWAs storage couldn't be recovered after. The developer @d4rken found out the root causes, and coded a certain mechanism to try a recovery to access the stored data. In case the retry fails, CWAs storage would need to be reset.
The retry/reset mechanism was intended to work for you in particular, because the crash happened already with CWA 1.3.1 last week, and the update to 1.5.0 should recover the app.
As the bug is very hard to reproduce in laboratory conditions, the code for the recovery needed to be developed by only abstracting from user reports (and their stracktraces), as well as from few internet resources of problem descriptions (not only CWA is affected, but also some other apps using encryption for storage). Unfortunately, because the first implementation of that retry mechanism could not yet succeed, @d4rken already re-coded that mechanism yesterday, so that it should work with the next release of CWA - either with a hotfix release (I hope!), or with the release of the next regular version 1.6 (I hope noone needs to wait that long!).
For the time beeing, you could re-reset the data again to make CWA work again.
Cheers, V.

[creiser-jambit]

Dear @vaubaehn ,
thanks a lot for the detailed explanation. So I am looking forward to 1.6 and try to prevent any hard crashes...
Best regards, CR

[MikeMcC399]

This issue with the label "hot topic" hasn't had any further comments in it lately.

The last mentioned version was 1.6 which was released on Nov 11, 2020. The current version is 1.7.1.

[dsarkar]

@MikeMcC399, thanks. We keep this one open for the moment.

Best wishes,
DS

---

Corona-Warn-App Open Source Team

[heinezen]

We cannot reproduce this on newer versions CWA >1.5, so this is probably fixed. This issue will therefore be closed.

---

Corona-Warn-App Open Source Team