Closed smichel17 closed 2 years ago
I did experience it too once, but couldn't reproduce it after. Maybe a feature to show logs from within the app could help find the cause. @matkoniecz wanted to implement something like that.
Am 18. September 2021 03:36:19 MESZ schrieb smichel17 @.***>:
How to Reproduce>
- Open a quest>
- Select
Other Answers
>Can't Say…
>OK
>- Hit the button to open the camera app>
- Take a photo>
Expected: Photo is taken and attached to the note> Actual: StreetComplete instantly closes and the photo is lost. There is no "StreetComplete crashed" message, the app is just killed.>
This is a very frustrating bug to track down because I am not able to reproduce it reliably. Or should I say, I am reliably unable to reproduce it when I am at my computer and can grab logs. At one time it was happening consistently when I was out and mapping; it seemed to get better with a recent update and I hadn't seen it for a while, so I assumed it was solved, but I encountered it again today :(>
I wasn't going to post this until I was able to reproduce and track it down a bit, but it has now caused me enough annoyance that I'm doing it anyway; maybe someone else is experiencing it too, and we can track it down together. Otherwise, I'll post updates if/when I'm finally able to get logs.>
Versions affected>
- Samsung Galaxy S6 (G920A) running Android 7.0>
- StreetComplete v34.0 from F-Droid, but it's been happening for a few versions at least.>
- Default camera app is Simple Camera v5.3.1, also from F-Droid>
-- > You are receiving this because you are subscribed to this thread.> Reply to this email directly or view it on GitHub:> https://github.com/streetcomplete/StreetComplete/issues/3293
-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Not this exact problem, but I did have my Xiaomi Redmi Note 3 Pro (running Android 6) kills apps, even if they are whitelisted against all power saving. For example, I have everything disabled except OsmAnd for recording GPX track, Antennapod playing podcast in background, and mapping with SC in foreground. When I want to take picture with SC, OsmAnd or Antennapod often gets killed.
One possible explanation is system update, which made it more aggressive. Another is that apps themselves have grown with time, and systems decides it does not have enough memory to run them all. Or you might have installed some new apps, which also try to run in the background or periodically (mail check, chat clients etc) which might trigger this?
If you have developer mode enabled on the phone, there is an option Background process limit
which may have some influence on that when Android decides to stop/kill apps?
Also, power saving "features" of the phones are getting more and more aggressive by the day. https://dontkillmyapp.com/ have some workarounds for various manufacturers, or at least estimates your chances to experience problems...
I sometimes (very rarely) see such unexpected close when adding a GPX note in my modified version. Not sure if it's just accidentally similar or whether there is a connection.
I've not been able to get logs from this. If I remember correctly there was nothing conclusive on e
log level (which is stored longer than the others, so I was able to see it)
Not this exact problem, but I did have my Xiaomi Redmi Note 3 Pro (running Android 6) kills apps, even if they are whitelisted against all power saving.
Android also likes killing background apps for high CPU usage. And "high" can actually be rather low, until some app update ActivityManager frequently killed my music player for ... playing music: https://github.com/aosp-mirror/platform_frameworks_base/blob/master/services/core/java/com/android/server/am/ActivityManagerService.java#L17851 Not sure though it already happens in Android 6, but you could check logs for the message.
Also, power saving "features" of the phones are getting more and more aggressive by the day. https://dontkillmyapp.com/ have some workarounds for various manufacturers, or at least estimates your chances to experience problems...
Even on default AOSP with power saving functions like doze disabled it's already horrible... I'm using a heavily modified location tracker and 80% of my work on it went into fighting power saving stuff.
Really kill it? Or just destroy it so it can be recreated when the user switches back to that application? If it is the former, do you have any source for that claim?
Well, the literal source linked above says app.kill()
, so either that function is badly misnamed, or it is really killing. That would match the pattern that I've seen in this bug, since I think SC no longer appears in the recent apps after it happens. But my memory is not 100% here; I think the best thing to do here is wait until someone is able to get a log.
Hm well, if this is really the case, nothing can be done about this.
If that is the case (which we won't discover until we have logs), we could
Avoid doing cpu-intensive work while waiting for the camera
and/or
The only thing that would be CPU intensive (in the background) would be a running download/upload. But that will automatically be put into a foreground service if the app is sent to the background.
It should not be that bad: If it's really AcitivtyManager that kills the app it can be avoided by having the right PROCESS_STATE
.
The whole part of checking CPU and killing is only called if app.setProcState >= ActivityManager.PROCESS_STATE_HOME
.
You can find those states here. Foreground service is (obviously) among those.
I sometimes (very rarely) see such unexpected close when adding a GPX note in my modified version. Not sure if it's just accidentally similar or whether there is a connection.
Got one of these today. Log says it's some tangram crash, so I think it's not connected to the problem here.
What tangram crash? Tangram shouldn't crash.
Edit: Anyway, please report that crash at https://github.com/tangrams/tangram-es if it is really tangram.
Ok, I thought I simply had done something to offend tangram with some of my modifications. Will report.
I reproduced, and sent an excited message. Then deleted it because I realized we already have logs. But now I think it might be a different crash here. However, it's really hard to sort through 60k lines of logs to make sure if it's the right crash. Could someone who has emails enabled tell me the exact timestamp I posted the post? That would be very helpful in determining if I'm looking at the right thing.
If this is in fact the crash, it seems likely it's another proguard issue, and it's from this line:
This line was refactored in the latest release, so it's possible that the problem goes away on its own.
All that said, I really need the timestamp to confirm :facepalm:
@smichel17 The message with content I GOT IT AND AM ON MY WAY TO GET LOGS NOW
had a following headers:
Date: Thu, 23 Sep 2021 14:27:48 -0700
From: smichel17 <notifications@github.com>
and it finished queuing at my mail server in different timezone on the other side of a planet a whooping 1 second later Thu, 23 Sep 2021 23:27:49 +0200 (CEST)
. One often forgets to marvel at todays technology!
Thank you very much @mnalis. That cuts the amount of logs I have to look through from ~60k lines to ~8k lines. Much more reasonable (stepping through them ~50 lines at a time). I'm not done and will continue this later, but here's some other interesting parts I found:
However, the ExynosCamera*
logs keep coming after that, so I'm not sure that's where it is.
If anyone wants me to send them the entire 8k lines so you can look through it yourself, let me know.
If this is in fact the crash, it seems likely it's another proguard issue
Can't be, otherwise it would crash immediately (on startup), not rarely
Hm, yeah. I dunno what else besides proguard would cause ClassNotFound issues that wouldn't be caught at compile time, though. Although I also don't know why it would happen only sometimes, in that case.
I am pretty sure now this is caused by #3967, so closing this as duplicate.
How to Reproduce
Other Answers
>Can't Say…
>OK
Expected: Photo is taken and attached to the note Actual: StreetComplete instantly closes and the photo is lost. There is no "StreetComplete crashed" message, the app is just killed.
This is a very frustrating bug to track down because I am not able to reproduce it reliably. Or should I say, I am reliably unable to reproduce it when I am at my computer and can grab logs. At one time it was happening consistently when I was out and mapping; it seemed to get better with a recent update and I hadn't seen it for a while, so I assumed it was solved, but I encountered it again today :(
I wasn't going to post this until I was able to reproduce and track it down a bit, but it has now caused me enough annoyance that I'm doing it anyway; maybe someone else is experiencing it too, and we can track it down together. Otherwise, I'll post updates if/when I'm finally able to get logs.
Versions affected