Primary Graphic not sent to SDL Core for Media Template

[ashwink11]

Primary Graphic not sent to SDL Core

Primary Graphic and text updated using Screen Manager, however only text gets updated

Reproduction Steps

1. Update Text and graphic using Screen Manager batch process
2. After sometime, keep updating graphic and text (simulate media player with different Artwork and song name)

Expected Behavior

Text and graphic should be updated

Observed Behavior

Only text is updated. Screen manager somehow determines that there is no image to update.
11:24:42:777 ⚪ VERBOSE com.apple.main-thread (SDL)Screen/TextAndGraphic:SDLTextAndGraphicManager:-[SDLTextAndGraphicManager sdl_updateWithCompletionHandler:]:162 - No images to send, sending text

OS & Version Information

• iOS Version: 12.1.2
• SDL iOS Version: 6.1.2
• Testing Against: Ford SYNC

Comments

the function sdl_shouldUpdatePrimaryImage in SDLTextAndGraphicManager.m has a check for [self.displayCapabilities hasImageFieldOfName:SDLImageFieldNameGraphic] and that's returning YES initially but NO later.

If Media app sends Setdisplaylayout with Media template or default. hasGraphic check in sdl_shouldUpdatePrimaryImage fails.

SDLSetDisplayLayout *setDisplayLayout = [[SDLSetDisplayLayout alloc] initWithPredefinedLayout:SDLPredefinedLayoutMedia];
[self.sdlManager sendRequest:setDisplayLayout];

[joeljfischer]

This is a bug with the head unit. They are sending a SetDisplayCapabilitiesResponse with incorrect DisplayCapabilities. There's not much we can do about that in the library because the head unit is literally declaring it doesn't support images when it does. Let us know if there are any additional complications with this issue and we can re-open it.

[jordynmackool]

It was requested that this issue is reopened during the Steering Committee meeting on 2020-11-10. Ford shared new details about this issue:

• Managers in the iOS SDK don’t work with legacy Ford vehicles due to a bug in those vehicle’s head units causing incorrect DisplayCapabilities to be sent when a media app switches from the media template to another template and back.

• The expectation for the resolution would be to always have graphics available with media templates and/or supported as true.

The PM noted that to resolve this issue, we will need to create a special case in the open source SDL library for Ford head units, and will respond on the issue with more information. Given the number of special cases already created, it was suggested that we also discuss having a broader system for handling special cases in a generic way for OEMs to update on their own, with a compatibility library for example.

[jordynmackool]

@ashwink11 It was requested in the Steering Committee meeting on 2020-12-01 by your team that I follow up with you on this issue. Are there any new details that you can share with us about this issue (or any details that were missed in the update on 2020-11-10)?

[ghost]

Hi @jordynmackool. I will try to respond on behalf of Ashwin as he is not in the office.

The issue is seen with media apps on Ford systems that are running software prior to the most recent Ford SYNC software version. As of today this means almost all vehicles on the road.

The displayCapabilities of RAI response can include one or many graphic elements in the imageFields array. The elements include the image resolution for the image field. The initial template for media apps is alwas "MEDIA" so we can expect the image fields to be related to the MEDIA template. I don't think the library scales the images before sending but for the sake of consistency the resolution should be stored for the workaround. The solution could be as followed:

1. If make is Ford/Lincoln, then store the graphic image fields after app registration
2. If app sets template to MEDIA using SetDisplayLayout and the image fields of the response don't contain "graphic", then paste the stores graphic image fields into the image fields of the response
3. We can expect the issue is limited to systems using the old and deprecated DisplayCapabilities struct. Therefore no logic required for Show.templateConfiguration or OnSystemCapability

I understand the motivation of the suggestion allowing OEMs to e.g. create a compatibility library but I'm afraid it'll take a lot of time until we identified a reasonable solution for this streamlined approach. We appreciate this issue to be handled similar to previous cases allowing app partners to continue their work while we discuss the broader system. My suggestion is to add hooks to the sdl libs where OEM specific compat libs could connect to. The hooks can be OnBeforeSendingRPC which is called right before the library sends out an RPC and OnAfterReceivingRPC right after it receives an RPC and before it's processed by managers.However, I don't know if these hooks would allow fixing all the special cases which exist today.

[joeljfischer]

I'm okay with this. I think this can be handled in a custom class / object that hooks into the SDLLifecycleRPCAdapter.

[jordynmackool]

Steering Committee update from the meeting on 2021-03-16: A fix for this issue did not make it into the April 14, 2021 release as testing began on 2021-03-15, Livio to prioritize this issue for a future release.