Build and Test

Version added 20-Jun-2018| Modified 12-Jun-2019

After developing the native app, you must build the app and verify its functionality.

Add Recipe File

webOS OSE uses OpenEmbedded of Yocto project to build its components. You must write a recipe that configures the build environment. For more details about the recipe, see Yocto project reference manual.

  • Create and update the file : <native-app-name>.bb

    • Directory : build-webos/meta-webosose/meta-webos/recipes-webos/<native-app-name>

where <native-app-name> is the name of the native app. For the sample native app, <native-app-name> must be replaced by ''.

SUMMARY = "Native Qt App"
SECTION = "webos/apps"
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/Apache-2.0;md5=89aea4e17d99a7cacdbeed46a0096b10"
PR = "r0"
DEPENDS = "qtbase luna-service2 glib-2.0 libpbnjson"
inherit webos_submissions
inherit webos_qmake5
inherit webos_app
FILES_${PN} += "${webos_applicationsdir}"

A brief explanation of the above file:

  • Line(1~4) : Basic descriptions of the component.

  • Line(6) : Version of the component. For the webOS OSE component, this field is mandatory.

  • Line(7) : Revision version of the recipe. Each recipe requires a counter to track its modification history. Make sure that you increment the version when you edit the recipe, unless you only change the value of the WEBOS_VERSION field or comments.

  • Line(9) : A list of a recipe's build-time dependencies.

  • Line(11) : Instruct OpenEmbedded to use the WEBOS_VERSION value as the component version number. If you develop your component on a local repository, this entry is required.

  • Line(12) : Instruct OpenEmbedded that the component uses QMake for configuration, which is the preferred choice for webOS components.

  • Line(13) : Inherit webos_app, because the component is an app.

  • Line(15) : Put OE_QMAKE_PATH_HEADERS = "${OE_QMAKE_PATH_QT_HEADERS}" so that Qt header files can be included at compile time.

  • Line(17) : ${webos_applicationsdir} indicates /usr/palm/applications${PN} is the package name, which is set to

Configure Local Source Directory

To build a component that is located on the local system, you must specify the directory information.

  • Create and update the file : webos-local.conf

    • Directory : build-webos

For the sample native app (, you must provide the local path where the source exists.

INHERIT += "externalsrc" = "/home/username/project/" = "/home/username/project/" =".local0"

A brief explanation of the above file:

  • Line(1) : Inherit "externalsrc" bbclass file.

  • Line(2) : The local source directory. The syntax of the property is EXTERNALSRC_pn-<component>.

  • Line(3) : The local build directory. The syntax of the property is EXTERNALSRC_BUILD_pn-<component>.

  • Line(4) : The appended revision version (PR) for building local source files. The syntax of the property is PR_append_pn-<component>. This property is optional.

We recommend that you add a trailing slash (/) at the end of all local directory paths, as in Line(2) and Line(3).

Build, Run, and Verify

  1. Build the native app.

    To build the component on the OpenEmbedded environment, enter the following commands on the shell.

    build-webos$ source oe-init-build-env
    build-webos$ bitbake

    For more information, see Building webOS OSE.


  2. Copy the IPK to the target.

    When the build is successful, oe-related directories are created under the project root directory. These directories are linked to the directory where the build output is generated from the actual build-webos sub-directory.

    ├── ServiceRequest.cpp
    ├── ServiceRequest.h
    ├── appinfo.json
    ├── icon.png
    ├── main.cpp
    ├── build
    ├── oe-logs -> /home/username/build/build-webos/BUILD/work/raspberrypi3-webos-linux-gnueabi/
    └── oe-workdir -> /home/username/build/build-webos/BUILD/work/raspberrypi3-webos-linux-gnueabi/

    If you go to oe-workdir/deploy-ipks/raspberrypi3, you can see file.


    Copy the IPK file to the target device using the scp command.

    ~/project/$ scp root@


  3. Install the app on the target.

    Connect to the target using the ssh command and install

    $ ssh root@
    	root@raspberrypi3:~# cd /media/internal/downloads/
    	root@raspberrypi3:/media/internal/downloads# opkg install
    	Installing (1.0.0) on root.


  4. Discover the LS2 configuration files.

    To make LS2 daemon scan the LS2 configuration files of the app, use the ls-control command as follows.

    root@raspberrypi3:/media/internal/downloads# ls-control scan-services
    	telling hub to reload setting and rescan all directories
    For the native app, LS2 configuration files are generated during the build in step 1. To run the app properly, you must make the system scan the newly generated configuration files.


  5. Scan the app.

    To make System and Application Manager (SAM) scan the app, restart SAM using the systemctl command. This step is required so that the app can be added to the app list, which in turn makes the app appear on the Home Launcher.

    root@raspberrypi3:/# systemctl restart sam
    Rebooting the target after step 3 will have the same effect as running step 4 and step 5. However, using the commands in step 4 and step 5 allows you to continue testing without rebooting.


  6. Run the native app.

    Use the Windows key on keyboard to show the Home Launcher. Click the app icon to see the window titled "Native qt app" with the following page:



  7. Verify the execution of the native app.

    • Using SAM's running method

      You can check whether the app is running by using SAM. For more SAM methods, see com.webos.service.applicationmanager.

      root@raspberrypi3:/# luna-send -i -f luna://com.webos.service.applicationmanager/running '{"subscribe":true}'
          "subscribed": true,
          "running": [
                  "id": "",
                  "webprocessid": "",
                  "defaultWindowType": "card",
                  "appType": "native",
                  "processid": "1778"
          "returnValue": true
    • Using logs

      You can use "tail -f /var/log/messages | grep NativeQtApp" commands on target for the app debugging.

      • When the app is first launched by SAM's launch method with "params", arguments passed from SAM is printed on messages file.

        luna-send -n 1 -f luna://com.webos.service.applicationmanager/launch '{"id":"", "params":{"test":"key1"}}'

        See the log file. [] NativeQtApp MAIN_ARGV {"argv[1]":{"event":"launch","reason":"","appId":"","interfaceVersion":2,"parameters":{"test":"key1"},"interfaceMethod":"registerApp","@system_native_app":true}}
      • When the app is registered by SAM successfully, it gets a "registered" event in response from SAM.

        See the log file. [] NativeQtApp REGISTER_CALLBACK {"payload":{"event":"registered","subscribed":true,"returnValue":true}} [] NativeQtApp REGISTER_CALLBACK {"event":"registered"}
      • Launch the app when the app is in the foreground. Use the "params" parameter to pass specific values to the app via SAM. 

        luna-send -n 1 -f luna://com.webos.service.applicationmanager/launch '{"id":"", "params":{"test":"key2"}}

        See the log file.  [] NativeQtApp REGISTER_CALLBACK {"payload":{"event":"relaunch","reason":"","appId":"","parameters":{"test":"key2"},"returnValue":true}} [] NativeQtApp REGISTER_CALLBACK {"event":"relaunch"} [] NativeQtApp REGISTER_CALLBACK {"parameters":{"test":"key2"}}
      • Close the app via SAM's closeByAppId, and "close" event is received.

        luna-send -n 1 -f luna://com.webos.service.applicationmanager/closeByAppId '{"id":""}'

        See the log file. 

        2019-05-14T05:34:02.618621Z [17503.946566389] [] NativeQtApp REGISTER_CALLBACK {"payload":{"event":"close","reason":"undefined","returnValue":true}} 
        2019-05-14T05:34:02.618725Z [17503.946669879] [] NativeQtApp REGISTER_CALLBACK {"event":"close"}


Except as noted, this content is licensed under Creative Commons Attribution 4.0 and sample code is licensed under Apache License 2.0.