Publish message when switch app

[hectork2]

When I switch the app from VLC to YouTube , no publish until the video is played in the YouTube app to :
Topic: mediaSession/1/applicationId
Therefore, if an automation is written based on program switch app in Home Assistant, it will not work properly
Is it possible publish change application without playing video?

[cbeyls]

Hello, thank you for your feedback.

Reporting the app currently displayed in the foreground would be a completely different feature. I'm not even sure there is an API for that, I need to investigate. If there is, I can try to add it and publish the value as a new topic.

The current code is based on MediaSession only. As soon as there is one active MediaSession, its application name will be published to the MQTT broker. In case there is more than one active session, the last one is used, unless another one moves to the "playing" state, then it becomes the new current one.

Unfortunately each application decides when to set the session as active, and it's usually right before the playback is about to start. Also note that applications can play audio in the background or video in picture-in-picture mode, so an active MediaSession doesn't always mean that the app is in the foreground.

[hectork2]

Thank you for the explanation and the good App you developed
In my opinion, this application can improve a lot, because currently there is no alternative, or at least I did not find one similar to it
i installed on fireTV and I am using it instead of ADB integration
I think will be able to provide better feedback in the coming days

[cbeyls]

Thank you. I wrote this in a few days so I could automate lights in a room with an old Android TV that didn't work well with existing Home Assistant integrations. Chromecast did not report anything outside of Chromecast and ADB was too heavy and did not react fast enough.

For security reasons, Android apps are quite limited when it comes to accessing other apps information. There seems to be a way to detect the foreground app using an accessibility service so I'll do some tests to see if it works.

I don't own a Fire TV so I appreciate if you can confirm that the app works on your device as well.

[hectork2]

I really don't know why no one has done this before and I'm glad you are doing it
Like you, I use it to control the lighting system while watching movies and other things
ADB integration is very slow and unreliable
I had no problem with the installation, only this:
""Finally, you need to give the app full access to system notifications. To do so, click on "Open system notification access settings" and check the box for "MediaSession2MQTT".""
And I used commands instead
After executing the instructions, it is necessary to restart the device because it does not work
Thank you very much, yes, sure I will definitely report if I see other cases

[cbeyls]

I had no problem with the installation, only this: ""Finally, you need to give the app full access to system notifications. To do so, click on "Open system notification access settings" and check the box for "MediaSession2MQTT"."" And I used commands instead After executing the instructions, it is necessary to restart the device because it does not work

I specifically wrote in the documentation that you should restart the device after typing the ADB command, so this was expected.

[cbeyls]

I did a few tests using an AccessibilityService that were not very conclusive:

• When listening to TYPE_WINDOW_STATE_CHANGED events, I receive an event when an activity is created, but not always when switching between already opened activities from different apps, so I can't detect the current foreground app reliably.
• When listening to TYPE_WINDOW_CONTENT_CHANGED events, I constantly receive many events from the currently visible UI, including events from system views. I can't know for sure if there is a way to filter these out reliably, so there is always a risk that a system process will be mistakenly detected as the current foreground app. Also, the overhead of receiving all these events may slow down the device a bit.

Another technique involves using UsageStatsManager to retrieve which app was used recently. However these stats are not instantly updated so there is a small delay, and the stats have to be polled frequently because there is no callback so it's very inefficient.