Don't Delay Apps Attempting to Connect over the MultiSession Protocol String

[joeljfischer]

Bug Report

Currently it appears that all apps are delayed in connecting to either a control or data session. However, since multisession apps directly connect to the multisession protocol string, we should not delay those apps from connecting.

See: SDLIAPTransport sdl_accessoryConnected: and SDLIAPTransport sdl_connectAccessory:

Reproduction Steps

1. Connect an app over the multisession protocol string

Expected Behavior

No delay exists in connecting the apps

Observed Behavior

Apps are delayed in connecting 1.5 - 9.5 seconds

OS & Version Information

• iOS Version: n/a
• SDL iOS Version: 6.2.0-develop
• Testing Against: Ford TDK Sync 3.0

[ghost]

@joeljfischer After lots of tests with 20 "SDL Example" builds on an iPhone X and on various Ford systems I can say that the retry delay cannot be removed for Ford systems.

First of all the delay must remain for pre multiplexing systems which don't support com.smartdevicelink.multisession. Tests showed that these system suffer most if the delay is removed. Also the first Ford system (SYNC3 MY18) shows inconsistent behavior where all 20 apps appear but the system processes the app icons for up to 10 minutes before the apps become operational. All other more recent versions work just fine with 20 apps as long as the SYNC system is already turned on.

If the test phone is connected to SYNC before it finished booting, some systems like our most common used version instantly crashes. Actually Core crashes making mobile app support non-functional for the whole ride. This is not far off common user behavior as the system needs some time until it's fully booted and ready. I don't think we can predict the uptime therefore my statement is that 20 apps without delay won't work on Ford systems.

I have not identified the "sweet spot" of how many apps would work as I would need to run this test again but I gave a delay of 4.5seconds a try on the affected SYNC version and it looked promising. I think the next steps are to do more tests on boot time and stress how many apps can connect without delay and what delay would work fine for that many apps.

[ghost]

After a couple more tests I cannot recommend removing the delay or even reducing it without risking app reliability to connect. This issue should remain open if we still pursue to speed up the connection time but we may need to find another approach to do so. The only solution is to have the HMI integration guideline describe certain KPIs for apps to get connected and support existing head units with their connection time behavior. The head unit should be able to provide information to the app if fast connect is supported. Either by adding a new protocol string (like com.smartdevicelink.default or fastsession etc., the easiest solution for SDL but may be the worst solution for OEMs adding new protocol strings to the MFi program) or by using EAAccessory properties where one property ("software version" or similar) indicates faster connection capabilities. We could also whitelist fast head units or blacklist those that are older and slow but this is more maintenance effort in the library.

I leave it up to the PM how to proceed and hope the tests that we made are helpful to understand the behavior on Ford head units with regards to connection time.

[joeljfischer]

@kshala-ford Thanks for the comments and the suggestions. I'll close this PR and move some of those comments to the issue.

[joeljfischer]

Whoops, this is the issue 😅

[joeljfischer]

This is going to stay as-is as we move into maintenance mode.