-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
StartService RPC not ACKed on IVI boot #1783
Comments
Hi @kshala-ford, thank you for reporting this issue. We have already completed development and started testing for the iOS 7.0 release, but will look to include a fix for this issue in the following release. If you are able to submit a PR to resolve this issue, please let us know once that is ready for review. Thanks! |
@theresalech I have not been able to identify the root cause of the issue, whether the system isn't responding or the response got stuck in the library. I could provide a PR to retry starting the session, similar to how the lib retries connecting to the the transport. |
First of all this issue is also visible with 7.0.0 RC3. This is not a surprise as the behavior hasn't changed. The release of 7.0.0 should not be blocked because this issue is no regression in 7.0.0 but goes back to 6.7.0. A possible solution however is to simply increase the timeout Suggested change in SDLLifecycleProtocolHandler.m 24 #import "SDLRPCMessage.h"
25 #import "SDLRPCMessageType.h"
26 #import "SDLTimer.h"
27
28 -static const float StartSessionTime = 10.0;
28 +static const float StartSessionTime = 20.0;
29
30 NS_ASSUME_NONNULL_BEGIN
31
32 @interface SDLLifecycleProtocolHandler () Testing with retry mechanismI tested several options and before I start with the important findings I want to note that a retry mechanism to resend StartService(RPC) in the lifecycle protocol handler causes a lot of problems. The head unit queues all the StartService requests and eventually processes all basically at once. This causes the head unit to enter a state returning Testing with increased timeoutAfter several tests I found that on boot, the iAP accessory driver boots faster than SDL Core hence the library sends the bytes for StartService(RPC) but there's nothing waiting to receive these bytes. They remain in the head unit buffer until SDL Core starts. I tested with a single app with transport based retryDelay disabled to eliminate race conditions by this delay. - (void)sdl_accessoryConnected:(NSNotification *)notification {
EAAccessory *newAccessory = notification.userInfo[EAAccessoryKey];
...
[self sdl_connect:newAccessory];
//[self performSelector:@selector(sdl_connect:) withObject:nil afterDelay:retryDelay];
} Also I increased the timeout in the lifecycle protocol handler to 30 seconds //static const float StartSessionTime = 10.0;
static const float StartSessionTime = 30.0; I also added SDLLog calls here and there in the transport classes to help finding the root cause. I performed the repro steps and turned on the test bench (step 5) at ~ 13:02:45 timestamp. Below filtered logs show the important pieces of what's happening:
The StartService ACK is received almost 14 seconds later. |
@joeljfischer After some testing with 20 "SDL Example" apps I found that on various SYNC3 systems, all apps connect reliably and no app is missing in the app list. On MY18 versions all apps connected as well but it can take up to 10 minutes for app icons to appear. However, at the moment only a small amount of apps would connect with lots of them hit the timeout of 10 seconds. At last app resumption / apps connecting while SYNC boots are affected as well and would properly connect without the timeout. My recommendation is to remove the timeout altogether and wait indefinitely for the head unit response. This is not a problem for the library considering the external accessory has the SDL specific protocol strings. Also disconnecting is not a problem either as deallocation of the lower layer is not affected in any way. Edit: The issue #1847 is not needed and can be closed If we remove the timeout. |
Following up on if removing the timeout altogether is an acceptable approach. Confidence on if the head unit is SDL capable is given due to the protocol string. Code wise it's the easiest solution with regards to reconnect (see #1847). Removing the timeout also solves #1795 based on recent connection time tests. |
I think it could be an acceptable solution, though we'd have to ensure that other OEMs have time to test a branch / PR. |
Steering Committee Update from 2021-03-23: Ford has proposed changes to resolve this issue that they have tested and have seen market improvements on. Ford to work to submit a pull request for this issue that Livio can review following the upcoming April releases. |
Bug Report
With sdl_ios 6.5.0 apps could properly start an RPC service and register if the phone is connected via USB before the IVI system turns on. With 6.7.0 it seems that this is not the case anymore.
I investigated code changes and saw a new class
SDLLifecycleProtocolHandler
which seems to be the successor of theSDLProxy
. My guess is a race condition in SYNC's old Core version couldn't catch the bytes of the StartService frame and probably theSDLProxy
class was not as fast in sending the frame.The issue only appears on MY19 and earlier but not MY20 or later and only for apps which process name results in low delay calculation in the iAP transport class. It was reproducible with the name "Sygic" (~ 2 seconds delay) but not with "Waze" (~9 seconds delay).
Reproduction Steps
Expected Behavior
Observed Behavior
OS & Version Information
Test Case, Sample Code, and / or Example App
You will need to mod the sdl_retryDelay method to fake other process names.
The text was updated successfully, but these errors were encountered: