├── .github ├── ISSUE_TEMPLATE.md └── PULL_REQUEST_TEMPLATE.md ├── .gitignore ├── 0000-template.md ├── LICENSE ├── README.md ├── SDL_Releases.md ├── assets └── proposals │ ├── 0062-template-images │ ├── button-day.png │ ├── button-highlighted.png │ ├── button-night.png │ ├── imagetype-example-day.png │ ├── imagetype-example-night.png │ ├── imagetype-icon-day.png │ ├── imagetype-icon-highlighted.png │ ├── imagetype-icon-night.png │ ├── imagetype-icon.png │ ├── imagetype-pattern-day.png │ ├── imagetype-pattern-highlighted.png │ └── imagetype-pattern-night.png │ ├── 0065-remote-control │ ├── 0065_SDLRC_HMI_Guidelines_v1 1.pdf │ └── 0065_SDLRC_Mobile_API_Guidelines_v1.0.pdf │ ├── 0068-idea_to_implementation │ └── sdl_workflow.png │ ├── 0075-HID-support-plug-in │ ├── HID_Architecture_Overview.pdf │ ├── HID_Architecture_Overview.png │ ├── HID_Architecture_Overview_Alt_1.png │ └── HID_Architecture_Overview_Alt_2.png │ ├── 0080-Support-for-MultiSession-protocol-string │ └── MultiSession-iOS_Proxy_Flow.png │ ├── 0084-Progress-Bar-Seek-Feature │ ├── Current.png │ └── Proposed.png │ ├── 0092-deprecated-interfaces-markup │ └── deprecated_doxygen_example.png │ ├── 0095-AOA-multiplexing │ ├── 0095-AOA-multiplexing_overview.png │ ├── 0095-aoa-multiplexing-class-diagram.png │ ├── 0095-aoa-possible-permanent-routerservice-solution.png │ └── 0095-multiplex_for_multiple_transports.png │ ├── 0122-new_rules_for_providing_vr_help_items_vr_help_title │ └── 0122-New_rules_for_providing_VRHelpItems_VRHelpTitl.png │ ├── 0123-SendURI │ ├── FacebookArticleShare2.jpg │ └── TwitterArticleShare2.jpg │ ├── 0126-ATF-Additional-Transports │ └── atf_transport_adapter.png │ ├── 0127-Atf-Sdl-Watchdog-Service │ └── sdl-watchdog.png │ ├── 0128-atf-script-runner │ └── atf_script_runner_diagram.png │ ├── 0130-SendLocation-for-Mobile-Nav │ ├── SendLocationForMobileNav_RAI.jpg │ └── SendLocationForMobileNav_RequestResponse.jpg │ ├── 0133-EnhancediOSProxyInterface.md │ ├── delegation_2x.png │ ├── f4kekYV.jpg │ └── model_view_controller_2x.png │ ├── 0136-rc-sdl-module │ ├── IMG_1125.jpg │ ├── SDL_App_RC.png │ └── packet_structure.png │ ├── 0137-TouchCoord-outside-video-screen-range │ ├── 0137-TouchCoord-outside-video-screen-range-pic1.png │ └── 0137-TouchCoord-outside-video-screen-range-pic2.png │ ├── 0147-template-color-scheme │ ├── accuweather-day.png │ ├── accuweather-night.png │ ├── iHeart-day.png │ ├── iHeart-night.png │ ├── pandora-day.png │ └── pandora-night.png │ ├── 0156-high-level-interface-foundation │ ├── application-lifecycle.png │ ├── view-controller-lifecycle.png │ └── view-controller-overview.png │ ├── 0158-cloud-app-transport-adapter │ ├── cloud_app_activation.png │ ├── example_use_case_1.png │ ├── example_use_case_2.png │ ├── example_use_case_3.png │ ├── example_use_case_4.png │ └── set_cloud_app_properties.png │ ├── 0167-app-services │ ├── consumer.png │ ├── file_transfer.png │ ├── provider.png │ └── rpc_passthrough.png │ ├── 0168-rpc-design-refactoring │ └── new_design.png │ ├── 0173-Read-Generic-Network-Signal-data │ ├── OEM Mapping table update flow.png │ ├── SDL-HMI request response flow.png │ └── Schema_Version_Update_flow.png │ ├── 0176-high-level-interface-views-and-controllers │ └── view-controller-lifecycle.png │ ├── 0178-getInteriorVehicleData │ ├── GetInteriorVehicleData_current.png │ └── GetInteriorVehicleData_new_subscribe.png │ ├── 0190-resumption-data-error-handling │ ├── multiple_app_error_handling.png │ └── multiple_app_error_handling_with_common_subscriptions.png │ ├── 0194-android-transport-overhaul │ ├── TransportOverhaul_bridge.png │ ├── TransportOverhaul_new.png │ └── TransportOverhaul_old.png │ ├── 0203-cloud_client_library_phase_1 │ ├── cloud_arch_0.png │ ├── cloud_arch_1.png │ ├── cloud_arch_2.png │ ├── java_sets.png │ └── project_hierarchy.png │ ├── 0206-remote_atf_testing │ └── ATFRemoteAdapter.png │ ├── 0211-ServiceStatusUpdateToHMI │ ├── Invalid-Cert.png │ ├── PTU-Time-Out.png │ ├── invalid-system-time.png │ └── sunny-day-scenario.png │ ├── 0216-widget-support │ ├── example-home.jpg │ ├── hmi-chart.png │ ├── rse.jpg │ ├── screen.png │ ├── template-graphic-with-text.png │ ├── template-text-with-graphic.png │ └── template-tiles-with-graphic.png │ ├── 0218-developer-oem-communication │ ├── app-chat-dev.jpg │ ├── app-chat-oem.jpg │ ├── catalog-of-apps.jpg │ ├── catalog-of-oems.jpg │ ├── email-new-issue.png │ ├── email-new-message.png │ ├── issue-create-oem.jpg │ ├── issue-list-dev.jpg │ ├── issue-list-oem.jpg │ ├── issue-view-dev.jpg │ └── issue-view-oem.jpg │ ├── 0221-multiple-modules │ ├── 2x3.jpg │ ├── 3x3.jpg │ └── 4x4.jpg │ ├── 0228-sdl-server-email-notifications │ ├── email-preview.jpg │ └── visual-config-preview.png │ ├── 0230-spp-resource-management-for-android │ ├── manage_notification_1.png │ ├── manage_notification_2.png │ └── spp_notification_popup.png │ ├── 0238-keyboard-enhancements │ ├── azerty_special_chars.png │ ├── numeric_keypad.png │ └── qwerty_special_chars.png │ ├── 0240-sdl-js-pwa │ ├── activate-web-app.png │ └── arch-overview.png │ ├── 0242-alert-style-subtle │ └── subtle-alert-mockup.png │ ├── 0245-sharing-wifi-ssid-and-password │ ├── WiFi_AP_created_manually_Disconnected.png │ ├── WiFi_AP_created_manually_Disconnected.puml │ ├── andoid_permissions.png │ ├── minimal_approach.png │ ├── minimal_approach.puml │ ├── mobile_access_point.png │ ├── mobile_access_point.puml │ ├── mobile_access_point_multidev_externalhost.png │ ├── mobile_access_point_multidev_externalhost.puml │ ├── secure_service.png │ ├── secure_service.puml │ ├── vehicle_access_point.png │ ├── vehicle_access_point.puml │ ├── vehicle_access_point_multiapps.png │ ├── vehicle_access_point_multiapps.puml │ ├── vehicle_access_point_multidev.png │ └── vehicle_access_point_multidev.puml │ ├── 0248-hmi-ptu-support │ ├── diagram_ptu_external_proprietary.png │ ├── diagram_ptu_external_proprietary_enhanced.png │ └── diagram_ptu_external_proprietary_enhanced_fallback.png │ ├── 0249-Persisting-HMI-Capabilities-specific-to-headunit │ ├── hmi_capabilities_caching_sw_different_happypath.png │ ├── hmi_capabilities_caching_sw_different_requestTimeout.png │ └── hmi_capabilities_caching_sw_same.png │ ├── 0250-NextRpcIndication │ ├── 0250-NextRpcIndication.png │ ├── 0250-NextRpcIndicationv2-2.PNG │ └── 0250-NextRpcIndicationv2.PNG │ ├── 0251-font-styles │ └── 0251-font-styles.png │ ├── 0259-Disabled-Softbuttons │ ├── iheartRadio1.PNG │ └── iheartRadio2.PNG │ ├── 0264-Separating-the-change-of-Audible-status-and-the-change-of-HMI-Status │ ├── PHONE_CALL1.png │ ├── PHONE_CALL2.png │ └── index.md │ ├── 0273-webengine-projection-mode │ ├── web-app-example_with_exit_button_and_template_title.jpg │ └── web-app-example_with_outside_menu_and_template_title.jpg │ ├── 0277-Continuous-Integration-And-Testing │ └── ClusterSchema.png │ ├── 0280-Adding-new-parameter-of-requiresAudioSupport-and-BluetoothDeviceAddress │ ├── registeringApp_flow.png │ └── registeringApp_flow2.png │ ├── 0284-DialNumber_Text │ ├── Current Dial Number.png │ └── Future Dial Number.png │ ├── 0291-allows-navigation-apps-to-access-information-about-Wi-Fi-networks │ └── sequence_diagram.png │ ├── 0292-improve-VDE-for-stable-frame-rate │ ├── vd_mc_unstable.png │ └── vd_w_intermediate_surface.png │ ├── 0293-vehicle-type-filter │ ├── OEM_APPS_1.png │ ├── OEM_APPS_2.png │ ├── OEM_APPS_3.png │ ├── OEM_APPS_4.png │ ├── one_noti.png │ ├── sequence_diagram.png │ └── two_noti.png │ ├── 0296-Update-video-streaming-capabilities-during-ignition-cycle │ ├── Negotiation_of_VSCs.svg │ └── Resolution_Switching.svg │ ├── 0297-Add-function-to-transmit-audio-data │ └── Image.gif │ ├── 0301-SDL-device-listener │ └── flow_chart.png │ ├── 0302-SDL-System-Structure-for-MiddleLow-end-Class-Model-of-Powered-Two-Wheeler │ ├── Figure1_Sample_of_a_simple_meter_display.png │ ├── Figure2_SDL_System_for_Middle_Low_end_class.png │ └── Figure3_System_structure_of_proxy_and_meter_unit.png │ ├── 0303-audio-io-manager │ ├── SDLAudioIOManager.h │ ├── SDLAudioIOManager.m │ └── SDLAudioIOManagerDelegate.h │ ├── 0307-GetInput │ ├── GetInput Overview.PNG │ ├── GetInput-1-1.PNG │ ├── GetInput-1-2.PNG │ ├── GetInput-1.PNG │ ├── GetInput-2.PNG │ ├── GetInput-3-1.PNG │ ├── GetInput-3-2.PNG │ ├── GetInput-3.PNG │ └── GetInput-ErrorFlow.PNG │ ├── 0309-android-notifications │ ├── all_noti.png │ ├── noti_button.png │ ├── noti_button_1.png │ ├── noti_button_2.png │ ├── review_1.png │ ├── review_2.png │ ├── review_3.png │ ├── sdl_faq.png │ └── waiting_for_connection.png │ ├── 0310-PerformInteraction-Multipick │ └── PerformInteraction Multipick overview.PNG │ ├── 0314-Clarification-of-SDL-App-Icon-display-sequence-and-display-order │ └── Figure1_SDL_App_Icon_display_sequence.PNG │ ├── 0315-Add-RPC-Conflict-Management │ ├── Figure1_Conflict_between_ScrollableMessage_and_PerformAudioPassThru_1.png │ ├── Figure2_ONS_RPCs_conflict.png │ ├── Figure3_TTS_RPCs_conflict.png │ └── Table_2_Priority_result_of_Table1.png │ ├── 0316-Clarification-of-transport-switching-rules-and-improvement-of-UX │ ├── Figure_1_Sequence_with_new_RPC_added_to_existing_logic1.png │ └── Table_1_Switching_of_Multiple_Transport.png │ ├── 0317-sdl-protocol-security-specification │ ├── tls-handshake.png │ └── tls-handshake.uml │ ├── 0319-Add-a-notification-and-restore-function-for-unexpected-exception-error │ ├── Figure_1_error_notification_sequence.png │ └── Figure_2_return_processing.png │ ├── 0320-Add-screen-stack-management-module │ ├── Screen_transition_process.png │ └── new_sequence.png │ ├── 0324-Function-to-control-the-priority-of-audio-and-video-when-switching-between-apps │ └── Figure_1_app_switching_sequence.png │ ├── 0325-Dynamic-App-List-Sorting │ └── Figure1_SDL_App_Icon_display_sequence.PNG │ ├── 0326-handle-late-malformed-hmi-responses │ └── addCommand_fail.png │ ├── 0331-Add-new-SDL-System-Structure-using-Mediation-Application │ ├── Figure1_Current_SDL_system_configuration.png │ └── Figure2_new_SDL_system_configuration.png │ ├── 0337-reject-proprietary-http-systemrequests-when-ptu-not-in-progress │ ├── Http_request_flow.png │ └── Proprietary_request_flow.png │ ├── 0340-atf-selenium-support │ └── ATFSelenium.png │ ├── 0341-add-generic-hmi-plugin-support │ ├── menu-example.png │ ├── plugin-tabs-example.png │ └── vr-plugin-stub-example.png │ └── 0343-Addition-of-a-way-to-notify-HMI-of-the-required-support-for-apps │ └── Figure_1_sequence_of_Add_Notifications_for_Required_App_Support.png ├── changelog.md ├── commonly_proposed.md ├── process.md ├── proposal-status.xsl ├── proposals.xml ├── proposals ├── 0001-secured-preferences.md ├── 0002-turn-by-turn-mobile-managers.md ├── 0003-last-mile-navigation.md ├── 0004-sendlocation-updates.md ├── 0005-ios-immutable-rpc-storage-properties.md ├── 0006-ios-stringly-typed-enums.md ├── 0007-ios-objc-generics.md ├── 0008-ios-7-0-minimum.md ├── 0009-ios-library-prefer-nonatomic.md ├── 0010-spec-buttonname-additions-for-navigation-applications.md ├── 0011-ios-library-conform-to-nscopying.md ├── 0012-ios-library-remove-siphon.md ├── 0013-ios-remove-json-encode-decode-classes.md ├── 0014-adding-audio-file-playback-to-ttschunk.md ├── 0015-android-studio-sdl-plugin.md ├── 0016-ios-library-transport-private-cleanup.md ├── 0017-ios-protocol-layer-nonpublic.md ├── 0018-ios-use-nullability-annotations.md ├── 0019-ios-proxy-layer-nonpublic.md ├── 0020-ios-remove-rpcrequestfactory.md ├── 0021-ios-remove-sdlttschunkfactory.md ├── 0022-android-rsvp-off.md ├── 0023-update-mobile-api-mandatory-flag.md ├── 0024-ios-8-0-minimum.md ├── 0025-ios-filemanager-stream-from-disk.md ├── 0026-android_move_to_android_studio.md ├── 0027-ios-specify-handlers.md ├── 0028-meta-template-potential-downsides.md ├── 0029-ios-multiple-file-manager-transactions.md ├── 0030-ios-logging-redesign.md ├── 0031-mobile-projection.md ├── 0032-on-hmi-status-state-changes.md ├── 0033-streaming-media-manager-update.md ├── 0034-ios-cocoapods-rename.md ├── 0035-audio-pass-thru-handler.md ├── 0036-android-up_target-version.md ├── 0037-Expand-Mobile-putfile-RPC.md ├── 0038-Communication-app-activation.md ├── 0039-'menuIcon'-menuTitle'-params.md ├── 0040-DTLS-encryption.md ├── 0041-appicon-resumption.md ├── 0042-transfer-invalid-image-rpc.md ├── 0043-upgrade-c++-standard.md ├── 0044-use-Boost-library.md ├── 0045-external-policy-manager.md ├── 0046-implement-logger-abstraction.md ├── 0047-manual-lockscreen-layout-ios.md ├── 0048-H264-over-RTP-support-for-video-streaming.md ├── 0049-touch-cancellation.md ├── 0050-add-api-patch-version.md ├── 0051-enhance_video_streaming_apis_for_android.md ├── 0052-constructed-payloads.md ├── 0053-Connectivity-via-iAP-BT-and-Transport-Switch.md ├── 0054-change-registration-manager.md ├── 0055-system_capabilities_query.md ├── 0056-hardware-validator-app-android.md ├── 0057-add-zeroconf-capability.md ├── 0058-video-streaming-capabilities.md ├── 0059-android_rpc_refactor.md ├── 0060-support-indian-english-thai.md ├── 0061-locale-support.md ├── 0062-template-images.md ├── 0063-display-name-parameter.md ├── 0064-choice-vr-optional.md ├── 0065-remote-control.md ├── 0066-steering-wheel-location.md ├── 0067-optimize-connection-wait-range.md ├── 0068-idea_to_implementation.md ├── 0069-enhance-video-streaming-performance-for-android.md ├── 0070-iap-transport-type-notification.md ├── 0071-remote-control-baseline.md ├── 0072-New-vehicle-data-FuelRange.md ├── 0073-Adding-Metadata-Types.md ├── 0074-android_o_changes_phase_1.md ├── 0075-HID-Support-Plug-in.md ├── 0076-Support-For-Additional-Languages.md ├── 0077-sdl-policy-server-enhancements.md ├── 0078-control_frame_payloads_v1_0_0.md ├── 0079-system_capability_manager.md ├── 0080-Support-for-MultiSession-protocol-string.md ├── 0081-SDLInterfaceManager.md ├── 0082-New-vehicle-data-EngineOilLife.md ├── 0083-Expandable-design-for-proprietary-data-exchange.md ├── 0084-Progress-Bar-Seek-Feature.md ├── 0085-submenu-icon.md ├── 0086-auto_set_correlation_ids_android.md ├── 0087-send-multiple-rpcs.md ├── 0088-ios-system-capability-manager.md ├── 0089-mobile-api-versioning.md ├── 0090-SDLHapticHitTesterProtocol.md ├── 0091-SDLScreen-SDLWindow-Projection.md ├── 0092-Deprecated-interfaces-markup.md ├── 0093-haptic-projection.md ├── 0094-sdl-policy-server-ui.md ├── 0095-AOA-multiplexing.md ├── 0096-deliver-build-configuration.md ├── 0097-tire-pressure-additions.md ├── 0098-localization.md ├── 0099-new-remote-control-modules-and-parameters.md ├── 0100-new-data-transfer-interface-for-streaming-android.md ├── 0101-android_internal_interface.md ├── 0102-New-vehicle-data-ElectronicParkBrakeStatus.md ├── 0103-ApplicationCustomSounds.md ├── 0104-atf_security_proposal.md ├── 0105-remote-control-seat.md ├── 0106-remote-control-onRcStatus-notification.md ├── 0107-New-vehicle-data-turnSignal.md ├── 0108-AutoCompleteList.md ├── 0109-set-audio-streaming-indicator.md ├── 0110-remove-qt-hmi-from-sdl-core.md ├── 0111-ios-carwindow.md ├── 0112-ios-serial-rpc-notifications.md ├── 0113-audiostreammanager.md ├── 0114-default-softbuttoncapabilities.md ├── 0115-close-application.md ├── 0116-open-menu.md ├── 0117-configurable-time-before-shutdown.md ├── 0118-video-background-string.md ├── 0119-SDL-passenger-mode.md ├── 0120-GetSystemTime.md ├── 0121-atf_facade_proposal.md ├── 0122-New_rules_for_providing_VRHelpItems_VRHelpTitle.md ├── 0123-SendURI.md ├── 0124-SDLImageUploadManager.md ├── 0125-atf-videostreaming-full-support.md ├── 0126-atf-additional-transports.md ├── 0127-atf-sdl-watchdog-service.md ├── 0128-atf-script-runner.md ├── 0129-ios-additional-apptypes.md ├── 0130-SendLocation-for-Mobile-Nav.md ├── 0131-test-scripts-common-modules-refactoring.md ├── 0132-Change_ATF_test_reports_folder_structure.md ├── 0133-EnhancediOSProxyInterface.md ├── 0134-ios-show-manager.md ├── 0135-PushToTalk-hardkey-support.md ├── 0136-rc-sdl-module.md ├── 0137-TouchCoord-outside-video-screen-range.md ├── 0138-hmi-audiopassthru-capability.md ├── 0139-apt-clarification.md ├── 0140-android_metadata.md ├── 0141-multiple-transports.md ├── 0142-mt-instance-ids.md ├── 0143-mt-service-discovery.md ├── 0144-app-nicknames.md ├── 0145-distraction-notification-after-registration.md ├── 0146-updating-mobile-version-dependencies.md ├── 0147-template-color-scheme.md ├── 0148-template-additional-submenus.md ├── 0149-mt-registration-limitation.md ├── 0150-video-streaming-state.md ├── 0151-imagefieldname-for-secondary-image.md ├── 0152-driver-distraction-list-limits.md ├── 0153-support-short-long-appid.md ├── 0154-add-sdl-core-daemon-script.md ├── 0155-mobile-menu-manager.md ├── 0156-high-level-interface-foundation.md ├── 0157-mobile-choice-manager.md ├── 0158-cloud-app-transport-adapter.md ├── 0159-Static-SDL-Icon-Names-Enum.md ├── 0160-rc-radio-parameter-update.md ├── 0161-remove-sdl-cordova.md ├── 0162-define-handling-of-duplicate-correlation-ids.md ├── 0163-make-spaceavailable-field-non-mandatory.md ├── 0164-modernize-ubuntu-support.md ├── 0165-rc-lights-more-names-and-status-values.md ├── 0166-use-android-annotations-library.md ├── 0167-app-services.md ├── 0168-rpc-design-refactoring.md ├── 0169-initial-and-hint-text-for-keyboard.md ├── 0170-sdl-behavior-in-case-of-Low-Voltage.md ├── 0171-android-manager-apis.md ├── 0172-onRcStatus-allowed.md ├── 0173-Read-Generic-Network-Signal-data.md ├── 0174-deprecate-rpc-request-factory.md ├── 0175-Updating-DOP-value-range-for-GPS-notification.md ├── 0176-high-level-interface-views-and-controllers.md ├── 0177-alert-icon.md ├── 0178-GetInteriorVehicleData.md ├── 0179-pixel-density-and-scale.md ├── 0180-broaden-choice-uniqueness.md ├── 0181-keep-rc-app-hmi-level-when-disable-rc.md ├── 0182-audio-source-am-fm-xm.md ├── 0183-mobile-hash-managment.md ├── 0184-cancel-interaction.md ├── 0185-remove-hello-sdl-ios.md ├── 0186-template-titles.md ├── 0187-restructure-ios-threading.md ├── 0188-get-interior-data-resumption.md ├── 0189-Restructuring-OnResetTimeout.md ├── 0190-resumption-data-error-handling.md ├── 0191-retry-failed-file-uploads.md ├── 0192-button_subscription_response_from_hmi.md ├── 0193-update-android-min-sdk.md ├── 0194-android-transport-overhaul.md ├── 0195-minimum-main-and-secondary-font-size.md ├── 0196-sdlartwork-static-icons.md ├── 0197-setmediaclocktimer-initializers.md ├── 0198-media-skip-indicators.md ├── 0199-Adding-GPS-Shift-support.md ├── 0200-Removing-URL-Param-Max-Length.md ├── 0201-high-level-interface-overlay-controllers.md ├── 0202-character-sets.md ├── 0203-cloud_client_library_phase_1.md ├── 0204-same-app-from-multiple-devices.md ├── 0205-Avoid_custom_button_subscription_when_HMI_does_not_support.md ├── 0206-remote_atf_testing.md ├── 0207-rpc-message-protection.md ├── 0208-block-sdl-head-units.md ├── 0209-static-icon-capability.md ├── 0210-mobile-dynamic-menu-cell-updating.md ├── 0211-ServiceStatusUpdateToHMI.md ├── 0212-add-ability-to-reuse-a-syncfilename-for-a-putfile.md ├── 0213-rc-radio-climate-parameter-update.md ├── 0214-secondary-transport-optimization.md ├── 0215-ios-replaykit-streaming.md ├── 0216-widget-support.md ├── 0217-android-manager-listener-update.md ├── 0218-developer-oem-communication.md ├── 0219-ios-check-type.md ├── 0220-support-for-android-custom-routerservice.md ├── 0221-multiple-modules.md ├── 0222-rair-system-software-name.md ├── 0223-media-service-image.md ├── 0224-navigation-subscription-buttons.md ├── 0225-update-published-app-services.md ├── 0226-ios-manager-rpc-subscriptions.md ├── 0227-add-supported-rgb-colors.md ├── 0228-sdl-server-email-notifications.md ├── 0229-sdl-server-version-tracking.md ├── 0230-spp-resource-management-for-android.md ├── 0231-main-menu-tiles.md ├── 0232-add_pushing_buffer_support_to_audio_stream_manager.md ├── 0233-policy-server-statistics-recording-visualizations.md ├── 0234-proxy-rpc-generation.md ├── 0235-sdl-js-library.md ├── 0236-TireStatus-Mismatch.md ├── 0237-add-feature-to-disable-video-streaming-backgrounded-string-feature.md ├── 0238-Keyboard-Enhancements.md ├── 0239-media-service-data-progress-bar-improvements.md ├── 0240-sdl-js-pwa.md ├── 0241-Commerce-App-Service.md ├── 0242-alert-style-subtle.md ├── 0243-manager-update-display-capability.md ├── 0244-setmediaclocktimer-custom-playback-rates.md ├── 0245-sharing-wifi-ssid-and-password.md ├── 0246-app-services-hmi_capabilities.md ├── 0247-sdl-server-3.md ├── 0248-hmi-ptu-support.md ├── 0249-Persisting-HMI-Capabilities-specific-to-headunit.md ├── 0250-NextRpcIndication.md ├── 0251-font-styles.md ├── 0252-Aligning-HMI-and-MOBILE-API-for-pcmStreamCapabilities.md ├── 0253-New-vehicle-data-StabilityControlsStatus.md ├── 0254-New-vehicle-data-HVBatteryLevel.md ├── 0255-Enhance-BodyInformation-vehicle-data.md ├── 0256-Refactor-Fuel-Information-Related-Vehicle-Data.md ├── 0257-New-vehicle-data-HandsOffSteering.md ├── 0258-Update-vehicle-data-TurnSignal.md ├── 0259-DisabledSoftbuttons.md ├── 0260-Deprecate-HMI-RPC-OnFindApplications.md ├── 0261-New-vehicle-data-WindowStatus.md ├── 0262-New-vehicle-data-SeatOccupancy.md ├── 0263-System-Request.md ├── 0264-Separating-the-change-of-Audible-status-and-the-change-of-HMI-Status.md ├── 0265-Remove-Duplicate-Parameter-HMI-RPC-OnPutFile.md ├── 0266-New-vehicle-data-GearStatus.md ├── 0267-addcommand-ui-updates.md ├── 0268-main-menu-updating.md ├── 0269-New-vehicle-data-ClimateData.md ├── 0270-Add-means-to-launch-with-optimum-appHMIType.md ├── 0271-Start-APT-of-SDL-App-by-pressing-PTT-Button.md ├── 0272-sdl-javascript-manager-layer.md ├── 0273-webengine-projection-mode.md ├── 0274-add-preferred-FPS.md ├── 0275-webengine-app-testing.md ├── 0276-POI-Service-Supported.md ├── 0277-Continuous-Integration-And-Testing.md ├── 0278-screenmanager-layout-management.md ├── 0279-screen-manager-subscribe-buttons.md ├── 0280-Adding-new-parameter-of-requiresAudioSupport-and-BluetoothDeviceAddress.md ├── 0281-Add-a-mechanism-to-exclude-route-guidance-between-embedded-navigation-and-SDL-navigation.md ├── 0282-screen-manager-alerts.md ├── 0283-screen-manager-scrollable-message-and-slider.md ├── 0284-DialNumber_Text.md ├── 0285-ConstantTBT-Update.md ├── 0286-java-suite-cleanup.md ├── 0287-example-apps-organization.md ├── 0288-screen-manager-play-audio.md ├── 0289-set-language-separately.md ├── 0290-modify-the-range-of-APT's-maxDuration.md ├── 0291-allows-navigation-apps-to-access-information-about-Wi-Fi-networks.md ├── 0292-improve-VDE-for-stable-frame-rate.md ├── 0293-vehicle-type-filter.md ├── 0294-app-service-messaging.md ├── 0295-screen-manager-audio-pass-thru.md ├── 0296-Update-video-streaming-capabilities-during-ignition-cycle.md ├── 0297-Add-function-to-transmit-audio-data.md ├── 0298-Processing-of-unknown-enum-values-by-SDL-Core.md ├── 0299-Avoid-Deadlock.md ├── 0300-Voice-Assistant-App-Service.md ├── 0301-SDL-device-listener.md ├── 0302-SDL-System-Structure-for-MiddleLow-end-Class-Model-of-Powered-Two-Wheeler.md ├── 0303-audio-io-manager.md ├── 0304-stream-ontouchevent.md ├── 0305-homogenize-textfieldname.md ├── 0306-Use-Taskmaster-To-Handle-Queuing-Operations-In-Managers.md ├── 0307-GetInputScreen.md ├── 0308-protocol-nak-reason.md ├── 0309-android-notifications.md ├── 0310-PerformInteractionMultipick.md ├── 0311-Make-RPC-Setters-Chainable.md ├── 0312-ios-update-minimum-version-ios10.md ├── 0313-Adding-new-parameters-for-transport-switching.md ├── 0314-Clarification-of-SDL-App-Icon-display-sequence-and-display-order.md ├── 0315-Add-RPC-Conflict-Management.md ├── 0316-Clarification-of-transport-switching-rules-and-improvement-of-UX.md ├── 0317-sdl-protocol-security-specification.md ├── 0318-app-lib-vehicle-data-manager.md ├── 0319-Add-a-notification-and-restore-function-for-unexpected-exception-error.md ├── 0320-Add-screen-stack-management-module.md ├── 0321-window-capabilities-template-name.md ├── 0322-improve-starting-streaming-services.md ├── 0323-align-VideoStreamingParameter-with-capability.md ├── 0324-Function-to-control-the-priority-of-audio-and-video-when-switching-between-apps.md ├── 0325-Dynamic-App-List-Sorting.md ├── 0326-handle-late-malformed-hmi-responses.md ├── 0327-app-lib-remote-control-manager.md ├── 0328-modernize-ubuntu-support-v20.md ├── 0329-on-data-resumed.md ├── 0330-app-service-resumption.md ├── 0331-Add-new-SDL-System-Structure-using-Mediation-Application.md ├── 0332-additional-video-streaming-capabilities-validation.md ├── 0333-handle-scenario-where-no-valid-cert-is-available.md ├── 0334-transform-setdisplaylayout-requests-to-ui-show.md ├── 0335-limit-textfield-length-according-to-hmi-capabilities.md ├── 0336-strict-versioning-for-outgoing-core-messages.md ├── 0337-reject-proprietary-http-systemrequests-when-ptu-not-in-progress.md ├── 0338-remove-unused-files-from-sdl-core.md ├── 0339-replace-pthread-implementation-with-threads-from-cpp11.md ├── 0340-atf-selenium-support.md ├── 0341-add-generic-hmi-plugin-support.md ├── 0342-remove-policy-mode-option-from-sdl-core.md ├── 0343-Addition-of-a-way-to-notify-HMI-of-the-required-support-for-apps.md ├── 0344-Promises-in-Policy-Server.md └── 0345-android-12-issues.md └── proposals_versus_issues.md /.github/ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | **IF YOU ARE NOT A REVIEW MANAGER, YOU SHOULD NOT BE ADDING ISSUES TO THIS REPOSITORY. IF YOU ADD AN ISSUE, NOBODY WILL RESPOND AND THE ISSUE WILL BE CLOSED WITHOUT A REASON GIVEN.** 2 | 3 | **ANY ISSUES YOU HAVE SHOULD BE DIRECTED TO THE APPROPRIATE SDL REPOSITORY.** 4 | 5 | **IF YOU HAVE A QUESTION, ASK IT IN THE [SDL SLACK](http://slack.smartdevicelink.com).** 6 | 7 | Hello SDL community, 8 | 9 | The review of "[[PROPOSAL TITLE]]" begins now and runs through [[NEXT TUESDAY END DATE]]. The proposal is available here: 10 | 11 | [[LINK TO PROPOSAL TEXT]] 12 | 13 | Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at: 14 | 15 | [[LINK TO THIS GITHUB ISSUE]] 16 | 17 | What goes into a review? 18 | 19 | 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: 20 | 21 | * Is the problem being addressed significant enough to warrant a change to SDL? 22 | * Does this proposal fit well with the feel and direction of SDL? 23 | * If you have used competitors with a similar feature, how do you feel that this proposal compares to those? 24 | * How much effort did you put into your review? A glance, a quick reading, or an in-depth study? 25 | Please state explicitly whether you believe that the proposal should be accepted into SDL. 26 | 27 | More information about the SDL evolution process is available at 28 | 29 | https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md 30 | 31 | Thank you, 32 | [[YOUR NAME]] 33 | 34 | [[YOUR TITLE]] - [[YOUR PLACE OF WORK]] 35 | [[YOUR EMAIL]] 36 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | [In creating a Pull Request for SDL Evolution, please note the following guidelines: 2 | 3 | 1. Please make the title of your pull request the *exact* title of your proposal. 4 | 2. Please make the text of your pull request the *exact* text of the introduction of your proposal. 5 | 3. Please make a new comment (do not do this in the initial text) notifying @theresalech that the proposal is ready for review when you wish to make no more changes and for the SDLC Steering Committee to consider reviewing your pull request. It will not be considered for review until you have done so. 6 | 4. Please follow the [template](https://github.com/smartdevicelink/sdl_evolution/blob/master/0000-template.md) and fill out the metadata at the top properly. 7 | 5. Please make sure your proposal is clear for reviewers to read, keeping in mind that the majority of reviewers are English-speaking. Proposals should be formatted per the templates and guidelines provided, including the rules in (4). Once you have asked for a "review ready" tag, the project maintainers will quickly skim your proposal and note obvious errors that need to be fixed. The maintainers are not to be relied upon to catch all errors. The Steering Committee may push back on misformatted proposals or decide not to review a proposal until it is formatted properly and easily read. Please make sure your proposals are in a "final" state before requesting review! 8 | 9 | Please delete the above section when you have read it.] 10 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | ############################## 2 | # Project Specific 3 | ############################## 4 | 5 | 6 | ############################## 7 | # OS generated files 8 | ############################## 9 | .DS_Store 10 | .DS_Store? 11 | ._* 12 | .Spotlight-V100 13 | .Trashes 14 | ehthumbs.db 15 | Thumbs.db 16 | 17 | ############################## 18 | # built application files 19 | ############################## 20 | *.apk 21 | *.ap_ 22 | 23 | ############################## 24 | # files for the dex VM 25 | ############################## 26 | *.dex 27 | 28 | ############################## 29 | # Java class files 30 | ############################## 31 | *.class 32 | 33 | ############################## 34 | # Generated files 35 | ############################## 36 | bin/ 37 | gen/ 38 | 39 | ############################## 40 | # Local configuration file 41 | ############################## 42 | local.properties 43 | 44 | ############################## 45 | # Eclipse project files 46 | ############################## 47 | .classpath 48 | .project 49 | 50 | ############################## 51 | # Proguard folder (Eclipse) 52 | ############################## 53 | proguard/ 54 | 55 | ############################## 56 | # Intellij project files 57 | ############################## 58 | *.iml 59 | *.ipr 60 | *.iws 61 | .idea/ 62 | build/ 63 | .gradle 64 | /local.properties 65 | /.idea/workspace.xml 66 | /.idea/libraries 67 | /captures 68 | .externalNativeBuild 69 | 70 | -------------------------------------------------------------------------------- /0000-template.md: -------------------------------------------------------------------------------- 1 | ``` 2 | # Feature name 3 | 4 | * Proposal: [SDL-NNNN](NNNN-filename.md) 5 | * Author: [SDL Developer](https://github.com/smartdevicelink) 6 | * Status: **Awaiting review** 7 | * Impacted Platforms: [Core / iOS / Java Suite / JavaScript Suite / HMI / Policy Server / SHAID / RPC / Protocol] 8 | 9 | ## Introduction 10 | 11 | A short description of what the feature is. Try to keep it to a single-paragraph "elevator pitch" so the reader understands what problem this proposal is addressing. 12 | 13 | ## Motivation 14 | 15 | Describe the problems that this proposal seeks to address. If the problem is that some common pattern is currently hard to express, show how one can currently get a similar effect and describe its drawbacks. If it's completely new functionality that cannot be emulated, motivate why this new functionality would help SDL mobile developers or OEMs provide users with useful functionality. 16 | 17 | ## Proposed solution 18 | 19 | Describe your solution to the problem. Provide examples and describe how they work. Show how your solution is better than current workarounds: is it cleaner, safer, or more efficient? Use subsections if necessary. 20 | 21 | Describe the design of the solution in detail. Use subsections to describe various details. If it involves new protocol changes or RPC changes, show the full XML of all changes and how they changed. Show documentation comments detailing what it does. Show how it might be implemented on the App Library and Core. The detail in this section should be sufficient for someone who is *not* one of the authors to be able to reasonably implement the feature and future [smartdevicelink.com](https://www.smartdevicelink.com) guides. 22 | 23 | ## Potential downsides 24 | 25 | Describe any potential downsides or known objections to the course of action presented in this proposal, then provide counter-arguments to these objections. You should anticipate possible objections that may come up in review and provide an initial response here. Explain why the positives of the proposal outweigh the downsides, or why the downside under discussion is not a large enough issue to prevent the proposal from being accepted. 26 | 27 | ## Impact on existing code 28 | 29 | Describe the impact that this change will have on existing code. Will some SDL integrations stop compiling due to this change? Will applications still compile but produce different behavior than they used to? Is it possible to migrate existing SDL code to use a new feature or API automatically? 30 | 31 | ## Alternatives considered 32 | 33 | Describe alternative approaches to addressing the same problem, and why you chose this approach instead. 34 | ``` 35 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Copyright (c) 2017 - 2020 SmartDeviceLink Consortium, Inc. 2 | All rights reserved. 3 | 4 | Redistribution and use in source and binary forms, with or without 5 | modification, are permitted provided that the following conditions are met: 6 | 7 | * Redistributions of source code must retain the above copyright notice, this 8 | list of conditions and the following disclaimer. 9 | 10 | * Redistributions in binary form must reproduce the above copyright notice, 11 | this list of conditions and the following disclaimer in the documentation 12 | and/or other materials provided with the distribution. 13 | 14 | * Neither the name of SmartDeviceLink Consortium, Inc. nor the names of its 15 | contributors may be used to endorse or promote products derived from 16 | this software without specific prior written permission. 17 | 18 | THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 19 | AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 20 | IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 21 | DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE 22 | FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 23 | DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 24 | SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 25 | CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 26 | OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 27 | OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 28 | -------------------------------------------------------------------------------- /assets/proposals/0062-template-images/button-day.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0062-template-images/button-day.png -------------------------------------------------------------------------------- /assets/proposals/0062-template-images/button-highlighted.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0062-template-images/button-highlighted.png -------------------------------------------------------------------------------- /assets/proposals/0062-template-images/button-night.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0062-template-images/button-night.png -------------------------------------------------------------------------------- /assets/proposals/0062-template-images/imagetype-example-day.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0062-template-images/imagetype-example-day.png -------------------------------------------------------------------------------- /assets/proposals/0062-template-images/imagetype-example-night.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0062-template-images/imagetype-example-night.png -------------------------------------------------------------------------------- /assets/proposals/0062-template-images/imagetype-icon-day.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0062-template-images/imagetype-icon-day.png -------------------------------------------------------------------------------- /assets/proposals/0062-template-images/imagetype-icon-highlighted.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0062-template-images/imagetype-icon-highlighted.png -------------------------------------------------------------------------------- /assets/proposals/0062-template-images/imagetype-icon-night.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0062-template-images/imagetype-icon-night.png -------------------------------------------------------------------------------- /assets/proposals/0062-template-images/imagetype-icon.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0062-template-images/imagetype-icon.png -------------------------------------------------------------------------------- /assets/proposals/0062-template-images/imagetype-pattern-day.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0062-template-images/imagetype-pattern-day.png -------------------------------------------------------------------------------- /assets/proposals/0062-template-images/imagetype-pattern-highlighted.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0062-template-images/imagetype-pattern-highlighted.png -------------------------------------------------------------------------------- /assets/proposals/0062-template-images/imagetype-pattern-night.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0062-template-images/imagetype-pattern-night.png -------------------------------------------------------------------------------- /assets/proposals/0065-remote-control/0065_SDLRC_HMI_Guidelines_v1 1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0065-remote-control/0065_SDLRC_HMI_Guidelines_v1 1.pdf -------------------------------------------------------------------------------- /assets/proposals/0065-remote-control/0065_SDLRC_Mobile_API_Guidelines_v1.0.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0065-remote-control/0065_SDLRC_Mobile_API_Guidelines_v1.0.pdf -------------------------------------------------------------------------------- /assets/proposals/0068-idea_to_implementation/sdl_workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0068-idea_to_implementation/sdl_workflow.png -------------------------------------------------------------------------------- /assets/proposals/0075-HID-support-plug-in/HID_Architecture_Overview.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0075-HID-support-plug-in/HID_Architecture_Overview.pdf -------------------------------------------------------------------------------- /assets/proposals/0075-HID-support-plug-in/HID_Architecture_Overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0075-HID-support-plug-in/HID_Architecture_Overview.png -------------------------------------------------------------------------------- /assets/proposals/0075-HID-support-plug-in/HID_Architecture_Overview_Alt_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0075-HID-support-plug-in/HID_Architecture_Overview_Alt_1.png -------------------------------------------------------------------------------- /assets/proposals/0075-HID-support-plug-in/HID_Architecture_Overview_Alt_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0075-HID-support-plug-in/HID_Architecture_Overview_Alt_2.png -------------------------------------------------------------------------------- /assets/proposals/0080-Support-for-MultiSession-protocol-string/MultiSession-iOS_Proxy_Flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0080-Support-for-MultiSession-protocol-string/MultiSession-iOS_Proxy_Flow.png -------------------------------------------------------------------------------- /assets/proposals/0084-Progress-Bar-Seek-Feature/Current.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0084-Progress-Bar-Seek-Feature/Current.png -------------------------------------------------------------------------------- /assets/proposals/0084-Progress-Bar-Seek-Feature/Proposed.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0084-Progress-Bar-Seek-Feature/Proposed.png -------------------------------------------------------------------------------- /assets/proposals/0092-deprecated-interfaces-markup/deprecated_doxygen_example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0092-deprecated-interfaces-markup/deprecated_doxygen_example.png -------------------------------------------------------------------------------- /assets/proposals/0095-AOA-multiplexing/0095-AOA-multiplexing_overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0095-AOA-multiplexing/0095-AOA-multiplexing_overview.png -------------------------------------------------------------------------------- /assets/proposals/0095-AOA-multiplexing/0095-aoa-multiplexing-class-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0095-AOA-multiplexing/0095-aoa-multiplexing-class-diagram.png -------------------------------------------------------------------------------- /assets/proposals/0095-AOA-multiplexing/0095-aoa-possible-permanent-routerservice-solution.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0095-AOA-multiplexing/0095-aoa-possible-permanent-routerservice-solution.png -------------------------------------------------------------------------------- /assets/proposals/0095-AOA-multiplexing/0095-multiplex_for_multiple_transports.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0095-AOA-multiplexing/0095-multiplex_for_multiple_transports.png -------------------------------------------------------------------------------- /assets/proposals/0122-new_rules_for_providing_vr_help_items_vr_help_title/0122-New_rules_for_providing_VRHelpItems_VRHelpTitl.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0122-new_rules_for_providing_vr_help_items_vr_help_title/0122-New_rules_for_providing_VRHelpItems_VRHelpTitl.png -------------------------------------------------------------------------------- /assets/proposals/0123-SendURI/FacebookArticleShare2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0123-SendURI/FacebookArticleShare2.jpg -------------------------------------------------------------------------------- /assets/proposals/0123-SendURI/TwitterArticleShare2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0123-SendURI/TwitterArticleShare2.jpg -------------------------------------------------------------------------------- /assets/proposals/0126-ATF-Additional-Transports/atf_transport_adapter.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0126-ATF-Additional-Transports/atf_transport_adapter.png -------------------------------------------------------------------------------- /assets/proposals/0127-Atf-Sdl-Watchdog-Service/sdl-watchdog.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0127-Atf-Sdl-Watchdog-Service/sdl-watchdog.png -------------------------------------------------------------------------------- /assets/proposals/0128-atf-script-runner/atf_script_runner_diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0128-atf-script-runner/atf_script_runner_diagram.png -------------------------------------------------------------------------------- /assets/proposals/0130-SendLocation-for-Mobile-Nav/SendLocationForMobileNav_RAI.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0130-SendLocation-for-Mobile-Nav/SendLocationForMobileNav_RAI.jpg -------------------------------------------------------------------------------- /assets/proposals/0130-SendLocation-for-Mobile-Nav/SendLocationForMobileNav_RequestResponse.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0130-SendLocation-for-Mobile-Nav/SendLocationForMobileNav_RequestResponse.jpg -------------------------------------------------------------------------------- /assets/proposals/0133-EnhancediOSProxyInterface.md/delegation_2x.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0133-EnhancediOSProxyInterface.md/delegation_2x.png -------------------------------------------------------------------------------- /assets/proposals/0133-EnhancediOSProxyInterface.md/f4kekYV.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0133-EnhancediOSProxyInterface.md/f4kekYV.jpg -------------------------------------------------------------------------------- /assets/proposals/0133-EnhancediOSProxyInterface.md/model_view_controller_2x.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0133-EnhancediOSProxyInterface.md/model_view_controller_2x.png -------------------------------------------------------------------------------- /assets/proposals/0136-rc-sdl-module/IMG_1125.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0136-rc-sdl-module/IMG_1125.jpg -------------------------------------------------------------------------------- /assets/proposals/0136-rc-sdl-module/SDL_App_RC.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0136-rc-sdl-module/SDL_App_RC.png -------------------------------------------------------------------------------- /assets/proposals/0136-rc-sdl-module/packet_structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0136-rc-sdl-module/packet_structure.png -------------------------------------------------------------------------------- /assets/proposals/0137-TouchCoord-outside-video-screen-range/0137-TouchCoord-outside-video-screen-range-pic1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0137-TouchCoord-outside-video-screen-range/0137-TouchCoord-outside-video-screen-range-pic1.png -------------------------------------------------------------------------------- /assets/proposals/0137-TouchCoord-outside-video-screen-range/0137-TouchCoord-outside-video-screen-range-pic2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0137-TouchCoord-outside-video-screen-range/0137-TouchCoord-outside-video-screen-range-pic2.png -------------------------------------------------------------------------------- /assets/proposals/0147-template-color-scheme/accuweather-day.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0147-template-color-scheme/accuweather-day.png -------------------------------------------------------------------------------- /assets/proposals/0147-template-color-scheme/accuweather-night.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0147-template-color-scheme/accuweather-night.png -------------------------------------------------------------------------------- /assets/proposals/0147-template-color-scheme/iHeart-day.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0147-template-color-scheme/iHeart-day.png -------------------------------------------------------------------------------- /assets/proposals/0147-template-color-scheme/iHeart-night.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0147-template-color-scheme/iHeart-night.png -------------------------------------------------------------------------------- /assets/proposals/0147-template-color-scheme/pandora-day.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0147-template-color-scheme/pandora-day.png -------------------------------------------------------------------------------- /assets/proposals/0147-template-color-scheme/pandora-night.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0147-template-color-scheme/pandora-night.png -------------------------------------------------------------------------------- /assets/proposals/0156-high-level-interface-foundation/application-lifecycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0156-high-level-interface-foundation/application-lifecycle.png -------------------------------------------------------------------------------- /assets/proposals/0156-high-level-interface-foundation/view-controller-lifecycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0156-high-level-interface-foundation/view-controller-lifecycle.png -------------------------------------------------------------------------------- /assets/proposals/0156-high-level-interface-foundation/view-controller-overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0156-high-level-interface-foundation/view-controller-overview.png -------------------------------------------------------------------------------- /assets/proposals/0158-cloud-app-transport-adapter/cloud_app_activation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0158-cloud-app-transport-adapter/cloud_app_activation.png -------------------------------------------------------------------------------- /assets/proposals/0158-cloud-app-transport-adapter/example_use_case_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0158-cloud-app-transport-adapter/example_use_case_1.png -------------------------------------------------------------------------------- /assets/proposals/0158-cloud-app-transport-adapter/example_use_case_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0158-cloud-app-transport-adapter/example_use_case_2.png -------------------------------------------------------------------------------- /assets/proposals/0158-cloud-app-transport-adapter/example_use_case_3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0158-cloud-app-transport-adapter/example_use_case_3.png -------------------------------------------------------------------------------- /assets/proposals/0158-cloud-app-transport-adapter/example_use_case_4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0158-cloud-app-transport-adapter/example_use_case_4.png -------------------------------------------------------------------------------- /assets/proposals/0158-cloud-app-transport-adapter/set_cloud_app_properties.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0158-cloud-app-transport-adapter/set_cloud_app_properties.png -------------------------------------------------------------------------------- /assets/proposals/0167-app-services/consumer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0167-app-services/consumer.png -------------------------------------------------------------------------------- /assets/proposals/0167-app-services/file_transfer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0167-app-services/file_transfer.png -------------------------------------------------------------------------------- /assets/proposals/0167-app-services/provider.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0167-app-services/provider.png -------------------------------------------------------------------------------- /assets/proposals/0167-app-services/rpc_passthrough.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0167-app-services/rpc_passthrough.png -------------------------------------------------------------------------------- /assets/proposals/0168-rpc-design-refactoring/new_design.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0168-rpc-design-refactoring/new_design.png -------------------------------------------------------------------------------- /assets/proposals/0173-Read-Generic-Network-Signal-data/OEM Mapping table update flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0173-Read-Generic-Network-Signal-data/OEM Mapping table update flow.png -------------------------------------------------------------------------------- /assets/proposals/0173-Read-Generic-Network-Signal-data/SDL-HMI request response flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0173-Read-Generic-Network-Signal-data/SDL-HMI request response flow.png -------------------------------------------------------------------------------- /assets/proposals/0173-Read-Generic-Network-Signal-data/Schema_Version_Update_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0173-Read-Generic-Network-Signal-data/Schema_Version_Update_flow.png -------------------------------------------------------------------------------- /assets/proposals/0176-high-level-interface-views-and-controllers/view-controller-lifecycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0176-high-level-interface-views-and-controllers/view-controller-lifecycle.png -------------------------------------------------------------------------------- /assets/proposals/0178-getInteriorVehicleData/GetInteriorVehicleData_current.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0178-getInteriorVehicleData/GetInteriorVehicleData_current.png -------------------------------------------------------------------------------- /assets/proposals/0178-getInteriorVehicleData/GetInteriorVehicleData_new_subscribe.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0178-getInteriorVehicleData/GetInteriorVehicleData_new_subscribe.png -------------------------------------------------------------------------------- /assets/proposals/0190-resumption-data-error-handling/multiple_app_error_handling.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0190-resumption-data-error-handling/multiple_app_error_handling.png -------------------------------------------------------------------------------- /assets/proposals/0190-resumption-data-error-handling/multiple_app_error_handling_with_common_subscriptions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0190-resumption-data-error-handling/multiple_app_error_handling_with_common_subscriptions.png -------------------------------------------------------------------------------- /assets/proposals/0194-android-transport-overhaul/TransportOverhaul_bridge.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0194-android-transport-overhaul/TransportOverhaul_bridge.png -------------------------------------------------------------------------------- /assets/proposals/0194-android-transport-overhaul/TransportOverhaul_new.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0194-android-transport-overhaul/TransportOverhaul_new.png -------------------------------------------------------------------------------- /assets/proposals/0194-android-transport-overhaul/TransportOverhaul_old.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0194-android-transport-overhaul/TransportOverhaul_old.png -------------------------------------------------------------------------------- /assets/proposals/0203-cloud_client_library_phase_1/cloud_arch_0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0203-cloud_client_library_phase_1/cloud_arch_0.png -------------------------------------------------------------------------------- /assets/proposals/0203-cloud_client_library_phase_1/cloud_arch_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0203-cloud_client_library_phase_1/cloud_arch_1.png -------------------------------------------------------------------------------- /assets/proposals/0203-cloud_client_library_phase_1/cloud_arch_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0203-cloud_client_library_phase_1/cloud_arch_2.png -------------------------------------------------------------------------------- /assets/proposals/0203-cloud_client_library_phase_1/java_sets.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0203-cloud_client_library_phase_1/java_sets.png -------------------------------------------------------------------------------- /assets/proposals/0203-cloud_client_library_phase_1/project_hierarchy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0203-cloud_client_library_phase_1/project_hierarchy.png -------------------------------------------------------------------------------- /assets/proposals/0206-remote_atf_testing/ATFRemoteAdapter.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0206-remote_atf_testing/ATFRemoteAdapter.png -------------------------------------------------------------------------------- /assets/proposals/0211-ServiceStatusUpdateToHMI/Invalid-Cert.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0211-ServiceStatusUpdateToHMI/Invalid-Cert.png -------------------------------------------------------------------------------- /assets/proposals/0211-ServiceStatusUpdateToHMI/PTU-Time-Out.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0211-ServiceStatusUpdateToHMI/PTU-Time-Out.png -------------------------------------------------------------------------------- /assets/proposals/0211-ServiceStatusUpdateToHMI/invalid-system-time.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0211-ServiceStatusUpdateToHMI/invalid-system-time.png -------------------------------------------------------------------------------- /assets/proposals/0211-ServiceStatusUpdateToHMI/sunny-day-scenario.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0211-ServiceStatusUpdateToHMI/sunny-day-scenario.png -------------------------------------------------------------------------------- /assets/proposals/0216-widget-support/example-home.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0216-widget-support/example-home.jpg -------------------------------------------------------------------------------- /assets/proposals/0216-widget-support/hmi-chart.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0216-widget-support/hmi-chart.png -------------------------------------------------------------------------------- /assets/proposals/0216-widget-support/rse.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0216-widget-support/rse.jpg -------------------------------------------------------------------------------- /assets/proposals/0216-widget-support/screen.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0216-widget-support/screen.png -------------------------------------------------------------------------------- /assets/proposals/0216-widget-support/template-graphic-with-text.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0216-widget-support/template-graphic-with-text.png -------------------------------------------------------------------------------- /assets/proposals/0216-widget-support/template-text-with-graphic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0216-widget-support/template-text-with-graphic.png -------------------------------------------------------------------------------- /assets/proposals/0216-widget-support/template-tiles-with-graphic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0216-widget-support/template-tiles-with-graphic.png -------------------------------------------------------------------------------- /assets/proposals/0218-developer-oem-communication/app-chat-dev.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0218-developer-oem-communication/app-chat-dev.jpg -------------------------------------------------------------------------------- /assets/proposals/0218-developer-oem-communication/app-chat-oem.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0218-developer-oem-communication/app-chat-oem.jpg -------------------------------------------------------------------------------- /assets/proposals/0218-developer-oem-communication/catalog-of-apps.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0218-developer-oem-communication/catalog-of-apps.jpg -------------------------------------------------------------------------------- /assets/proposals/0218-developer-oem-communication/catalog-of-oems.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0218-developer-oem-communication/catalog-of-oems.jpg -------------------------------------------------------------------------------- /assets/proposals/0218-developer-oem-communication/email-new-issue.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0218-developer-oem-communication/email-new-issue.png -------------------------------------------------------------------------------- /assets/proposals/0218-developer-oem-communication/email-new-message.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0218-developer-oem-communication/email-new-message.png -------------------------------------------------------------------------------- /assets/proposals/0218-developer-oem-communication/issue-create-oem.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0218-developer-oem-communication/issue-create-oem.jpg -------------------------------------------------------------------------------- /assets/proposals/0218-developer-oem-communication/issue-list-dev.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0218-developer-oem-communication/issue-list-dev.jpg -------------------------------------------------------------------------------- /assets/proposals/0218-developer-oem-communication/issue-list-oem.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0218-developer-oem-communication/issue-list-oem.jpg -------------------------------------------------------------------------------- /assets/proposals/0218-developer-oem-communication/issue-view-dev.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0218-developer-oem-communication/issue-view-dev.jpg -------------------------------------------------------------------------------- /assets/proposals/0218-developer-oem-communication/issue-view-oem.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0218-developer-oem-communication/issue-view-oem.jpg -------------------------------------------------------------------------------- /assets/proposals/0221-multiple-modules/2x3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0221-multiple-modules/2x3.jpg -------------------------------------------------------------------------------- /assets/proposals/0221-multiple-modules/3x3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0221-multiple-modules/3x3.jpg -------------------------------------------------------------------------------- /assets/proposals/0221-multiple-modules/4x4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0221-multiple-modules/4x4.jpg -------------------------------------------------------------------------------- /assets/proposals/0228-sdl-server-email-notifications/email-preview.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0228-sdl-server-email-notifications/email-preview.jpg -------------------------------------------------------------------------------- /assets/proposals/0228-sdl-server-email-notifications/visual-config-preview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0228-sdl-server-email-notifications/visual-config-preview.png -------------------------------------------------------------------------------- /assets/proposals/0230-spp-resource-management-for-android/manage_notification_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0230-spp-resource-management-for-android/manage_notification_1.png -------------------------------------------------------------------------------- /assets/proposals/0230-spp-resource-management-for-android/manage_notification_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0230-spp-resource-management-for-android/manage_notification_2.png -------------------------------------------------------------------------------- /assets/proposals/0230-spp-resource-management-for-android/spp_notification_popup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0230-spp-resource-management-for-android/spp_notification_popup.png -------------------------------------------------------------------------------- /assets/proposals/0238-keyboard-enhancements/azerty_special_chars.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0238-keyboard-enhancements/azerty_special_chars.png -------------------------------------------------------------------------------- /assets/proposals/0238-keyboard-enhancements/numeric_keypad.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0238-keyboard-enhancements/numeric_keypad.png -------------------------------------------------------------------------------- /assets/proposals/0238-keyboard-enhancements/qwerty_special_chars.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0238-keyboard-enhancements/qwerty_special_chars.png -------------------------------------------------------------------------------- /assets/proposals/0240-sdl-js-pwa/activate-web-app.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0240-sdl-js-pwa/activate-web-app.png -------------------------------------------------------------------------------- /assets/proposals/0240-sdl-js-pwa/arch-overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0240-sdl-js-pwa/arch-overview.png -------------------------------------------------------------------------------- /assets/proposals/0242-alert-style-subtle/subtle-alert-mockup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0242-alert-style-subtle/subtle-alert-mockup.png -------------------------------------------------------------------------------- /assets/proposals/0245-sharing-wifi-ssid-and-password/WiFi_AP_created_manually_Disconnected.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0245-sharing-wifi-ssid-and-password/WiFi_AP_created_manually_Disconnected.png -------------------------------------------------------------------------------- /assets/proposals/0245-sharing-wifi-ssid-and-password/andoid_permissions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0245-sharing-wifi-ssid-and-password/andoid_permissions.png -------------------------------------------------------------------------------- /assets/proposals/0245-sharing-wifi-ssid-and-password/minimal_approach.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0245-sharing-wifi-ssid-and-password/minimal_approach.png -------------------------------------------------------------------------------- /assets/proposals/0245-sharing-wifi-ssid-and-password/minimal_approach.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | !pragma teoz true 3 | title Sharing ssid minimal approach 4 | participant HMI 5 | participant SDL 6 | 7 | box "Device" 8 | participant APP1 9 | participant APP2 10 | end box 11 | 12 | box "Device2" 13 | participant APP3 14 | endbox 15 | 16 | note over HMI, APP2: Policy restrictions, encryption_required": true, 17 | APP1 -> SDL : RAI_1(NetworkingCapabilities) 18 | SDL -> HMI : OnAppRegistered(App1, NetworkingCapabilities) 19 | SDL -> APP1 : RAI(App2) response 20 | APP2 -> SDL : RAI_2(NetworkingCapabilities) 21 | SDL -> HMI : OnAppRegistered(App2, NetworkingCapabilities) 22 | SDL -> APP2 : RAI(App2) response 23 | APP3 -> SDL : RAI_3(NetworkingCapabilities) 24 | SDL -> HMI : OnAppRegistered(App3, NetworkingCapabilities) 25 | SDL -> APP3 : RAI(App3) response 26 | note over HMI : HMI compares own capabilities,\n\ 27 | WiFi adapter status, and check if MOBILE or HMI should be AP 28 | APP2 -> SDL : Init Secure RPC service 29 | SDL -> HMI : ServiceStatusUppate(app2, rpc, encrypted=true) 30 | APP3 -> SDL : Init Secure RPC service 31 | APP3 -> SDL : Init Secure RPC service 32 | SDL -> HMI : ServiceStatusUppate(app3, rpc, encrypted=true) 33 | 34 | alt HMI is an access point 35 | 36 | alt Vehicle should be an access point 37 | HMI -> SDL : JoinVehicleNetwork (app2) 38 | SDL -> APP2 : JoinVehicleNetwork (app2) 39 | APP2 -> APP2 : Establish \n\ 40 | WiFiConnection 41 | APP2 -> SDL : JoinVehicleNetwork response 42 | SDL -> HMI : JoinVehicleNetwork response 43 | HMI -> SDL : JoinVehicleNetwork (app3) 44 | SDL -> APP3 : JoinVehicleNetwork (app3) 45 | APP3 -> APP3 : Establish \n\ 46 | WiFiConnectionAPP3 -> SDL : JoinVehicleNetwork response 47 | end 48 | 49 | alt Mobile is an access point 50 | note right HMI : HMI sends OnSystemRequst to the first APP1 51 | HMI -> SDL : OnSystemRequst (APP1) (WIFI_READY_TO_CONNECT) 52 | SDL -> APP1 : OnSystemRequst (WIFI_READY_TO_CONNECT) 53 | APP1 -> SDL : JoinMobileNetwork (app1) 54 | SDL -> HMI : JoinMobileNetwork (app1) 55 | HMI -> SDL : JoinMobileNetwork response 56 | SDL -> APP1 : JoinMobileNetwork response 57 | note right HMI : HMI shares credentials of the APP1 58 | HMI -> SDL : JoinVehicleNetwork (app3) 59 | SDL -> APP3 : JoinVehicleNetwork (app3) 60 | APP3 -> SDL : JoinVehicleNetwork response 61 | SDL -> HMI : JoinVehicleNetwork response 62 | end 63 | @enduml 64 | -------------------------------------------------------------------------------- /assets/proposals/0245-sharing-wifi-ssid-and-password/mobile_access_point.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0245-sharing-wifi-ssid-and-password/mobile_access_point.png -------------------------------------------------------------------------------- /assets/proposals/0245-sharing-wifi-ssid-and-password/mobile_access_point.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | !pragma teoz true 3 | 4 | title SDL decides that MOBILE is an access point 5 | participant HMI 6 | participant SDL 7 | participant APP 8 | 9 | note over HMI, APP: in ini file : NetworkHost = MOBILE \n\ 10 | App allowed to use feature by policies 11 | 12 | SDL -> HMI : UI.GetCapabilities() request 13 | HMI -> SDL : UI.GetCapabilities(NetworkingCapabilities) response : \n\ 14 | \t autoJoinWiFiSupported : \t true \n\ 15 | \t canHostWiFiNetwork : \t true \n\ 16 | \t preferredNetworkHost : \t **MOBILE** \n\ 17 | \t wifiFrequencyBandsSupported : \t "FREQUENCY_BAND_2_4_GHZ" 18 | 19 | APP -> SDL : RAI(NetworkCapabilities): \n\ 20 | \t autoJoinWiFiSupported : \t true \n\ 21 | \t canHostWiFiNetwork : \t true \n\ 22 | \t preferredNetworkHost : \t **MOBILE** \n\ 23 | \t wifiFrequencyBandsSupported : \t "FREQUENCY_BAND_2_4_GHZ" 24 | 25 | SDL -> HMI : OnAppRegistered 26 | SDL -> APP : RAI response 27 | 28 | SDL -> SDL : Based on ini file, RAI and HMI NetworkCapabilities\n\ 29 | SDL decides that **Mobile should be AP** 30 | 31 | SDL -> APP: OnSystemCapabilityUpdated(NetworkCapabilities): \n\ 32 | \t preferredNetworkHost : \t **MOBILE** \n\ 33 | \t wifiFrequencyBandsSupported : \t "FREQUENCY_BAND_2_4_GHZ" 34 | 35 | APP -> APP : Mobile creates \n\ 36 | WiFi Access Point 37 | 38 | APP -> SDL: JoinNetwork request\n\ 39 | \t ssid : \t DeviceWiFiAP \n\ 40 | \t password : \t 12345678 \n\ 41 | \t securityType : \t WIFI_SECURITY_WPA2 \n\ 42 | \t allowAccessPointToBeShared : \t **false** \n\ 43 | \t accessPointSupportsInternetAccess : \t true 44 | 45 | SDL -> HMI: JoinNetwork request\n\ 46 | \t ssid : \t DeviceWiFiAP \n\ 47 | \t password : \t 12345678 \n\ 48 | \t securityType : \t WIFI_SECURITY_WPA2 \n\ 49 | \t allowAccessPointToBeShared : \t **false** \n\ 50 | \t accessPointSupportsInternetAccess : \t true 51 | 52 | HMI -> HMI : Establish \n\ 53 | WiFiConnection 54 | 55 | HMI -> SDL : JoinNetwork response 56 | SDL -> APP : JoinNetwork response 57 | 58 | SDL -> APP: TransportUpdateEvent 59 | 60 | HMI -> SDL: OnSystemCapabilityUpdate(NetworkCapabilities): \n\ 61 | \t autoJoinWiFiSupported : \t **false** \n\ 62 | \t canHostWiFiNetwork : \t **false** \n\ 63 | 64 | @enduml 65 | -------------------------------------------------------------------------------- /assets/proposals/0245-sharing-wifi-ssid-and-password/mobile_access_point_multidev_externalhost.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0245-sharing-wifi-ssid-and-password/mobile_access_point_multidev_externalhost.png -------------------------------------------------------------------------------- /assets/proposals/0245-sharing-wifi-ssid-and-password/secure_service.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0245-sharing-wifi-ssid-and-password/secure_service.png -------------------------------------------------------------------------------- /assets/proposals/0245-sharing-wifi-ssid-and-password/secure_service.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | !pragma teoz true 3 | 4 | title Secure service 5 | 6 | participant HMI 7 | participant SDL 8 | participant APP 9 | 10 | note over HMI, APP: APP allowed to use feature by policies 11 | 12 | HMI -> SDL : OnSystemCapabilityUpdated : \n\ 13 | \t autoJoinWiFiSupported : \t true \n\ 14 | \t canHostWiFiNetwork : \t true \n\ 15 | \t preferredNetworkHost : \t MOBILE \n\ 16 | \t securityType : \t WIFI_SECURITY_WPA2 \n\ 17 | 18 | APP -> SDL : RAI(NetworkCapabilities): \n\ 19 | \t autoJoinWiFiSupported : \t true \n\ 20 | \t canHostWiFiNetwork : \t true \n\ 21 | \t preferredNetworkHost : \t MOBILE \n\ 22 | \t allowAccessPointToBeShared : \t true 23 | 24 | SDL -> HMI : OnAppRegistered (app1) 25 | SDL -> APP : RAI response 26 | 27 | SDL -> SDL : Based on ini file, RAI and HMI NetworkCapabilities\n\ 28 | SDL decides that **MOBILE should be AP** 29 | 30 | SDL -> APP: OnPermissionsChange("JoinNetwork, OnSystemCapabilityUpdated") 31 | 32 | SDL -> APP: \n OnSystemCapabilityUpdated : \n\ 33 | \t preferredNetworkHost : \t MOBILE \n\ 34 | 35 | APP -> SDL : Start **secure** RPC service 36 | 37 | 38 | APP -> SDL : JoinNetwork request 39 | SDL -> HMI : JoinNetwork requset 40 | HMI -> HMI : Establish WifiConnection 41 | HMI -> SDL : JoinNetwork response 42 | SDL -> APP : JoinNetwork response 43 | 44 | 45 | @enduml 46 | -------------------------------------------------------------------------------- /assets/proposals/0245-sharing-wifi-ssid-and-password/vehicle_access_point.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0245-sharing-wifi-ssid-and-password/vehicle_access_point.png -------------------------------------------------------------------------------- /assets/proposals/0245-sharing-wifi-ssid-and-password/vehicle_access_point.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | !pragma teoz true 3 | 4 | 5 | title SDL decides that VEHICLE is an access point 6 | 7 | participant HMI 8 | participant SDL 9 | participant APP 10 | 11 | note over HMI, APP: in ini file : NetworkHost = VEHICLE \n\ 12 | App allowed to use feature by policies 13 | 14 | SDL -> HMI : UI.GetCapabilities() request 15 | HMI -> SDL : UI.GetCapabilities(NetworkingCapabilities) response : \n\ 16 | \t autoJoinWiFiSupported : \t true \n\ 17 | \t canHostWiFiNetwork : \t true \n\ 18 | \t preferredNetworkHost : \t **VEHICLE** \n\ 19 | \t networkingCapabilities : "initial HMI networkingCapabilities" 20 | 21 | APP -> SDL : RAI(NetworkingCapabilities): \n\ 22 | \t autoJoinWiFiSupported : \t true \n\ 23 | \t canHostWiFiNetwork : \t true \n\ 24 | \t preferredNetworkHost : \t **VEHICLE** \n\ 25 | \t networkingCapabilities : "mobile networkingCapabilities" 26 | 27 | SDL -> HMI : OnAppRegistered 28 | 29 | SDL -> SDL : Based on ini file, RAI and HMI NetworkCapabilities\n\ 30 | SDL decides that **VEHICLE should be AP** 31 | 32 | SDL -> HMI: OnSystemCapabilityUpdated(NetworkCapabilities): \n\ 33 | \t preferredNetworkHost : \t **VEHICLE** \n\ 34 | \t networkingCapabilities: "networkingCapabilities received from APP" 35 | HMI -> HMI : HMI creates WiFi Access Point 36 | 37 | HMI -> SDL: OnSystemCapabilityUpdate(NetworkCapabilities): \n\ 38 | \t autoJoinWiFiSupported : \t **false** \n\ 39 | \t canHostWiFiNetwork : \t true \n\ 40 | \t preferredNetworkHost : \t **VEHICLE** \n\ 41 | \t networkingCapabilities : "updated networkingCapabilities" 42 | 43 | note over HMI: HMI shows pop-up \n\ 44 | user consent 45 | 46 | HMI -> SDL: JoinNetwork request\n\ 47 | \t ssid : \t InCarWiFiAP \n\ 48 | \t password : \t 12345678 \n\ 49 | \t securityType : \t WIFI_SECURITY_WPA2 \n\ 50 | \t accessPointSupportsInternetAccess : \t true 51 | 52 | SDL -> APP: JoinNetwork request\n\ 53 | \t ssid : \t InCarWiFiAP \n\ 54 | \t password : \t 12345678 \n\ 55 | \t securityType : \t WIFI_SECURITY_WPA2 \n\ 56 | \t accessPointSupportsInternetAccess : \t true 57 | 58 | note over APP: APP shows pop-up \n\ 59 | user consent 60 | 61 | APP -> APP : Establish \n\ 62 | WiFiConnection 63 | 64 | APP -> SDL : JoinNetwork response 65 | SDL -> HMI : JoinNetwork response 66 | 67 | SDL -> APP: TransportUpdateEvent 68 | @enduml 69 | -------------------------------------------------------------------------------- /assets/proposals/0245-sharing-wifi-ssid-and-password/vehicle_access_point_multiapps.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0245-sharing-wifi-ssid-and-password/vehicle_access_point_multiapps.png -------------------------------------------------------------------------------- /assets/proposals/0245-sharing-wifi-ssid-and-password/vehicle_access_point_multidev.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0245-sharing-wifi-ssid-and-password/vehicle_access_point_multidev.png -------------------------------------------------------------------------------- /assets/proposals/0248-hmi-ptu-support/diagram_ptu_external_proprietary.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0248-hmi-ptu-support/diagram_ptu_external_proprietary.png -------------------------------------------------------------------------------- /assets/proposals/0248-hmi-ptu-support/diagram_ptu_external_proprietary_enhanced.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0248-hmi-ptu-support/diagram_ptu_external_proprietary_enhanced.png -------------------------------------------------------------------------------- /assets/proposals/0248-hmi-ptu-support/diagram_ptu_external_proprietary_enhanced_fallback.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0248-hmi-ptu-support/diagram_ptu_external_proprietary_enhanced_fallback.png -------------------------------------------------------------------------------- /assets/proposals/0249-Persisting-HMI-Capabilities-specific-to-headunit/hmi_capabilities_caching_sw_different_happypath.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0249-Persisting-HMI-Capabilities-specific-to-headunit/hmi_capabilities_caching_sw_different_happypath.png -------------------------------------------------------------------------------- /assets/proposals/0249-Persisting-HMI-Capabilities-specific-to-headunit/hmi_capabilities_caching_sw_different_requestTimeout.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0249-Persisting-HMI-Capabilities-specific-to-headunit/hmi_capabilities_caching_sw_different_requestTimeout.png -------------------------------------------------------------------------------- /assets/proposals/0249-Persisting-HMI-Capabilities-specific-to-headunit/hmi_capabilities_caching_sw_same.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0249-Persisting-HMI-Capabilities-specific-to-headunit/hmi_capabilities_caching_sw_same.png -------------------------------------------------------------------------------- /assets/proposals/0250-NextRpcIndication/0250-NextRpcIndication.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0250-NextRpcIndication/0250-NextRpcIndication.png -------------------------------------------------------------------------------- /assets/proposals/0250-NextRpcIndication/0250-NextRpcIndicationv2-2.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0250-NextRpcIndication/0250-NextRpcIndicationv2-2.PNG -------------------------------------------------------------------------------- /assets/proposals/0250-NextRpcIndication/0250-NextRpcIndicationv2.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0250-NextRpcIndication/0250-NextRpcIndicationv2.PNG -------------------------------------------------------------------------------- /assets/proposals/0251-font-styles/0251-font-styles.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0251-font-styles/0251-font-styles.png -------------------------------------------------------------------------------- /assets/proposals/0259-Disabled-Softbuttons/iheartRadio1.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0259-Disabled-Softbuttons/iheartRadio1.PNG -------------------------------------------------------------------------------- /assets/proposals/0259-Disabled-Softbuttons/iheartRadio2.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0259-Disabled-Softbuttons/iheartRadio2.PNG -------------------------------------------------------------------------------- /assets/proposals/0264-Separating-the-change-of-Audible-status-and-the-change-of-HMI-Status/PHONE_CALL1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0264-Separating-the-change-of-Audible-status-and-the-change-of-HMI-Status/PHONE_CALL1.png -------------------------------------------------------------------------------- /assets/proposals/0264-Separating-the-change-of-Audible-status-and-the-change-of-HMI-Status/PHONE_CALL2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0264-Separating-the-change-of-Audible-status-and-the-change-of-HMI-Status/PHONE_CALL2.png -------------------------------------------------------------------------------- /assets/proposals/0264-Separating-the-change-of-Audible-status-and-the-change-of-HMI-Status/index.md: -------------------------------------------------------------------------------- 1 | ## OnEventChanged 2 | 3 | ##### PHONE_CALL 4 | 5 | !!! MUST 6 | 1. Change audioStreamingState to NOT_AUDIBLE for all apps (keep hmiLevel) when active call on HMI has been started. 7 | 8 | 2. Send notification with appropriate parameter value when the event ends. 9 | !!! 10 | 11 | !!! NOTE 12 | - SDL does not send BC.ActivateApp or BC.OnResumeAudioSource to HMI after the phone call is ended. 13 | 14 | - If HU wants to switch the screen (HMIStatus) during PHONE_CALL, they can use API `BC.OnAppDeactivated (AppID)` and `BC.OnAppActivated (AppID)`. 15 | !!! 16 | 17 | Upon receiving `OnEventChanged(PHONE_CALL)`, SDL will: 18 | 19 | |isActive|Result| 20 | |:-------|:-----| 21 | |true|Keep the HMI state of all applications but change audible state of all applications to NOT_AUDIBLE| 22 | |false|Return applications to the same HMI state they had prior to the event| 23 | -------------------------------------------------------------------------------- /assets/proposals/0273-webengine-projection-mode/web-app-example_with_exit_button_and_template_title.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0273-webengine-projection-mode/web-app-example_with_exit_button_and_template_title.jpg -------------------------------------------------------------------------------- /assets/proposals/0273-webengine-projection-mode/web-app-example_with_outside_menu_and_template_title.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0273-webengine-projection-mode/web-app-example_with_outside_menu_and_template_title.jpg -------------------------------------------------------------------------------- /assets/proposals/0277-Continuous-Integration-And-Testing/ClusterSchema.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0277-Continuous-Integration-And-Testing/ClusterSchema.png -------------------------------------------------------------------------------- /assets/proposals/0280-Adding-new-parameter-of-requiresAudioSupport-and-BluetoothDeviceAddress/registeringApp_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0280-Adding-new-parameter-of-requiresAudioSupport-and-BluetoothDeviceAddress/registeringApp_flow.png -------------------------------------------------------------------------------- /assets/proposals/0280-Adding-new-parameter-of-requiresAudioSupport-and-BluetoothDeviceAddress/registeringApp_flow2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0280-Adding-new-parameter-of-requiresAudioSupport-and-BluetoothDeviceAddress/registeringApp_flow2.png -------------------------------------------------------------------------------- /assets/proposals/0284-DialNumber_Text/Current Dial Number.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0284-DialNumber_Text/Current Dial Number.png -------------------------------------------------------------------------------- /assets/proposals/0284-DialNumber_Text/Future Dial Number.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0284-DialNumber_Text/Future Dial Number.png -------------------------------------------------------------------------------- /assets/proposals/0291-allows-navigation-apps-to-access-information-about-Wi-Fi-networks/sequence_diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0291-allows-navigation-apps-to-access-information-about-Wi-Fi-networks/sequence_diagram.png -------------------------------------------------------------------------------- /assets/proposals/0292-improve-VDE-for-stable-frame-rate/vd_mc_unstable.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0292-improve-VDE-for-stable-frame-rate/vd_mc_unstable.png -------------------------------------------------------------------------------- /assets/proposals/0292-improve-VDE-for-stable-frame-rate/vd_w_intermediate_surface.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0292-improve-VDE-for-stable-frame-rate/vd_w_intermediate_surface.png -------------------------------------------------------------------------------- /assets/proposals/0293-vehicle-type-filter/OEM_APPS_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0293-vehicle-type-filter/OEM_APPS_1.png -------------------------------------------------------------------------------- /assets/proposals/0293-vehicle-type-filter/OEM_APPS_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0293-vehicle-type-filter/OEM_APPS_2.png -------------------------------------------------------------------------------- /assets/proposals/0293-vehicle-type-filter/OEM_APPS_3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0293-vehicle-type-filter/OEM_APPS_3.png -------------------------------------------------------------------------------- /assets/proposals/0293-vehicle-type-filter/OEM_APPS_4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0293-vehicle-type-filter/OEM_APPS_4.png -------------------------------------------------------------------------------- /assets/proposals/0293-vehicle-type-filter/one_noti.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0293-vehicle-type-filter/one_noti.png -------------------------------------------------------------------------------- /assets/proposals/0293-vehicle-type-filter/sequence_diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0293-vehicle-type-filter/sequence_diagram.png -------------------------------------------------------------------------------- /assets/proposals/0293-vehicle-type-filter/two_noti.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0293-vehicle-type-filter/two_noti.png -------------------------------------------------------------------------------- /assets/proposals/0297-Add-function-to-transmit-audio-data/Image.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0297-Add-function-to-transmit-audio-data/Image.gif -------------------------------------------------------------------------------- /assets/proposals/0301-SDL-device-listener/flow_chart.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0301-SDL-device-listener/flow_chart.png -------------------------------------------------------------------------------- /assets/proposals/0302-SDL-System-Structure-for-MiddleLow-end-Class-Model-of-Powered-Two-Wheeler/Figure1_Sample_of_a_simple_meter_display.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0302-SDL-System-Structure-for-MiddleLow-end-Class-Model-of-Powered-Two-Wheeler/Figure1_Sample_of_a_simple_meter_display.png -------------------------------------------------------------------------------- /assets/proposals/0302-SDL-System-Structure-for-MiddleLow-end-Class-Model-of-Powered-Two-Wheeler/Figure2_SDL_System_for_Middle_Low_end_class.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0302-SDL-System-Structure-for-MiddleLow-end-Class-Model-of-Powered-Two-Wheeler/Figure2_SDL_System_for_Middle_Low_end_class.png -------------------------------------------------------------------------------- /assets/proposals/0302-SDL-System-Structure-for-MiddleLow-end-Class-Model-of-Powered-Two-Wheeler/Figure3_System_structure_of_proxy_and_meter_unit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0302-SDL-System-Structure-for-MiddleLow-end-Class-Model-of-Powered-Two-Wheeler/Figure3_System_structure_of_proxy_and_meter_unit.png -------------------------------------------------------------------------------- /assets/proposals/0303-audio-io-manager/SDLAudioIOManager.h: -------------------------------------------------------------------------------- 1 | #import 2 | 3 | @class SDLManager; 4 | @class SDLTTSChunk; 5 | @protocol SDLAudioIOManagerDelegate; 6 | 7 | NS_ASSUME_NONNULL_BEGIN 8 | 9 | extern NSString *const SDLErrorDomainAudioIOManager; 10 | 11 | @interface SDLAudioIOManager : NSObject 12 | 13 | @property (weak, nonatomic) id delegate; 14 | 15 | @property (assign, nonatomic, readonly) BOOL isOutputStreamPlaying; 16 | @property (assign, nonatomic, readonly) BOOL isInputStreamPlaying; 17 | 18 | @property (strong, nonatomic, readwrite) SDLTTSChunk *inputStreamPrompt; 19 | @property (strong, nonatomic, readwrite) NSString *inputStreamText; 20 | 21 | /** 22 | * Creates an instance of the SDLAudioIOManager. 23 | */ 24 | - (instancetype)initWithManager:(nonnull SDLManager *)sdlManager delegate:(id)delegate; 25 | 26 | /** 27 | * Starts writing the audio data of the specified audio file. 28 | * Audio output as priority to audio input. When writing audio to the output stream while input stream is playing 29 | * the input stream will be paused during the output stream playback. 30 | */ 31 | - (void)writeOutputStreamWithFileURL:(NSURL *)fileURL; 32 | 33 | /** 34 | * Starts an input stream using the vehicle microphone and sends the audio data to the specified delegate. 35 | * Audio output as priority to audio input. When starting input stream while output stream is playing 36 | * the input stream will be paused during the output stream playback. 37 | */ 38 | - (void)startInputStream; 39 | 40 | /** 41 | * Stops the input stream. 42 | */ 43 | - (void)stopInputStream; 44 | 45 | @end 46 | 47 | NS_ASSUME_NONNULL_END 48 | -------------------------------------------------------------------------------- /assets/proposals/0303-audio-io-manager/SDLAudioIOManagerDelegate.h: -------------------------------------------------------------------------------- 1 | #import 2 | #import 3 | 4 | @class SDLAudioIOManager; 5 | @class SDLAudioPassThruCapabilities; 6 | 7 | NS_ASSUME_NONNULL_BEGIN 8 | 9 | @protocol SDLAudioIOManagerDelegate 10 | 11 | @optional 12 | 13 | #pragma mark - Ouput stream delegate methods 14 | 15 | /** 16 | * Informs the delegate that the manager is starting to play audio files on the output stream. 17 | */ 18 | - (void)audioManagerDidStartOutputStream:(SDLAudioIOManager *)audioManager; 19 | 20 | /** 21 | * Informs the delegate that the manager finished playing all audio files and stopped the output stream. 22 | */ 23 | - (void)audioManagerDidStopOutputStream:(SDLAudioIOManager *)audioManager; 24 | 25 | /** 26 | * Informs the delegate that the manager finished playing the specified audio file on the output stream. 27 | */ 28 | - (void)audioManager:(SDLAudioIOManager *)audioManager didFinishPlayingURL:(NSURL *)url; 29 | 30 | /** 31 | * Informs the delegate that the manager failed to play the specified audio file on the output stream. 32 | */ 33 | - (void)audioManager:(SDLAudioIOManager *)audioManager errorDidOccurForURL:(NSURL *)url error:(NSError *)error; 34 | 35 | #pragma mark - Input stream delegate methods 36 | 37 | /** 38 | * Informs the delegate that the manager did start the input stream with the specified audio options including: 39 | * - audio format (e.g. PCM) 40 | * - sampling rate (e.g. 22 khz) 41 | * - bits per sample (e.g. 16 bits) 42 | */ 43 | - (void)audioManager:(SDLAudioIOManager *)audioManager didStartInputStreamWithOptions:(SDLAudioPassThruCapabilities *)options; 44 | 45 | /** 46 | * Informs the delegate that the manager did receive an audio chunk from the input stream. 47 | */ 48 | - (void)audioManager:(SDLAudioIOManager *)audioManager didReceiveAudioData:(NSData *)audioData; 49 | 50 | /** 51 | * Informs the delegate that the manager did finish the input stream with the specified result code. 52 | * Possible result code are: 53 | * SUCCESS if the user or the app confirmed to end the audio input stream. 54 | * DISALLOWED if the application does not have permission to start the audio input stream. 55 | * REJECTED if the vehicle rejected to start the audio input stream due to other priority. 56 | * ABORTED if the user has chosen to abort the audio input requesting the app to discard any audio data recorded in this active session. 57 | * RETRY if the user requests the app to restart the audio input stream. 58 | */ 59 | - (void)audioManager:(SDLAudioIOManager *)audioManager didFinishInputStreamWithResult:(SDLResult)result; 60 | 61 | @end 62 | 63 | NS_ASSUME_NONNULL_END 64 | -------------------------------------------------------------------------------- /assets/proposals/0307-GetInput/GetInput Overview.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0307-GetInput/GetInput Overview.PNG -------------------------------------------------------------------------------- /assets/proposals/0307-GetInput/GetInput-1-1.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0307-GetInput/GetInput-1-1.PNG -------------------------------------------------------------------------------- /assets/proposals/0307-GetInput/GetInput-1-2.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0307-GetInput/GetInput-1-2.PNG -------------------------------------------------------------------------------- /assets/proposals/0307-GetInput/GetInput-1.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0307-GetInput/GetInput-1.PNG -------------------------------------------------------------------------------- /assets/proposals/0307-GetInput/GetInput-2.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0307-GetInput/GetInput-2.PNG -------------------------------------------------------------------------------- /assets/proposals/0307-GetInput/GetInput-3-1.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0307-GetInput/GetInput-3-1.PNG -------------------------------------------------------------------------------- /assets/proposals/0307-GetInput/GetInput-3-2.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0307-GetInput/GetInput-3-2.PNG -------------------------------------------------------------------------------- /assets/proposals/0307-GetInput/GetInput-3.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0307-GetInput/GetInput-3.PNG -------------------------------------------------------------------------------- /assets/proposals/0307-GetInput/GetInput-ErrorFlow.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0307-GetInput/GetInput-ErrorFlow.PNG -------------------------------------------------------------------------------- /assets/proposals/0309-android-notifications/all_noti.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0309-android-notifications/all_noti.png -------------------------------------------------------------------------------- /assets/proposals/0309-android-notifications/noti_button.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0309-android-notifications/noti_button.png -------------------------------------------------------------------------------- /assets/proposals/0309-android-notifications/noti_button_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0309-android-notifications/noti_button_1.png -------------------------------------------------------------------------------- /assets/proposals/0309-android-notifications/noti_button_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0309-android-notifications/noti_button_2.png -------------------------------------------------------------------------------- /assets/proposals/0309-android-notifications/review_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0309-android-notifications/review_1.png -------------------------------------------------------------------------------- /assets/proposals/0309-android-notifications/review_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0309-android-notifications/review_2.png -------------------------------------------------------------------------------- /assets/proposals/0309-android-notifications/review_3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0309-android-notifications/review_3.png -------------------------------------------------------------------------------- /assets/proposals/0309-android-notifications/sdl_faq.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0309-android-notifications/sdl_faq.png -------------------------------------------------------------------------------- /assets/proposals/0309-android-notifications/waiting_for_connection.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0309-android-notifications/waiting_for_connection.png -------------------------------------------------------------------------------- /assets/proposals/0310-PerformInteraction-Multipick/PerformInteraction Multipick overview.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0310-PerformInteraction-Multipick/PerformInteraction Multipick overview.PNG -------------------------------------------------------------------------------- /assets/proposals/0314-Clarification-of-SDL-App-Icon-display-sequence-and-display-order/Figure1_SDL_App_Icon_display_sequence.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0314-Clarification-of-SDL-App-Icon-display-sequence-and-display-order/Figure1_SDL_App_Icon_display_sequence.PNG -------------------------------------------------------------------------------- /assets/proposals/0315-Add-RPC-Conflict-Management/Figure1_Conflict_between_ScrollableMessage_and_PerformAudioPassThru_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0315-Add-RPC-Conflict-Management/Figure1_Conflict_between_ScrollableMessage_and_PerformAudioPassThru_1.png -------------------------------------------------------------------------------- /assets/proposals/0315-Add-RPC-Conflict-Management/Figure2_ONS_RPCs_conflict.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0315-Add-RPC-Conflict-Management/Figure2_ONS_RPCs_conflict.png -------------------------------------------------------------------------------- /assets/proposals/0315-Add-RPC-Conflict-Management/Figure3_TTS_RPCs_conflict.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0315-Add-RPC-Conflict-Management/Figure3_TTS_RPCs_conflict.png -------------------------------------------------------------------------------- /assets/proposals/0315-Add-RPC-Conflict-Management/Table_2_Priority_result_of_Table1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0315-Add-RPC-Conflict-Management/Table_2_Priority_result_of_Table1.png -------------------------------------------------------------------------------- /assets/proposals/0316-Clarification-of-transport-switching-rules-and-improvement-of-UX/Figure_1_Sequence_with_new_RPC_added_to_existing_logic1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0316-Clarification-of-transport-switching-rules-and-improvement-of-UX/Figure_1_Sequence_with_new_RPC_added_to_existing_logic1.png -------------------------------------------------------------------------------- /assets/proposals/0316-Clarification-of-transport-switching-rules-and-improvement-of-UX/Table_1_Switching_of_Multiple_Transport.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0316-Clarification-of-transport-switching-rules-and-improvement-of-UX/Table_1_Switching_of_Multiple_Transport.png -------------------------------------------------------------------------------- /assets/proposals/0317-sdl-protocol-security-specification/tls-handshake.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0317-sdl-protocol-security-specification/tls-handshake.png -------------------------------------------------------------------------------- /assets/proposals/0317-sdl-protocol-security-specification/tls-handshake.uml: -------------------------------------------------------------------------------- 1 | @startuml 2 | 3 | title TLS Handshake 4 | 5 | participant Client as "SDL Core\n(Client)" 6 | participant Server as "SDL App\n(Server)" 7 | 8 | Client -> Server : ClientHello 9 | Server -> Client : ServerHello 10 | Server -> Client : ServerCertificate 11 | Server -> Client : ServerKeyExchange 12 | opt With Client authentication 13 | Server -> Client : CertificateRequest 14 | end opt 15 | 16 | Server -> Client : ServerHelloDone 17 | opt With Client authentication 18 | Client -> Server : Certificate 19 | end opt 20 | Client -> Server : ClientKeyExchange 21 | opt With Client authentication 22 | Client -> Server : CertificateVerify 23 | end opt 24 | note over Client, Server 25 | Compute master secret 26 | end note 27 | Client -> Server : ChangeCipherSpec 28 | Client -> Server : Finished 29 | Server -> Client : ChangeCipherSpec 30 | Server -> Client : Finished 31 | 32 | @enduml -------------------------------------------------------------------------------- /assets/proposals/0319-Add-a-notification-and-restore-function-for-unexpected-exception-error/Figure_1_error_notification_sequence.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0319-Add-a-notification-and-restore-function-for-unexpected-exception-error/Figure_1_error_notification_sequence.png -------------------------------------------------------------------------------- /assets/proposals/0319-Add-a-notification-and-restore-function-for-unexpected-exception-error/Figure_2_return_processing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0319-Add-a-notification-and-restore-function-for-unexpected-exception-error/Figure_2_return_processing.png -------------------------------------------------------------------------------- /assets/proposals/0320-Add-screen-stack-management-module/Screen_transition_process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0320-Add-screen-stack-management-module/Screen_transition_process.png -------------------------------------------------------------------------------- /assets/proposals/0320-Add-screen-stack-management-module/new_sequence.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0320-Add-screen-stack-management-module/new_sequence.png -------------------------------------------------------------------------------- /assets/proposals/0324-Function-to-control-the-priority-of-audio-and-video-when-switching-between-apps/Figure_1_app_switching_sequence.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0324-Function-to-control-the-priority-of-audio-and-video-when-switching-between-apps/Figure_1_app_switching_sequence.png -------------------------------------------------------------------------------- /assets/proposals/0325-Dynamic-App-List-Sorting/Figure1_SDL_App_Icon_display_sequence.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0325-Dynamic-App-List-Sorting/Figure1_SDL_App_Icon_display_sequence.PNG -------------------------------------------------------------------------------- /assets/proposals/0326-handle-late-malformed-hmi-responses/addCommand_fail.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0326-handle-late-malformed-hmi-responses/addCommand_fail.png -------------------------------------------------------------------------------- /assets/proposals/0331-Add-new-SDL-System-Structure-using-Mediation-Application/Figure1_Current_SDL_system_configuration.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0331-Add-new-SDL-System-Structure-using-Mediation-Application/Figure1_Current_SDL_system_configuration.png -------------------------------------------------------------------------------- /assets/proposals/0331-Add-new-SDL-System-Structure-using-Mediation-Application/Figure2_new_SDL_system_configuration.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0331-Add-new-SDL-System-Structure-using-Mediation-Application/Figure2_new_SDL_system_configuration.png -------------------------------------------------------------------------------- /assets/proposals/0337-reject-proprietary-http-systemrequests-when-ptu-not-in-progress/Http_request_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0337-reject-proprietary-http-systemrequests-when-ptu-not-in-progress/Http_request_flow.png -------------------------------------------------------------------------------- /assets/proposals/0337-reject-proprietary-http-systemrequests-when-ptu-not-in-progress/Proprietary_request_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0337-reject-proprietary-http-systemrequests-when-ptu-not-in-progress/Proprietary_request_flow.png -------------------------------------------------------------------------------- /assets/proposals/0340-atf-selenium-support/ATFSelenium.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0340-atf-selenium-support/ATFSelenium.png -------------------------------------------------------------------------------- /assets/proposals/0341-add-generic-hmi-plugin-support/menu-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0341-add-generic-hmi-plugin-support/menu-example.png -------------------------------------------------------------------------------- /assets/proposals/0341-add-generic-hmi-plugin-support/plugin-tabs-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0341-add-generic-hmi-plugin-support/plugin-tabs-example.png -------------------------------------------------------------------------------- /assets/proposals/0341-add-generic-hmi-plugin-support/vr-plugin-stub-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0341-add-generic-hmi-plugin-support/vr-plugin-stub-example.png -------------------------------------------------------------------------------- /assets/proposals/0343-Addition-of-a-way-to-notify-HMI-of-the-required-support-for-apps/Figure_1_sequence_of_Add_Notifications_for_Required_App_Support.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/smartdevicelink/sdl_evolution/a0e2c653d583c0d9e7e0c86624d524932def902f/assets/proposals/0343-Addition-of-a-way-to-notify-HMI-of-the-required-support-for-apps/Figure_1_sequence_of_Add_Notifications_for_Required_App_Support.png -------------------------------------------------------------------------------- /changelog.md: -------------------------------------------------------------------------------- 1 | # SDL Evolution Changes 2 | This document tracks past releases of SDL projects and their implemented proposals, as well as proposals which have been rejected. See [commonly rejected proposals][common-proposals] for a list of commonly rejected proposals and the rationale behind the rejection. 3 | 4 | ## Example SDL Library X.X 5 | The goals for this release were... 6 | 7 | ### Implemented proposals 8 | 9 | ## Rejected or withdrawn proposals 10 | * N/A 11 | 12 | [common-proposals]: commonly_proposed.md "Commonly rejected proposals" 13 | -------------------------------------------------------------------------------- /commonly_proposed.md: -------------------------------------------------------------------------------- 1 | # Commonly Rejected Proposals 2 | N/A 3 | -------------------------------------------------------------------------------- /proposals/0008-ios-7-0-minimum.md: -------------------------------------------------------------------------------- 1 | # Base iOS Version to 7.0 2 | * Proposal: [SDL-0008](0008-ios-7-0-minimum.md) 3 | * Author: [Joel Fischer](https://github.com/joeljfischer) 4 | * Status: **Accepted** 5 | * Impacted Platforms: iOS 6 | 7 | ## Introduction 8 | This proposal is to move the minimum iOS version allowed by iOS from 6.0 to 7.0 and to make changes taking advantage of the available iOS 7.0 APIs. Since we don't know of any major partners who currently support iOS 6.0+, we should move up our version accordingly. 9 | 10 | ## Motivation 11 | The reason to move up to iOS 7.0 is to make available additional APIs such as `NSURLSession` and `NSURLComponents`. 12 | 13 | ## Proposed solution 14 | In addition to moving to iOS 7.0, we should remove private classes such as `SDLURLSession` and related classes and move to `NSURLSession` which it attempts to mimic. 15 | 16 | ## Potential Downsides 17 | Any existing app partners on iOS 6.0 would either have to drop SDL support or move to iOS 7.0+. 18 | 19 | ## Impact on existing code 20 | This would only impact us by making available additional APIs. 21 | -------------------------------------------------------------------------------- /proposals/0011-ios-library-conform-to-nscopying.md: -------------------------------------------------------------------------------- 1 | # iOS Library RPCs conform to NSCopying 2 | * Proposal: [SDL-0011](0011-ios-library-conform-to-nscopying.md) 3 | * Author: [Joel Fischer](https://github.com/joeljfischer) 4 | * Status: **Accepted** 5 | * Impacted Platforms: iOS 6 | 7 | ## Introduction 8 | This proposal is to make all RPC requests, responses, and structs conform to the `NSCopying` protocol and for all requests containing structs to hold those properties with the `copy` modifier. This is a minor change, as the public interfaces for the RPCs will change to support the `copy` method. 9 | 10 | ## Motivation 11 | It makes sense for model objects to be copyable. Since we will not be using fully immutable RPCs, we should permit defensive copying instead of only allowing reference passing. For example, if we are passing an RPC between threads, since the properties are mutable, they can be modified while in use on the other thread, or modified on both threads. By copying before passing it to the new thread, we can guarantee that we have two separate objects and modifying one will not modify the other. This could be useful, for example, for copying the RPC after the developer has attempted to send it to the head unit. If it is copied, it can no longer be modified once the developer has passed it to the `send` method. 12 | 13 | ## Proposed Solution 14 | To implement this proposal, we only need to modify `SDLRPCStruct` and a small number of other types since all other RPC types inherit from it and all other RPC properties (barring a few, discussed below) are stored in the dictionary attached to it. So we need to add `` as a conformed protocol to `SDLRPCStruct` and implement the following method: 15 | 16 | ``` 17 | - (id)copyWithZone:(NSZone *)zone { 18 | SDLRPCStruct *newStruct = [[[self class] allocWithZone:zone] init]; 19 | newStruct -> store = [self -> store copy]; 20 | 21 | return newStruct; 22 | } 23 | ``` 24 | 25 | The only RPCs that will not work using this method are those in 4.3 that added the 'handler' property. These RPCs will need to add something like: 26 | 27 | ``` 28 | - (id)copyWithZone:(NSZone *)zone { 29 | SDLAddCommand *newCommand = [super copyWithZone:zone]; 30 | newCommand -> handler = self.handler; 31 | 32 | return newCommand; 33 | } 34 | ``` 35 | 36 | ## Potential Downsides 37 | There should be no downsides to this proposal. 38 | 39 | ## Impact on existing code 40 | This would be a minor change as we are adding protocol conformance to classes, which is a purely additive change. 41 | 42 | ## Alternatives considered 43 | The only other alternative was to make RPCs fully immutable, a change which died in the concept stage. 44 | -------------------------------------------------------------------------------- /proposals/0012-ios-library-remove-siphon.md: -------------------------------------------------------------------------------- 1 | # iOS Library Remove Siphon Server 2 | * Proposal: [SDL-0012](0012-ios-library-remove-siphon.md) 3 | * Author: [Joel Fischer](https://github.com/joeljfischer) 4 | * Status: **In review** 5 | * Impacted Platforms: iOS 6 | 7 | ## Introduction 8 | This proposal is to make major changes by removing the "siphon server" aspect from the SDL libraries. 9 | 10 | ## Motivation 11 | The siphon server is a legacy piece that is Ford proprietary (that is, only Ford employees can use it) which allows them to view SDL logs on a Windows (only) computer over a TCP connection. This feature should be removed for a variety of reasons. First, the feature is proprietary to Ford, and this is an open-source project. Second, this feature has been superceded by the Relay app, which does the same job much better. Third, after asking about this feature among Ford employees, half didn't know what it was and the other half hadn't used it in a long time. 12 | 13 | ## Proposed Solution 14 | The proposed solution is simply to remove it and not replace it. The Relay app captures the same use case (a desire to see logs while connected to a physical head unit over USB IAP) while doing the job much better. For example, the Relay app allows the use of debugging with breakpoints, and as of iOS 10 + macOS Sierra, a variety of additional `os_log` tools. Further improvements could be made in SDL logging to improve for example, filtering and sorting to match what exists in iOS 10 + macOS Sierra. 15 | 16 | ## Potential Downsides 17 | The only downside is that the better debugging capabilities of Relay requires the app to be built in Xcode. This means that another company could not provide Ford with an app with Siphon turned on for Ford to debug. However, since this is a proprietary solution, it should nonetheless be removed until, if needed, it is replaced with an open solution. iOS 10's new logging would allow us to pass around `.logarchive` files to try to debug that way, if necessary, however, iOS 10's very good new logging APIs would need to be implemented, and they only work on iOS 10+ and macOS Sierra+ devices. 18 | 19 | ## Impact on existing code 20 | This would be a major change removing several public files and methods. 21 | 22 | ## Alternatives considered 23 | We could leave it as is, but this is judged to be a poor option. 24 | -------------------------------------------------------------------------------- /proposals/0016-ios-library-transport-private-cleanup.md: -------------------------------------------------------------------------------- 1 | # iOS Library Make Transport Classes Private and Cleaner 2 | * Proposal: [SDL-0016](0016-ios-library-transport-private-cleanup.md) 3 | * Author: [Joel Fischer](https://github.com/joeljfischer) 4 | * Status: **Accepted** 5 | * Impacted Platforms: iOS 6 | 7 | ## Introduction 8 | This proposal is to make a major change by altering transport classes to be private instead of public. 9 | 10 | ## Motivation 11 | Privacy should be preferred in order to allow developers to make API changes to the classes without requiring minor or major version changes. The transport classes have no need for a developer to interact with them, and doing so would be harmful. Therefore, these classes should be private. The second change should be made for safety reasons and to simply be cleaner. 12 | 13 | ## Proposed Solution 14 | The specific classes to be changed from public to private are: 15 | * `SDLTransportDelegate` 16 | * `SDLAbstractTransport` 17 | * `SDLIAPSessionDelegate` 18 | * `SDLIAPTransport` 19 | * `SDLTCPTransport` 20 | 21 | Changing this would additionally require changes in `SDLProxy`'s initializer: `- (id)initWithTransport:(SDLAbstractTransport *)transport protocol:(SDLAbstractProtocol *)protocol delegate:(NSObject *)delegate;` because we would no longer be having the developer create the transports. 22 | 23 | ## Potential Downsides 24 | There are no potential downsides. We do not want the developer to interface with these classes, so we should disable that ability. 25 | 26 | ## Impact on existing code 27 | This would be a breaking change. We would need to change these classes' scope in Xcode, Cocoapods, and alter the `SDLProxy` initializer. 28 | -------------------------------------------------------------------------------- /proposals/0017-ios-protocol-layer-nonpublic.md: -------------------------------------------------------------------------------- 1 | # iOS Library Protocol Layer Should Not Be Public 2 | 3 | * Proposal: [SDL-0017](0017-ios-protocol-layer-nonpublic.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted** 6 | * Impacted Platforms: iOS 7 | 8 | ## Introduction 9 | This proposal is to make breaking changes by shifting all code on the protocol layer to be non-public. No class on the protocol layer should have a public API. 10 | 11 | ## Motivation 12 | The protocol layer is the layer that handles the breaking down of RPCs into bytes to be sent, the building of byte packets into RPCs, and the protocol services. None of these APIs ought to be touched by an app developer, but the APIs are currently public. Because those APIs are public, they are difficult to update because any change to the API of the protocol layer requires minor or major version changes. This change would allow SDL developers to refactor the protocol layer as necessary without needing to make minor or major changes. In addition, it would hide potentially harmful-for-the-developer-to-use APIs from the developer, decreasing cognitive load and increasing safety. 13 | 14 | ## Proposed solution 15 | Currently, the following classes of the protocol layer are public: 16 | * `SDLProtocolListener.h` 17 | * `SDLProtocolHeader.h` 18 | * `SDLProtocolMessage.h` 19 | * `SDLAbstractProtocol.h` 20 | * `SDLProtocol.h` 21 | 22 | These classes should be shifted to `project` instead of `public` and all public API references to them, such as in `SDLProxy`'s `init` method, should be removed. 23 | 24 | ## Impact on existing code 25 | This is a major change, but would likely not affect many people because they should not be using these methods anyway. The `SDLProxy` method: `- (id)initWithTransport:(SDLAbstractTransport *)transport protocol:(SDLAbstractProtocol *)protocol delegate:(NSObject *)delegate;` would need to change, but this would be simple. Removing the `protocol` portion of it and simply instantiating an `SDLProtocol` would be all that is required. 26 | 27 | ## Alternatives considered 28 | The only alternative is to make API changes to these methods as desired and leave them public. There's no reason to do this, however, and further changes would require further major version changes. 29 | -------------------------------------------------------------------------------- /proposals/0020-ios-remove-rpcrequestfactory.md: -------------------------------------------------------------------------------- 1 | # Remove `SDLRPCRequestFactory` 2 | 3 | * Proposal: [SDL-0020](0020-filename.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted** 6 | * Impacted Platforms: iOS 7 | 8 | ## Introduction 9 | This proposal is to make a major change to remove the `SDLRPCRequestFactory` class and move instead build better initializers onto the RPC classes themselves. 10 | 11 | ## Motivation 12 | Instead of having a dedicated factory class, we should instead create initializer methods directly on the RPC classes. Currently, the factory methods (which is more of a Java convention anyway) are somewhat hidden on the `SDLRPCRequestFactory` class, and shifting them to the individual RPC classes will make them more visible to developers and easier to find in general. Second, it will help ensure that when RPCs are added that the initializers are also updated. Finally, this will help to ensure that the library is more cohesive. Currently, some RPCs have factory methods, some have lots of factory methods, and many RPCs have none. Moving these methods out of the `SDLRPCRequestFactory` class will help to ensure that we keep the library consistent with good initializers. 13 | 14 | ## Proposed solution 15 | The proposed solution is simply to remove the `SDLRPCRequestFactory` class entirely and to create initializers on RPC classes where they make sense, some may be similar to how `SDLRPCRequestFactory` already generates them with minor tweaks. For example, the correlation id is now automatically handled by the new dev API, therefore it should not be on any initializers as it is on the RPC factory methods. 16 | 17 | ## Impact on existing code 18 | This is a major change because we are removing a class and a host of methods. This will be a breaking change for many developers who are using those methods to build their RPC requests. They will have to shift to using the initializers or building them manually. 19 | 20 | ## Alternatives considered 21 | A few alternatives were considered. First is to leave it as is, only tweaking the RPC factory methods (e.g. removing correlation id parameters). This is judged as a worse option because all the methods would still be clumped together in one class instead of spread out to where they should be, close to their respective RPCs. Second is to remove it without replacing the methods with initializers. This is judged as a worse option because the initializers can be useful and manually building every RPC can be a pain on some of the larger RPCs. 22 | -------------------------------------------------------------------------------- /proposals/0021-ios-remove-sdlttschunkfactory.md: -------------------------------------------------------------------------------- 1 | # Remove SDLTTSChunkFactory 2 | * Proposal: [SDL-0021](0021-remove-sdlttschunkfactory.md) 3 | * Author: [Alex Muller](https://github.com/asm09fsu) 4 | * Status: **Accepted** 5 | * Impacted Platforms: iOS 6 | 7 | ## Introduction 8 | 9 | This proposal is to remove the `SDLTTSChunkFactory` class and move all functions to create TTS Chunks into `SDLTTSChunk` 10 | 11 | ## Motivation 12 | 13 | First and foremost, factories are a java construct, not used in Objective-C/Swift. With having these useful functions extracted out to a separate class, this results in them being hidden from the developer more difficult to use. Moving these functions out of `SDLTTSChunkFactory` and place them in `SDLTTSChunk` will help developers understand how to easily create chunks used in other RPCs. 14 | 15 | ## Proposed solution 16 | 17 | The proposed solution is to remove `SDLTTSChunkFactory` and place them within `SDLTTSChunk` 18 | 19 | 20 | ## Detailed design 21 | 22 | ```objc 23 | // SDLTTSChunk.h 24 | // 25 | 26 | #import "SDLRPCMessage.h" 27 | 28 | @class SDLSpeechCapabilities; 29 | 30 | @interface SDLTTSChunk : SDLRPCStruct 31 | 32 | - (instancetype)init; 33 | 34 | - (instancetype)initWithDictionary:(NSMutableDictionary *)dict; 35 | 36 | + (instancetype)ttsChunkForString:(NSString *)text type:(SDLSpeechCapabilities *)type; 37 | 38 | + (NSMutableArray *)ttsChunksForString:(NSString *)simple; 39 | 40 | @property (strong) NSString *text; 41 | 42 | @property (strong) SDLSpeechCapabilities *type; 43 | 44 | @end 45 | ``` 46 | 47 | ## Impact on existing code 48 | 49 | The impact on existing code is that `SDLTTSChunkFactory` will cease to exist. We could also deprecate the class, and direct developers to use `SDLTTSChunk` and remove it in a future release. 50 | 51 | ## Alternatives considered 52 | 53 | An alternative considered would be to leave `SDLTTSChunkFactory`, although it is felt that this adds confusion to the end developer. 54 | -------------------------------------------------------------------------------- /proposals/0023-update-mobile-api-mandatory-flag.md: -------------------------------------------------------------------------------- 1 | # Update Mobile API to Include Mandatory Flag on Parameters 2 | 3 | * Proposal: [SDL-0023](0023-update-mobile-api-mandatory-flag.md) 4 | * Author: [Alex Muller](https://github.com/asm09fsu) 5 | * Status: **Accepted** 6 | * Impacted Platforms: RPC 7 | 8 | ## Introduction 9 | Currently within the spec that is used by core ([MOBILE_API.xml](https://github.com/smartdevicelink/sdl_core/blob/master/src/components/interfaces/MOBILE_API.xml) ), there is a lack of consistency among structs and functions relating to their parameters not stating whether they are all mandatory or not. 10 | 11 | ## Motivation 12 | 13 | This proposal seeks to address the issues relating to readability and understand of the spec in its current state relating to whether or not a parameter of a request, response, or struct is mandatory. 14 | 15 | ## Proposed solution 16 | 17 | Solution is to update the mobile_api.xml to include mandatory flags for all struct & function objects. 18 | 19 | ## Detailed design 20 | 21 | Example is for SoftButton (with descriptions stripped): 22 | ```xml 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | ``` 38 | to 39 | ```xml 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | ``` 55 | 56 | ## Impact on existing code 57 | 58 | This will not change any code, only add clarity to the spec for potential new partners. 59 | 60 | ## Alternatives considered 61 | 62 | No alternatives considered. 63 | -------------------------------------------------------------------------------- /proposals/0024-ios-8-0-minimum.md: -------------------------------------------------------------------------------- 1 | # Minimum iOS Version to 8.0 2 | * Proposal: [SDL-0024](0024-ios-8-0-minimum.md) 3 | * Author: [Alex Muller](https://github.com/asm09fsu) 4 | * Status: **Accepted** 5 | * Impacted Platforms: iOS 6 | 7 | ## Introduction 8 | This proposal is to move the minimum iOS version allowed by iOS from 7.0 to 8.0 and to make changes taking advantage of the available iOS 8.0 APIs. Since we don't know of any major partners who currently support iOS 7.0+, we should move up our version accordingly. 9 | 10 | ## Motivation 11 | The reason to move up to iOS 8.0 is to be able to make sure we are able to leverage newer technologies, such as Swift 3, and Xcode 8, without additional resources to confirm backwards compatibility. This also allows us to remove the checks for SDLStreamingMediaManager being only usable on iOS 8, as the whole library will be iOS 8.0+. 12 | 13 | ## Proposed solution 14 | In addition to moving to iOS 8.0, we should remove the checks for SDLStreamingMediaManager and iOS 8.0. 15 | 16 | ## Potential Downsides 17 | Any existing app partners on iOS 7.0 would either have to drop SDL support or move to iOS 8.0+ 18 | 19 | ## Impact on existing code 20 | This would only impact us by making available additional APIs. 21 | -------------------------------------------------------------------------------- /proposals/0025-ios-filemanager-stream-from-disk.md: -------------------------------------------------------------------------------- 1 | # Stream File Manager Uploads from Disk 2 | 3 | * Proposal: [SDL-0025](0025-ios-filemanager-stream-from-disk.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted** 6 | * Impacted Platforms: iOS 7 | 8 | ## Introduction 9 | This proposal is to make a minor API addition to the SDL iOS library to make possible streaming a file from disk in order to reduce memory usage when uploading a large file to the remote system. 10 | 11 | ## Motivation 12 | In SDL v5.0, the `SDLProxy` class is likely to be removed, and with it, the only method for streaming a file from disk without pulling the whole file into memory. We should build a method for only pulling required data from an `SDLFile`. Currently we can only pull all of the data at once. 13 | 14 | ## Proposed solution 15 | The proposed solution is to add a new method onto `SDLFile`: `SDLFile dataAtOffset:length:`. This would only pull the required data from the file on disk or in memory using `NSFileHandle`. 16 | 17 | There would be additional changes made to `SDLUploadFileOperation` to handle pulling a specific range of data rather than the whole range, but no public API changes. `SDLUploadFileOperation` will call `SDLFile dataAtOffset:length:`, create a PutFile using that data, and send it. It will wrap this process in `@autoreleasepool` so that the PutFiles can be released as soon as possible. This should free up data when sending a large file. 18 | 19 | ## Impact on existing code 20 | This will be a minor API change to the iOS library. There will be no additional impact. 21 | 22 | ## Alternatives considered 23 | An alternative would be to more directly copy the `putFileStream:withRequest` method from `SDLProxy`, however, it really doesn't fit with the rest of the File Manager API. 24 | -------------------------------------------------------------------------------- /proposals/0040-DTLS-encryption.md: -------------------------------------------------------------------------------- 1 | # DTLS encryption 2 | 3 | * Proposal: [SDL-0040](0040-DTLS-encryption.md) 4 | * Author: [Markos Rapitis](https://github.com/mrapitis) 5 | * Status: **Accepted** 6 | * Impacted Platforms: Core 7 | 8 | 9 | ## Introduction 10 | 11 | This proposal is to add DTLS (Datagram Transport Layer Security) to SDL core. SDL core will utilize the DTLS communications protocol as a preferred solution when sending encrypted data over protected services (such audio 0x0a and video 0x0b ) including the handshake, encryption and decryption processes. 12 | 13 | ## Motivation 14 | 15 | Currently SDL core offers the capability to utilize the TLS v1.2 communications protocol to establish protected services for activities like video and audio streaming. While TLS v1.2 is an exceptional security protocol, it unfortunately has dependence on packet ordering and lacks the ability to recover from lost packets. Since many OEM hardware implementations cannot 100% guarantee packet delivery and ordering, TLS v1.2 does not provide a sufficient capabilities for the utilization of protected services. 16 | DTLS is an implementation of TLS over a datagram protocol. DTLS is similar to TLS intentionally except that DTLS has to solve two large problems that OEM headunits may face -- packet loss and packet reordering. DTLS implements three important features to solve these problems: 17 | 18 | - A packet retransmission strategy 19 | - Assigning sequence number within the handshake process 20 | - Replay detection for added security 21 | 22 | 23 | 24 | ## Proposed solution 25 | 26 | - Add capability to SDL core to utilize the DTLS v1.0 communications protocol. 27 | 28 | - Add a ‘DTLSv1.0’ parameter to the ‘[Security Manager]’ section of the SmartDeviceLink.ini file. 29 | 30 | - If the ‘DTLSv1.0’ has been specified in the .ini file, SDL core will open protected services using the DTLS v1.0 protocol including the following: 31 | - Perform DTLS v1.0 handshake 32 | - Encryption 33 | - Decryption 34 | 35 | - Fortunately from an implementation standpoint, since SDL core is currently utilizing the OpenSSL library all necessary supporting API’s for DTLS v1.0 already exists to leverage the communications protocol. 36 | - From a SDL core code perspective, the existing SDL core security initialization process will make use of the following additional OpenSSL API: 37 | 38 | - DTLSv1_server_method() 39 | - DTLSv1_client_method() 40 | 41 | 42 | ## Potential downsides 43 | None 44 | 45 | 46 | ## Impact on existing code 47 | Impact on existing code will be minimal as SDL core already makes use of the OpenSSL library and already offers some existing security protocols inside of the library. 48 | 49 | 50 | ## Alternatives considered 51 | TLS v1.2, however given the downsides previously mentioned with this protocol, DTLS v1.0 suits SDL's needs best. 52 | -------------------------------------------------------------------------------- /proposals/0049-touch-cancellation.md: -------------------------------------------------------------------------------- 1 | # Gesture cancellation on video streaming 2 | 3 | * Proposal: [SDL-0049](0049-touch-cancellation.md) 4 | * Author: [Masato Ogawa](https://github.com/masatoogawa) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core / iOS / Android / RPC] 7 | 8 | ## Introduction 9 | 10 | This proposal defines a gesture cancellation event to prevent false gesture recognition during an interrupted video stream. 11 | 12 | ## Motivation 13 | 14 | During operation with an SDL application supporting video streaming, a native dialog such as incoming-call may interrupt. If touch events before and after a screen interruption are evaluated as one gesture, an unexpected gesture may be detected. 15 | 16 | ## Proposed solution 17 | 18 | HMI notifies gesture cancellation by OnTouchEvent method of UI component. 19 | 20 | ## Detailed design 21 | 22 | ### Additions to Mobile_API 23 | 24 | ``` 25 | 26 | 27 | 28 | 29 | + 30 | 31 | ``` 32 | 33 | ### Additions to HMI_API 34 | 35 | ``` 36 | 37 | 38 | 39 | 40 | + 41 | 42 | ``` 43 | 44 | HMI notifies with JSON as below. It passes through Core and is passed to Application. In the case of multi-touch, it is necessary to notify each ID. 45 | 46 | ``` 47 | { 48 | "jsonrpc" : "2.0", 49 | "method" : "UI.OnTouchEvent", 50 | "params" : 51 | { 52 | "type" : "CANCEL", 53 | "event" : [ 54 | { 55 | "id":0, 56 | "ts":[49013], 57 | "c":[{"x":323,"y":259}], 58 | } 59 | ] 60 | } 61 | } 62 | ``` 63 | 64 | ## Potential downsides 65 | 66 | 1) Can it be implemented with currently defined values? 67 | 68 | Yes, we can treat TouchType::BEGIN during TouchType::MOVE as a cancellation. However, to avoid misunderstanding, it's good to define a single event rather than defining a sequence. And general mobile OS has an event like this. 69 | 70 | ## Impact on existing code 71 | 72 | This change is only adding TouchType's enum value. It does not stop compilation and does not change the current behavior. 73 | 74 | ## Alternatives considered 75 | 76 | If TouchType::BEGIN is received during TouchType::MOVE, the application cancels gesture recognition. 77 | 78 | -------------------------------------------------------------------------------- /proposals/0060-support-indian-english-thai.md: -------------------------------------------------------------------------------- 1 | # Support Indian English and Thai 2 | 3 | * Proposal: [SDL-0060](0060-support-indian-english-thai.md) 4 | * Author: [Kujtim Shala](https://github.com/kshala-ford) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core / iOS / Android / RPC] 7 | 8 | ## Introduction 9 | 10 | This proposal is about adding support for Indian English (EN_IN) and Thai (TH_TH). 11 | 12 | ## Motivation 13 | 14 | Ford's infotainment system is going to support those languages in a future version. Those languages don't exist in the current list of supported languages. 15 | 16 | ## Proposed solution 17 | 18 | The solution is to add and implement both languages to the HMI and mobile API (the change is equal to both APIs): 19 | 20 | ```xml 21 | 22 | English - India 23 | 24 | 25 | 26 | Thai - Thailand 27 | 28 | ``` 29 | 30 | ## Potential downsides 31 | 32 | The effort of adding new languages is quite high. However, given our need to add these Langauges, adding new items to the `Language` enum is simpler than changing the language support to be more flexible. 33 | 34 | ## Impact on existing code 35 | 36 | The proposal requires changes on SDL_core, both SDKs (Android, iOS) and APIs (mobile, HMI). 37 | 38 | ## Alternatives considered 39 | 40 | SDL should not control localization through an enumeration which will be proposed in a separate proposal as a long-term solution. 41 | -------------------------------------------------------------------------------- /proposals/0063-display-name-parameter.md: -------------------------------------------------------------------------------- 1 | # Display name parameter 2 | 3 | * Proposal: [SDL-0063](0063-display-name-parameter.md) 4 | * Author: [Kujtim Shala](https://github.com/kshala-ford) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core / iOS / Android / RPC] 7 | 8 | ## Introduction 9 | 10 | This proposal is about deprecating the parameter `displayType` and replace it with `displayName`. 11 | 12 | ## Motivation 13 | 14 | The parameter `displayType` is of type `DisplayType` which is an enum of many old/legacy displays. The enum would need to be changed for every new head unit with a new display. The enum should be deprecated. 15 | 16 | ## Proposed solution 17 | 18 | The proposed solution is to deprecate the `DisplayType` enum and the `DisplayCapabilities.displayType` parameter in the APIs and SDKs. As a replacement a new (optional) string parameter called `displayName` should be added to the `DisplayCapabilities` struct. 19 | 20 | ### API (mobile and HMI) 21 | 22 | ```xml 23 | 24 | 25 | The name of the display the app is connected to. 26 | 27 | 28 | ``` 29 | 30 | ### SDK 31 | 32 | Depending on the JSON data the SDK should use the `displayName` parameter for the corresponding property by default. If the JSON data does not contain a `displayName` parameter the SDK should use the `displayType` parameter as string for backwards compatibility. 33 | 34 | ## Potential downsides 35 | 36 | The downside is that displays are not known anymore. Any string can be provided by the head unit. Depending on the importance a list of displays can be provided through the website's documentation. 37 | 38 | ## Impact on existing code 39 | 40 | All areas would need to be addressed (HMI, core, RPC and SDKs). Fortunately the existing code is basically just forwarding a string that comes from the HMI. Therefore the impact is expected to be small. 41 | 42 | ## Alternatives considered 43 | 44 | This proposal is quite careful to not remove but replace a feature. As an alternative the display type can be deprecated without a replacement if knowing the display is not important. 45 | -------------------------------------------------------------------------------- /proposals/0066-steering-wheel-location.md: -------------------------------------------------------------------------------- 1 | # Steering wheel location 2 | 3 | * Proposal: [0066](0066-steering-wheel-location.md) 4 | * Author: [Kujtim Shala](https://github.com/kshala-ford) 5 | * Status: **Rejected** 6 | * Impacted Platforms: [Core / iOS / Android / RPC ] 7 | 8 | ## Introduction 9 | 10 | This proposal is about adding a new parameter to the `VehicleType` structure to inform the app about the steering wheel location within the vehicle. 11 | 12 | ## Motivation 13 | 14 | Some apps want to use different templates based on the steering wheel location. As an example TEXT_WITH_BUTTONS_AND_GRAPHIC works great for left handed drives as buttons are closer to the driver. For right handed drives apps would want to use GRAPHIC_WITH_TEXT_AND_BUTTONS. Today apps would use the language/region code and **guess** the location of the steering wheel. 15 | 16 | ## Proposed solution 17 | 18 | In order to improve the user experience for right handed drive the app should know the steering wheel location. This information can be provided to the app right after the app's registration on the head unit. This newly added parameter should be optional for backwards compatibility. The type of the parameter should be an enum. Following values should be allowed: 19 | 20 | - `null`: Either the head unit is of an old version and/or the steering wheel location is not known. 21 | - `.LEFT`: The steering wheel location is on the left hand side. 22 | - `.RIGHT`: The steering wheel location is on the right hand side. 23 | - `.CENTER`: The steering wheel location is centered. 24 | - `.NONE`: The vehicle does not contain a steering wheel (e.g. autonomous. different to `null` the app would definitely know that no steering wheel exists). 25 | 26 | ### HMI and mobile API: 27 | 28 | ```xml 29 | 30 | Describes the location of the Steering Wheel. 31 | 32 | 33 | 34 | 35 | 36 | : 37 | 38 | : 39 | 40 | See SteeringWheelLocation 41 | 42 | 43 | ``` 44 | 45 | ## Impact on existing code 46 | 47 | - The proposal should just require a minor version change. 48 | - Core and mobile libraries would just implement the API changes. 49 | 50 | ## Alternatives considered 51 | 52 | Language/country code can be used instead. An app can assume that majority of the vehicles e.g. EN_GB are right hand drive. 53 | -------------------------------------------------------------------------------- /proposals/0068-idea_to_implementation.md: -------------------------------------------------------------------------------- 1 | # Idea To Implementation 2 | 3 | * Proposal: [SDL-0068](0068-idea_to_implementation.md) 4 | * Author: [Joey Grover](https://github.com/joeygrover) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Meta / RPC] 7 | 8 | ## Introduction 9 | 10 | This proposal is to define a process on how ideas and improvements are taken from the SDL Evolution Process to actually being implemented, specifically for changes that alter the RPC spec. 11 | 12 | ## Motivation 13 | 14 | Currently it is very hard to track how or when different proposals will be implemented. Some proposals that only affect a single project and not the protocol or RPC spec can be implemented as time allows for that specific projects release cycle. However, whenever a proposal affects the RPC spec it has to be coordinated among all the SDL projects so that proper inoperability is achieved. 15 | 16 | 17 | ## Proposed solution 18 | 19 | This proposal is to define a process from idea to implementation. This also aims to ensure that the SDL RPC spec and its versions are well defined. 20 | 21 | The process is defined as such: 22 | 23 | ![SDL Workflow][sdl-workflow] 24 | 25 | #### RPC Spec Timing 26 | The biggest roadblock with this process is that we would have to define what to include a while in advance to actual releases of the projects. 27 | 28 | An RPC spec would have to be accepted before the next version of the projects work started. Then it will become clear which version of the projects support which version of the RPC spec. 29 | 30 | It is possible that sdl\_core skips RPC spec versions. For example, release 4.4 of sdl\_core could support v4.5.0 of the RPC spec. Then the next version of the RPC spec is approved (v4.6.0) and implemented into the next release of the SDL proxies. However, sdl\_core is set for two releases a year, unlike the proxies that are slated to have four. That means a new RPC spec version (v4.7.0) could be approved after v4.6.0 was implemented into the proxy libraries. Then the next release of both the proxies and sdl\_core would have v4.6.0 implemented. 31 | 32 | 33 | |Project| Release Version| RPC Spec version | 34 | |----|-----|-----| 35 | |Core| 4.3.0|4.4.0 36 | |Android Proxy|4.3.0|4.4.0| 37 | |iOS Proxy|4.5.0|4.4.0| 38 | |**RPC Spec**|---|4.5.0| 39 | |Android Proxy|4.4.0|4.5.0| 40 | |iOS Proxy|4.6.0|4.5.0| 41 | |**RPC Spec**|---|4.6.0| 42 | |Core| 4.4.0|4.6.0| 43 | |Android Proxy|4.5.0|4.6.0| 44 | |iOS Proxy|4.7.0|4.6.0| 45 | 46 | 47 | ## Potential downside 48 | 49 | N/A 50 | 51 | ## Impact on existing code 52 | 53 | No actual changes to code. The SDL Core project will be able to take the MOBILE_API.XML file from the RPC spec git repo directly though. 54 | 55 | ## Alternatives considered 56 | N/A 57 | 58 | [sdl-workflow]: ../assets/proposals/0068-idea_to_implementation/sdl_workflow.png 59 | -------------------------------------------------------------------------------- /proposals/0076-Support-For-Additional-Languages.md: -------------------------------------------------------------------------------- 1 | # Support for Additional Languages 2 | 3 | * Proposal: [SDL-0076](0076-Support-For-Additional-Languages.md) 4 | * Author: [Scott Betts](https://github.com/Toyota-Sbetts) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core / iOS / Android / RPC] 7 | 8 | ## Introduction 9 | 10 | This proposal introduces additional languages for support by SDL. 11 | 12 | ## Motivation 13 | 14 | To support Toyota's global roll out plan for SDL, additional languages need to be added to the list of supported languages. 15 | 16 | ## Proposed Solution 17 | 18 | We should add the following to both the HMI and Mobile API. 19 | 20 | ```xml 21 | 22 | English - Middle East 23 | 24 | 25 | Hebrew - Israel 26 | 27 | 28 | Romanian - Romania 29 | 30 | 31 | Ukrainian - Ukraine 32 | 33 | 34 | Indonesian - Indonesia 35 | 36 | 37 | Vietnamese - Vietnam 38 | 39 | 40 | Malay - Malaysia 41 | 42 | 43 | Hindi - India 44 | 45 | ``` 46 | 47 | ## Potential downsides 48 | 49 | This further expands the already large enumeration of language support. As additional language support is necessary this list will continue to grow. 50 | 51 | ## Impacts on existing code 52 | 53 | This proposal will require changes to SDL Core, both SDKs and the Mobile and HMI APIs. 54 | 55 | ## Alternatives considered 56 | 57 | If the current proposal for locale support [#179](https://github.com/smartdevicelink/sdl_evolution/issues/179) is passed, this proposal is unnecessary. 58 | -------------------------------------------------------------------------------- /proposals/0096-deliver-build-configuration.md: -------------------------------------------------------------------------------- 1 | # Deliver build configuration 2 | 3 | * Proposal: [SDL-0096](0096-deliver-build-configuration.md) 4 | * Author: [Alexander Kutsan](https://github.com/LuxoftAKutsan) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core] 7 | 8 | ## Introduction 9 | 10 | Add text file with information about SDL build configuration as part of SDL delivery. 11 | 12 | ## Motivation 13 | 14 | After installation of SDL (`make install`) there are couple of files besides SDL binary: 15 | 16 | - audio.8bit.wav 17 | - libPolicy.so 18 | - mycert.pem 19 | - sample_policy_manager.py 20 | - smartDeviceLink.ini 21 | - hmi_capabilities.json 22 | - libUtils.a 23 | - mykey.pem 24 | - sdl_preloaded_pt.json 25 | - start.sh 26 | - libappenders.so 27 | - log4cxx.properties 28 | - plugins 29 | - smartDeviceLinkCore 30 | 31 | 32 | Only these files (except 3rd party libraries) are required for SDL testing. 33 | But there is no information about flags that were used for SDL compiling. 34 | And there is no way to find out this information from delivered files 35 | 36 | Because of that automated scripts should be manually configured for each build options of SDL. 37 | Adding information about build options will add possibility to find out what SDL build type is used 38 | and automatically modify some test steps during script execution. 39 | 40 | SDL build flags that affect SDL behaviour : 41 | - EXTENDED_POLICY (regulates policy flow) 42 | - REMOTE_CONTROL (switch on/off remote control functionality) 43 | - BUILD_BT_SUPPORT (switch on/off Bluetooth support) 44 | - BUILD_USB_SUPPORT (switch on/off USB support) 45 | - ENABLE_SECURITY (switch on/off security support) 46 | - EXTENDED_MEDIA_MODE (switch on/off additional media features) 47 | - TELEMETRY_MONITOR (share information about CPU/MEM usage and time consumptions for RPC processing) 48 | - HMI (used hmi type: Dbus or web HMI) 49 | 50 | Some of these flags are not supported, but exist, and may affect SDL behavior. 51 | 52 | 53 | ## Proposed solution 54 | Solution is to create text file `build_options.txt` in format: 55 | 56 | ```ini 57 | // description of build option 58 | BUILD_OPTION:TYPE=BUILD_OPTION_VALUE 59 | 60 | // description of build option 2 61 | BUILD_OPTION2:TYPE=BUILD_OPTION2_VALUE 62 | ... 63 | ``` 64 | Syntax is the same as in CMakeCache.txt. 65 | 66 | 67 | ## Potential downsides 68 | 69 | N/A 70 | 71 | ## Impact on existing code 72 | 73 | It should impact only configuration files, no SDL behavior and no SDL code should be changed. 74 | 75 | ## Alternatives considered 76 | 77 | Copy CMakeCache.txt to bin folder during `make install`, but CMakeCache.txt contains a lot of redundant information. 78 | -------------------------------------------------------------------------------- /proposals/0112-ios-serial-rpc-notifications.md: -------------------------------------------------------------------------------- 1 | # SDL iOS Move RPC Notifications to a Serial Background Queue 2 | 3 | * Proposal: [SDL-0112](0112-ios-serial-rpc-notifications.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted with Revisions** 6 | * Impacted Platforms: iOS 7 | 8 | ## Introduction 9 | 10 | This proposal seeks to move iOS RPC notifications from being sent on the main thread to a serial background queue. 11 | 12 | ## Motivation 13 | 14 | Currently, RPC `NSNotification`s which are used for RPC responses and notifications, use the main thread to notify SDL and the developer of their arrival. This results in most of SDL running on the main thread as the developer will generally do all of their logic in the thread which the RPC is returned on. This isn't a huge issue unless many RPCs are being returned simultaneously or the UI thread is doing a lot of work. Unfortunately, this is exactly what is happening during many video streaming situations. 15 | 16 | ## Proposed solution 17 | 18 | This proposal ensures that RPC reception is entirely off the main thread, this should improve speed, especially in resource constrained conditions such as video streaming (which must often run on the main thread) because it can run on a separate CPU core. 19 | 20 | `SDLNotificationDispatcher` creates a new property with a concurrent queue: 21 | 22 | ```objc 23 | _rpcResponseQueue = dispatch_queue_create("com.sdl.rpcNotificationQueue", DISPATCH_QUEUE_SERIAL); 24 | ``` 25 | 26 | Posting of notifications changes from: 27 | 28 | ```objc 29 | dispatch_async(dispatch_get_main_queue(), ^{ 30 | ``` 31 | 32 | to: 33 | 34 | ```objc 35 | dispatch_async(_rpcResponseQueue, ^{ 36 | ``` 37 | 38 | ## Potential downsides 39 | 40 | 1. If there is code that previously assumed to run on the main thread, it no longer will and that code will have to manually change queues back to the main queue for that code (e.g. UI code). 41 | 42 | ## Impact on existing code 43 | 44 | The rest of the SDL library continues to run without significant alteration, just with a significant speed up. Some UI lockscreen code that previously was always automatically run on the main thread has to be manually moved there. Nothing within this proposal requires a minor or major version change. 45 | 46 | ## Alternatives considered 47 | 48 | 1. Move the responses to a background concurrent queue instead of a serial queue. This was the original proposal. It would offer additional performance benefits, but at too great a risk to out of order events that must be serialized – such as audio pass thru notifications. 49 | -------------------------------------------------------------------------------- /proposals/0118-video-background-string.md: -------------------------------------------------------------------------------- 1 | # Video Streaming Backgrounded String 2 | 3 | * Proposal: [SDL-0118](0118-video-background-string.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted with Revisions** 6 | * Impacted Platforms: iOS, Android 7 | 8 | ## Introduction 9 | 10 | Display a string of text on the head unit screen when the app leaves the foreground. 11 | 12 | ## Motivation 13 | 14 | This was originally discussed in [SDL-0033](https://github.com/smartdevicelink/sdl_evolution/issues/103) but put on hold at the time. When a video streaming `NAVIGATION` or `PROJECTION` app enters the background on the phone, the video stream stops sending data due to background limitations. On current iOS devices as the device is entering the background, it sends a few frames of pure black. Instead we should send a black screen with some white text telling the driver why their stream stopped. 15 | 16 | ## Proposed solution 17 | 18 | The proposed solution is to display a black screen with white text saying: 19 | 20 | > "`` must be open on the phone in order to work. When it is safe to do so, open `` on phone." 21 | 22 | An alternate text is available if the above is too lengthy to fit on the screen: 23 | 24 | > "When it is safe to do so, open `` on phone" 25 | 26 | ## Potential downsides 27 | 28 | Driver distraction is an issue, but a purely black screen is considered to very confusing to the user. 29 | 30 | ## Impact on existing code 31 | 32 | This should be a minor version change, as no API changes are needed. 33 | 34 | ## Alternatives considered 35 | 36 | 1. Use IAP messaging to reopen the app when the user interacts with the head unit screen. The app can only go into the backgound because of the user interacting with the phone while they are in the car, and they may not know they need to re-open the navigation / projection app manually to have it work. By bringing it into the foreground automatically, this would be much easier for the driver. Unfortunately, it would require changes to both Core and IAP code. 37 | 38 | 2. A different string is possible. 39 | -------------------------------------------------------------------------------- /proposals/0120-GetSystemTime.md: -------------------------------------------------------------------------------- 1 | # GetSystemTime RPC 2 | 3 | * Proposal: [SDL-0120](0120-GetSystemTime.md) 4 | * Author: [Aleksandr Stasiuk](https://github.com/AStasiuk) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core / RPC] 7 | 8 | ## Introduction 9 | 10 | This proposal is about adding a new RPC GetSystemTime in order for SDL Core to get accurate system time information which is utilized by the TLS handshake mechanism. 11 | 12 | 13 | ## Motivation 14 | 15 | Head units can make use of TLS handshake mechanism for security reasons to ensure the connected applications are authentic. This becomes necessary for projection experiences (such as Mobile Navigation) where the app has complete control over the content it displays. To facilitate such security mechanisms SDL Core will need to be provided with accurate time information. Today, SDL Core can get the time information by querying the platform OS which may or may not be accurate. 16 | This proposal provides a solution to this problem by having SDL Core request the system for time information. The system would then be responsible for providing accurate time related information. 17 | 18 | 19 | ## Proposed solution 20 | 21 | 22 | The solution proposes adding a new RPC between SDL and HMI called `GetSystemTime`. This RPC allows SDL Core to query the HMI for the accurate system time. 23 | 24 | SDL Core must send the `GetSystemTime` RPC to HMI for obtaining the system time during the Security TLS Handshake. 25 | 26 | The expectation is that HMI will provide the accurate system time with the GetSystemTime response. 27 | 28 | ## Additions to HMI_API 29 | 30 | GetSystemTime request\response 31 | 32 | ```xml 33 | 34 | 35 | Request from SDL to HMI to obtain current UTC time. 36 | 37 | 38 | 39 | Current UTC system time 40 | 41 | 42 | ``` 43 | OnSystemTimeReady notification 44 | 45 | ```xml 46 | 47 | 48 | HMI must notify SDL about readiness to provide system time. 49 | 50 | ``` 51 | 52 | ## Potential downsides 53 | 54 | N/A 55 | 56 | ## Impact on existing code 57 | 58 | Requires changes on SDL core, and HMI_API. 59 | 60 | Would require a minor version change. 61 | 62 | ## Alternatives considered 63 | 64 | The alternative would be to use the platform provided time which is the existing solution. 65 | -------------------------------------------------------------------------------- /proposals/0125-atf-videostreaming-full-support.md: -------------------------------------------------------------------------------- 1 | # ATF Video streaming support 2 | 3 | * Proposal: [SDL-0125](0125-atf-videostreaming-full-support.md) 4 | * Author: [Alexander Kutsan](https://github.com/LuxoftAKutsan) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core] 7 | 8 | ## Introduction 9 | 10 | Video streaming is a major feature of SDL. 11 | Currently it should be tested manually for each release. 12 | Testing of video streaming is rather complicated and expensive, and there is big probability of human mistakes during testing. 13 | 14 | Currently ATF is able to stream data from mobile side, but not able to handle streaming from HMI side, and to check data is received and not corrupted. 15 | 16 | ATF should provide ability to cover mentioned use cases related to video streaming. 17 | 18 | ## Motivation 19 | 20 | Full video streaming feature support will provide ability to cover mentioned streaming use cases with automated tests and reduce efforts for manual testing. 21 | 22 | Tests related to video streaming will be included into smoke SDL test cases and could be performed on each pull request. 23 | 24 | Automatization of testing of video streaming use cases could reduce time consumption for testing video streaming. 25 | 26 | In addition ATF will provide ability to create tests for complicated use cases like send requests, notifications, etc during streaming. 27 | 28 | ## Proposed solution 29 | 30 | ATF should support reading data from pipe/socket and save it to file system. 31 | List of provided APIs to test script: 32 | 33 | #### ListenStreaming 34 | 35 | **Parameters** : 36 | - Streaming source (pipe or socket) 37 | - Count of bytes for event call : event with custom callback will be called after streaming some amount of bytes 38 | 39 | **Return value** : 40 | - Event that will be triggered on each "*count of bytes*" received or on closing port\pipe. 41 | Event callback should provide access to file with received data, count of received bytes and root cause of event. 42 | 43 | 44 | ## Potential downsides 45 | 46 | N/A 47 | 48 | ## Impact on existing code 49 | 50 | Add additional components to ATF project, add additional API to ATF Facade. 51 | After implementation scripts that test videostreaming could be extended. 52 | 53 | ## Alternatives considered 54 | 55 | Do not test video streaming with automated test framework. 56 | -------------------------------------------------------------------------------- /proposals/0128-atf-script-runner.md: -------------------------------------------------------------------------------- 1 | # ATF Script Runner 2 | 3 | * Proposal: [SDL-0128](0128-atf-script-runner.md) 4 | * Author: [Dmytro Boltovskyi](https://github.com/dboltovskyi) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core] 7 | 8 | ## Introduction 9 | 10 | ATF is a great tool for both developers and testers that helps to test SDL functionality. 11 | But it lacks a powerful test script runner. 12 | 13 | ## Motivation 14 | 15 | Currently ATF is unable to: 16 | 17 | - run multiple test scripts 18 | - run test script in parallel 19 | - create test reports in standard format 20 | 21 | The purpose of this proposal is to develop extended script runner as part of ATF package. 22 | 23 | ## Proposed solution 24 | 25 | Script runner is a command line tool with the following features: 26 | 27 | - An option to run single test script 28 | - An option to run batch of test scripts 29 | - An option to run test set 30 | - Possibility to run test scripts in parallel (in separate threads) 31 | - Ability to create reports with logs collected in a format used by continuous integration system 32 | 33 | Input data could be defined as a set of input parameters and options. 34 | 35 | ![Component relations](../assets/proposals/0128-atf-script-runner/atf_script_runner_diagram.png) 36 | 37 | Functionality of 'SDL Watchdog' and 'ATF Facade' is described in other proposals. 38 | 39 | ## Potential downsides 40 | 41 | N/A 42 | 43 | ## Impact on existing code 44 | 45 | No impact on existing code is observed since script runner is a new module. 46 | 47 | ## Alternatives considered 48 | 49 | Refactoring of existing runner (bash script), but it will negotiate current big base of test artifacts. 50 | -------------------------------------------------------------------------------- /proposals/0129-ios-additional-apptypes.md: -------------------------------------------------------------------------------- 1 | # Add Additional AppHMIType Array iOS 2 | 3 | * Proposal: [SDL-0129](0129-ios-additional-apptypes.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted with Revisions** 6 | * Impacted Platforms: iOS 7 | 8 | ## Introduction 9 | 10 | This proposal adds a new optional parameter to `SDLLifecycleConfiguration` allowing for more than one AppHMITypes when using `SDLManager`. 11 | 12 | ## Motivation 13 | 14 | Due to an oversight, only one AppHMITypes is currently possible for any app using the `SDLManager` framework. However, in the `RegisterAppInterface`, AppHMITypes is an array, and multiple AppHMITypes are allowed. We should expand the API to support that situation. 15 | 16 | ## Proposed solution 17 | 18 | The proposed solution is very simple, in addition to the current optional `appType` to add the following: 19 | 20 | ```objc 21 | @property (strong, nonatomic, nullable) NSArray *additionalHMITypes; 22 | ``` 23 | 24 | When not set, only the primary app type will be used. When set, the `additionalHMITypes` array will be concatenated with the primary app type and all the values sent over in the `RegisterAppInterface`. 25 | 26 | ## Potential downsides 27 | 28 | It might be slightly confusing to developers how to set their `AppHMIType` by having two separate properties. 29 | 30 | ## Impact on existing code 31 | 32 | This would be a minor version change. 33 | 34 | ## Alternatives considered 35 | 36 | 1. We could remove the existing `appType` and only use an array, but this would be a major version change. 37 | -------------------------------------------------------------------------------- /proposals/0132-Change_ATF_test_reports_folder_structure.md: -------------------------------------------------------------------------------- 1 | # Change ATF test reports folder structure 2 | 3 | * Proposal: [SDL-0132](0132-Change_ATF_test_reports_folder_structure.md) 4 | * Author: [Irina Getmanets](https://github.com/GetmanetsIrina) 5 | * Status: **Accepted** 6 | * Impacted Platforms: Core 7 | 8 | ## Introduction 9 | 10 | Main output of ATF is test reports. 11 | ATF provide such reports: 12 | * Console logs - name of test cases with execution status FAILED/PASSED. 13 | * SDL logs - SDL log received by ATF via telnet logger. 14 | * Transport logs - all received and sent data from/to SDL. Transport log can have default view - messages on protocol level (except binaries) and full view - log will be expanded with packages: streamings, service messages, heartbeat, json files. 15 | * Detailed report - all expected and sent massages related to test cases with expected and actual result.Also contains info about test cases: name, time, sequence, status, duration. 16 | 17 | This proposal is about creating clear and useful structure of test scripts reports. 18 | 19 | ## Motivation 20 | 21 | Create more convenient reports structure, less nested. Running multiple test scripts should not override old reports. Structure of reports should be clear, so you can easily search for a certain report. 22 | 23 | ## Proposed solution 24 | 25 | The solution is to create new structure: 26 | ``` 27 | TestingReports 28 | -> ScriptName_YYYYMMDDHHMMSS 29 | -> ATF 30 | -> SDL 31 | ``` 32 | Subfolder ATF will contain ATF logs and report. 33 | Subfolder SDL will contain SDL logs. 34 | 35 | ## Potential downsides 36 | 37 | n/a 38 | 39 | ## Impact on existing code 40 | 41 | Impact on ATF reporting functionality. 42 | 43 | ## Alternatives considered 44 | 45 | Leave as is. 46 | -------------------------------------------------------------------------------- /proposals/0145-distraction-notification-after-registration.md: -------------------------------------------------------------------------------- 1 | # Driver Distraction Notification Upon Registration 2 | 3 | * Proposal: [SDL-0145](0145-distraction-notification-after-registration.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core] 7 | 8 | ## Introduction 9 | 10 | This document proposes that Core send an additional Driver Distraction Notification just after registration to ensure that the mobile device knows the distraction status at all times. 11 | 12 | ## Motivation 13 | 14 | Currently, apps have no way of knowing the driver distraction status until it changes. This forces the mobile libraries to initially consider it locked. 15 | 16 | ## Proposed solution 17 | 18 | The proposed solution is very simple. Immediately after an app registers, Core should send that app an `OnDriverDistraction`. We already do this with `OnHMIStatus`, for example. 19 | 20 | ## Potential downsides 21 | 22 | The author can think of no potential downsides. 23 | 24 | ## Impact on existing code 25 | 26 | This should not require even a minor version change. 27 | 28 | ## Alternatives considered 29 | 30 | 1. It could happen at a different time, for example, after an app reaches its first non-`NONE` HMI state. 31 | -------------------------------------------------------------------------------- /proposals/0146-updating-mobile-version-dependencies.md: -------------------------------------------------------------------------------- 1 | # Updating Mobile Version Dependencies 2 | 3 | * Proposal: [SDL-0146](0146-updating-mobile-version-dependencies.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer), [Joey Grover](https://github.com/joeygrover) 5 | * Status: **Accepted with Revisions** 6 | * Impacted Platforms: [Meta] 7 | 8 | ## Introduction 9 | 10 | This proposal sets a meta requirement on when mobile platform dependencies should be updated. 11 | 12 | ## Motivation 13 | 14 | We've updated the base iOS platform dependency version in the past and it was agreed that we need a stricter set of rules on when platform dependency updates should occur. 15 | 16 | ## Proposed solution 17 | 18 | The proposed solution is the following guideline: 19 | 20 | * If a platform dependency update would cover 90% of users, a proposal may be entered with reasons for the update and the proposal considered. If a proposed version would not cover 90% of users, no proposal may be entered. 21 | 22 | The [Android platform versions website](https://developer.android.com/about/dashboards/index.html) and [iOS platform versions website](https://developer.apple.com/support/app-store/) are to be used for making these determinations. 23 | 24 | ### Android 25 | So, for example, if a proposal is entered and accepted, this guideline means that v4.4 (94.3% usage) is the highest version permitted to be the base Android platform version. 26 | 27 | ### iOS 28 | This guideline means that iOS 10 is the highest version permitted to be the base iOS platform version (iOS 10 has greater than 93% usage). 29 | 30 | ## Potential downsides 31 | 32 | None the authors can see. 33 | 34 | ## Impact on existing code 35 | 36 | This is a meta change, no code will be impacted. 37 | 38 | ## Alternatives considered 39 | 40 | Various other methods could be used to determine version updates. 41 | -------------------------------------------------------------------------------- /proposals/0151-imagefieldname-for-secondary-image.md: -------------------------------------------------------------------------------- 1 | # ImageFieldName for SecondaryImage 2 | 3 | * Proposal: [SDL-0151](0151-imagefieldname-for-secondary-image.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core / iOS / Android / RPC] 7 | 8 | ## Introduction 9 | 10 | Adds a `secondaryGraphic` enum value to the `ImageFieldName` enum to enable app developers to know if a secondary graphic is on screen. 11 | 12 | ## Motivation 13 | 14 | Currently, there is no way for an app developer to know if there is a secondary graphic on the current template. This requires developers to always set the `secondaryGraphic` in Show if they have one, or to check and guess based on the template. This may result in the app developer always uploading the secondary image and attempting to set it. 15 | 16 | ## Proposed solution 17 | 18 | The proposed solution is to add the enum value `secondaryGraphic` to the `ImageFieldName` enum, and to send it within `ImageField` / `DisplayCapabilities` whenever a display capabilities is sent for a layout that contains a secondary graphic. 19 | 20 | ## Potential downsides 21 | 22 | The author could not identify any downsides. 23 | 24 | ## Impact on existing code 25 | 26 | This would be a minor version change. Additions may have to be made to HMI to support this. This will help the iOS Show Manager better support automatically doing the right thing based on the current display layout. 27 | 28 | ## Alternatives considered 29 | 30 | No alternatives were identified. 31 | -------------------------------------------------------------------------------- /proposals/0159-Static-SDL-Icon-Names-Enum.md: -------------------------------------------------------------------------------- 1 | # Static SDL Icon Names Enum 2 | 3 | * Proposal: [SDL-0159](0159-Static-SDL-Icon-Names-Enum.mdd) 4 | * Author: [Nicole Yarroch](https://github.com/NicoleYarroch) 5 | * Status: **Accepted** 6 | * Impacted Platforms: iOS, Android 7 | 8 | ## Introduction 9 | 10 | This proposal is to create a strongly typed enum for static SDL icon names. This will make it easier for developers to use these icons in their SDL apps. 11 | 12 | 13 | ## Motivation 14 | 15 | Developers have access to a set of static on-board icons on SDL Core, however the developer must know the exact name of the icon in order to use it in a RPC. In addition, the static icons are obscurely named with hexadecimal values, which makes it hard to figure out which icon is currently being used. 16 | 17 | ## Proposed solution 18 | 19 | 1. Create a new enum called `SDLStaticIconName`. The hexidecimal name for the static icon will be the string constant. 20 | 21 | ```objc 22 | // SDLStaticIconName.h 23 | typedef SDLEnum SDLStaticIconName SDL_SWIFT_ENUM; 24 | extern SDLStaticIconName const SDLStaticImageNamePhoneDevice; 25 | ``` 26 | ```objc 27 | // SDLStaticIconName.h 28 | SDLStaticIconName const SDLStaticIconName PhoneDevice = @“0x03”; 29 | ``` 30 | 31 | 2. Add a convenience initializer to the `SDLImage` class that takes the new enum. 32 | 33 | ```objc 34 | [SDLImage initWithStaticIconName:(SDLStaticIconName)] 35 | ``` 36 | 37 | ## Potential downsides 38 | 39 | A manufacturer might choose to support a subset of the 100+ static icons. If a static icon is not supported, an empty icon will be used used in its place. Developers will still need to send a RPC using the static icon and then check the response from SDL Core to see if the static icon is actually available. 40 | 41 | ## Impact on existing code 42 | 43 | This is a minor version change. A new public enum, `SDLStaticIconName`, will be available, and the `SDLImage` class will get a new convenience initializer. 44 | 45 | ## Alternatives considered 46 | 47 | None. 48 | -------------------------------------------------------------------------------- /proposals/0161-remove-sdl-cordova.md: -------------------------------------------------------------------------------- 1 | # Remove SmartDeviceLink Cordova plugin 2 | 3 | * Proposal: [SDL-0161](0161-remove-sdl-cordova.md) 4 | * Author: [Bilal Alsharifi](https://github.com/bilal-alsharifi) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [iOS / Android] 7 | 8 | ## Introduction 9 | 10 | The [SmartDeviceLink Cordova plugin](https://github.com/smartdevicelink/sdl_cordova_android) was developed to enable web-based apps to access vehicle data via SDL. When the plugin was written, Apache Cordova Framework was more popular among mobile developers. In recent years, however, Cordova started to become less popular. Moreover, SmartDeviceLink Cordova plugin hasn't had any updates in the last three years. 11 | 12 | 13 | ## Motivation 14 | 15 | Apache Cordova is a framework that lets developers write mobile applications using HTML, CSS, and JavaScript inside a native app container. Mobile developers were excited about it because of its simplicity. However, in recent years, it started to lose popularity in favor of other hybrid development frameworks. The SmartDeviceLink Cordova plugin was written to allow developers to write SDL enabled apps utilizing Cordova to communicate with Sdl Core. 16 | According to [AppBrain](http://www.appbrain.com/stats/libraries/details/phonegap/phonegap-apache-cordova), Cordova takes up only 6.94% apps and 1.20% installs of the Android apps market. Also, Cordova apps account for only 3.41% of new Android apps. 17 | 18 | 19 | ## Proposed solution 20 | The [SmartDeviceLink Cordova plugin](https://github.com/smartdevicelink/sdl_cordova_android) will be removed because it has not been updated in the last three years, and because of lack of community interest. 21 | 22 | 23 | ## Potential downsides 24 | 25 | Some mobile developers may be still using the SmartDeviceLink Cordova plugin to develop SDL apps. Those developers will have to start using SDL iOS and SDL Android to develop SDL enabled apps. However, because Corodva is not very used currently, this is not going to have a big impact. 26 | 27 | 28 | ## Impact on existing code 29 | 30 | The proposal suggests that we remove the [SmartDeviceLink Cordova plugin](https://github.com/smartdevicelink/sdl_cordova_android) which will affect any developer who is still using the plugin. SDL iOS and SDL Android should be used by developers for creating SDL apps. 31 | 32 | ## Alternatives considered 33 | 34 | Even though Apache Corodva Framework is not as popular nowadays, an alternative solution is to keep supporting and updating SmartDeviceLink Cordova plugin because some mobile developers are still using the plugin. 35 | -------------------------------------------------------------------------------- /proposals/0164-modernize-ubuntu-support.md: -------------------------------------------------------------------------------- 1 | # Modernize Ubuntu Support 2 | 3 | * Proposal: [SDL-0164](0164-modernize-ubuntu-support.md) 4 | * Author: [Jacob Keeler](https://github.com/jacobkeeler) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core] 7 | 8 | ## Introduction 9 | 10 | This proposal is to add official support of the latest Ubuntu LTS Release (version 18.04 as of April 26th, 2018) to SDL Core, as well as update the minimum supported version from Ubuntu 14.04 to Ubuntu 16.04 as the former reaches the end of its support lifetime. 11 | 12 | ## Motivation 13 | 14 | Official support of Ubuntu 14.04 will be dropped in one year (April 2019), meaning that the default build platform of SDL Core should be updated to account for this. In addition, a new LTS release of Ubuntu was very recently released, and SDL Core can be updated to officially support this version. 15 | 16 | ## Proposed solution 17 | 18 | The proposed solution to this is to test SDL Core on the new Ubuntu 18.04 LTS release to verify it fully supports this release. Any compatibility issues with this release found in testing will be fixed before as part of this proposal. Upon resolving these compatibility issues, all relevant documentation will be updated to include 16.04 as the minimum supported version and 18.04 as the recommended version. 19 | 20 | ## Potential downsides 21 | 22 | As always, upgrading the supported version has its own support costs, but considering that the current default OS (Ubuntu 14.04) is close to being no longer supported, this is likely a worthwhile jump. 23 | 24 | ## Impact on existing code 25 | 26 | The exact changes to the codebase needed must be determined after testing the current project on the new release of Ubuntu. Some of known compatibility issues are shown in [this PR](https://github.com/smartdevicelink/sdl_core/pull/924/files) which was originally meant to add support for Ubuntu 16.04 LTS. 27 | 28 | The SDL Core [README](https://github.com/smartdevicelink/sdl_core/blob/master/README.md) and [FAQ](https://github.com/smartdevicelink/sdl_core_guides/blob/master/docs/FAQ/index.md) also need to be updated with these version changes. 29 | 30 | ## Alternatives considered 31 | 32 | - Just updating the minimum supported version, adding support for Ubuntu 18.04 LTS at a later time. 33 | -------------------------------------------------------------------------------- /proposals/0169-initial-and-hint-text-for-keyboard.md: -------------------------------------------------------------------------------- 1 | # Arguments initialText and hintText for SDL Keyboard 2 | 3 | * Proposal: [SDL-0169](0169-initial-and-hint-text-for-keyboard.md) 4 | * Author: [MarekForys](https://github.com/mforys) (TomTom) 5 | * Status: **Returned for Revisions** 6 | * Impacted Platforms: [Core, Android, iOS] 7 | 8 | 9 | ## Introduction 10 | 11 | SDL Keyboard may be started with argument initialText, but it's displayed in iOS version as blue hint/description in the input field of SDL Keyboard. In the case of Android this initial text is never displayed. 12 | 13 | There should be a possibility of using initial and hint/description text as well. 14 | All available documentation is here: [SDLPerformInteraction](https://smartdevicelink.com/en/docs/iOS/master/Classes/SDLPerformInteraction/). 15 | 16 | 17 | ## Motivation 18 | 19 | Sometimes a user wants to continue to input text which is already partially filled in within their device's input text field, then after connecting to SDL the text field is totally empty. Another scenario is when some text is filled into SDL keyboard then we press Enter and we launch Keyboard again. Input text field is blank and previously entered text is gone. 20 | 21 | 22 | ## Proposed solution 23 | 24 | When creating an SDL Keyboard we should give two text arguments: initialText and hintText. Argument hintText should just replace current initialText. Flow for initialText must be developed in all submodules from scratch. 25 | 26 | So the perfect description of these arguments should be like this: 27 | 28 | * initialText - text which is prefilled to input text field of Keyboard 29 | * hintText - text which is a hint or description of the content which should be entered into input text field 30 | 31 | Possible usage should be like: 32 | 33 | ```objc 34 | - (instancetype)initWithInitialChunks:(nullable NSArray *)initialChunks initialText:(NSString *)initialText hintText:(NSString *)hintText 35 | ``` 36 | 37 | ## Potential downsides 38 | 39 | None. 40 | 41 | 42 | ## Impact on existing code 43 | 44 | All apps which already use initialText argument will be fixed, unless initialText is not used as a regular hint. 45 | 46 | 47 | ## Alternatives considered 48 | 49 | The easier option is to just use the current parameter initialText and use it as a text which should be prefilled into Text Field of the Keyboard. 50 | Although it seems the interesting feature of a hint/descriptive welcome text (dark blue), which is already implemented can be lost then. 51 | So it's better to use both arguments. 52 | -------------------------------------------------------------------------------- /proposals/0174-deprecate-rpc-request-factory.md: -------------------------------------------------------------------------------- 1 | # Deprecate RPCRequestFactory 2 | 3 | * Proposal: [SDL-0174](0174-deprecate-rpc-request-factory.md) 4 | * Author: [Bilal Alsharifi](https://github.com/bilal-alsharifi) 5 | * Status: **Accepted with Revisions** 6 | * Impacted Platforms: [Android] 7 | 8 | ## Introduction 9 | 10 | This proposal is to deprecate the `RPCRequestFactory` class and start using RPC constructors directly to create new RPC instances. 11 | 12 | ## Motivation 13 | 14 | Currently, the RPC factory methods are hidden inside one big class called `RPCRequestFactory`. A better approach to handle RPC instantiation is to create constructors in each RPC class when necessary. This will make it more natural for the developers to create new RPC instances. Moreover, this will make it easier to maintain the SDL library because everything related to a specific RPC will be within the same class. A [similar solution](https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0020-ios-remove-rpcrequestfactory.md) was proposed and applied to the iOS library. 15 | 16 | 17 | ## Proposed solution 18 | 19 | The `RPCRequestFactory` will be deprecated and the factory methods will be replaced by constructors in the RPC classes. 20 | 21 | ## Potential downsides 22 | 23 | Developers who are currently using the public methods in `RPCRequestFactory` class will have to modify their code and start using the RPC constructors to create RPC instances. 24 | 25 | ## Impact on existing code 26 | 27 | This will be a minor change. The `RPCRequestFactory` will be flagged as deprecated in the next minor release to let developers know that its public methods may not be available in future releases. Developers will then have to use RPC constructors directly after the next major release. 28 | 29 | ## Alternatives considered 30 | 31 | The alternative solution that was considered is to keep the `RPCRequestFactory` class. However, this is not considered a good solution because the factory methods are not very visible to the developers in that way. It will also keep the RPC factory methods in one big class instead of spreading them out to the PRC classes where they should naturally be. 32 | 33 | 34 | 35 | -------------------------------------------------------------------------------- /proposals/0185-remove-hello-sdl-ios.md: -------------------------------------------------------------------------------- 1 | # Remove Hello SDL Mobile Repositories 2 | 3 | * Proposal: [SDL-0185](0185-remove-hello-sdl-ios.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted with Revisions** 6 | * Impacted Platforms: [iOS, Android] 7 | 8 | ## Introduction 9 | 10 | With the additions of the Objective-C and Swift example apps within the sdl_ios repository, the hello_sdl_ios example app has become unnecessary. We should match the iOS library on Android as well by removing the hello_sdl_android and moving example apps into the sdl_android repository. 11 | 12 | ## Motivation 13 | 14 | The hello_sdl_ios app has been unsupported in favor of the example apps within the sdl_ios repository. Having the apps in the sdl_ios repo and deleting the hello_sdl_ios app has several advantages: 15 | 16 | * The apps can be run to test changes to the sdl_ios library as those changes are made, with hello_sdl, the library must be imported, and recompiled from scratch to test changes to the library. This simplifies and speeds up development. 17 | * When going to a new branch or an older version of the library, the example app updated for that branch or version of the library is ready to go. 18 | * Developers can use the `pod try` command to quickly try the SDL example apps instead of finding a separate repository, cloning, installing dependencies, and then running the app. 19 | * We have people on the SDL slack pointing developers to the unsupported hello_sdl app, which brings confusion because the app is not fully up to date. There is only one repository to point people towards, and an easy command line command to try an example app. 20 | 21 | Android should match the iOS library and move the example apps into its main repository as well. 22 | 23 | ## Proposed solution 24 | 25 | On iOS, simply delete the hello_sdl_ios repository and point people to the sdl_ios repository. On Android, delete the hello_sdl_android repository, move the example app into the sdl_android repository, and point the old repository to the main repository. 26 | 27 | ## Potential downsides 28 | 29 | There are no downsides. 30 | 31 | ## Impact on existing code 32 | 33 | No impact on the libraries. An unsupported example library will be deleted. 34 | 35 | ## Alternatives considered 36 | 37 | No alternatives were identified. -------------------------------------------------------------------------------- /proposals/0186-template-titles.md: -------------------------------------------------------------------------------- 1 | # Template Titles 2 | 3 | * Proposal: [SDL-0186](0186-template-titles.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted with Revisions** 6 | * Impacted Platforms: [Core / iOS / Android / RPC] 7 | 8 | ## Introduction 9 | 10 | Templates should have the capability to have a title to help orient the user in the UI. 11 | 12 | ## Motivation 13 | 14 | Basic templates have nothing to orient the user to where they are in the UI. A title allows the user to know what the content of the current screen is showing them. For example, a weather app may have several template screens: the current weather, an hourly view, and a daily view. Without titles, the user must rely on knowing the button they've pressed and their intuition to know what screen they are on. 15 | 16 | ## Proposed solution 17 | 18 | ```xml 19 | 20 | 21 | Updates the persistent display. Supported fields depend on display capabilities 22 | 23 | ... 24 | 25 | 26 | 27 | 28 | The title of the new template that will be displayed. 29 | How this will be displayed is dependent on the OEM design and implementation of the template. 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | The template title field; applies to "Show" 40 | 41 | 42 | ``` 43 | 44 | ## Potential downsides 45 | 46 | No downsides were identified. 47 | 48 | ## Impact on existing code 49 | 50 | This is a minor version change on all platforms. 51 | 52 | ## Alternatives considered 53 | 54 | No alternatives were considered. 55 | -------------------------------------------------------------------------------- /proposals/0191-retry-failed-file-uploads.md: -------------------------------------------------------------------------------- 1 | # Retry Failed File Uploads 2 | * Proposal: [SDL-0191](0191-retry-failed-file-uploads.md) 3 | * Author: [Nicole Yarroch](https://github.com/NicoleYarroch) 4 | * Status: **Accepted with Revisions** 5 | * Impacted Platforms: [iOS, Android] 6 | 7 | ## Introduction 8 | This proposal is to implement retry attempts when a file upload fails. 9 | 10 | ## Motivation 11 | Currently the file manager only attempts to upload a file to Core once. If a developer wants to retry sending a failed upload, it is up to them to implement this feature. This can make it frustrating to handle transport failures. 12 | 13 | ## Proposed solution 14 | 1. Create a new configuration, `SDLFileManagerConfiguration`, to be added to the `SDLConfiguration` class. The new configuration will allow the developer to set the number of retry attempts for two types of files: `SDLArtwork` files, which are images to be displayed in the UI, and general files, which can be any non-artwork files such audio and text files. A default configuration will set the retry attempts to 1. Setting the retry attempts to 0 will disable the retry feature. 15 | 16 | ```objc 17 | // SDLFileManagerConfiguration.h 18 | @property (strong, nonatomic, nullable) NSNumber *artworkRetryCount; 19 | @property (strong, nonatomic, nullable) NSNumber *fileRetryCount; 20 | 21 | + (instancetype)defaultConfiguration; 22 | - (instancetype)initWithArtworkRetryCount:(UInt8)artworkRetryCount fileRetryCount:(UInt8)fileRetryCount; 23 | ``` 24 | 25 | 2. Add the retry logic to the existing `SDLFileManager` class. When the file fails to upload, the manager will check the number of failed upload attempts for the file's name, and retry the upload if allowed. A dictionary will be used to track the failed upload count for files. The dictionary will be emptied when the app is disconnected from Core. 26 | 27 | ```objc 28 | // SDLFileManager.m 29 | @property (strong, nonatomic) NSMutableDictionary *> *failedFileUploadsCount; 30 | ``` 31 | 32 | ## Potential downsides 33 | None. 34 | 35 | ## Impact on existing code 36 | This is a minor version change. A new configuration, `SDLFileManagerConfiguration`, will be added to the `SDLConfiguration` class. The `SDLFileManager`'s `sdl_uploadFile:completionHandler:` method will be updated to handle retry attempts. 37 | 38 | ## Alternatives considered 39 | 1. Add a retry attempt count to the `SDLFileManager`'s `uploadFiles:` and `uploadArtworks:` methods. The developer would have to set the desired retry attempt count every time they upload a file, which could be tedious. This would also require deprecating 6 existing methods and replacing them with new methods that include the retry attempts parameter. 40 | -------------------------------------------------------------------------------- /proposals/0193-update-android-min-sdk.md: -------------------------------------------------------------------------------- 1 | # Update SDL-Android minimum SDK 2 | 3 | * Proposal: [SDL-0193](0193-update-android-min-sdk.md) 4 | * Author: [Brett M.](https://github.com/brettywhite) 5 | * Status: **Accepted** 6 | * Impacted Platforms: Android 7 | 8 | ## Introduction 9 | 10 | With the progression of SDL Android as a library, it has become necessary to update the minimum supported SDK from 8. The proposed minimum SDK will be API 16, Jelly Bean. 11 | 12 | ## Motivation 13 | 14 | Maintaining backwards compatibility is often a double edged sword. While it is important for SDL libraries to be able to be used on the widest array of phones possible, maintaining old APIs and not being able to use newer ones comes at a cost of additional time and a reduction in forward movement. This allows the use of newer libraries, such as `ConstraintLayout` that are not usable in the current SDL Android library because its' minimum SDK is higher than our own. 15 | 16 | ## Proposed solution 17 | 18 | The proposed solution is to raise the minimum SDK from 8 to 16. According to [Android's Dashboard](https://developer.android.com/about/dashboards/), 99.5% of all Android devices run SDK 16 or newer. 19 | 20 | Because this is a major change, it would need to be implemented in SDL Android's 5.0 release. 21 | 22 | The current minimum SDK 8 was released in 2010. SDK 16 was released in 2012. In comparison, the current SDL iOS's minimum deployment target is 8, which was released in 2014. Both SDK 16 and iOS deployment target 8 have similar numbers in terms of devices not supported (<= 0.5%). 23 | 24 | Having our minimum at 16 will help with managers as well. It will allow a more streamlined audio streaming manager, for example, by not having to create any *coding tricks* (read: messy code) to make it work with lower unsupported APIs. 25 | 26 | A much larger reason, however, is for testing. The library should, as it is being updated, test against all supported SDKs. It is difficult to find phones that go back to SDK 8, adding to testing cost, time and complexity - for very little in return in terms of additional devices being supported. 27 | 28 | ## Potential downsides 29 | 30 | We potentially leave out 0.5% of Android devices. However, many developers now only write apps with higher minimum SDKs meaning that this is a non-issue. As stated earlier, it is a major version change and should target SDL Android v5.0. This means there will be a wait before developers can enjoy the newer minimum. 31 | 32 | ## Impact on existing code 33 | 34 | Change the min SDK in the `build.gradle` file. 35 | ## Alternatives considered 36 | 37 | Raising the min SDK to a number higher than 8 but less than 16 was considered. However, distribution on those versions are on average less than 0.5% of the entire Android ecosystem. 38 | -------------------------------------------------------------------------------- /proposals/0197-setmediaclocktimer-initializers.md: -------------------------------------------------------------------------------- 1 | # Update SetMediaClockTimer Initializers 2 | 3 | * Proposal: [SDL-0197](0197-setmediaclocktimer-initializers.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [iOS, Android] 7 | 8 | ## Introduction 9 | This proposal is to update the SDL mobile library `SetMediaClockTimer` class with initializers to assist developers with creating RPCs for each of the use cases of that RPC. 10 | 11 | ## Motivation 12 | Initializers can be very helpful for developers to create correct code. The `SetMediaClockTimer` RPC has several very specific use cases, however the initializers do not assist developers in creating those use cases correctly. 13 | 14 | ## Proposed solution 15 | The proposed solution is to add initializers to the RPC classes to assist developers in creating `SetMediaClockTimer` objects conforming to each of the use-cases. 16 | 17 | ```objc 18 | // Will return nil if startTime is greater than endTime 19 | + (instancetype)countUpWithStartTime:(NSTimeInterval)startTime endTime:(NSTimeInterval)endTime audioIndicator:(nullable SDLAudioStreamingIndicator)audioIndicator; 20 | + (instancetype)countUpWithStartTime:(SDLStartTime *)startTime endTime:(SDLStartTime *)endTime audioIndicator:(nullable SDLAudioStreamingIndicator)audioIndicator; 21 | 22 | // Will return nil if startTime is lesser than endTime 23 | + (instancetype)countDownWithStartTime:(SDLStartTime *)startTime endTime:(SDLStartTime *)endTime audioIndicator:(nullable SDLAudioStreamingIndicator)audioIndicator; 24 | + (instancetype)countDownWithStartTime:(SDLStartTime *)startTime endTime:(SDLStartTime *)endTime audioIndicator:(nullable SDLAudioStreamingIndicator)audioIndicator; 25 | 26 | + (instancetype)pauseWithAudioIndicator:(nullable SDLAudioStreamingIndicator)audioIndicator; 27 | + (instancetype)resumeWithAudioIndicator:(nullable SDLAudioStreamingIndicator)audioIndicator; 28 | + (instancetype)clearWithAudioIndicator:(nullable SDLAudioStreamingIndicator)audioIndicator; 29 | ``` 30 | 31 | Changes similar to these should be made on Android. Additionally, old initializers should be deprecated. 32 | 33 | ## Potential downsides 34 | There are no downsides. This adds additional initializers, but doesn't remove any functionality. 35 | 36 | ## Impact on existing code 37 | This is a minor version change on the mobile platforms. 38 | 39 | ## Alternatives considered 40 | No alternatives have been considered. 41 | -------------------------------------------------------------------------------- /proposals/0205-Avoid_custom_button_subscription_when_HMI_does_not_support.md: -------------------------------------------------------------------------------- 1 | 2 | # Avoid Custom button subscription in case HMI incompatibility 3 | 4 | * Proposal: [SDL-0205](0205-Avoid_custom_button_subscription_when_HMI_does_not_support.md) 5 | * Author: [Getmanets Irina](https://github.com/GetmanetsIrina) 6 | * Status: **Accepted with Revisions** 7 | * Impacted Platforms: [Core] 8 | 9 | ## Introduction 10 | 11 | In case HMI does not support `CUSTOM_BUTTON`, SDL should not try to subscribe an application to it. 12 | 13 | ## Motivation 14 | 15 | SDL does not check hmi_capabilities before subscription to `CUSTOM_BUTTON`, so it tries to subscribe each registered application to `CUSTOM_BUTTON` even if it is unsupported by HMI. 16 | 17 | SDL should check hmi_capabilities and subscribe application to `CUSTOM_BUTTON` if it is **supported by HMI only**. 18 | 19 | ## Proposed solution 20 | 21 | SDL should check hmi_capabilities for `CUSTOM_BUTTON` by the start and save support state for `CUSTOM_BUTTON` internally. 22 | On the app registration, SDL should check the saved support state for `CUSTOM_BUTTON`. 23 | 24 | In case `CUSTOM_BUTTON` is supported by hmi_capabilities: 25 | SDL should send `Buttons.SubscribeButtons(CUSTOM_BUTTON)` to HMI and wait for a response. 26 | 27 | 28 | In case `CUSTOM_BUTTON` is not supported by hmi_capabilities: 29 | SDL should **not** send `Buttons.SubscribeButtons(CUSTOM_BUTTON)` to HMI. 30 | 31 | If HMI supports `CUSTOM_BUTTON`, it should be in the `Buttons[capabilities]` section of `hmi_capabilities.json`: 32 | 33 | ``` 34 | "Buttons": { 35 | "capabilities": [ 36 | ..., 37 | { 38 | "name": "CUSTOM_BUTTON", 39 | "shortPressAvailable": true, 40 | "longPressAvailable": true, 41 | "upDownAvailable": true 42 | } 43 | ] 44 | } 45 | ``` 46 | 47 | 48 | If HMI supports `CUSTOM_BUTTON`, response to `Buttons.GetCapabilities` should contain following structure: 49 | 50 | ``` 51 | "capabilities": [ 52 | ..., 53 | { 54 | "name": "CUSTOM_BUTTON", 55 | "shortPressAvailable": true, 56 | "longPressAvailable": true, 57 | "upDownAvailable": true 58 | } 59 | ] 60 | ``` 61 | 62 | 63 | `Buttons.GetCapabilities` request has higher priority than `hmi_capabilities.json`. 64 | 65 | The existing rules for applying HMI capabilities won't be changed. If a mobile application sends `SubscribeButton (buttonName = CUSTOM_BUTTON)` and `CUSTOM_BUTTON` and they are not supported by HMI (absent in the `hmi_capabilities.json`), then SDL will respond with an `UNSUPPORTED_RESOURCE` result code. 66 | 67 | ## Potential downsides 68 | 69 | N/A 70 | 71 | ## Impact on existing code 72 | 73 | SDL core will need to be updated. 74 | 75 | ## Alternatives considered 76 | 77 | N/A 78 | -------------------------------------------------------------------------------- /proposals/0209-static-icon-capability.md: -------------------------------------------------------------------------------- 1 | # Static Icon Capability 2 | 3 | * Proposal: [SDL-0209](0209-static-icon-capability.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted with Revisions** 6 | * Impacted Platforms: [RPC / HMI] 7 | 8 | ## Introduction 9 | 10 | Add a capability for app developers to know if static icons are available on a connected head unit. 11 | 12 | ## Motivation 13 | 14 | Currently, any app developer building their app with static icons has no way to know if a connected head unit supports those static icons. We should add a capability for the developer to know if static icons exist or not. 15 | 16 | ## Proposed solution 17 | 18 | The proposed solution is to add a new RPC boolean describing whether or not static icons are supported. This capability therefore means to the app developer that they can assume that all static icons are supported. 19 | 20 | ### Mobile HMI Changes 21 | ```xml 22 | 23 | 24 | 25 | 26 | ``` 27 | 28 | ## Potential downsides 29 | 30 | In this proposal there is no room for granular support of some icons but not others. 31 | 32 | If a future set of icons were ever enabled, however, then we could add a new capability, e.g. `staticIconsSetV2Supported`. 33 | 34 | ## Impact on existing code 35 | 36 | This would be a minor version change to all affected platforms. 37 | 38 | ## Alternatives considered 39 | 40 | 1. We could change the name of the parameter to `staticIconsSetV1Supported` for additional future-proofing. 41 | -------------------------------------------------------------------------------- /proposals/0212-add-ability-to-reuse-a-syncfilename-for-a-putfile.md: -------------------------------------------------------------------------------- 1 | # Add Ability to Reuse a SyncFileName for a PutFile 2 | 3 | * Proposal: [SDL-0212](0212-add-ability-to-reuse-a-syncfilename-for-a-putfile.md) 4 | * Author: [Nicole Yarroch](https://github.com/NicoleYarroch) 5 | * Status: **Accepted with Revisions** 6 | * Impacted Platforms: [Core] 7 | 8 | ## Introduction 9 | 10 | Currently, when a developer tries to reuse the same `syncFileName` for a `PutFile` with image data, the HMI is not updated to show the new image. This is due to Core only sending a notification to the HMI when the `PutFile` is a system file. To remedy this issue, Core needs to send a notification to the HMI when it receives any type of `PutFile`. 11 | 12 | ## Motivation 13 | 14 | Reusing a `syncFileName` for a `PutFile` is useful for developers because they do not have to come up with unique names for dynamically updated images, and it saves them the extra step of having to delete the old data as the new data will overwrite the old. 15 | 16 | ## Proposed solution 17 | 18 | When Core receives a `PutFile` it should send a notification to the HMI that a new `PutFile` was received. Currently an `OnPutFile` notification is only sent when the `PutFile` is a `systemFile`. Two new parameters will be added to the `OnPutFile` notification: `isSystemFile`, which will preserve the current task Core performs for system files, and `appID` which will be used to update the correct app's UI. 19 | 20 | ``` 21 | 22 | 23 | Notification sent to HMI when mobile sends file 24 | 25 | 26 | ... 27 | 28 | /* New parameters */ 29 | 30 | 31 | Indicates if the file is meant to be passed thru core to elsewhere on the system. If true the system will pass the data thru as it arrives to a predetermined area outside of core. 32 | 33 | 34 | 35 | 36 | 37 | Unique (during ignition cycle) id of the application. To be used in all RPCs sent by both HU system and SDL 38 | 39 | 40 | 41 | ``` 42 | 43 | ## Potential downsides 44 | 45 | No potential downsides. 46 | 47 | ## Impact on existing code 48 | 49 | This is a minor version change. 50 | 51 | ## Alternatives considered 52 | 53 | No alternatives considered. 54 | 55 | -------------------------------------------------------------------------------- /proposals/0222-rair-system-software-name.md: -------------------------------------------------------------------------------- 1 | # Add System Software Name parameter to Register App Interface Response 2 | 3 | * Proposal: [SDL-0222](0222-rair-system-software-name.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted with Revisions** 6 | * Impacted Platforms: [Core / iOS / Android / RPC] 7 | 8 | ## Introduction 9 | 10 | This proposal adds a new Register App Interface Response parameter called `systemSoftwareName` that pairs with the existing `systemSoftwareVersion` and `sdlVersion`. 11 | 12 | ## Motivation 13 | 14 | Currently, information about the connected head unit is limited to the `vehicleType` (i.e. make / model / modelYear), the version of the system running, and the version of SDL that the system is running. This provides everything necessary for analytics and identifying a particular head unit. However, it's not as easy or as good as it could be. If an OEM has multiple head unit types, then the app developer would need to differentiate those based on a table of available Makes, Models, and Trims. This could be made easier by simply identifying the name of the system. 15 | 16 | ## Proposed solution 17 | 18 | Add a new parameter to the `RegisterAppInterfaceResponse` called `systemSoftwareName` like so: 19 | 20 | ```xml 21 | 22 | 23 | 24 | The name of the head unit software, to be paired with the version in `systemSoftwareVersion`. 25 | 26 | 27 | ``` 28 | 29 | ## Potential downsides 30 | 31 | No downsides have been identified. 32 | 33 | ## Impact on existing code 34 | 35 | This is a minor version change for all affected platforms. 36 | 37 | ## Alternatives considered 38 | 39 | 1. We can continue with the current system, but the ability for app developers to identify which head units are connected is hampered by the need to match Make / Model / Trim to head unit types. 40 | -------------------------------------------------------------------------------- /proposals/0223-media-service-image.md: -------------------------------------------------------------------------------- 1 | # Add Currently Playing Media Image to MediaServiceData 2 | 3 | * Proposal: [SDL-0223](0223-media-service-image.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core / iOS / Java Suite / RPC] 7 | 8 | ## Introduction 9 | This proposal adds an image for the currently playing media item to the media app service. 10 | 11 | ## Motivation 12 | An image for the media service was originally proposed but unfortunately somehow got lost in the app services shuffle and didn't make it into the RPC spec v5.1.0. We should add in the currently playing item's image to the service. 13 | 14 | ## Proposed solution 15 | Very simply, we add a new parameter to the `MediaServiceData` RPC struct: 16 | 17 | ```xml 18 | 19 | 20 | 21 | 22 | 23 | Music: The album art of the current track 24 | Podcast: The podcast or chapter artwork of the current podcast episode 25 | Audiobook: The book or chapter artwork of the current audiobook 26 | 27 | 28 | 29 | ``` 30 | 31 | ## Potential downsides 32 | No downsides were identified 33 | 34 | ## Impact on existing code 35 | This is a minor version change to the RPC spec, Core, and proxy libraries. 36 | 37 | ## Alternatives considered 38 | No alternatives were identified. 39 | -------------------------------------------------------------------------------- /proposals/0229-sdl-server-version-tracking.md: -------------------------------------------------------------------------------- 1 | # SDL Server Version Tracking 2 | 3 | * Proposal: [SDL-0229](0229-sdl-server-version-tracking.md) 4 | * Author: [Nick Schwab](https://github.com/nickschwab) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [SDL Server, SHAID] 7 | 8 | ## Introduction 9 | 10 | The goal of this proposal is enable the SDLC and Project Maintainer to track which SDL Server versions are in use by OEMs. 11 | 12 | ## Motivation 13 | 14 | With the knowledge of which SDL Server versions are being used by OEM partners, the Project Maintainer can provide faster, more accurate product support. Additionally, tracking SDL Server versions will allow the SDLC to better understand the frequency of which OEMs update their SDL Server installations, and identify deprecation opportunities with minimal OEM impact. 15 | 16 | ## Proposed solution 17 | 18 | The proposed solution is to add a new HTTP header attribute to each API call to SHAID from SDL Server containing the version of the SDL Server installation. 19 | 20 | ### SDL Server Changes 21 | 22 | A new HTTP header attribute sent with each API call to SHAID. 23 | 24 | `sdl_server_version`: String representing the SDL Server version, e.g. "2.6.1" 25 | 26 | ### SHAID Changes 27 | 28 | Add a new column to SHAID's `request_log` database table to store the incoming SDL Server version header string. Write this value to the database asynchronously when an API request is fulfilled. 29 | 30 | New column: 31 | 32 | `sdl_server_version`: VARCHAR(12) DEFAULT NULL 33 | 34 | 35 | ## Impact on Existing Code 36 | The proposed solution has minimal impact on existing code, as some header attributes are already sent in API requests from SDL Server to SHAID for authentication purposes and SHAID's existing API request logging already occurs in an asynchronous fashion. There would be no direct impact to API calls or user interfaces. 37 | 38 | ## Potential Downsides 39 | 40 | * Nominal increase in database storage consumption 41 | 42 | ## Alternatives Considered 43 | 44 | ### SDL Server Version Setting 45 | This alternative would be to add an "SDL Server Version" dropdown to the "Company Info" tab on [smartdevicelink.com](https://smartdevicelink.com). Using this dropdown, OEMs could select which version of SDL Server they are using and the selection would be saved to their company's profile. 46 | 47 | Downsides to this alternative include: 48 | 49 | * Requires direct action by an OEM rather than an automated approach 50 | * OEM users may select the wrong version 51 | * OEM users may not update the selection after they upgrade their SDL Server installation 52 | * Requires supporting UI, UX, and API changes 53 | -------------------------------------------------------------------------------- /proposals/0232-add_pushing_buffer_support_to_audio_stream_manager.md: -------------------------------------------------------------------------------- 1 | # Add Pushing Buffer Support to AudioStreamManager 2 | 3 | * Proposal: [SDL-0232](0232-add_pushing_buffer_support_to_audio_stream_manager.md) 4 | * Author: [Bilal Alsharifi](https://github.com/bilal-alsharifi) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Java Suite / iOS] 7 | 8 | ## Introduction 9 | 10 | This proposal is to add the ability to push an audio buffer to the `AudioStreamManager` so it supports playing audio from raw data in addition to supporting playing audio from actual files. 11 | 12 | ## Motivation 13 | 14 | Currently, `AudioStreamManager` in Java Suite supports pushing audio source only from actual files. It doesn't support pushing an audio buffer. iOS, however, has that ability but not through the `AudioManager`. It can do that through the `StreamManager`: 15 | 16 | ```objc 17 | [self.sdlManager.streamManager sendAudioData:audioData] 18 | ``` 19 | 20 | It will be useful to make `AudioStreamManager` in Java Suite support playing audio from a buffer as some apps may have the audio generated as a buffer rather than stored in an actual file. Also, adding a new API to `AudioStreamManager` in iOS to play audio from a buffer will make playing audio in iOS less confusing to developers. Moreover, that will make iOS and Java Suite APIs more aligned. 21 | 22 | 23 | ## Proposed solution 24 | 25 | New API will be added to `AudioStreamManager` to support playing audio from a buffer: 26 | 27 | ### Java Suite 28 | ```java 29 | public class AudioStreamManager extends BaseAudioStreamManager { 30 | ... 31 | public void pushBuffer(ByteBuffer data, final CompletionListener completionListener); 32 | } 33 | ``` 34 | 35 | ### iOS 36 | ```objc 37 | @implementation SDLAudioStreamManager 38 | ... 39 | - (void)pushWithData:(NSData *)data; 40 | @end 41 | ``` 42 | 43 | ## Potential downsides 44 | 45 | The iOS library will end up having two possible APIs for playing audio from a buffer. One being in the `StreamManager` and one in the `AudioStreamManager`. 46 | 47 | ## Impact on existing code 48 | 49 | This would be a minor version update to all libraries implementing `AudioStreamManger`, namely, the iOS, and Java Suite APIs. 50 | 51 | ## Alternatives considered 52 | 53 | The alternative solution that was considered is to keep the current iOS APIs and just add new API to Java Suite but that will make the two libraries less aligned. 54 | 55 | -------------------------------------------------------------------------------- /proposals/0239-media-service-data-progress-bar-improvements.md: -------------------------------------------------------------------------------- 1 | # Media Service Data Progress Bar Improvements 2 | 3 | * Proposal: [SDL-0239](0239-media-service-data-progress-bar-improvements.md) 4 | * Author: [Jack Byrne](https://github.com/jacklivio) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core / iOS / Java Suite / RPC] 7 | 8 | ## Introduction 9 | 10 | This proposal adds new parameters to the media service data to allow the app consumers to know the playback status and progress of a selected track. 11 | 12 | ## Motivation 13 | 14 | The motivation for the proposal came from creating an implementation of a media type app service consumer that displays the progress bar data from an active media service provider. 15 | 16 | Currently app service providers can notify consumers about a track's playback progress via `trackPlaybackProgress` and `trackPlaybackDuration`. However, if an app consumer wants to display progress using these parameters, it would require the app provider to send an `OnAppServiceData` RPC with updated information every second. 17 | 18 | Also, there are no parameters in the media service data struct that tell the consumer if the track is playing, paused, or stopped. 19 | 20 | ## Proposed solution 21 | 1. Add a new parameter `updateMode` to the media service data struct. The use of this parameter follows the usage of `updateMode` in the `SetMediaClockTimer` RPC. 22 | 2. Add a new parameter `audioStreamingIndicator` to the media service data struct. The use of this parameter follows the usage of `audioStreamingIndicator` in the `SetMediaClockTimer` RPC. 23 | 24 | ```xml 25 | 26 | 27 | 28 | 29 | 30 | Enumeration to control the media clock. 31 | 32 | 33 | 34 | 35 | Enumeration for the indicator icon on a play/pause button. see AudioStreamingIndicator. 36 | 37 | 38 | 39 | ``` 40 | 41 | ## Potential downsides 42 | No downsides were identified 43 | 44 | ## Impact on existing code 45 | This is a minor version change to the RPC spec, Core, and proxy libraries. 46 | 47 | ## Alternatives considered 48 | No alternatives were identified. 49 | -------------------------------------------------------------------------------- /proposals/0244-setmediaclocktimer-custom-playback-rates.md: -------------------------------------------------------------------------------- 1 | # Custom Playback Rates for SetMediaClockTimer 2 | 3 | * Proposal: [SDL-0244](0244-setmediaclocktimer-custom-playback-rates.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core / iOS / Java Suite / HMI / RPC] 7 | 8 | ## Introduction 9 | This proposal adds the ability for a media app to set the media playback timer and bar to advance at a custom rate like 125% speed. 10 | 11 | ## Motivation 12 | Many non-music audio apps, such as podcast and audiobook apps, have features that allow users to playback the audio at a rate that is not 1.0. For example, a user can play a podcast at 125% speed. Competitors like Carplay have this ability built in, and without this ability, the playback timer gets out of sync every few seconds, requiring the developer to manually update the timer. 13 | 14 | ## Proposed solution 15 | The proposed solution is to add a new `SetMediaClockTimer` RPC parameter called `countRate` that can be set to modify the speed at which the playback timer advances. 16 | 17 | ### MOBILE_API 18 | ```xml 19 | 20 | Sets the initial media clock value and automatic update method. 21 | 22 | 23 | 24 | 25 | The value of this parameter is the amount that the media clock timer will advance per 1.0 seconds of real time. 26 | 27 | Values less than 1.0 will therefore advance the timer slower than real-time, while values greater than 1.0 will advance the timer faster than real-time. 28 | 29 | e.g. If this parameter is set to `0.5`, the timer will advance one second per two seconds real-time, or at 50% speed. If this parameter is set to `2.0`, the timer will advance two seconds per one second real-time, or at 200% speed. 30 | 31 | 32 | 33 | ``` 34 | 35 | ### HMI_API 36 | The changes are identical to the above but applied to `UI.SetMediaClockTimer`. 37 | 38 | ## Potential downsides 39 | 1. There is no way for a head unit to declare its support for this feature, so any head unit implementing this version of SDL Core will _have_ to support this feature. 40 | 41 | ## Impact on existing code 42 | This will be a minor version change. 43 | 44 | The app library screen manager will need an update if it supports a high-level API for the `SetMediaClockTimer` at that point. It doesn't currently however, so I cannot provide those changes in this proposal. 45 | 46 | ## Alternatives considered 47 | No alternatives were considered. 48 | -------------------------------------------------------------------------------- /proposals/0252-Aligning-HMI-and-MOBILE-API-for-pcmStreamCapabilities.md: -------------------------------------------------------------------------------- 1 | # Aligning HMI and MOBILE API for pcmStreamCapabilities 2 | 3 | * Proposal: [SDL-0252](0252-Aligning-HMI-and-MOBILE-API-for-pcmStreamCapabilities.md) 4 | * Author: [Heather Williams](https://github.com/hwilli88/), [Ankur Tiwari](https://github.com/atiwari9/) 5 | * Status: **Accepted with Revisions** 6 | * Impacted Platforms: [Core / HMI] 7 | 8 | ## Introduction 9 | 10 | This proposal is to add param `pcmStreamCapabilities` in `UI.GetCapabilities` response in HMI API. 11 | 12 | ## Motivation 13 | 14 | `pcmStreamCapabilities` was introduced by PR: https://github.com/smartdevicelink/sdl_core/pull/472 , but this PR missed adding implementation for HMI API. `pcmStreamCapabilities` is present in MOBILE API, but HMI has no way to provide this information to SDL Core. As a result, SDL Core always uses default `hmi_capabilities.json` for `pcmStreamCapabilities` in `RAI` response to MOBILE. 15 | 16 | ## Proposed Solution 17 | 18 | Align HMI API with MOBILE API for `pcmStreamCapabilities` by adding this param to HMI API in `UI.GetCapabilities` response. 19 | 20 | ```xml 21 | 22 | 23 | Information about the capabilities of the display: its type, text field supported, etc. See DisplayCapabilities. 24 | 25 | 26 | 27 | 28 | Must be returned if the platform supports on-screen SoftButtons. 29 | 30 | 31 | Specifies the HMI’s capabilities. See HMICapabilities. 32 | 33 | 34 | Specifies system capabilities. See SystemCapabilities 35 | 36 | + 37 | 38 | ``` 39 | 40 | ## Potential downsides 41 | 42 | Author is not aware of any downsides to proposed solution. 43 | 44 | ## Impact on existing code 45 | 46 | * HMI needs to be updated to provide `pcmStreamCapabilities`. 47 | * SDL Core needs to be updated to read `pcmStreamCapabilities` from HMI in `UI.GetCapabilities` response. 48 | 49 | ## Alternatives considered 50 | 51 | * None 52 | -------------------------------------------------------------------------------- /proposals/0260-Deprecate-HMI-RPC-OnFindApplications.md: -------------------------------------------------------------------------------- 1 | # Deprecate HMI RPC OnFindApplications 2 | 3 | * Proposal: [SDL-0260](0260-Deprecate-HMI-RPC-OnFindApplications.md) 4 | * Author: [Jack Byrne](hhttps://github.com/JackLivio) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core] 7 | 8 | ## Introduction 9 | 10 | This proposal is for deprecating and removing an unusable HMI RPC `OnFindApplications`. 11 | 12 | ## Motivation 13 | 14 | There is an HMI RPC `OnFindApplications` which has no implemented logic and sending the notification to Core will cause no action. 15 | 16 | The Run function for the RPC only has a comment "TODO" 17 | 18 | ``` 19 | void OnFindApplications::Run() { 20 | LOG4CXX_AUTO_TRACE(logger_); 21 | 22 | // TODO(PV): add UpdateAppsOnDevice to ApplicationManager 23 | } 24 | ``` 25 | 26 | The author has failed to find possible ways to implement this RPC to make it useful without creating redundancies. 27 | 28 | HMI RPC `UpdateAppList` already communicates app information to the HMI automatically when apps are registered. 29 | 30 | HMI RPC `OnStartDeviceDiscovery` will tell Core's transport adapters (ie Bluetooth) to search paired devices and discover SDL Apps. 31 | 32 | ## Proposed solution 33 | 34 | The author proposes to mark the RPC `OnFindApplications` as deprecated in the HMI API in the next release, and then remove the RPC from the HMI API and Core in the following release. 35 | 36 | ``` 37 | 38 | - This method must be invoked by HMI to get list of registered apps. 39 | + DEPRECATED - This RPC is not implemented 40 | 41 | The name and ID of the device the list of registered applications is required for. 42 | 43 | 44 | ``` 45 | 46 | ## Potential downsides 47 | 48 | An OEM could have implemented this RPC on their own in which case the Author requests that OEMs reviewing this proposal note if they are using this RPC. 49 | 50 | ## Impact on existing code 51 | 52 | Only impacts SDL Core. OnFindApplications should be removed from the HMI API and the OnFindApplications supporting command files should be removed from the repository. 53 | 54 | ## Alternatives considered 55 | 56 | Find a possible implementation for this RPC. 57 | 58 | ``` 59 | -------------------------------------------------------------------------------- /proposals/0265-Remove-Duplicate-Parameter-HMI-RPC-OnPutFile.md: -------------------------------------------------------------------------------- 1 | # Remove duplicate parameter FileName from HMI RPC BasicCommunication.OnPutFile 2 | 3 | * Proposal: [SDL-0265](0265-Remove-Duplicate-Parameter-HMI-RPC-OnPutFile.md) 4 | * Author: [Shobhit Adlakha](https://github.com/ShobhitAd) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core] 7 | 8 | ## Introduction 9 | 10 | This proposal is for removing the duplicate parameter `FileName` from the HMI RPC `BasicCommunication.OnPutFile`. 11 | 12 | ## Motivation 13 | 14 | Currently, there are two file name parameters in the HMI API for the `BasicCommunication.OnPutFile` notification: 15 | 16 | ```xml 17 | 18 | File reference name. 19 | 20 | ``` 21 | 22 | and 23 | 24 | ```xml 25 | 26 | File reference name. 27 | 28 | ``` 29 | 30 | SDL Core, ATF and the HMI only use the `syncFileName` parameter for the implementation/testing of `BasicCommunication.OnPutFile`. The `FileName` parameter is not used. 31 | 32 | ## Proposed solution 33 | 34 | The author proposes removing the `FileName` parameter for the RPC `BasicCommunication.OnPutFile` from the [HMI_API.xml](https://github.com/smartdevicelink/sdl_core/blob/master/src/components/interfaces/HMI_API.xml) file in SDL Core. 35 | 36 | ```xml 37 | 38 | ... 39 | - 40 | - File reference name. 41 | - 42 | 43 | 44 | File reference name. 45 | 46 | ... 47 | 48 | ``` 49 | 50 | Since the parameter is unused, it can be removed from the API without any implementation changes in Core, ATF or the HMI. 51 | 52 | ## Potential downsides 53 | 54 | An OEM may have implemented the `FileName` parameter for `BasicCommunication.OnPutFile` on their own. If that is the case, the author requests that OEMs reviewing this proposal note that they are using this parameter. 55 | 56 | ## Impact on existing code 57 | 58 | This proposal only impacts SDL Core. The `FileName` parameter for `BasicCommunication.OnPutFile` should be removed from the HMI API in SDL Core. 59 | 60 | ## Alternatives considered 61 | 62 | Find a possible use for the extra filename parameter in the notification. For example, have the `syncFileName` be the actual file name and the `FileName` be a string used by the HMI to map to the actual file name. 63 | -------------------------------------------------------------------------------- /proposals/0299-Avoid-Deadlock.md: -------------------------------------------------------------------------------- 1 | # Add a Mechanism to Avoid Deadlock 2 | 3 | * Proposal: [SDL-0299](0299-Avoid-Deadlock.md) 4 | * Author: [Yuki Shoda](https://github.com/Yuki-Shoda), [Akihiro Miyazaki (Nexty)](https://github.com/Akihiro-Miyazaki) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [ iOS ] 7 | 8 | ## Introduction 9 | This proposal is to avoid deadlock by adding a mechanism that stops Audio Streaming under certain conditions when the app on the mobile device side moves to BACKGROUND. 10 | 11 | ## Motivation 12 | When using SDL Core 4.5, and SDL iOS (v6.3.1 or later), a deadlock may occur when Audio Streaming is played while Video Streaming is stopped. 13 | Due to this support (https://github.com/smartdevicelink/sdl_ios/pull/1235/) in the current SDL iOS (v6.3.1 or later), Audio Streaming continues to play when the app on the mobile device side moves to BACKGROUND. 14 | For this reason (#1235), a deadlock may occur. 15 | To avoid the deadlock, it is desirable to add a mechanism where the negotiated RPC spec version is judged by the iOS library and stops Audio Streaming when the app on the mobile device side moves to BACKGROUND. 16 | 17 | ## Proposed solution 18 | The negotiated RPC spec version and the manufacturer name are checked by the iOS library, when the app on the mobile device side moves to BACKGROUND. If the negotiated RPC spec version is 4.5.1 (used in SDL Core v4.5.2) or older and the manufacturer name is not `Ford`, then Audio Streaming is stopped. 19 | 20 | ## Potential downsides 21 | None 22 | 23 | ## Impact on existing code 24 | This will be a bugfix/patch version change to the iOS Library. 25 | 26 | ## Alternatives considered 27 | - Update the modified SDL Core to head unit (HU) 28 | -> It will be difficult because updating the HU is not realistic. 29 | 30 | - Add an API, which sets whether to use Audio Streaming on the app side or not, to the library and supported by each app vendor 31 | -> Deadlock will still occur in unsupported apps because there is no way to enforce. 32 | -------------------------------------------------------------------------------- /proposals/0308-protocol-nak-reason.md: -------------------------------------------------------------------------------- 1 | # Add a Reason Parameter to All Protocol NAKs 2 | 3 | * Proposal: [SDL-0308](0308-protocol-nak-reason.md) 4 | * Author: [Joel Fischer](https://github.com/joeljfischer) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core / iOS / Java Suite / JavaScript Suite / Protocol] 7 | 8 | ## Introduction 9 | This proposal seeks to add a "reason" string parameter to all NAKs in the protocol spec. 10 | 11 | ## Motivation 12 | As a maintainer of an app library, it is often difficult to understand why Core has NAKed a protocol message. Most NAKs currently have a `rejectedParams` parameter, but in practice, this has not been enough information to determine why a NAK has occurred and properly alert the developer. In place of the `rejectedParams` parameter, the `RegisterSecondaryTransportNAK` has a `reason` parameter to describe the failure reason. This is a better approach and we should expand it to all NAK parameters. 13 | 14 | ## Proposed solution 15 | The proposed solution is to introduce a `reason` parameter into all protocol_spec NAK packets, and to update Core to provide strings for all known cases of NAKing a protocol spec request. 16 | 17 | The following would be the new parameter 18 | 19 | | Tag Name | Type | Introduced | Description | 20 | |----------|------|------------|-------------| 21 | | reason | string | x.x.x | Specify a string describing the reason of failure | 22 | 23 | The following messages would be affected: 24 | 25 | ### Control Service 26 | * Start Service NAK 27 | * End Service NAK 28 | 29 | ### Audio Service 30 | * Start Service NAK 31 | * End Service NAK 32 | 33 | ### Video Service 34 | * Start Service NAK 35 | * End Service NAK 36 | 37 | ## Potential downsides 38 | 1. This proposal adds a small amount of redundancy between the existing `rejectedParams` field and the new `reason` field. However, there isn't always a 1-1 tie between a send parameter and the rejection reason. Therefore I believe that the `reason` parameter will be a good addition. 39 | 2. This does bump the protocol version spec, which should be avoided as often as possible. However, this is only a minor version update and I believe that this proposal's utility is worth the update. 40 | 41 | ## Impact on existing code 42 | This would be a minor version change to the protocol spec, and therefore would affect Core and all mobile libraries with corresponding minor version changes. Core would also need to update in order to provide reason strings whenever a failure is occurring. 43 | 44 | ## Alternatives considered 45 | The author did not consider any alternatives. 46 | -------------------------------------------------------------------------------- /proposals/0312-ios-update-minimum-version-ios10.md: -------------------------------------------------------------------------------- 1 | # Update the Minimum Required iOS Version to 10.0 2 | * Proposal: [SDL-0312](0312-ios-update-minimum-version-ios10.md) 3 | * Author: [Joel Fischer](https://github.com/joeljfischer) 4 | * Status: **Accepted** 5 | * Impacted Platforms: [iOS] 6 | 7 | ## Introduction 8 | This proposal is to update the minimum supported iOS deployment version from iOS 8.0 to iOS 10.0. 9 | 10 | ## Motivation 11 | In September 2020, Xcode 12 will be released. In the current beta release notes, it's noted that Xcode 12 drops support for creating apps below iOS 9.0. We currently support down to iOS 8.0. Therefore, we will need to update our minimum supported version to at least iOS 9.0. 12 | 13 | ## Proposed solution 14 | The proposal is to move the minimum required deployment version to iOS 10.0. I chose this in order to be able to remove additional version checked code and to give us a larger buffer before another major version change is necessary to do this again. 15 | 16 | ### Code that can be removed at iOS 9.0 17 | * Workaround for a crash on iOS 8.0 when launching an app when not checking if an app is installed first. 18 | * Failure cases for haptic item locator which only works on iOS 9.0+. 19 | 20 | ### Code that can be removed at iOS 10.0 21 | * Disabling example app audio transcription code. 22 | * Workarounds for target queues not being available. 23 | * Disabling os_log. 24 | 25 | ### Additional reasons to move to iOS 10.0 26 | * Gives us a larger buffer before we need to do another major version change. 27 | 28 | ## Potential downsides 29 | 1. I was able to find one iOS partner app that currently supports iOS 9 (Sygic). 30 | 31 | ## Impact on existing code 32 | This will require a major version change to the iOS library because we are dropping support for some iOS devices. 33 | 34 | ## Alternatives considered 35 | 1. We could update our minimum version to iOS 9.0 instead. We would be unable to remove as much code as if we move to iOS 10.0, and we will be more likely to have to do another major version change to bump the minimum required version again. 36 | -------------------------------------------------------------------------------- /proposals/0328-modernize-ubuntu-support-v20.md: -------------------------------------------------------------------------------- 1 | # Modernize Ubuntu Support V20 LTS 2 | 3 | * Proposal: [SDL-0328](0328-modernize-ubuntu-support-v20.md) 4 | * Author: [Jack Byrne](https://github.com/JackLivio) 5 | * Status: **Accepted** 6 | * Impacted Platforms: [Core, ATF] 7 | 8 | ## Introduction 9 | 10 | This proposal would like to provide support for Ubuntu 20 LTS and bump the minimum required version of Ubuntu to Ubuntu 18 LTS. Currently Ubuntu 18 is the recommended platform and Ubuntu 16 is the minimum required version. 11 | 12 | These changes will mainly affect the build process for SDL Core and ATF. 13 | 14 | ## Motivation 15 | 16 | Ubuntu 16 will lose support on April 30, 2021, therefore it is important that we update the minimum required version for using SDL Core and related platforms that use a linux environment. 17 | 18 | This type of proposal needs to be entered every couple of years to keep up with new versions and retire older environments. 19 | 20 | ## Proposed solution 21 | 22 | The proposed solution is to make necessary updates for SDL Core and ATF to use Ubuntu 20, while maintaining compatibility with Ubuntu 18. 23 | 24 | The main updates will include resolving compiler issues and warnings from using the Ubuntu 20 LTS environment which includes GCC version 9.3. 25 | 26 | Currently Ubuntu 18 LTS uses GCC 7.5. 27 | 28 | An additional note is that Ubuntu 20 comes installed with only Python3 (not 2.7), but this should not be an issue as all of the support scripts used by SDL Core have been updated to use python3 in a previous release. 29 | 30 | 31 | ## Potential downsides 32 | 33 | Changing environments is bound to cause compiler and runtime issues that will require resources to fix. Switching to a newer Ubuntu version should be done earlier in a release cycle in order to find non-obvious issues over the course of the development cycle. 34 | 35 | ## Impact on existing code 36 | 37 | Updates may be needed to the build scripts used in SDL Core and ATF. Any runtime issues will need to be fixed. Runtime issues will be discovered via a full regression test run via ATF. 38 | 39 | SDL Core and related platform documentation must be updated to note support of Ubuntu 20. 40 | 41 | ## Alternatives considered 42 | 43 | - Only update the minimum version of Ubuntu to 18 LTS and do not add support for version 20. 44 | --------------------------------------------------------------------------------