TheTimeWalker / wallpanel-android

WallPanel is an Android application for Web Based Dashboards and Home Automation Platforms
https://wallpanel.xyz
Apache License 2.0
396 stars 41 forks source link

[BUG] Wallpanel app minimises and/or tablet goes to home launcher on Fire 7 tablet #11

Open cromelex opened 2 years ago

cromelex commented 2 years ago

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

TheTimeWalker commented 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.

starkillerOG commented 2 years ago

@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?

TheTimeWalker commented 2 years ago

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

starkillerOG commented 2 years ago

you mean a official release on the play store? I think that would be really nice also for others wanting to install/update.

tmakowka commented 1 year ago

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?

VanDoni commented 1 year ago

Same issue here with v0.9.6. Will update soon to the latest.

Madseason41 commented 1 year ago

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.

howi42 commented 1 year ago

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.

tmakowka commented 1 year ago

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

Freddan101 commented 1 year ago

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?

dotdoom commented 3 weeks ago

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?

adb logcat ``` 06-28 17:51:28.554 987 1109 D performance: LRU skip force stop: {com.lenovo.ota=adj<=200, com.google.android.tts=inputMethods, com.google.android.ext.services=adj<=200, com.google.android.providers.media.module=adj<=200, com.android.bluetooth=adj<=200, com.google.android.gms=adj<=200, com.google.android.apps.messaging=adj<=200, com.android.phone=adj<=200, com.google.android.googlequicksearchbox=inputMethods, com.dolby.daxservice=adj<=200, com.google.android.networkstack=adj<=200, com.lenovo.ue.device=adj<=200, com.android.systemui=wallpaper, com.tblenovo.launcher=lock ams, com.android.se=adj<=200, com.lenovo.tbengine=adj<=200, com.google.android.inputmethod.latin=inputMethods, com.google.android.apps.setupwizard.searchselector=adj<=200, com.android.smspush=adj<=200}, swapKill: -1 06-28 17:51:28.554 987 1109 D performance: force-stop com.google.android.webview due to available memory:390to free 49740KB < ... > 06-28 17:51:28.568 987 1109 I ActivityManager: Killing 3438:xyz.wallpanel.app/u0a201 (adj 0): stop com.google.android.webview due to from pid 987 ```