[Withdrawn] Revise SDL 0280 - Adding new parameter of requiresAudioSupport and BluetoothDeviceAddress
jordynmackool opened this issue · 14 comments
Hello SDL community,
The review of "Revise SDL-0280 Adding new parameter of requiresAudioSupport and BluetoothDeviceAddress" began on March 23, 2021, and continues through April 20, 2021.
This will be a review of proposed revisions to a previously accepted but not yet implemented proposal, SDL 0280.
The pull request outlining the revisions under review is available here:
Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:
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
If you have any suggestions regarding this Proposal, please comment.
I do not believe this feature works properly without using a unique identifier of the phone such as the bluetooth MAC address. The use of the bluetooth friendly name is not a good enough indicator of a unique device. If two users that have the same make and model of phones enter a car their phones' bluetooth friendly names will be the same by default. The IVI system would have to make a complete guess as to which phone to connect bluetooth with. If the IVI chose wrong it would lead to an extremely confusing UX.
Based on the previously unknown limitations from Android 6.0 and onward, I do not believe this proposal can work as originally intended. I recommend the author rethink how a feature like this can work. It might no longer be possible to allow for an automatic bluetooth connection to happen. The library itself might need to check for a bluetooth connection before sending the StartService packet like it does today, and if no connection is preset, request that the IVI ask the user to connect bluetooth because the IVI no longer has enough information to automatically do so correctly.
@joeygrover -san
Thank you for your comment.
If the device name is not duplicated, an automatic connection will be performed, and if it is duplicated, IVI will request the user to make a Bluetooth connection. How about the above?
Alternatively, we can use UUID to identify the device, but this has a big disadvantage.
The bluetooth friendly name can be duplicated, modified, etc. which prevents it from being able to be used as a unique identifier. There is simply no way around this issue.
Fail cases:
Duplicate Name
Two Android users could pair two of the same make and model phones where both of the BT friendly names equals the default name like "Pixel 5", the IVI would cache those value along with the MAC addresses. When the feature attempted to work it would have to pick one. Or as the author suggests, the IVI could request the user connect a device. However in that instance the app state is unclear based on the current proposal. This also leads to users having to interact with the IVI system while potentially driving where the temptation to do so is greater as they want the apps they see as connected to "just work."
Changed Name
Android users could pair their phone when the BT friendly name equals the default name like "Pixel 5", the IVI would cache that value along with the MAC address. If the user changed the BT friendly name to "Joey Pixel 5", the friendly name would be different than the one cached from pairing on the IVI. The IVI would need to refresh that name before this feature would work. It would also cause confusion to the user if the IVI requested them to connect/pair a device with a different name.
Spoofed Names
Building off the previous example, a user could change their friendly name to match another phone. The user could change "Pixel 5" to "Joey iPhone X" in which the IVI would attempt to connect to that phone if it had already been paired.
UUID
I believe this is referring to using the SPP UUID as identifying a phone by performing an SDP query on nearby devices. If using the SDL UUID, this could lead to still connecting to the incorrect phone if two mobile devices with SDL apps are in the vehicle at the same time.
Overall Review
In most cases the IVI system should reconnect to the last connected or primary bluetooth device, and, in my opinion, users do not tend to turn off bluetooth. This means that a bluetooth connection for the happy path steps of this feature is already covered. This leads to the question of if a feature like this is worth the complexity that it adds, and in my opinion that is no. Previously when using the MAC address the feature was at least borderline enough to accept and implement, but without it, the feature becomes riddled with potential corner cases and errors states that does not become much better than the situation today.
Simplified Solution
The current proposal is not viable with only using the bluetooth friendly name or SPP UUID. A much simpler solution would be to simply have the IVI system alert the user when USB is connected without a bluetooth connection that states something like the following: "Please connect bluetooth to access additional apps."
It could go a step further and introduce a new control packet that informs the IVI that it requires an audio out channel before it can connect. In that scenario the app would not register though and therefore avoid some of the corner case issues present with the current proposal.
The Steering Committee voted to keep this proposal in review on 2021-03-30 to allow for the discussion to continue on the review issue and the author to respond to the most recent comment.
@joeygrover -san
Thank you for your review.
A much simpler solution would be to simply have the IVI system alert the user when USB is connected without a bluetooth connection that states something like the following: "Please connect bluetooth to access additional apps."
It could go a step further and introduce a new control packet that informs the IVI that it requires an audio out channel before it can connect.
Let me check these flows.
We assume the following two flows. Does it match your expectations? Please let me know if it is different.
Flow 1
- StartService and StartServiceAck are executed as before
- If audio output is not possible even though it is a media type in the Android SDL app library, RAI is not sent. (Up to here, this is the same method as before.)
At the same time, send a new RPC to Core, send it from Core to HMI, and send an alert.
Flow 2
- Send StartService with requiresAudioSupport = true from the SDL app on the Androd terminal to Core.
- When Core receives StartService, if the source of StartService is Android, requiresAudioSupport = true, and the terminal and HU are not connected to BT A2DP, a new RPC will be sent to HMI to send an alert.
* Flow 1 would have less impact on SDL than Flow 2.
@joeygrover @Yuki-Kanadome-Nexty
Brainstorming an idea: I am thinking about how to leverage already connected apps to send the alert to Core about connecting the device's bluetooth to register more apps.
We could introduce a new RPC named GetAppList that returns the list of registered apps to the mobile device with some information including appHMIType. This type of message could be useful for reasons outside of just Android devices over usb. It could potentially be useful for general connection issues/troubleshooting on all platforms?
In terms of privacy concerns, this type of RPC would probably be reserved for companion apps. This is all policy configurable anyways.
@JackLivio -san
Thank you for your idea.
We are thinking of the following in terms of UX. Is our confirmation correct?
joeygrover-san's idea
- Attempts to launch the Media app on an Android device using only a USB connection
- Display a message on IVI prompting the user to connect to BT
- The app is not registered
JackLivio-san's idea
- Attempts to launch the Media app on an Android device using only a USB connection
- Display a message on IVI prompting the user to connect to BT
- The app is registered, but if BT is not connected, it will not start even if you press the icon, and then a message prompting the user to connect to BT will be displayed on IVI.
In terms of privacy concerns, this type of RPC would probably be reserved for companion apps. This is all policy configurable anyways.
Will apps except the companion app behave as usual?
- Attempts to launch the Media app on an Android device using only a USB connection
- The app is not registered and the user is not notified.
The Steering Committee voted to keep this proposal in review on 2021-04-06 to allow for conversation to continue on the review issue.
Regarding My Idea: The "companion" app sending the alert would likely be nonmedia and already be connected via usb. This companion app would need to do some parsing of installed app packages on the mobile device and the compare to the GetAppList RPC response to see what apps it thinks should be registered but are not for some reason.
If the companion app is able to determine the phone has SDL connected apps (which are also media) but for some reason aren't registered (due to bt being off), Companion app would then send the alert to turn BT on with anticipation this would allow for those media apps to register. The Companion app is being used to assist the other installed media apps connect in a way they need to (over bluetooth).
What I was thinking as the flow is a little different than stated. The Android library would check for audio arbitration prior to sending any message or packet to the IVI. If an audio output was available, it would continue as normal. If it was not, the library would simply send a new control frame message like RequestAdditionalSupport or similar with the flag requiresAudioSupport set to true. This new control frame could include an app name so the IVI could use that when presenting a dialog. The library would then close as normal while not starting an RPC service or registering the app. The IVI would then prompt the user to connect audio over an available channel such as bluetooth. Once the audio connection was made, the IVI could send a control frame message like PingApps with information about the potential audio output device. The router service would listen for this packet specifically, and if found, it would send out the SDL_CONNECTED intent for apps to try and register again.
I left the messages vague because I can see other situations where they would be helpful. For example RequestAdditionalSupport could be used for apps that require high bandwidth to function, ie requesting the user to plug in USB. This would allow the IVI to provide the user with potential alerts that can lead to more app discovery. PingApps could be used in other scenarios where not all apps might have registered or if an app crashed during a connection the IVI could send the request to see if it can get apps to re-register or register when new support requests have been fulfilled.
These are just some open ended ideas / brainstorming because I feel as if this proposal has moved back into a discovery type of phase and it's not possible to simply judge the original revisions or proposal as is.
The Steering Committee voted to keep this proposal in review on 2021-04-13 to allow for the conversation to continue on the review issue.
@JackLivio -san, @joeygrover -san
Thank you for your ideas and explanations.
We could understand them.
As a result of internal examination, joeygrover-san's idea seems to be more versatile in that it doesn't require a companion app, so we think we should go with it.
Please let this proposal be withdrawn.
This proposal has been withdrawn per the author's request.