-
Notifications
You must be signed in to change notification settings - Fork 244
Release 4.2.0 #907
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release 4.2.0 #907
Conversation
Related issue : APPLINK-24892
Applaunch functionality in TransportMaanger and ConnectionHAndler implementation Related issue : APPLINK-24892
Related issue : APPLINK-24892
Related issue : APPLINK-24892
`ResumeCtrl` was divided onto interface and implementation. Related to: APPLINK-24892
`HMICapabilities` was divided onto interface and implementation. Related to: APPLINK-24892
Reduced dependence of `ApplicationManager` from `ResumeCtrl` and `HMICapabilities`. Related to: APPLINK-24892
Related issue : APPLINK-24892
Related issue : APPLINK-24892
Has been done: - Fixed coding style; - Fixed header guard naming; - Fixed copyright comments. Related to: APPLINK-24892
Feature AppLaunch
Has been covered: - `ConnectionHandlerImpl::RunAppOnDevice`; - `TransportManagerImpl::RunAppOnDevice`; - `TransportAdapterImpl::RunAppOnDevice`; - `ResumeCtrlImpl::GetSavedAppHmiLevel`. Related to: APPLINK-24895
Related issue : APPLINK-20920
Related issue : APPLINK-20920
Related issue : APPLINK-20920
Related issue : APPLINK-20920
Related issue : APPLINK-20920
Related issue : APPLINK-20920
Related issue : APPLINK-20920
…R_not_avaliable SDL behaviour if VR not available
…R_not_avaliable Change variable name due to build error
…sReady request or respond with "available" = false Added logic for processing case when HMI does not respond to IsReady request or respond with "available"=false. Based on implementation CRQ [APPLINK-20920](https://adc.luxoft.com/jira/browse/APPLINK-20920) CRQ [APPLINK-25201](https://adc.luxoft.com/jira/browse/APPLINK-25201)
…L_behavior_in_case_HMI_does_not_respond_to_IsReady_request_or_respond_with_available_false VehicleInfo interface: SDL behavior in case HMI does not respond to IsReady request or respond with "available" = false
Been done: - Added specific abstract classes for commands testing (CommandsTest and CommandRequestTest); - Been added unit tests for base command classes (CommandImpl, CommandRequestImpl, CommandResponseImpl); - Been added unit tests for next mobile response commands: - ListFilesResponse - ReadDIDResponse - AlertManeuverResponse - AlertResponse - SubscribeButtonResponse Related to: APPLINK-24911
- moved UT for mobile commands in release/4.2.0 - added some unit tests for mobile commands Related to APPLINK-20925
…mmands_to_release_4_2_0 Feature/Move_unit_tests_for_mobile_commands
Related issue: [APPLINK-27161}(https://adc.luxoft.com/jira/browse/APPLINK-27161)
…heck Add function_id check in request controller
Related issue : APPLINK-28819
…vailable Send language param in RAI response if TTS is available
…timer related issue : APPLINK-28817
…resolve result code relate issue : APPLINK-28797
…orted_resource_delete_command Fix/rui rejected vr unsupported resource delete command
* Fix problem with incorrect success result HMI send erronius result code and after that SDL answers with success=true. I fix this problem. Fix UT according to new implementation. Closes bug [APPLINK-28762](https://adc.luxoft.com/jira/browse/APPLINK-28762)
* Fix TTS IsReady false issues Related: APPLINK-28576, 28577, 28662
* Fix problem with merging info Closes defect [APPLINK-28758](https://adc.luxoft.com/jira/browse/APPLINK-28758)
* Fix change registration wrong code Related: APPLINK-28910, 28905
Test case `RegisterAppInterfaceRequestTest .Run_HmiInterfacesStateAvailable_SUCCESS` has been fixed. Related to: APPLINK-28912
…egisterAppInterfaceRequestTest Fix broken test case in RegisterAppInterfaceRequestTest
Closes defect [APPLINK-28944](https://adc.luxoft.com/jira/browse/APPLINK-28944)
* Add Unit Tests to TTS IsReady false Add uncovered cases to change registration Related: APPLINK-25123 Related: APPLINK-25122
Has been covered SDL commands behavior in case HMI does not respond to `IsReadyRequest`, or respond with `available == false`. Related to: APPLINK-25174
* Create unit test for mobile commands - created UT for mobile commands for UI interface for checking SDL behavior in case HMI does not respond to IsReady_request or respond with "available" = false. Command list: 1. Alert 2. Show 3. AddCommand 4. DeleteCommand 5. AddSubMenu 6. DeleteSubMenu 7. PerformInteraction 8. SetMediaClockTimer 9. SetGlobalProperties 10. ChangeRegistration 11. SetAppIcon 12. SetDisplayLayout 13. Slider 14. ScrollableMessage 15. PerformAudioPassThru 16. EndAudioPassThru Related to APPLINK-25091
113bee8
to
4374842
Compare
@dtrunov I noticed that there is no "onTimeout()" function implemented for the navigation is ready request. @LuxoftAKutsan @mghiumiusliu @AnastasiyaBritanova Also why is the behavior to send messages to HMI components when a timeout for an is ready request occurs? If an HMI component doesn't respond to the is ready request wouldn't it be assumed that the component is unavailable? Also what is the expected behavior for when the HMI reports that a component is NOT ready? |
@JackLivio: "I noticed that there is no "onTimeout()" function implemented for the navigation is ready request". |
@JackLivio it is correct behaviour according to requirements to avoid missing resources in case if IsReady stubs on HMI. I case if HMI didn't respond to INTERFACE.IsReady() request SDL still should send INTERFACE specific requests and wait responses, in case time out for them send GENERIC_ERROR to mobile. I case if HMI respond to INTERFACE.IsReady() request with available=true SDL should send INTERFACE specific requests and wait responses, in case time out for them send GENERIC_ERROR to mobile I case if HMI respond to INTERFACE.IsReady() request with available=false SDL should not send INTERFACE specific requests and respond UNSUPPORTED_RESOURCE to mobile. @AnastasiyaBritanova please approve or amend. |
In `AudioStartStreamRequest` and `NaviStartStreamRequest`, subscription to event and disabling of `AllowedToTerminate` flag, has been moved after checking for applications presence. Closes bug: APPLINK-28988
…uest_may_hang_forever_in_case_of_app_absence Fix that StartStreamRequest may hang forever in case of app absence
@LuxoftAKutsan , what you described above is correct. |
Conflicts: src/components/application_manager/src/request_controller.cc
No description provided.