Open cromelex opened 2 years ago
I think what happens here is that the WebView app crashes, but the background intent is still running fine. It's possible that the WebView or something else is having a memory leak before it gets killed by the memory manager. The best way would be to find out if there is a stacktrace in logcat.
@TheTimeWalker I also still have very regular crashes, a few times a day. Did you receive any crash logs? How can I retrieve logs for the app?
Hmm no, unfortunately I'm not receiving them. I think I have to upload a new release which could potentially help send crash logs more reliably
you mean a official release on the play store? I think that would be really nice also for others wanting to install/update.
I just updated to v0.10.0-beta1 from some 0.9.X Version (unfortunately haven't checked the old version id) on my Fire HD 10 Tablet, and this morning i was presented the home launcher, so i believe i'm having the same issue. Wakeup via MQTT still worked, so the background process seems to be still alive.
If i can provide any stacktrace i'm happy to help. The 0.9 version was rock solid 🤔
@TheTimeWalker Could you please look into this?
Same issue here with v0.9.6. Will update soon to the latest.
I have this issue on a Fire 7 and two Fire HD 8s running LineageOS. I use the automate app to reboot and relaunch wallpanel every twelve hours as a temp solution. Recently I updated the two Fire HD 8s to LineageOS 17.1 and it seems the crashes have went away.
Any news on this one ? For me it looks like the app ( or the underlying system ) is eating up all resources ( memory leak ?). Sometimes the app display is closed, but the app is still running, sometimes the app is just getting unresponsive. Only workaround is forcing it to stop and start again.
Is there a way to do this regularly from Home Assistant ?
Btw, the Fully Browser has similar problems, but seems to be better prepared to be able to recover on its own.
Update on this, I'm on 0.10.5 and the issue came back recently after the update to this version.
I also have the feeling that there is some type of memory leak since the app behaves very sluggish before returning to the home screen. Rebooting the tablet helps for some time.
@TheTimeWalker Can I send you some sort of debugging to sort this issue out?
Thanks Torben
I have the exact same issue on my Samsung Tab A8. I believe there has been a few fixes since 0.10.5 was released in January. Has anybody already built a new version with the latest fixes that could share the app?
I think this is also reported in #136 (or at least very similar). Getting logs from ADB I was able to confirm the theory from https://github.com/TheTimeWalker/wallpanel-android/issues/11#issuecomment-1111438963 (at least for my case). This is OOMkiller coming in and killing what it thinks make sense.
Looks like there's some LRU list and a factor (adj
?) that is used to prioritize the app to kill. Is this something that can be set per Activity or package?
At random times the Wallpanel app seems to minimise (ie, goes to the view on Android where you can clear the open apps) or the tablet goes back to the Home launcher, but the Wallpanel app keeps running on the background (and the notification saying it is running is available. If I set the Wallpanel app as the launcher (via Firetoolbox), the same thing seems to happen but instead of going to the "launcher", it basically triggers Wallpanel to reopen again.
I can see a number of people reporting the same issue on the HomeAssistant forums: https://community.home-assistant.io/t/wallpanel-for-android-formerly-homedash/16217/300