Application 1.6.0 crashes on startup - MediaTek bug

openmindculture commented 3 years ago

The current android version keeps crashing on startup. Steps to reproduce: touch the app icon. After showing a splash screen for a few seconds, the app closes without further notice. Earlier versions of the app did work on the same phone. Android systems settings report that corona risk detection is active and that the German Corona Warn App is assigned to manage them. Bluetooth and location service is activated. Error keeps recurring also after restarting the device.

App version: 1.6.0 (updated using google play store on 9 November 2020). Android version: 7.0 (security patch 1 December 2018) Kernel 3.18.35+jslave@WUH1000074104 #3 Hardware: Huawei Honor JMM-L22 Build JMM-L22C432B136 EMU-Version 5.1.3

Avoid duplicates

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

Describe the bug

Expected behaviour

Steps to reproduce the issue

Technical details

Mobile device:
Android version:

Possible Fix

Additional context

Internal Tracking ID: EXPOSUREAPP-3847

JHKobarg commented 3 years ago

Hi, I observed the same behaviour with the 1.6.0 version of the app on both my parent’s HTC Desire 12 (with Android 7.1.1, Kernel 4.4.22+); one device failed to start Friday, the other since today; the App shows the logo/splash screen and then crashes directly; the symptom appears to be identical to the description from #1053 but I tried to execute the countermeasure described there and they are not effective.

The system log begins with

F/libc (339): unable to stat "/proc/self/exe": Permission denied
F/libc (339): Fatal signal 6 (SIGABRT), code -6 in tid 339 (init.lct.bootch)

If you need more information I will try to provide that.

vaubaehn commented 3 years ago

Hi @JHKobarg and @openmindculture , your issues are most likely not connected to #1053 (with #642 as the underlying root cause). ~~However, the problem is addressed in PRs #1612 and #1604. Interpreting #1620 , a hotfix v1.6.1 should be available in the Google Play Store soon.~~

@d4rken : FYI. In case you need more logs, @JHKobarg could probably help out here?

d4rken commented 3 years ago

A system log (logcat) from a few seconds before the app is opened till after it crashes would be very welcome.

For how long does the splash screen stay? If the splash screen stays for ~15 seconds, it would point towards the encryption issue, as the retry mechanism will give up after 15 seconds.

https://github.com/corona-warn-app/cwa-app-android/blob/5bb2427e5671c681d6aad0d53c6a4772855abcb3/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/security/EncryptedPreferencesFactory.kt#L32

https://github.com/corona-warn-app/cwa-app-android/blob/5bb2427e5671c681d6aad0d53c6a4772855abcb3/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/RetryMechanism.kt#L43

openmindculture commented 3 years ago

The splash screen only stays for about 2 seconds, sometimes but not always followed by a white screen for another ca. 4 seconds.

Is there an easy way to generate an error log directly on my phone, or do I have to connect to a pc running adb to do so? I can try to provide an error log tomorrow.

Am 16. November 2020 22:00:13 MEZ schrieb Matthias Urhahn notifications@github.com:

A system log (logcat) from a few seconds before the app is opened till after it crashes would be very welcome.

For how long does the splash screen stay? If the splash screen stays for ~15 seconds, it would point towards the encryption issue, as the retry mechanism will give up after 15 seconds.

https://github.com/corona-warn-app/cwa-app-android/blob/5bb2427e5671c681d6aad0d53c6a4772855abcb3/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/security/EncryptedPreferencesFactory.kt#L32

https://github.com/corona-warn-app/cwa-app-android/blob/5bb2427e5671c681d6aad0d53c6a4772855abcb3/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/RetryMechanism.kt#L43

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/corona-warn-app/cwa-app-android/issues/1609#issuecomment-728326339

d4rken commented 3 years ago

ADB would let you pull only that specific log section.

You can also catch a log via "bugreport" on the device itself.

Note that the bug report may contain sensitive information such as your phone number or log output from other installed apps. I'd recommend to not post that publicly, but you could share (email/cloud) that directly with me if that is okay for you (matthias.urhahn@sap.com).

openmindculture commented 3 years ago

logcat.log

Here is a logfile around a cwa crash. As the log mentions "not enough space" on my device, I will retry to reproduce the crash after freeing up some space.

openmindculture commented 3 years ago

Freed up memory, force stopped cwa app, restarted the phone, then launched cwa again. Same bug keeps ocurring.

d4rken commented 3 years ago

Awesome thanks for the log, so this is the stacktrace:

11-17 12:23:03.635 29303 29328 E AndroidRuntime: Process: de.rki.coronawarnapp, PID: 29303
11-17 12:23:03.635 29303 29328 E AndroidRuntime: java.lang.ClassCastException: kotlinx.coroutines.channels.ProducerCoroutine cannot be cast to kotlin.jvm.functions.Function2
11-17 12:23:03.635 29303 29328 E AndroidRuntime:    at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsJvmKt$createCoroutineUnintercepted$$inlined$createCoroutineFromSuspendFunction$IntrinsicsKt__IntrinsicsJvmKt$4.invokeSuspend(IntrinsicsJvm.kt:7)
11-17 12:23:03.635 29303 29328 E AndroidRuntime:    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3)
11-17 12:23:03.635 29303 29328 E AndroidRuntime:    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:15)
11-17 12:23:03.635 29303 29328 E AndroidRuntime:    at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:1)
11-17 12:23:03.635 29303 29328 E AndroidRuntime:    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:13)
11-17 12:23:03.635 29303 29328 E AndroidRuntime:    Suppressed: java.lang.ClassCastException: kotlinx.coroutines.channels.ProducerCoroutine cannot be cast to kotlin.jvm.functions.Function2
11-17 12:23:03.635 29303 29328 E AndroidRuntime:        ... 5 more

Seems to be this:

That's a tough cookie :frowning_face: According to b/140347159 on Google's bug tracker it's a bug in the VM of your ROM. Where the code of our app is just right to trigger it.

I can find similar stacktraces for other devices, all with Android 7.0-7.1, and all with Mediatek Chipsets.

Will analyze this further to see what would be the best way forward. Some thoughts:

This could be fixed by any update if we are lucky enough that the code is just compiled different enough to not hit that VM bug.
Could adjust the proguard config so that R8 shrinks the code differently so that we no longer hit this. Difficult to see which code to target as the stacktrace is unspecific :thinking:

vaubaehn commented 3 years ago

@d4rken this looks like bad news in general, as the bug could occur anytime when the triggering byte code is compiled by chance in future updates... And even Google can fix this issue in a timely manner, will the vendors provide updates for their old devices? (Or is this something that can go through Google Play Services?)

Is there any Huawei Honor JMM-L22 with Android 7 in the Telekom test farm as a test device? If not, then it's maybe time to add one...

vaubaehn commented 3 years ago

@JHKobarg as you are also on Android 7, and your HTC Desire 12 also owns a MediTek chipset, there is a large likelihood, that you're also experiencing the VM Bug. @openmindculture and @JHKobarg , CWA 1.6.1 just released in Play Store in these minutes. The fixes of that hotfix release are not adressing your problem here. But it would be wonderful if you updated, and report back, if by chance the crash is gone for you (in other words, the byte code change was already good enough). Thanks a lot!

d4rken commented 3 years ago

will the vendors provide updates for their old devices?

I wouldn't get my hopes up. Devices withMediaTek chipsets are unfortunately notorious for this, few updates and ROM specific bugs :frowning:.

(Or is this something that can go through Google Play Services?)

The fix would have to come as OTA from the device manufacturer.

vaubaehn commented 3 years ago

Irgendwas ist ja immer. :slightly_frowning_face: (didn't know how to express in English)

vaubaehn commented 3 years ago

@d4rken but to have a positive perspective on that issue: Until now, at least the VM bug was not affecting CWA. And maybe after any arbitrary update, it won't occur again. Let's keep fingers crossed.

vaubaehn commented 3 years ago

@d4rken one idea: did I see right, that devs put some APKs to the tracked google issue? If it's a specific byte code that triggers the crash, wouldn't it be possible to compare the compilations on binary level, and to search for similar patterns? If the triggering pattern could be identified, then at least after CWA compilation the compiled code could be scanned to be free of the trigger. Worth investigating?

vaubaehn commented 3 years ago

@d4rken another approach could be to build yourself using https://github.com/Kotlin/kotlinx.coroutines/pull/1648#issuecomment-617143634 - this seems to fix/workaround/mitigate it. Not sure if it's possible and worth the effort.

d4rken commented 3 years ago

@d4rken one idea: did I see right, that devs put some APKs to the tracked google issue? If it's a specific byte code that triggers the crash, wouldn't it be possible to compare the compilations on binary level, and to search for similar patterns? If the triggering pattern could be identified, then at least after CWA compilation the compiled code could be scanned to be free of the trigger. Worth investigating?

Maybe, but I'm not sure if it's an effective approach. Each update contains so many changes, and we don't have a locally reproduced case, finding the byte code that causes this could take weeks if not month. But even if we had a device where we could reproduce it locally. Once found it's not guaranteed that there is a fix available that would help all affected devices, it may be that each device needs it's own specific variant of a fix.

@d4rken another approach could be to build yourself using Kotlin/kotlinx.coroutines#1648 (comment) - this seems to fix/workaround/mitigate it. Not sure if it's possible and worth the effort.

That looks interesting and will be looked into.

vaubaehn commented 3 years ago

Maybe, but I'm not sure if it's an effective approach. Each update contains so many changes, and we don't have a locally reproduced case, finding the byte code that causes this could take weeks if not month. But even if we had a device where we could reproduce it locally. Once found it's not guaranteed that there is a fix available that would help all affected devices, it may be that each device needs it's own specific variant of a fix.

I was assuming, there may be only one specific byte code that triggers the crash for all apps that contain that specific byte code (on Android 7 devices with MediaTek chipset). When comparing different apps (of different producers) experiencing the crash, maybe that triggering byte code could be identified. If you then know that code, in the end, you could check if your own compiled code contains that specific pattern that causes the crash. If yes,

This could be fixed by any update if we are lucky enough that the code is just compiled different enough to not hit that VM bug.

Could adjust the proguard config so that R8 shrinks the code differently so that we no longer hit this. Difficult to see which code to target as the stacktrace is unspecific thinking

If no, do nothing. So, if my assumptions would be right, that'll just be workaround, not a fix.

That looks interesting and will be looked into.

If this looks promising for you, then this is actually the best way.

I'm off for the time - have a nice evening and rest of the week!

openmindculture commented 3 years ago

As of 18 November 2020 on 8:31 a.m. CET, I still do not see CWA 1.6.1 in my German Google Play Store.

As soon as I will, I will install the update and give feedback.

Am 17. November 2020 17:46:01 MEZ schrieb vaubaehn notifications@github.com:

@JHKobarg as you are also on Android 7, and your HTC Desire 12 also owns a MediTek chipset, there is a large likelihood, that you're also experiencing the VM Bug. @openmindculture and @JHKobarg , CWA 1.6.1 just released in Play Store in these minutes. The fixes of that hotfix release are not adressing your problem here. But it would be wonderful if you updated, and report back, if by chance the crash is gone for you (in other words, the byte code change was already good enough). Thanks a lot!

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/corona-warn-app/cwa-app-android/issues/1609#issuecomment-729054516

openmindculture commented 3 years ago

CWA 1.6.1 works, no more crash.

Am 17. November 2020 18:38:28 MEZ schrieb vaubaehn notifications@github.com:

Maybe, but I'm not sure if it's an effective approach. Each update contains so many changes, and we don't have a locally reproduced case, finding the byte code that causes this could take weeks if not month. But even if we had a device where we could reproduce it locally. Once found it's not guaranteed that there is a fix available that would help all affected devices, it may be that each device needs it's own specific variant of a fix.

I was assuming, there may be only one specific byte code that triggers the crash for all apps that contain that specific byte code (on Android 7 devices with MediaTek chipset). When comparing different apps (of different producers) experiencing the crash, maybe that triggering byte code could be identified. If you then know that code, in the end, you could check if your own compiled code contains that specific pattern that causes the crash. If yes,

This could be fixed by any update if we are lucky enough that the code is just compiled different enough to not hit that VM bug.

Could adjust the proguard config so that R8 shrinks the code differently so that we no longer hit this. Difficult to see which code to target as the stacktrace is unspecific thinking

If no, do nothing. So, if my assumptions would be right, that'll just be workaround, not a fix.

That looks interesting and will be looked into.

If this looks promising for you, then this is actually the best way.

I'm off for the time - have a nice evening and rest of the week!

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/corona-warn-app/cwa-app-android/issues/1609#issuecomment-729087684

vaubaehn commented 3 years ago

@openmindculture Great, thanks a lot! This gives some space for breathing and time for devs to adapt their testing strategy before future roll outs. But probably @d4rken will find a long lasting solution for that unforeseen problem :slightly_smiling_face:

vaubaehn commented 3 years ago

@openmindculture I read some more about the bug, and obviously at might reappear also with 1.6.1 at this stage of investigating the bug: https://issuetracker.google.com/issues/140347159#comment17 Would you be willingful to help investigating a little? In worst case, it would take a little effort on your side.

What we could try out with your device: Leave it on the charger during the night, and also maybe for the day time if possible. This could trigger a recompilation/optimization of CWA by your device. The byte code of death could actually occur again, and then also the update 1.6.1 would crash... But hopefully not! In case of a crash you could reactivate CWA as follows:

install 'immuni' or any other COVID tracing app that makes use of Google's ENF.
start 'immuni' (or other app), make sure that it will be used by ENF and CWA is deactivated by ENF.
uninstall CWA
reinstall CWA 1.6.1 from Google Play Store It should work again then, until the CWA's code is recompiled/optimized again. Short but frequent charging times could prevent recompiling in future.

But full understanding from my side, if this is just too much effort for you to test, if CWA 1.6.1 might crash again.

Anyway, thanks a lot for your support here!

edit: forgot to explain: installing 'immuni' or other ENF-app before uninstalling CWA will keep your recorded contacts safely on your device to get warned if there was an encounter with positive tested person! Otherwise they would be erased when uninstalling CWA.

JHKobarg commented 3 years ago

Hi, I just had a remote session with my parents “How to update Apps manually via Google Store” ... after the update to 1.6.1 they both report the app starts again. Thanks for your help.

As for log files, I could only provide a screenshot from the error message produced by the app. Probably that is not what you need. Though they said, they submitted a couple of that crashes (presumably via the PlayStore feedback?).

d4rken commented 3 years ago

I'm very happy that 1.6.1 solved it for a few users. The nature of the bug unfortunately just means that it's "by chance", and Google Play based stack traces show that this still happens for other users :frowning:, although noticeably less often than in 1.6.0. We will keep monitoring this and are evaluating @vaubaehn's kotlin dependency update suggestion as first mitigation.

openmindculture commented 3 years ago

Leave it on the charger during the night, and also maybe for the day time if possible. This could trigger a recompilation/optimization of CWA by your device. The byte code of death could actually occur again, and then also the update 1.6.1 would crash...

And so it did. CWA 1.6.1 crashed. Do you need more logs?

vaubaehn commented 3 years ago

@openmindculture That's extremely disappointing. 😳 But thanks very much for your report. If you already took a log, could probably be useful to double check that there's not a second unrelated issue (like #642). If you didn't do yet, we could wait for @d4rken If it's worth the effort. If you urgently need/want exposure logging, then I'd recommend to recover CWA like described above, and prevent long charging times. Thanks again

vaubaehn commented 3 years ago

@d4rken

Google Play based stack traces

Are they actively submitted via bug reports? Cause I didn't see any Firebase dependencies?

Batterypack200 commented 3 years ago

I can confirm the bug in version 1.6.1. Smartphone: Motorola E4, MediaTek MT6735 Android 7.1.1 The same bug at the Smarphone of my wife: same cell phone, same bug.

openmindculture commented 3 years ago

The undesirable optimization, that reintroduces the bug, also happens after 1-2 hours charging. Reactivating the original cwa 1.6.0 by installing immuni worked, but erased all my previous German tracking history! So I had 2 days of a working cwa 1.6.0 with only 2 days of data coverage, until it crashed again yesterday. Still no sign of 1.7.0 for me in Google app store.

dsarkar commented 3 years ago

Regarding the update to CWA 1.7: Please note that it is a staged rollout. Over the next two days, 100% of the users should have received the update.

Best wishes, DS

Corona-Warn-App Open Source Team

ghost commented 3 years ago

If the update to CWA 1.7 was supposed to fix it - it didn't.

I have exactly the same hardware. I skipped the 1.6 and when I updated from 1.5 to 1.7 (the new one), this exact bug occurs.

dsarkar commented 3 years ago

Dear community,

Thanks for contributing here. Stand by for an update to version 1.7.1, it should be available very soon.

Regarding the update to CWA 1.7.1 (for both iOS and Android): Please note that it is a staged rollout. Over the next two days, 100% of the users should have received the update.

We would appreciate very much your feedback regarding this issue over the next few days!

Best wishes, DS

Corona-Warn-App Open Source Team

ghost commented 3 years ago

Thanks, @dsarkar - I'll look forward to it.

vaubaehn commented 3 years ago

@openmindculture

Reactivating the original cwa 1.6.0 by installing immuni worked, but erased all my previous German tracking history! So I had 2 days of a working cwa 1.6.0 with only 2 days of data coverage, until it crashed again yesterday.

Just to prevent any misunderstanding: What was deleted was only the Exposure Check History, the log of matching your stored contacts/exposures against the published diagnosis keys of positive tested users. So, the most important data is still retained on your device: the received rolling proximity identifiers (RPIs), which are the beacons of other users with contact tracing apps (CWA) that your device recorded. And the temporary exposure keys (TEKs) that your device generates to provide warnings to other users in case you get tested positive and you're submitting your keys. (They would have been deleted, if you not have had installed Immuni.) The tracking history is mostly only useful for identifiying problems. In case you're interested in joining our community slack channel, these or other open questions/issues could be discussed there.

openmindculture commented 3 years ago

Regarding the update to CWA 1.7: Please note that it is a staged rollout. Over the next two days, 100% of the users should have received the update.

Best wishes, DS

Corona-Warn-App Open Source Team

Those staged rollouts always take several days for me in google play store. Other stores, like f-droid or Huawei AppGallery don't offer CWA at all. The github release tgz seems to be empty when opened on my mobile.

For a quick rollout and easy access for fellow devs willing to colloborate and give feedback, it would be helpful if you could relase apk files on github if this is possible with reasonable effort.

MikeMcC399 commented 3 years ago

@openmindculture

For a quick rollout and easy access for fellow devs willing to colloborate and give feedback, it would be helpful if you could relase apk files on github if this is possible with reasonable effort.

The CWA 1.7.0 staged rollout was halted after significant bugs were found. This rollout has now been replaced by CWA Android 1.7.1 with the respective hotfixes incorporated. So the two day rollout clock has been restarted. I agree that it is awkward for fellow collaborators who would like to give quick feedback. Unfortunately going to the Google Play Store manually doesn't let you by-pass the staged rollout.

The official answer in the FAQ about the availability of apks is here. In practice though, Google Play Store apks find their way onto apkmirror.com but I would not recommend downloading 1.7.0 from there since that version has been withdrawn (unless perhaps you are just installing on a test device).

BTW: I'm also waiting for 1.7.1 to appear on my instance of Google Play Store!

thomasaugsten commented 3 years ago

V1.7.1 has not a 2 day rollout you should see the update in the playstore

ghost commented 3 years ago

Just got 1.7.1 a few minutes ago.

It opens again and doesn't crash, which is good.

However, right now, it's stuck at checking the data for at least 3minutes. Considering that I haven't been outside the house for 24 hours, that's a bit odd.

ETA: I had to press the arrow on the checking screen repeatedly, sometimes it closed itself then, sometimes I could get to the other "tab" (where the hygiene rules are). Now finally, after at least 5 minutes things look normal again.

I'll cross my fingers that you guys fixed it for good. The next days will tell.

Thanks for being this fast.

ghost commented 3 years ago

Well, there are still problems.

Same problem as yesterday. It's stuck on the checking screen, pressing the arrow sometimes makes it crash, sometimes it gets you to the screen where the hygiene rules are.

I was fiddling with it for thirty minutes whereas before, with 1.5, I was done with in under 5.

I am seriously consideing uninstalling, cleaning the cache and reinstalling fresh.

d4rken commented 3 years ago

@Yanabamenara The described behavior is very likely unrelated to this issue ticket, could you create a new one such that it can be independently investigated?

However, right now, it's stuck at checking the data for at least 3minutes. Considering that I haven't been outside the house for 24 hours, that's a bit odd. Same problem as yesterday. It's stuck on the checking screen, pressing the arrow sometimes makes it crash, sometimes it gets you to the screen where the hygiene rules are.

It should never crash, that's 100% a bug. It being "stuck" or taking longer is not necessarily a bug. From v1.5 to v1.7, the whole process changed a lot. Not only does the app download more data (days+hours), but the actual progress display is more accurate. Previously it would mostly show the progress of the file download, but now it also shows a progress indicator while Google is checking for matches out side of the CWA.

I don't have access to your type of device so I can't say if 3 minutes is an expected amount of processing time.

If the app crashed due to a UI bug, it's possible that the CWA missed the callback regarding Google's key matching being done. This would result in a progress display of ~15 minutes after which our internal check will treat it as "timeout".

If this is reproducible, maybe you could record a video to help me better understand what's going on?

I am seriously consideing uninstalling, cleaning the cache and reinstalling fresh.

I don't think this is required, please wait at least a full day. If something could out of line with the day downloads I'd expect it to fix itself after a 24h and a new day package being available for download.

ghost commented 3 years ago

I can do that.

There's a progress indicator? Where can I find that? BTW, I have the same device as listed by openmindculture, who started this thread.

ETA: I'll see if I can record a vid with the tablet within the next days.

thomasaugsten commented 3 years ago

@Yanabamenara you can also use the integrated screen recorder but please be aware it will record the surrounding sounds You can upload to a cloud or e-mail me directly https://consumer.huawei.com/en/support/content/en-us00762396/

ndegendogo commented 3 years ago

I am seriously consideing uninstalling, cleaning the cache and reinstalling fresh.

@Yanabamenara please be aware that uninstalling the app will also delete your collected RPI (contacts) of the past 14 days. Try to avoid this. (And should you really need it: there are recommended procedures, like first installing and activating a compatible covid tracing app from another country)

ghost commented 3 years ago

@Yanabamenara you can also use the integrated screen recorder but please be aware it will record the surrounding sounds You can upload to a cloud or e-mail me directly [...]

I managed to get one of the crashes with the tablet, when opening and emailed you that short one.
I don't use the Huawei cloud.

ETA: Well, that didn't work, the email system at sap rejected it. I emailed you an unlisted peertube link instead.

d4rken commented 3 years ago

Based on bug reports from @Yanabamenara I could narrow down the code the issue partly originates from, which is

https://github.com/corona-warn-app/cwa-app-android/blob/3ad97ffa06df60905eccff571ef462d24edf4f04/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/tracing/GeneralTracingStatus.kt#L22

Curiously the behavior for @Yanabamenara is slightly different than expected, as it's not a permanent crash, but the app opens on subsequent opening attempts.

stack traces

```kotlin 11-28 21:37:05.926 5429 5429 E AndroidRuntime: FATAL EXCEPTION: main 11-28 21:37:05.926 5429 5429 E AndroidRuntime: Process: de.rki.coronawarnapp, PID: 5429 11-28 21:37:05.926 5429 5429 E AndroidRuntime: java.lang.ClassCastException: kotlinx.coroutines.channels.ProducerCoroutine cannot be cast to kotlin.jvm.functions.Function2 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsJvmKt$createCoroutineUnintercepted$$inlined$createCoroutineFromSuspendFunction$IntrinsicsKt__IntrinsicsJvmKt$4.invokeSuspend(IntrinsicsJvm.kt:7) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:15) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at kotlinx.coroutines.EventLoop.processUnconfinedEvent(EventLoop.common.kt:7) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at kotlinx.coroutines.internal.DispatchedContinuationKt.resumeCancellableWith(DispatchedContinuation.kt:23) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at kotlin.collections.CollectionsKt__CollectionsKt.startCoroutineCancellable(Collections.kt:1) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at kotlin.collections.CollectionsKt__CollectionsKt.startCoroutineCancellable$default(Collections.kt:1) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at kotlinx.coroutines.AbstractCoroutine.start(AbstractCoroutine.kt:16) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at kotlin.collections.CollectionsKt__CollectionsKt.launch$default(Collections.kt:7) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at de.rki.coronawarnapp.ui.main.home.HomeFragment.onViewCreated(HomeFragment.kt:46) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at androidx.fragment.app.FragmentManager.moveToState(FragmentManager.java:115) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at androidx.fragment.app.FragmentManager.addAddedFragments(FragmentManager.java:5) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:53) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:11) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at androidx.fragment.app.FragmentManager.execPendingActions(FragmentManager.java:14) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at androidx.fragment.app.FragmentManager.dispatchStateChange(FragmentManager.java:5) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at androidx.fragment.app.FragmentManager.moveToState(FragmentManager.java:129) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at androidx.fragment.app.FragmentManager.moveFragmentToExpectedState(FragmentManager.java:4) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at androidx.fragment.app.FragmentManager.moveToState(FragmentManager.java:360) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at androidx.fragment.app.FragmentManager.dispatchStateChange(FragmentManager.java:3) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at androidx.fragment.app.FragmentActivity.onStart(FragmentActivity.java:9) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at androidx.appcompat.app.AppCompatActivity.onStart(AppCompatActivity.java:1) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at android.app.Instrumentation.callActivityOnStart(Instrumentation.java:1254) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at android.app.Activity.performStart(Activity.java:6932) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2834) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2946) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at android.app.ActivityThread.-wrap12(ActivityThread.java) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1634) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:113) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at android.os.Looper.loop(Looper.java:205) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:6783) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1225) 11-28 21:37:05.926 5429 5429 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1086) ``` ```kotlin 11-28 08:56:38.568 5292 5292 I AEE_AED : Build fingerprint: 'HUAWEI/JMM-L22/HWJMM:7.0/HUAWEIJMM-L22/C432B136:user/release-keys' 11-28 08:56:38.568 5292 5292 I AEE_AED : Revision: '0' 11-28 08:56:38.568 5292 5292 I AEE_AED : ABI: 'arm64' 11-28 08:56:38.569 5292 5292 I AEE_AED : pid: 4721, tid: 4777, name: DefaultDispatch >>> de.rki.coronawarnapp <<< 11-28 08:56:38.569 5292 5292 I AEE_AED : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8 11-28 08:56:38.569 5292 5292 I AEE_AED : x0 00000000333aadb0 x1 0000000000000008 x2 0000000000000002 x3 0000000000000000 11-28 08:56:38.569 5292 5292 I AEE_AED : x4 00000078e41fbc30 x5 00000078e41fbc28 x6 000000000000003f x7 0000000000000000 11-28 08:56:38.569 5292 5292 I AEE_AED : x8 0000000000000000 x9 0000000033585fb8 x10 0000000000000c60 x11 00000078e41ff4e8 11-28 08:56:38.569 5292 5292 I AEE_AED : x12 00000078c86f6190 x13 0000000000000001 x14 00000000fffffff8 x15 0000000000000028 11-28 08:56:38.569 5292 5292 I AEE_AED : x16 000000000003f1b0 x17 000000000000821c x18 0000000c00000000 x19 00000078e4227600 11-28 08:56:38.569 5292 5292 I AEE_AED : x20 0000000033585fb8 x21 00000000334c0e40 x22 00000000334c0e78 x23 00000000333aaf50 11-28 08:56:38.569 5292 5292 I AEE_AED : x24 000000000000000b x25 00000000333aada0 x26 000000003385cec0 x27 00000078cb113580 11-28 08:56:38.569 5292 5292 I AEE_AED : x28 00000000333aadb0 x29 0000000000000000 x30 00000078cec7bb5c 11-28 08:56:38.569 5292 5292 I AEE_AED : sp 00000078e41fbd20 pc 00000078cec7bb94 pstate 0000000020000000 11-28 08:56:38.569 5292 5292 I AEE_AED : 11-28 08:56:38.569 5292 5292 I AEE_AED : backtrace: 11-28 08:56:38.570 5292 5292 I AEE_AED : #00 pc 000000000004ab94 /dev/ashmem/dalvik-jit-code-cache (deleted) 11-28 08:56:38.570 5292 5292 I AEE_AED : #01 pc 000000000004ab58 /dev/ashmem/dalvik-jit-code-cache (deleted) ```

d4rken commented 3 years ago

Can someone affected look into their exposure detection system log and check the frequency? I'm curious whether the issue is UI related and the app possibly executes sometimes or all the time in the background.

Based on the recent logs, I can at least say that #1707 goes into the right direction, the isTracingEnabled flow is in the code path where @Yanabamenara's stacktraces point.

ghost commented 3 years ago

Over the weekend, the app cannot be opened anymore. It's back to crash on startup. If you guys need anything more from me, like another bug report to compare, do ask, please.

d4rken commented 3 years ago

@Yanabamenara Can you post a screen of Device > Settings > Google > "Covid-19-Benachrichtungen" > Menu > "Überprüfungen auf mögliche Begegnungen" ? It will tell us whether the app executed in the background despite crashing on opening .

ghost commented 3 years ago

Screenshot_20201130-131506

Sure, can do. Doesn't look like it executed in the background.

ETA: I didn't cut this screenshot, because I normally would open the app in wlan daily every morning, so you can see when it didn't work.

dsarkar commented 3 years ago

@Yanabamenara, Thanks for reporting. Although this is a different issue, is the background actualization now working or still stuck since 28. November? Thanks, DS

dsarkar commented 3 years ago

@Yanabamenara, Is the background actualization now working or still stuck since 28. November? Feedback much appreciated. Thanks, DS

corona-warn-app / cwa-app-android