[androiddebugbridge] Add start intent channel

[GiviMAD]

Signed-off-by: Miguel Álvarez Díez miguelwork92@gmail.com

This pr add a new channel for start application intents.
Also fixes the discovery and revert to use the device serial number as identifier on both discovery methods.

[jaywiseman]

I'm using this version of the binding.

https://docs.smarthomej.org/3.2.12-SNAPSHOT/org.smarthomej.binding.androiddebugbridge.html

This version has the Intent channel defined already.

I have these items working with the binding I'm referencing above.

https://community.openhab.org/t/android-debug-binding-adb-notes-for-others/133777

Best, Jay

[lsiepel]

Did a quick scan for this PR. Usually it is preferred to seperate bug and enhancements PR. Anyway, did you get in contact with previous contributer that changed the identifier for discovery?

[GiviMAD]

@lsiepel, yes he is one of the reviewers also I mentioned him in the issue, and for the reference I'm the original contributor.

I was working on the new channel when I discovered the issue so I fixed it to been able to tested it.

[GiviMAD]

@jaywiseman I have no clue, I don't think it will work without changes.
Edit:
If you are referring to the start-package channel yes, I think both should work.
The start-intent channel added by this pr is meant to call 'am start' passing more arguments apart from the package as a uri and action and some extra parameters, to been able to use other app intents.

[GiviMAD]

@cweitkamp did you have a chance to look at this?
We can take a different path and use the ip as identifier if you think that connect through adb from the MDNS discovery is too much.

[cweitkamp]

Sry for my late reply. As I already stated in #11881 (comment) for me it looks like the Mac address is the only unique identifier available in both discovery service implementations.

The mDNS discovery in general does not require to enable usb debugging in general as requested in the documentation. Imo your approach will fail to discover a new device as long as this requirement is not given. The question now is if we want to restrict the discovery results to rely on this setting or not.

May I ask you to slit this PR into two separate ones? One for the discovery issue and one for the enhancement to add the new channel. Thanks.

[GiviMAD]

Sorry but I can’t agree @cweitkamp.



First of all we don’t have the mac address in both discovery methods, the way currently implemented on the normal discovery is totally wrong and I couldn’t find an easy way to get it, also the serial number used util that pr seems the best option and with this changes is available on both sides.







Also currently we have broken a rudimentary but functional discovery that works for all android devices, just for adding one for discover FireTV devices, which is not the only target of this binding, so for me it’s more a problem right now, so if we could not find a good solution quickly I think its better to remove the new discovery method and implemented it again when we know how to do without break the current one.











And finally as I said before I have added the fix to this pr because I discovered it was broken at that moment, I can move it to a separate one if is needed, but seems like and extra work for me and I really don’t see the point as the pr is not huge.

[GiviMAD]

Removed all discovery related changes.
So the problem with the discovery remains open as the device MAC address is not available in the adb discovery method.

[jlaur]

Thanks for the PR. I have made a few minor comments.

[lolodomo]

@GiviMAD : there is not too much to do so that I can merge your PR.

[GiviMAD]

@GiviMAD : there is not too much to do so that I can merge your PR.

Sorry, almost forgot about it, I was messing around trying other things. Thanks for pinging me, I'll go for it.

[lolodomo]

LGTM

[lolodomo]

@jlaur : is it ok for you (as you reviewed this PR without approving it) ?