android
android copied to clipboard
home-assistant
command_webview notification does not change current view on the companion app
Home Assistant Android app version(s): 2023.1.1-full
Android version(s): 10
Device model(s): Teclast P20HD
Home Assistant version: Home Assistant 2023.2.2 Supervisor 2023.01.1 Operating System 9.5 Frontend 20230202.0
Last working Home Assistant release (if known): N/A
Description of problem, include YAML if issue is related to notifications: According to documentation, the script below should navigate to the specified by path view on a remote Android companion application. In fact, this works only if the companion app is not yet running. So running the script below, it launches and navigates to the requested view. Next, after the current view is changed manually, or another path is specified in the script, and script started again, navigation does not happen, and view is not changed.
- service: notify.mobile_app_android_tablet
data:
message: command_webview
data:
command: /dashboard-main/resources
Steps to reproduce:
- close the companion app
- start the script above (using existing view path)
- see the app is open and the view is set as requested
- switch to a different view by hand on the Android app OR change the view path in the script
- start the script again
Expected result: view changes accordingly. Actual result: view is not changed anymore.
Companion App Logs: In logs below: 19:46:xx - no app running, script launched, requested view opened 19:47:xx - view changed manually on the android app 19:48:xx - scipt launched again, no view changed (expected: change back to requested one)
02-17 19:46:25.993 23130 23584 W FirebaseMessaging: Unable to log event: analytics library is missing
02-17 19:46:25.997 23130 23584 D FCMService: From: 331041709873
02-17 19:46:25.999 23130 23584 D MessagingService: Processing device command
02-17 19:46:26.281 23130 23584 W FirebaseMessaging: Unable to log event: analytics library is missing
02-17 19:46:26.283 23130 23584 D FCMService: From: 331041709873
02-17 19:46:26.285 23130 23584 D MessagingService: Processing device command
02-17 19:46:26.514 23130 23584 W FirebaseMessaging: Unable to log event: analytics library is missing
02-17 19:46:26.515 23130 23584 D FCMService: From: 331041709873
02-17 19:46:26.517 23130 23584 D MessagingService: Processing device command
02-17 19:46:26.551 23130 23130 W ActivityThread: handleWindowVisibility: no activity for token android.os.BinderProxy@5df5a59
02-17 19:46:26.675 23130 23130 D IntegrationRepository: isAppLocked(): false. (LockEnabled: false, appActive: false, expireMillis: 1676652332305, currentMillis: 1676652386675)
02-17 19:46:26.679 23130 23130 W cr_SupportWebSettings: setForceDarkBehavior() is a no-op in an app with targetSdkVersion>=T
02-17 19:46:26.679 23130 23130 W cr_SupportWebSettings: setForceDark() is a no-op in an app with targetSdkVersion>=T
02-17 19:46:26.680 23130 23130 D WebviewActivity: Current webview package com.google.android.webview and version 109.0.5414.117
02-17 19:46:26.691 23130 23130 D WebviewActivity: Matter commissioning status changed to NOT_STARTED
02-17 19:46:26.693 23130 23130 D IntegrationRepository: isAppLocked(): false. (LockEnabled: false, appActive: false, expireMillis: 1676652332305, currentMillis: 1676652386693)
02-17 19:46:27.360 23130 23130 I Choreographer: Skipped 38 frames! The application may be doing too much work on its main thread.
02-17 19:46:27.412 23130 23195 D : Gralloc Register w:1200, h:1920, f:0x1101, usage:0xb00, ui64Stamp:114125, sSize:9236480, line = 2270
02-17 19:46:27.447 23130 23248 W chromium: [WARNING:display_webview.cc(31)] WebView overlays are enabled!
02-17 19:46:27.451 23130 23195 I OpenGLRenderer: Davey! duration=728ms; Flags=1, IntendedVsync=78204966805102, Vsync=78205610872878, OldestInputEvent=9223372036854775807, NewestInputEvent=0, HandleInputStart=78205613330485, AnimationStart=78205613358139, PerformTraversalsStart=78205613639139, DrawStart=78205654267600, SyncQueued=78205656851331, SyncStart=78205665487754, IssueDrawCommandsStart=78205665678408, SwapBuffers=78205701307754, FrameCompleted=78205703624600, DequeueBufferDuration=0, QueueBufferDuration=1702000,
02-17 19:46:27.489 23130 23195 D : Gralloc Register w:1200, h:1920, f:0x1101, usage:0xb00, ui64Stamp:114136, sSize:9236480, line = 2270
02-17 19:46:27.489 23130 23130 D IntegrationRepository: isAppLocked(): false. (LockEnabled: false, appActive: false, expireMillis: 1676652332305, currentMillis: 1676652387489)
02-17 19:46:27.514 23130 23163 D UrlRepository: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
02-17 19:46:27.518 23130 23172 I WM-Processor: Moving WorkSpec (882299a0-344b-4c9a-a843-7b21259ae659) to the foreground
02-17 19:46:27.522 23130 23165 D UrlRepository: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
02-17 19:46:27.525 23130 23130 D UrlRepository: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
02-17 19:46:27.525 23130 23130 D UrlRepository: Using external URL
02-17 19:46:27.528 23130 23195 D : Gralloc Register w:1200, h:1920, f:0x1101, usage:0xb00, ui64Stamp:114138, sSize:9236480, line = 2270
02-17 19:46:27.536 23130 23165 D SensorWorker: Updating all Sensors in foreground.
02-17 19:46:27.544 23130 23165 D UrlRepository: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
02-17 19:46:27.551 23130 23172 I WM-WorkerWrapper: Worker result SUCCESS for Work [ id=e8cada00-541c-4565-b046-86eb6e4905f1, tags={ io.homeassistant.companion.android.websocket.WebsocketManager } ]
02-17 19:46:27.554 23130 23165 D UrlRepository: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
02-17 19:46:27.560 23130 23130 I WM-SystemFgDispatcher: Started foreground service Intent { act=ACTION_START_FOREGROUND cmp=io.homeassistant.companion.android/androidx.work.impl.foreground.SystemForegroundService (has extras) }
02-17 19:46:27.881 23130 23142 I mpanion.androi: Background concurrent copying GC freed 38208(2093KB) AllocSpace objects, 6(184KB) LOS objects, 49% free, 6347KB/12MB, paused 201us total 186.557ms
02-17 19:46:28.712 23130 23315 D WebviewActivity: External bus {"type":"config/get","id":1}
02-17 19:46:28.713 23130 23130 D WebviewActivity: externalBus({"id":1,"type":"result","success":true,"result":{"hasSettingsScreen":true,"canWriteTag":false,"hasExoPlayer":true,"canCommissionMatter":true}});
02-17 19:46:28.785 23130 23130 D UrlRepository: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
02-17 19:46:28.785 23130 23130 D UrlRepository: Using external URL
02-17 19:46:28.788 23130 23130 D WebviewActivity: Callback null
02-17 19:46:28.789 23130 23130 D WebviewActivity: Color from webview is "#101e24-SPACER-#111111"
02-17 19:46:28.789 23130 23130 D WebviewActivity: Color from webview is "#101e24-SPACER-#111111"
02-17 19:46:28.790 23130 23163 D WebViewPresenterImpl: Try getting color from webview color "#101e24".
02-17 19:46:28.790 23130 23163 I WebViewPresenterImpl: Found color -15720924.
02-17 19:46:28.792 23130 23164 D WebViewPresenterImpl: Try getting color from webview color "#111111".
02-17 19:46:28.793 23130 23164 I WebViewPresenterImpl: Found color -15658735.
02-17 19:46:28.920 23130 23165 D UrlRepository: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
02-17 19:46:28.956 23130 23169 I WM-WorkerWrapper: Worker result SUCCESS for Work [ id=882299a0-344b-4c9a-a843-7b21259ae659, tags={ io.homeassistant.companion.android.sensors.SensorWorker } ]
02-17 19:46:28.974 23130 23130 I WM-SystemFgDispatcher: Stopping foreground service
02-17 19:46:30.119 23130 23315 D WebviewActivity: External bus {"type":"connection-status","payload":{"event":"connected"},"id":2}
02-17 19:46:30.121 23130 23130 D UrlRepository: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
02-17 19:46:30.279 23130 23315 D WebviewActivity: External bus {"type":"theme-update","id":3}
02-17 19:46:30.302 23130 23130 D WebviewActivity: Color from webview is "#101e24-SPACER-#111111"
02-17 19:46:30.302 23130 23130 D WebviewActivity: Color from webview is "#101e24-SPACER-#111111"
02-17 19:46:30.302 23130 23164 D WebViewPresenterImpl: Try getting color from webview color "#101e24".
02-17 19:46:30.303 23130 23164 I WebViewPresenterImpl: Found color -15720924.
02-17 19:46:30.304 23130 23164 D WebViewPresenterImpl: Try getting color from webview color "#111111".
02-17 19:46:30.304 23130 23164 I WebViewPresenterImpl: Found color -15658735.
02-17 19:47:09.840 23130 23716 E IMGSRV : :0: BufPoolFreeBuffer: fragment buffer for render surface still in use
02-17 19:47:09.840 23130 23716 I chatty : uid=10147(io.homeassistant.companion.android) identical 29 lines
02-17 19:47:09.840 23130 23716 E IMGSRV : :0: BufPoolFreeBuffer: fragment buffer for render surface still in use
02-17 19:47:09.853 23130 23716 E IMGSRV : :0: BufPoolFreeBuffer: fragment buffer for render surface still in use
02-17 19:47:09.853 23130 23716 E IMGSRV : :0: BufPoolFreeBuffer: fragment buffer for render surface still in use
02-17 19:47:15.778 23130 23716 E IMGSRV : :0: BufPoolFreeBuffer: fragment buffer for render surface still in use
02-17 19:47:15.862 23130 23716 E IMGSRV : :0: BufPoolFreeBuffer: fragment buffer for render surface still in use
02-17 19:48:10.030 23130 23741 W FirebaseMessaging: Unable to log event: analytics library is missing
02-17 19:48:10.033 23130 23741 D FCMService: From: 331041709873
02-17 19:48:10.035 23130 23741 D MessagingService: Processing device command
02-17 19:48:10.230 23130 23741 W FirebaseMessaging: Unable to log event: analytics library is missing
02-17 19:48:10.233 23130 23741 D FCMService: From: 331041709873
02-17 19:48:10.235 23130 23741 D MessagingService: Processing device command
02-17 19:48:10.465 23130 23741 W FirebaseMessaging: Unable to log event: analytics library is missing
02-17 19:48:10.466 23130 23741 D FCMService: From: 331041709873
02-17 19:48:10.468 23130 23741 D MessagingService: Processing device command
Screenshot or video of problem:
Additional information:
I am unable to reproduce.
I can successfully send
service: notify.mobile_app_dannys_pixel_7_pro
data:
message: command_webview
data:
command: /lovelace/settings
and while the app is open send
service: notify.mobile_app_dannys_pixel_7_pro
data:
message: command_webview
data:
command: /lovelace/ollies
and the dashboard changes as per my expectations.
Even if I change the dashboard by clicking on another one in between the 2 service calls the second service call still loads as I would expect
Do you have any custom cards enabled? maybe try disabling them in case they are causing a conflict.
Yes, I use a lot of custom cards. So the next step then should be to use clean Home Assistant instance first to see if the feature works on the same Android tablet. Then I will try to find out what exactly breaks it.
You may close the issue then, or keep it open since I need some free time to check everything. I will report ASAP.
This also could be a device specific issue as we request a new webview instance every time this command is executed. It could be the device is not respecting the intent flags we have set.
@dshokouhi Which app version are you using to test? There was a change in webview intents for multiserver.
@dshokouhi Which app version are you using to test? There was a change in webview intents for multiserver.
beta 3180, I always update to the latest :)
I thought we always flagged those intents to create a new instance? at least thats how it was before
Edit: Looking at the diff I do not see changes done to the intent flags, just that the new instance now takes the server into account but it should still create a new instance with the flags we have set.
I thought we always flagged those intents to create a new instance? at least thats how it was before
It still creates a new task, but as you said it may not be respected I'd thought that maybe implementing onNewIntent might make a difference. Would be good to do the same test on 2023.1.1-full instead of beta to confirm.
Would be good to do the same test on 2023.1.1-full instead of beta to confirm.
Usually when we suspect an issue is fixed in the beta we ask the user to check :)
@osnwt can you try the latest beta found on the github release tab to see if the issue is fixed there for you?
Took a second tablet of the same manufacturer, but with Android 11. Installed latest beta-3182-1ceafa39. Checked again: the same behavior.
My script has 3 command notificatons: turn on the screen, set screen brightness, navigate to the view. First two work as expected. The last one fails as before.
So the only versions are: manufacturer-specific issue or custom cards. I will try to setup a new fresh Home Assistant instance and check with it.
Home Assistant 2023.2.5 Supervisor 2023.01.1 Operating System 9.5 Frontend 20230202.0 Android App: beta-3182-1ceafa39
Fresh install with no custom config: same issue :-(
Anything else I can try?
do you have another android device from another manufacturer to try?
also you can try to double check that android system webview is upto date but I am not sure that will have any impact here
Tried Play Market app version on Samsung Galaxy S6 phone with old Android 7, and it works. Visually it looks like visible view is being completely reloaded and opened at requested URL. On Teclast tablets it even doesn't try to reload.
What's weird, Teclast tablets use vanilla Android system unlike Samsung with own shell, browser, etc.
Anything else I can try? I am ok to run debug version with logging. I've bought two Teclast tablets with plain Android specially for Home Assistant panels, so would like to make them finally working.
PS. Custom cards do not affect the result: if it works, it works with them. If not, no matter if some custom cards exist.
Unfortunately there is not much we can do if your device is not respecting the intents we have setup. As you can see another android device works as expected. It is not uncommon for manufacturers to go against the android documentation, even Google does it from time to time.
There is really nothing else we can try, Telcast should respect the intent flags that the app uses.
Closing as this is a device specific issue and that it is not respecting the intent in a certain situation.
So, let me summarize the result. Please correct me if I am wrong on some points.
- No one can assume or expect that getting a vanilla Android device, it will work with Home Assistant companion app. I am not talking about actual proven «by design» limitation of Google or vendor, but when a feature which supposed to work just doesn’t in particular case.
- If a feature doesn’t work, it is easier to just drop it as is instead of helping to find a root cause and maybe try to find a workaround. Of course, it’s free and open source, and no one oblidged to do that. But usually developers are interested to get a reason of failure. At least, I am (being a developer since 1991, unfortunately, not an Android or Java one).
- The app team is not interested to help to investigate the problem. Say, ask to build/run a simplest test app and find out reason. I don’t believe that so basic feature just doesn’t work. Or at least give more info where to look at. Having a log-proven bug, I could at least ask manufacturer to help and/or fix it in the next firmware upgrade version. I don’t believe that so basic feature was intentionally disabled for no reason.
If so, I am very disappointed. I was ready to offer any help I can to investigate it. But I see no one is interested. Sigh…
If my contribution with my tests can be useful: With a stock Motorola Android 12 = same problem, lovelace doesn't change. With a Huawey Android 9 tablet = it works perfectly
obviously Home Assistant 2023.3.0
If my contribution with my tests can be useful: With a stock Motorola Android 12 = same problem, lovelace doesn't change. With a Huawey Android 9 tablet = it works perfectly
Unless otherwise stated, according to the info in this thread only, currently Android <= 9 works, Android >= 10 doesn't (I have no other devices to check myself). Failed not only vendors like Teclast, but also such as Motorola. But of course, it's a "device specific issue" with no intention to fix.
EDIT: tested on Samsung A41 phone with Android 11: it works as well as on Samsung S6 with Android 7. So it is not an Android version.
Samsung A40 with Android 11 lovelace doesn't change, always start at main view.
service: notify.mobile_app_sm_a405fn
data:
message: command_webview
data:
command: /lovelace/1
I own the popular Samsung Galaxy TAB A8, it doesn't work... can you please reopen the issue?
I own the popular Samsung Galaxy TAB A8, it doesn't work... can you please reopen the issue?
No we cannot based on the research it's a device issue not respecting Android developer documentation.
@Suxsem, it obviously seems they develop the app to be used on a spherical horse in vacuum, because a lot of devices just don't work. You never know in advance buying either branded device like Samsung or pure Android device like Teclast if it works. Moreover, there is no any mention in docs that this may not work or is so much device-dependent. And there is no list of known good devices either.
If your requirements are moderate (say, not a live video streem), I would recommend to have a look at OpenHASP project as a HA control panel. It requires some time to setup, but you have full control over displayed content and GUI primitives on a cheap LCD with touchpad (like some Sunton screens up to 7").
@Suxsem, it obviously seems they develop the app to be used on a spherical horse in vacuum, because a lot of devices just don't work.
if a device manufacturer deliberately goes out of their way to code the device against Googles own documentation there is not much we can do. Samsung has already admitted in the past that they stop certain features from woking on purpose. This is not the first device specific issue and it wont be the last.
Moreover, there is no any mention in docs that this may not work or is so much device-dependent. And there is no list of known good devices either.
Google does not mention which manufacturers follow their documentation and you should not expect others to as well. The best device that follows their own documentation are pixel devices but even those can at times deviate from developer documentation. We would be happy to support all devices however there is only so much you can do if they decide to go against documentation and not to provide their own documentation or workaround.
In this specific case there is a flag that Android looks for to specifically open a new task which in turn allows for WebView to change its current view to the one desired and some devices are just outright ignoring it without anything else to use as a workaround. Without this flag the feature will not work on other device that follow developer documentation.
I'm an android app developer myself, I'll look into it. Worse case, the app should check if the webview is already active and in this case just inject javascript to switch tab or dashboard. As a bonus, this would avoid the webview reload. That said, development would be easier having an open issue to discuss solutions and progress. The problem is there, solutions (or workaround) are surely possible, I really don't see why close the issue, but I'm not the maintainer so it's up to you.
There are enough people here who seem to be affected by it, so even if it doesn't work as it should, the issue could be opened if someone is looking at alternatives to make the command work on more devices as mentioned above. Reopening.
Just to be clear, my last comment was not about the issue itself, but about an attitude and wish to find a solution.
I perfectly understand that there is a lot of Android devices, and many may deviate from expected behavior. And in most cases a workaround is really possible. But since maintainers of the app were not interested to find a solution, it's really up to them if they wish to close it instead of keep open. At least, a notice in the docs may be given that "this feature is known to not work on many devices", so people are advised before buying a tablet for Home Assistant panel.
I am not an Android developer. Even so, if I saw at least any sign of wish to find a solution, I am able to setup a dev environment and try to debug as I did for other apps. Unfortunately there was no such wish, and issue was closed.
I had a chance to take a look at the code. In my opinion, intent should be fired adding flags:
intent.addFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT)
intent.addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP)
below the existing
intent.flags = Intent.FLAG_ACTIVITY_NEW_TASK
This prevent the webviewactivity to be reopened if already started, but still create a new task if activity is not running.
Doing so, methods onCreate and onStart of WebViewActivity.kt are not fired, but onResume is.
In the onResume method, desired path should be retrieved using
val path = intent.getStringExtra(EXTRA_PATH)
and javascript should be injected (webView.evaluateJavascript("<JS CODE>") in order to check if desired path is the current one, otherwise change the view with something like
anchor = 'a[href="/' + path+ '"]';
document.querySelector('body > home-assistant').shadowRoot.querySelector('home-assistant-main')
.shadowRoot.querySelector('ha-sidebar')
.shadowRoot.querySelector('paper-listbox > ' + anchor).click();
window.scrollTo(0, 0);
Some work must be done in the last part ( 1. as I said, check if the desired path is not the current one 2. target specific tabs in a dashboard 3. handle the entityId:domain.entity special path to open entity popup).
That said...
I simply gave up and used Browser Mod (https://github.com/thomasloven/hass-browser_mod) to navigate to view just after sending a notification with the command_webview command to open the app.
- can confirm the issue with the latest companion app and haos
- it works fine (not reproducible) if companion app was started manually
