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

[cromelex]

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

• Device: Fire 7 tablet
• OS: Fire OS
• Application version: V0.10.0 Build1

[TheTimeWalker]

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]

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

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]

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

[tmakowka]

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]

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

[Madseason41]

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]

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]

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]

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]

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 #11 (comment) (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

[Nisbo]

Old thread, but I also have this issue with the latest version from the Google Store on a Fire Tablet HD10 - 9th Generation (2019)
Already asked but no answer yet. Is there a way from Home Assistant to restart the app ?

EDIT: maybe this can help via MQTT
clearCache true {"clearCache": true}
but I am not at home an can test it and also dont know if its deletes the cookies

[Nisbo]

I arrived at home and the app was working again. There was an outage of about 2 hours. How does this happen ? Was is frozen for 2 hours ? Or was the app restarting by its own after 2 hours ?

[Nisbo]

Today I had the issue again. Screen was not turned on, entities were not available in HA.
After I pushed the power button, the screen turns on and the app was still running but very slow.
Sending the clear cache command did not solve the issue.

Sending {"relaunch": true} made the app fast again. So maybe this is the interim solution, sending this command from time to time.