Intermittent quit on taking a photo for a note #3293
Comments
Closed
|
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](https://f-droid.org/en/packages/com.simplemobiletools.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:>
#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 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.
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
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 |
|
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
|
|
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 The whole part of checking CPU and killing is only called if |
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. Log |
|
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. Anyway, here's logsIf 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 🤦 |
|
@smichel17 The message with content and it finished queuing at my mail server in different timezone on the other side of a planet a whooping 1 second later |
|
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: One possibility: killed by oom killer?However, the I'm not sure what InputDispatcher is…Then there's some interesting stuff with SurfaceFlinger, which I think is the display compositor |
|
If anyone wants me to send them the entire 8k lines so you can look through it yourself, let me know. |
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
How to Reproduce
Other Answers>Can't Say…>OKExpected: 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
The text was updated successfully, but these errors were encountered: