Trying to perform a policy table update and am receiving the warning,"Incorrect delete from request type."

Logs claim that the policy table was successfully updated but when viewing sql db, changes are not present.

The display capabilities of the new layout should always be sent back to the application

I'm trying to get a demo up and running using SDL, Bluetooth, and Pandora on Android. I've got SDL core up and running on an Ubuntu laptop with these options enabled: EXTENDED_MEDIA_MODE, BUILD_BT_SUPPORT, and BUILD_USB_SUPPORT. I've tried connecting using the SDL helper app on Android, but it doesn't see the SDL over Bluetooth. Do I need to enable something different? How do I get this up and running using Bluetooth?

Is there a document describing how the putfile stream concept works using putFiles?

@stefanek22 @mrapitis

To have backward compatibility, the sequence of events runs as follows:

1. The mobile library sends a v1 style StartService packet
2. The HU sends a StartServiceACK packet with the highest version it supports
3. The mobile library starts sending packets with the correct negotiated version

The issue I believe could happen is that in (2), the HU doesn't necessarily send a v1 packet for it's StartServiceACK. If it sends a newer style (v2) packet for this control frame, there could be crashes. This would mean that mobile library backcompat is broken from v2+ to v1. It still works from v3 to v2 because the packet structure is the same.

So far we have "Integer" and "Float" in HMI_API.xml and MOBILE_API.xml

Are "Long" and "Double" allowed? The intention is to define 64-bit length values.

Are "Integer" and "Float" assumed to be definitions for 32-bit values?

In the Livio SDL Tester application, a Show message is automatically sent once the HMI is updated to HMI_FULL to display the initial text the user will see when the app is connected. This used to work fine in previous versions of the emulator, but the same JSON is now being rejected in the most recent version on github (3.8?).

Here's the JSON:

{
  "request":{
    "correlationID":102,
    "parameters":{
      "mainField3":" ",
      "alignment":"LEFT_ALIGNED",
      "mainField1":"Livio SDL Tester",
      "graphic":{
        "value":"App Icon",
        "imageType":"DYNAMIC"
      },
      "mainField2":"Send SDL Commands"
    },
    "name":"Show"
  }
}

Anybody see anything wrong in the JSON string? I'll keep experimenting and see if I can find what data is invalid.

Also, see attached screenshots:

I have libusb and aoa flags on, when I connect a USB device I get the following error message:

INFO  [19 Feb 2015 08:47:11,803][TransportManager] USB control transfer completed
INFO  [19 Feb 2015 08:47:11,803][TransportManager] AOA protocol version 2
INFO  [19 Feb 2015 08:47:11,803][TransportManager] USB control transfer completed
INFO  [19 Feb 2015 08:47:11,803][TransportManager] USB control transfer completed
INFO  [19 Feb 2015 08:47:11,803][TransportManager] USB control transfer completed
INFO  [19 Feb 2015 08:47:11,803][TransportManager] USB control transfer completed
INFO  [19 Feb 2015 08:47:11,803][TransportManager] USB control transfer completed
INFO  [19 Feb 2015 08:47:11,803][TransportManager] USB control transfer completed
INFO  [19 Feb 2015 08:47:11,803][TransportManager] USB control transfer completed
ERROR [19 Feb 2015 08:47:12,707][TransportManager] libusb_open failed: LIBUSB_ERROR_ACCESS

Hi, Guys.

The response of "RegisterAppInterface" shall indicate whether the app could be list on the Head Unit.

Are there any internal Error callbacks / Notifications from SDL Core to Head Unit such as

• JSON parsing(Proxy) errors
• App crash erros
• JSON request/response generating erros
• Transiting data corruption
  etc

Thanks a lot!

sdl with qt5 hmi and dbus adapter not work on ubuntu 12.04 X86_64, but seems to work on ubuntu 12.04 i686. sdl with web hmi work on ubuntu 12.04 x86_64.

seems dbus releated problem

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fdf700 (LWP 8378)]
0x00007ffff64ae9f9 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
(gdb) bt
#0  0x00007ffff64ae9f9 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#1  0x00007ffff64aef66 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#2  0x00007ffff64b347c in dbus_message_iter_open_container () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#3  0x00000000015a4084 in dbus::DBusAdapter::SetStructValue (this=0x1df4a80, iter=0x7ffff7fdd860, rules=0x1cacf00, structure=...)
    at /home/chenbd/github/sdl_core/src/components/dbus/src/dbus_adapter.cc:625
#4  0x00000000015a2ba0 in dbus::DBusAdapter::SetValue (this=0x1df4a80, iter=0x7ffff7fdd860, rules=0x1cacf00, param=...)
    at /home/chenbd/github/sdl_core/src/components/dbus/src/dbus_adapter.cc:521
#5  0x00000000015a3ade in dbus::DBusAdapter::SetArrayValue (this=0x1df4a80, iter=0x7ffff7fddec0, rules=0x1cacf20, param=...)
    at /home/chenbd/github/sdl_core/src/components/dbus/src/dbus_adapter.cc:602
#6  0x00000000015a2b74 in dbus::DBusAdapter::SetValue (this=0x1df4a80, iter=0x7ffff7fddec0, rules=0x1cacf20, param=...)
    at /home/chenbd/github/sdl_core/src/components/dbus/src/dbus_adapter.cc:515
#7  0x00000000015a2831 in dbus::DBusAdapter::SetOneArgument (this=0x1df4a80, iter=0x7ffff7fddec0, rules=0x1cacf20, param=...)
    at /home/chenbd/github/sdl_core/src/components/dbus/src/dbus_adapter.cc:488
#8  0x00000000015a2782 in dbus::DBusAdapter::SetArguments (this=0x1df4a80, msg=0x1e0b880, rules=..., args=...)
    at /home/chenbd/github/sdl_core/src/components/dbus/src/dbus_adapter.cc:476
#9  0x000000000159d997 in dbus::DBusAdapter::MethodCall (this=0x1df4a80, id=1, 
    func_id=hmi_apis::FunctionID::BasicCommunication_UpdateDeviceList, name=..., obj=...)
    at /home/chenbd/github/sdl_core/src/components/dbus/src/dbus_adapter.cc:242
#10 0x0000000001426784 in hmi_message_handler::DBusMessageAdapter::Request (this=0x1df4a70, obj=...)
    at /home/chenbd/github/sdl_core/src/components/hmi_message_handler/src/dbus_message_adapter.cc:179
#11 0x000000000142125a in hmi_message_handler::DBusMessageAdapter::SendMessageToHMI (this=0x1df4a70, message=...)
    at /home/chenbd/github/sdl_core/src/components/hmi_message_handler/src/dbus_message_adapter.cc:76
#12 0x00000000014157d7 in hmi_message_handler::HMIMessageHandlerImpl::Handle (this=0x1d74dd0, message=...)
    at /home/chenbd/github/sdl_core/src/components/hmi_message_handler/src/hmi_message_handler_impl.cc:121
#13 0x000000000141f2e4 in threads::MessageLoopThread<utils::PrioritizedQueue<hmi_message_handler::impl::MessageToHmi> >::LoopThreadDelegate::DrainQue (this=0x1dad700) at /home/chenbd/github/sdl_core/src/components/include/utils/threads/message_loop_thread.h:167
#14 0x000000000141f016 in threads::MessageLoopThread<utils::PrioritizedQueue<hmi_message_handler::impl::MessageToHmi> >::LoopThreadDelegate::threadMain (this=0x1dad700) at /home/chenbd/github/sdl_core/src/components/include/utils/threads/message_loop_thread.h:147
#15 0x00007ffff7bbbcbe in threads::(anonymous namespace)::threadFunc (arg=0x1dad750)
    at /home/chenbd/github/sdl_core/src/components/utils/src/threads/posix_thread.cc:64
#16 0x00007ffff7989e9a in start_thread (arg=0x7ffff7fdf700) at pthread_create.c:308
#17 0x00007ffff55a82ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#18 0x0000000000000000 in ?? ()

The trigger source defines whether or not the application is being brought into HMI FULL via a selection on the head unit or by voice recognition.

By default is ON, tried to compile with it OFF. When off, it no longer compiles and installs 3rd_party_logger. Files that include <log4cxx/logger.h> won't be able to compile.

1. Need to investigate whether setting this correctly has any implications on current systems
2. Need to update the application manager (or other?) to set the service type correctly

Many methods have an int or bool return type, but never vary the return value and are not checked in the calling code.

transport_manager_impl.cc:

int TransportManagerImpl::Init() {                                               
  LOG4CXX_TRACE(logger_, "enter");                                               
  all_thread_active_ = true;                                                     
  is_initialized_ = true;                                                        
  LOG4CXX_TRACE(logger_, "exit with E_SUCCESS");                                 
  return E_SUCCESS;                                                              
}

Call from life_cycle.cc:

transport_manager_->Init();

Either return values should be checked or functions should have return type of void.

In order to connect core to an SDL server you must update the default policy JSON file or current mysql policy table database to point to the desired SDL server. Documentation to do this does not currently exist on github, but should!

Should implement a separate transport adapter that supports OEMs using BlueZ 5.x. Known issues so far with the current implementation of BlueZ 4.x are that bt-device is not supported for querying paired devices and connecting with the BlueZ 5.x dev APIs.

apr.h is a generated file, and so should change, but these changes should show up in the build directory, not a tracked repository file.

We're merging SDL version 4.0 on 3/31 - we need to be sure that the MOBILE_API.xml specification that we include is the correct version and works with our 4.0 changes

http://pastebin.com/F8Eyknjy is the current version that we have but the ICONS_WITH_TEXT issue exists here. We need the version afterward

add a default response to notify the mobile app to start encoding video stream.

SDL_Core should be able to query compatible applications on the smartphone, list them for the user, and launch them remotely even if they are currently not in the background.

For iOS, this solution involves understanding the URL schemes of the applications that are installed on the iOS device. For Android, the package names are required. SDL current supports Android with a service for each SDL Android application which connects after an SDP query (bt-device for the included transport adapter)

It is possible that we can use a system request notification to the handset to launch the applications, but we need to investigate the need for creating new RPCs as well.

The launching strategy should be the same whether the connected handset is Android or iOS

The following namespaces contain capital letters:

• Errors
• Formatters
• NsJSONHandler
• NsMessageBroker
• NsSmartDeviceLink
• NsSmartObjects
• protocol_handlerHandler

This is inconsistent with the style guide, and should be fixed. This will not be addressed in #25, and needs its own fix branch.

Dependency checking should be performed at the cmake phase of the build. We shouldn't have the situation where cmake passes and make fails.
This subsumes #15.

We want the smartphone to display a logo in the lock screen that is defined by the OEM and based on the connected vehicle. The current proposed solution (POC) for SDL Core is on GENIVI

The solution sends an OnSystemRequest notification with a URL that points to the logo for the application to download, cache, and display based on the vehicle type returned in the register app interface response.

We discovered #16 when we were discussing this issue.

We can never actually increase the version beyond 15 because of how backward compatibility works. If we attempt to, we would run into an issue with the Head Unit sending it's max version back as part of a StartSessionACK. If the head unit sends a new style ACK with a larger version byte, then previous versions of the mobile library will not be able to read it. If it sends an old style ACK then that version can never be increased beyond 0x0F.

I am trying to start the version of SDL Core on the release/4.0.0 branch and am getting a fatal error "HMI index.hml doesn't exist!"

Is there any setup/configuration that is different from the version of SDL core on the develop branch that might cause this error?

It should also tell the application about the current mode during registeration

Instead the SetDisplayType RPC takes a string for the display type, claiming that it can either be a string defined in the PredefinedLayout enum or some other string.

Is there a reason that the PredefinedLayouts aren't used or a situation in which an app would know about a layout that isn't defined by the RPC Specification implemented on a head unit that it's connected to?

Hi,

The last commit I have from the smartdevicelink repo in GENIVI is from June; http://git.projects.genivi.org/?p=smartdevicelink.git;a=summary

This seems to imply that the GENIVI git repos for SDL have gone out of sync. This might mean that if there are people only following the GENIVI repos, then they will be following an older code base which might contain bugs and likely won't contain the latest and greatest. Also, there may be licenses and other collateral that might be out of date or inaccurate.

I think we should either sync up the GENIVI repos so that they are a mirror of what is pushed to github, or we should deprecate the GENIVI repos altogether. The current situation is confusing for SDL users and for GENIVI since we get questions about SDL that we can't really answer.

What do you folks think?

While trying to do a policy table update by sending the Proprietary system request from SDL Core to SDL Server I get the below error logged out from Sync Proxy Tester.

E/OnSystemRequest(  377): HTTPRequest in bulk data was malformed.
W/System.err(  377): org.json.JSONException: Value 4Ezay^ק<yi'*' of type java.lang.String cannot be converted to JSONObject
W/System.err(  377):    at org.json.JSON.typeMismatch(JSON.java:111)
W/System.err(  377):    at org.json.JSONObject.<init>(JSONObject.java:160)
W/System.err(  377):    at org.json.JSONObject.<init>(JSONObject.java:173)
W/System.err(  377):    at com.smartdevicelink.proxy.rpc.OnSystemRequest.handleBulkData(OnSystemRequest.java:57)
W/System.err(  377):    at com.smartdevicelink.proxy.rpc.OnSystemRequest.setBulkData(OnSystemRequest.java:114)
W/System.err(  377):    at com.smartdevicelink.proxy.rpc.OnSystemRequest.<init>(OnSystemRequest.java:44)
W/System.err(  377):    at com.smartdevicelink.proxy.rpc.OnSystemRequest.<init>(OnSystemRequest.java:39)
W/System.err(  377):    at com.smartdevicelink.proxy.SdlProxyBase.handleRPCMessage(SdlProxyBase.java:2707)
W/System.err(  377):    at com.smartdevicelink.proxy.SdlProxyBase.dispatchIncomingMessage(SdlProxyBase.java:1391)
W/System.err(  377):    at com.smartdevicelink.proxy.SdlProxyBase.access$2100(SdlProxyBase.java:100)
W/System.err(  377):    at com.smartdevicelink.proxy.SdlProxyBase$2.dispatch(SdlProxyBase.java:571)
W/System.err(  377):    at com.smartdevicelink.proxy.SdlProxyBase$2.dispatch(SdlProxyBase.java:568)
W/System.err(  377):    at com.smartdevicelink.Dispatcher.ProxyMessageDispatcher.handleMessages(ProxyMessageDispatcher.java:45)
W/System.err(  377):    at com.smartdevicelink.Dispatcher.ProxyMessageDispatcher.access$000(ProxyMessageDispatcher.java:8)
W/System.err(  377):    at com.smartdevicelink.Dispatcher.ProxyMessageDispatcher$1.run(ProxyMessageDispatcher.java:23)
W/System.err(  377):    at java.lang.Thread.run(Thread.java:818)

When I open the request on Android, the 0x07 endpoint does not appear in the JSON.

If any field of a Show command is invalid - the head unit should display what it can instead of sending back invalid data. The head unit should only send invalid data if there is not a single valid field.

So far here are our proposed solutions on core:

-Disconnect on bad packet
-Drop packets/RPCs silently when stuff goes south
-Full retry strategy

Some varialbes which are declared uint32_t are compared < 0
sdl_core/src/components/config_profile/include/config_profile/profile.h
uint32_t max_cmd_id_;
uint32_t put_file_in_none_;
uint32_t delete_file_in_none_;
uint32_t list_files_in_none_;

sdl_core/src/components/config_profile/include/config_profile/profile.cc
if (max_cmd_id_ < 0) {
if (put_file_in_none_ < 0) {
if (delete_file_in_none_ < 0) {
if (list_files_in_none_ < 0) {

Please excuse the issue history mess, had some issues with github UI.

It looks like the only difference is eventMode vs pressMode where the values are UP/DOWN vs. LONG/SHORT. This could easily be one RPC.

Head unit wants to show SDL version in system diagnosis. Suggest we add SDL version in HMI protocol GetSystemInfo.

While running SDL Core on Ubuntu 14.04.1 (64-bit) through VMWare 7 there is a loss of communication that occurs randomly while testing connected apps. Buttons on the emulator and phone may be pressed, but the communication from the emulator to the phone does not occur despite seeing a connected status and the current screen on the emulator is unnavigable.

Closing the app on the phone does not update the connection status on the emulator, so to fix this issue it requires restarting VMWare 7 and the phone being used for debugging. Doing one or the other does not seem to solve the issue.

Hi!

GENIVI has both archives of old SDL repos and mirrors of current SDL repos hosted in its git repository: http://git.projects.genivi.org/

We wonder if it makes sense for us to still be carrying the older repos? Is anyone using them? Does the SDL project have the same history in its repos?

Feedback welcome!

We should consider defining a way of deprecating the functions and parameters in MOBILE_API such that answers to questions like Mike's regarding the use of different parameter keys for OnSystemRequest are obvious. (If the V1 url and timeout parameter keys are still valid in the current version, they would be shown as deprecated, otherwise they would be removed)

Hi!
When I compiled SDL-Core(Use Qt HMI) code, I got a build error:

[ 96%] Built target copy_library_HWButtons
make[2]: *** [src/components/qt_hmi/qml_plugins/hw_buttons/CMakeFiles/qmltypes_HWButtons] Error 127
make[1]: *** [src/components/qt_hmi/qml_plugins/hw_buttons/CMakeFiles/qmltypes_HWButtons.dir/all] Error 2
make: *** [all] Error 2

How can I solve it?
3Q~

I want to start communication with SDL core,
I notify sdl-core that hmi is ready, my code is as follows:

QDBusMessage msg = QDBusMessage::createSignal("/", "com.ford.hmi.sdl.BasicCommunication", "OnReady");
QDBusConnection::sessionBus().send(msg);

Is it right? or what need to be done in advance?
But my UI.IsReady is not called.(UI.IsReady has been registered in dbus)

https://github.com/blog/1184-contributing-guidelines

Path: components/formatters/include
In file: CFormatterJsonSDLRPCv2.hpp
Method: inline bool CFormatterJsonSDLRPCv2::fromString

Looking at the following:

Json::Value root;
Json::Reader reader;
namespace strings = NsSmartDeviceLink::NsJSONHandler::strings;
bool result = reader.parse(str, root);

The variable root is not initialized. Is the reader.parse looking intentionally for an empty string in the str variable?

If so, what is the reasoning behind this?

Thank you

Error occurs building sdl core with qt hmi.

Generating files:
   /home/work/SDL/sdl_core-release-4.0.0/src/components/interfaces/QT_HMI_API.h;/home/work/SDL/sdl_core-release-4.0.0/src/components/interfaces/QT_HMI_API_schema.h
   /home/work/SDL/sdl_core-release-4.0.0/src/components/interfaces/QT_HMI_API_schema.cc
from:
   QT_HMI_API.xml ...

Generating interface source code with following parameters:
    Source xml      : /home/work/SDL/sdl_core-release-4.0.0/src/components/interfaces/QT_HMI_API.xml
    Namespace       : hmi_apis
    Output directory: /home/work/SDL/sdl_core-release-4.0.0/src/components/interfaces
    Parser type     : jsonrpc

Unknown type 'Common.DeviceInfo'

Source

It only converts the buffer into an integer and checks if the integer is zero. It should do the following, which is how most boolean values are read out of the .ini file

  std::string result_string;
  if (ReadValue(&result_string, <kSection>, <kKey>) &&
      0 == strcmp("true", result_string.c_str())) {
      *value = true;
  } else {
      *value = false;
  }

The failure in the current implementation can be seen when trying to set EnableLogs = true in the smartDeviceLink.ini file and breaking on the value after it's set in UpdateValues()

Looking at MOBILE_API.XML,

In function onSystemRequest Notification, there is a URL parameter. The description says:
"If blank, the binary data shall be forwarded to the app.".

Where does the binary data go? I see no parameter in that function to hold binary data.

Building on a system without libbluetooth-dev or bluez-tools will pass cmake but choke in the build. This should be added as a fatal dependency check for cmake.