wallpanel-android icon indicating copy to clipboard operation
wallpanel-android copied to clipboard

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

Open cromelex opened this issue 3 years ago • 14 comments

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

cromelex avatar Apr 12 '22 15:04 cromelex

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 avatar Apr 27 '22 20:04 TheTimeWalker

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

starkillerOG avatar Jul 06 '22 19:07 starkillerOG

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

TheTimeWalker avatar Jul 06 '22 20:07 TheTimeWalker

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

starkillerOG avatar Jul 07 '22 09:07 starkillerOG

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?

tmakowka avatar Aug 17 '22 09:08 tmakowka

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

VanDoni avatar Sep 02 '22 14:09 VanDoni

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.

Madseason41 avatar Oct 04 '22 16:10 Madseason41

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.

howi42 avatar Apr 23 '23 09:04 howi42

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

tmakowka avatar Apr 26 '23 15:04 tmakowka

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?

Freddan101 avatar Apr 28 '23 05:04 Freddan101

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

dotdoom avatar Jun 28 '24 17:06 dotdoom