[Accepted with Revisions] SDL 0293 - Enable OEM exclusive apps support

theresalech commented 4 years ago

Hello SDL community,

The review of the revised proposal "SDL 0293 - Enable OEM exclusive apps support" begins now and runs through November 24, 2020. Previous reviews of this proposal took place March 17 - 24, 2020, June 16 - July 27, 2020, and October 7 - November 10, 2020. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0293-vehicle-type-filter.md

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

https://github.com/smartdevicelink/sdl_evolution/issues/971

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, Theresa Lech

Program Manager - Livio theresa@livio.io

ashwink11 commented 3 years ago

Hi @vladmu , Thank you for reviewing this proposal. JS Suite will not have any supported vehicle type files. As discussed in item 1/2, we will have a callback function that would provide vehicle type information to App. Please refer to this comment for details. This will be added to the proposal in the next revision.

vladmu commented 3 years ago

@ashwink11 thank you for the response. It was just hard to recognize what was proposed due to the missed formatting of the code part of https://github.com/smartdevicelink/sdl_evolution/issues/971#issuecomment-720712448, but if it will be added in the revision, it's fine now.

theresalech commented 3 years ago

@Sohei-Suzuki-Nexty, yes, that's correct.

@ashwink11, thanks for confirming! I've included an updated summary of discussion items below.

Open Items 10. Awaiting input from SDLC Members on the following:

What is the opinion of the SDLC on the probability that a user will have downloaded OEM specific apps that are not of the OEM their vehicle is from? Have we had any reports from actual customers that this is a problem? Or are we trying to solve a problem that seems like a problem?

Author to Revise

1/2. Update to use the an API that allows the developer to receive information from either the protocol StartServiceACK or from the RegisterAppInterfaceResponse. The information is then sent to the SDLManagerDelegate / SdlManagerListener for the developer to handle.

iOS:

- (BOOL)didReceiveVehicleType:(SDLVehicleType *)type;

Java Suite:

boolean onVehicleTypeReceived(VehicleType type);

JavaScript Suite:

     /**
     * A way to determine if this SDL session should continue to be active while
     * connected to the determined vehicle type.
     * @param {SdlManager} sdlManager - A reference to an SdlManager instance.
     * @param {VehicleType} vehicleType - the type of vehicle that this session is currently active on.
     * @returns {Boolean} true if this session should continue, false if the session should end
     */
    onVehicleTypeReceived (sdlManager, vehicleType) {}

If the StartServiceACK comes in with vehicle data, this method will be called with the vehicle type information. If the developer responds true, the session continues, if false, the session ends with an EndService sent by the library. When the RegisterAppInterfaceResponse happens, if the this method will not be called a second time. If the StartServiceACK doesn’t have the vehicle data, when the RegisterAppInterfaceResponse comes in, this above methods will be called. If the developer responds with false, the library will send an UnregisterAppInterface request.

3.

Above mentioned changes need to be implemented in SDL Core, the Java Suite app library, and the iOS app library.

Update to "Above mentioned changes need to be implemented in SDL Core, the Java Suite app library, the iOS app library, and the JavaScript Suite app library."

4.

It is necessary to check support for the StartServiceACK protocol message and vehicle type info before notifying the client with SDL enabled callback. If clients are informed before checking the mentioned info, the exclusive apps could end up registering on an unintended SDL enabled IVI system.

This conflicts with the flow chart further down in the proposal. This should read that the developer will be responsible for checking in the onSDLEnabled method against supported vehicle models before starting their SDL service. The router service will still notify all potential clients that the an SDL device has connected and supply the vehicle info for those potential client apps to decide if they wish to start their SDL services.

5.

If the StartServiceACK message does not have vehicle type info or the protocol version is less than that supporting the vehicle type info and if there are multiple SDL apps available on the user's device, the exclusive apps will not host the router service.

Update to state that if the SS_ACK does not contain vehicle info, the protocol version is less than that of the support of this feature, and no vehicle data is saved regarding this connected device, the normal flow will be followed. However, after the session, once vehicle data is cached from the RAI response, it should be used in determining which app should start the router service.

6.

If the StartServiceACK message does not have vehicle type info or the protocol version is less than that supporting the vehicle type info and if all SDL apps available on the user's device are exclusive apps, the exclusive apps, in this case, will rely on vehicle type info received in the RegisterAppInterface response. In such a case, if vehicle type is not supported, the exclusive apps will be allowed to unregister apps from the SDL system and stop the Android Router Service. The exclusive app will be only allowed to stop the Android Router Service that it hosts.

Update to reflect that the router service should remain up for the remainder of that connection. On the second connection the vehicle info should be saved from the RAI response and can follow the previously defined flows.

7.

public static final String CONNECTED_VEHICLE_INFO = "connected_vehicle_info_for_router_service"; public static final String START_ROUTER_SERVICE_SDL_ENABLED_CONNECTED_VEHICLE_INFO = "connected_vehicle_info";

Update to one constant: public static final String VEHICLE_INFO = "vehicle_info";

9. Specify that the proposal is not applicable for apps registered through AOA

Closed - No Action Required 8. It's been determined this was incorporated into the current proposal in the last set of revisions.

jordynmackool commented 3 years ago

The Steering Committee voted to return this proposal for revisions. The author is to update the proposal to include the revisions described in this comment.

It was requested that SDLC Members respond to the open item number 10 called out in this comment upon review of the revised proposal.

jordynmackool commented 3 years ago

The author has updated this proposal based on the Steering Committee's agreed-upon revisions, and the revised proposal is now in review until November 24, 2020.

The specific items that were updated since the last review can be found in this merged pull request: https://github.com/smartdevicelink/sdl_evolution/pull/1092.

It was requested that SDLC Members respond to the open item number 10 during this review period.

What is the opinion of the SDLC on the probability that a user will have downloaded OEM specific apps that are not of the OEM their vehicle is from? Have we had any reports from actual customers that this is a problem? Or are we trying to solve a problem that seems like a problem?

joeljfischer commented 3 years ago

This proposal looks good to me from an iOS perspective

joeygrover commented 3 years ago

Overall I think this proposal is in good shape. There is likely going to be some code changes when it comes to implementation but mostly minor that wouldn't affect the overall goal of the proposal.

The only thing I would request would be that for the Java Suite library it is possible to complete this feature using two pull requests. The first one being all the protocol changes necessary and developer facing APIs from the SdlManager. The second pull request would focus on the SdlRouterService, SdlBroadcastReceiver, and SdlDeviceListener changes. This would allow the PM to verify the cross platform aspect of this feature first and ensure its inclusion into the next slate of releases no problem. The router service changes take a lot more testing, but that can be done during the SDLC review of the next core release as the mobile libraries have time to include mobile specific features. In other words, one PR that we can use to validate the protocol layer changes with core and ensure they are included, another PR to validate the router service changes (if necessary) while the SDLC reviews the core release.

vladmu commented 3 years ago

@joeljfischer I'd recommend including the last point regarding two PRs in the proposal if it is a requirement. If it is just a recommendation, it could be lost here because is not a part of the proposal, and developers who will implement this follow the proposal first and could even don't read this conversation.

jordynmackool commented 3 years ago

The Steering Committee voted to accept this proposal with revisions. The author is to update the proposal to include the requested requirement for the Java Suite Library to have two pull requests submitted for this feature. The reasoning as to why is documented in this comment and should be included in the proposal.

jordynmackool commented 3 years ago

@ashwink11 please advise when a new PR has been entered to update the proposal to reflect the agreed-upon revisions. I'll then merge the PR so the proposal is up to date, and enter issues in impacted repositories for implementation. Thanks!

jordynmackool commented 3 years ago

Accepted revisions made on 12/14/20. Implementation issues entered:

smartdevicelink / sdl_evolution

[Accepted with Revisions] SDL 0293 - Enable OEM exclusive apps support #971