Add CloseApplication RPC

[jacobkeeler]

Implements #1931

This PR is ready for review.

Risk

This PR makes minor API changes.

Testing Plan

Create base ATF tests for new RPC

Summary

Add new CloseApplication RPC to Mobile and HMI interfaces.

Changelog

Enhancements

• Add new CloseApplication RPC to Mobile and HMI interfaces.

CLA

• I have signed the CLA

[LuxoftAKutsan]

@jacobkeeler This PR contains additional Request\Resoponse to HMI.
There was clarification with proposal author, that for Mobile Close RPC can be used existing ActivateApp to None .
smartdevicelink/sdl_requirements#111
@kshala-ford could you please provide any information about it?

[kshala-ford]

@LuxoftAKutsan does this PR follow option 2 of smartdevicelink/sdl_requirements#111 ?

[jacobkeeler]

@kshala-ford It would appear so.

@LuxoftAKutsan My only reservation with using BC.ActivateApp for this purpose is that it seems like an improper use of the RPC. The app is not being activated, it is being deactivated. I would think that the level parameter of BC.ActivateApp is really only meant to be filled with LIMITED or BACKGROUND in specific cases, NONE doesn't make much sense in the context of this message since the description states that the app should be brought to the foreground. It would technically work as it is implemented in the sdl_hmi currently, but the generic_hmi doesn't have this sort of logic because it isn't really described in the HMI integration guidelines.

[LuxoftAKutsan]

@kshala-ford this PR follow option 2 from smartdevicelink/sdl_requirements#111.

@jacobkeeler From my perspective Adding CloseApplication RPC to HMI API will add confusion.
We will have :

• BC.ActiveteApp (with possible HMI level NONE and background, and as I remember SDL use int in some cases)
• CloseApplicaiton

Now we have 2 options :

• Add explicit description that NONE, BACKGROUND should not be used in ActivateApp and add new CloseApplication RPC. Look throw existing sequenses and replace sending ActivateApp[NONE] to CloseApplication (I suppose that one of the use cases is revoke applicaiton).

• Avoid adding additional RPC CloseApplication, and use ActivateApp[NONE] instead of it. Add apropriate implementation to generic_hmi.

Also it is not clear for me difference between sdl_hmi and generic_hmi. Why do we need both in opensource?

[jacobkeeler]

@LuxoftAKutsan I believe that the documentation would need to be updated in either case, because the HMI documentation doesn't describe the HMI's behavior for each HMI level. As stated, it doesn't seem like ActivateApp(NONE) is a valid case as it is currently described:

<description>Request from SDL to HMI to bring specified application to front on UI e.g make it HMI status 'FULL'.</description>

In addition, it seems to me that HMILevel is generally used as a Mobile<->Core concept rather than a Core<->HMI concept. BC.ActivateApp is the only message which includes this enum in the entire HMI API, so it appears to me that it might have been added after the RPC was initially implemented to fix a specific issue.

The generic_hmi is generally preferred as a reference implementation for SDL, but it is missing several components at the moment (such as Navigation). Being a reference implementation, it is not meant to imitate a full infotainment system, so components such as VehicleInfo will likely never be a part of the generic_hmi. The sdl_hmi is still available specifically as an emulator for a full infotainment system, including the components which cannot be included in the scope of the generic_hmi.

[LuxoftAKutsan]

Not sure, but I suppose that merging this PR will affect existing test scripts ( Smoke and delivered features).
Existing scripts probably will expect ActivateApp(None) in case if the application will be deactivated.

[Jack-Byrne]

Should part of the success be to check if the HMI also sent an OnAppDeactivated? Before setting the app state to HMI_LEVEL none, should the state be checked to see if it is in limited or background?

[jacobkeeler]

I think OnExitApplication would be more appropriate, but I don't think it's necessary for the HMI to send this message, the response should be enough.

[Jack-Byrne]

Why the change to uint32 and then recast to int64?

[jacobkeeler]

It seems this was originally chosen for the return value of SendBCActivateApp to allow for an error response of -1, correlation IDs use uint32_t. I could remove these casts, but it was being done implicitly before anyway.