SDL 0204- Support running the same app from multiple devices at the same time

[jordynmackool]

Hello SDL community,

The review of "SDL 0204- Support running the same app from multiple devices at the same time" begins now and runs through November 20, 2018. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0204-same-app-from-multiple-devices.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

#618

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you,
Jordyn Mackool

Program Manager - Livio
jordyn@livio.io

[joeljfischer]

I would be interested in knowing the difficulty of the sdl_core updates to permit this since the proposal doesn't go into that aspect of it even though it's the largest part of this proposal.

[yang1070]

@joeljfischer I think it shall be relatively small change of SDL.
1

SDL shall treat the same app from the same device with multiple transport connections as the same app instance.

This is existing function of SDL (currently, an application on the same iPhone device connected via BT and USB will be treated as one app, not two apps)

2

As before, SDL assigns unique internal app id to each app instance.

This is existing function of SDL.

3

SDL shall treat the same app from different connected devices as different app instances or different apps.
SDL shall allow only one instance of the app from one device. I.e. SDL shall reject the app with same app name or the same app id from one device as before.

I think the key point is whether to accept the application's RegisterAppInterface request. Once the app successfully registers and gets an unique internal app id, (thus it treated as a new different app) the work flow is the same what we have now.

Current, when an app registers app interface, SDL checks if there is any existing app that has the same app_policy_id, and rejects the request if there is one. We need update the logic here. SDL still need to check if there is any existing app that has the same app_policy_id, if no, continue as before (allow register), if yes, SDL compares the device information (device id or whatever need to differentiate a device) to those already registered apps that have the same app_policy_id, if not the same as any of those devices, continue as before (allow register), if the device has been found, rejects the request. (thus allow only one instance for one device)
SDL can apply similar logic to app name if needed.

[LuxoftAKutsan]

1. I would like to specify explicitly that same application on 2 different devices will be different applications on HMI and have different HMI application ID.

2. I would specify in proposal that after policy update, it will be applied for both of registered applications

3. ttsName and vrSynonyms should also be unique for device.

4. Application on different device should share same usage statistics, because they use same policy app_id. this should be added to the proposal.

We should propose solution for sdl_hmi how to activate application by ttsName or vrSynonyms via VR.

[justinjdickow]

@LuxoftAKutsan Why would the ttsName and vrSynonyms have to be unique? That sounds very difficult to support from the application side and complicates register logic because it suggests you'd disconnect the second application. Why not prompt the user on the HMI which application to open when using VR and show the associated device?

[yang1070]

@justinjdickow I agree with you that it is up to HMI to determine which app need to be activated/exit with the duplicated appName or ttsName by the method of, for example 1. multiple rounds of conversation to clarify the user's intent; or 2. a list of options for the user to choose, etc.

currently, ttsName Needs to be unique over all applications.

        <param name="ttsName" type="TTSChunk" minsize="1" maxsize="100" array="true" mandatory="false" since="2.0">
            <description>
                TTS string for VR recognition of the mobile application name, e.g. "Ford Drive Green".
                Meant to overcome any failing on speech engine in properly pronouncing / understanding app name.
_                Needs to be unique over all applications.
+               Needs to be unique over applications from the same device.
                May not be empty.
                May not start with a new line character.
                Only characters from char set [@TODO: Create char set (character/hex value) for each ACM and refer to] are supported.
            </description>
        </param>

I think we can update it to Needs to be unique over applications from the same device.

[Jack-Byrne]

I agree with Justin. Not sure how the app developers would ensure their vrSynonyms are unique since they don't know that other devices that are connected to core.

Maybe SDL Core could append the device name to the vrSynonyms before sending to the HMI to try and differentiate between devices? "Play music on X's Phone" vs "Play music on Y's Phone"

Another approach could be to give VR priority to the app that has the higher HMI level.

[yang1070]

currently, in the mobile api, function RegisterAppInterface and ChangeRegistration, it has the following

        <param name="vrSynonyms" type="String" maxlength="40" minsize="1" maxsize="100" array="true" mandatory="false" since="1.0">
            <description>
                Defines an additional voice recognition command.
                May not interfere with any app name of previously registered applications and any predefined blacklist of words (global commands)
                Only characters from char set [@TODO: Create char set (character/hex value) for each ACM and refer to] are supported.
            </description>
        </param>

in the hmi api, function RegisterAppInterface, function ChangeRegistration and data type HMIApplication, it has

    <param name="vrSynonyms" type="String" maxlength="40" minsize="1" maxsize="100" array="true" mandatory="false">
      <description>
        Request new VR synonyms registration
        Defines an additional voice recognition command.
        Must not interfere with any name of previously registered applications(SDL makes check).
      </description>
    </param>

But when I searched the code base, I didn't find anything in sdl core to enforce vrSynonyms or ttsName to be unique across all applications. I guess it is a requirement in HMI (VR engine) and the checks in HMI. So it is HMI's responsibility, not SDL's responsibility to differentiate between devices.

[jordynmackool]

The Steering Committee voted to accept this proposal with revisions. The revisions will include updating the descriptions of ttName and vrSynonyms as discussed in this comment.
In addition, the author will address numbers 2 and 4 in this comment.
• 2. I would specify in proposal that after policy update, it will be applied for both of registered applications
• 4. Application on different device should share same usage statistics, because they use same policy app_id. this should be added to the proposal.

[jordynmackool]

Accepted revisions were made on 11.21.18.
Core Issue

[theresalech]

sdl_hmi issue