Site Tools


Here some community notes about IoTivity on Tizen os

Supported documentation is :

Since 2015, there are many projects maintained in parallel, so this page try to provide an entry point for Iotivity on Tizen.

If you have questions let me suggest to ask on this wiki page (insert TODO) Then, we will try to give more hints ;)

Or contact the following developers who like to help :



To build it just use shipped script after installing tizen tools as explained at :

EXEC_MODE=true ./ 
./  tizen

Reminder: “scons TARGET_OS=tizen” should be called in GBS/RPM environment and not directly from developer shell like on linux, it will not work ( )

It will fail and suggest to fetch other build dependencies (as sources), For instance:

*********************************** Error: ****************************************
* Please download cbor using the following command:                               *
git clone extlibs/tinycbor/tinycbor

Run again

In the end you should have RPM for Tizen:2.4

You can also build for an other “supported” profile using this line:

 EXEC_MODE=true ./ # Since [[1.3-rel]]+
 gbsarch=armv7l gbsprofile=tizen_4_0_unified_armv7l ./ 

Related change to clone automatically :

ATM this armv7l repo is used to build :

More “upstream” tizen resources :

For latest snapshot you can also check this “staging” area :


EXEC_MODE=true ./
scons -f resource/csdk/stack/samples/tizen/build/SConscript \
scons -f service/easy-setup/sampleapp/enrollee/tizen-sdb/EnrolleeSample/build/tizen/SConscript \
scons -f resource/csdk/stack/samples/tizen/build/SConscript \
scons -f resource/csdk/stack/samples/tizen/build/SConscript \

Please comment on issues:


Maintained by Tizen, current version is 1.2.0 :

It is currently unaligned, but it is planned to realign on upstream git tag on next version as suggested at

Maintenance Tips

Here some tips for co maintenance

Note, it would be nice to rebase on tag from upstream, to have a clean and lean history.

More details :

Build for common profile :

gbs build

Note, since 1.2-rel there is no need to maintain a duplicate packaging/iotivity.spec since tool/tizen/iotivity.spec can be built out of the box using this merged change:

Here are related links about ongoing discussions :


Here is the procedure to update to new release

If version released, it will use a tag name in this form: x.y.z (z can be latest revision, for instance 1.2.2) :

 git clone ssh://
 cd iotivity
 git remote add from ssh://
 git fetch from x.y.z
 git tag upstream/x.y.z x.y.z # can be used if not using .gbs.conf
 git push origin x.y.z # tag needs to be on too
 git push origin upstream/x.y.z # tag needs to be on too
 git checkout -b next remotes/origin/tizen_3.0 #
 git rebase -i x.y.z # will list our patches to apply
 gbs build
 # git push --force origin HEAD:tizen_3.0 # base changed on tizen, so force is used

If not x.y.z not yet released you can still release branch (ie: 1.2-rel for 1.2.2) similarly:

 git clone ssh://
 cd iotivity
 git remote add from ssh://
 git fetch --all # to fetch latest changes we want from upstream
 git checkout -b next remotes/origin/tizen_3.0
 git rebase -i from/upstream/1.2-rel # will list our patches to apply if any
 git rebase -i remotes/origin/tizen_3.0 # optionally reorder
 gbs build
 # git push origin HEAD:refs/for/tizen_3.0 # base isnt changed on tizen, so force is not used

Note, never push a tag to a branch name (ie git push origin x.y.z:tizen_3.0), gerrit will not be able to merge changes on it.

1.3-rel branch could be build from this base:

 git branch -D 1.3.0+RC1
 git branch -D 1.3.0+RC1 ; git branch 1.3.0+RC1 remotes/upstream/master
 gbs build


Next version can be build from scratch on upstream 1.3.0 tag from :

Those patches are needed to pull (and track) dependencies versions and special configuration flags:

Eventually more to come at:

Tizen will align to upstream default configuration except for those config flags :

  • TCP=1

You can rebuild version for Tizen:Common using those steps:

  git clone ssh:// -b 1.3-rel && cd iotivity
  git remote add tizen ssh://
  # To pull dependencies libs and non upstream changes (SECURITY, TCP)
  url=ssh:// refs/changes/77/19477/3
  git fetch $url && git checkout FETCH_HEAD
  git checkout -b tizen FETCH_HEAD
  gbs build -P "profile.tizen_common_armv7l" --arch armv7l
  git log
  git push tizen 1.3.0 # tag must be present there too, if there already skip to next line
  git push tizen HEAD:tizen # ask confirmation to maintainers

Now if you want to build without security :

gbs  build  -P "profile.tizen_common_armv7l" --arch armv7l --define 'SECURED 0'

Related links:



Next version can be build from scratch on upstream 1.2.1 tag from :

Those patches are needed to pull (and track) dependencies versions and special configuration flags:

Tizen will align to upstream default configuration except for those config flags :

  • TCP=1

You can rebuild version for Tizen:Common using those steps:

  git clone ssh:// -b 1.2-rel && cd iotivity
  git remote add tizen ssh://
  # To pull dependencies libs and non upstream changes (SECURITY, TCP)
  git fetch ssh:// refs/changes/57/12357/9
  git checkout -b tizen FETCH_HEAD
  gbs  build  -P "profile.tizen_common_armv7l" --arch armv7l
  git log
  git push tizen 1.2.1 # tag must be present there too, if there already skip to next line
  git push tizen HEAD:tizen # ask confirmation to maintainers

Now if you want to build without security :

gbs  build  -P "profile.tizen_common_armv7l" --arch armv7l --define 'SECURED 0'

Related links:


Version can be build from scratch from 1.2-rel:

git checkout -b tizen 1.2-rel
git tag 1.2.0+RC3 1.2.0-RC3 
grep 'Version:' tools/tizen/iotivity.spec # edit it 
Version: 1.2.0+RC3

Then you need to cherry-pick “dependencies patches”, tinycbor-0.3.2

Optionally add TLS (if SECURED=1)

Enable/disable features WITH_??? in tools/tizen/iotivity.spec

Or just clone this branch as example:

Supported configurations :

  • SECURE=0, WITH_TCP=0 : Default


It easier to maintain extlibs as patches, for instance :

git “module” was converted to patch this way:

git clone -b v0.4 extlibs/tinycbor/tinycbor
rm -rf extlibs/tinycbor/tinycbor/.git
git add -f  extlibs/tinycbor/tinycbor/
git commit -sm 'tinycbor: Update import to v0.4' extlibs/tinycbor/tinycbor/

git “module” update:

rm .gitignore 
git commit -sam "Change to remove from history"
rm -rf extlibs/mbedtls/mbedtls
EXEC_MODE=true ./ 
rm -rf extlibs/mbedtls/mbedtls/.git
git add extlibs/mbedtls/mbedtls
git commit -sm 'mbedtls: Update to mbedtls-2.4.2' extlibs/mbedtls/mbedtls
git revert HEAD~1
git rebase -i remotes/upstream/master # Remove .gitignore changes


Note: This version remains here for history and will probably not evolve, as more recent version is maintained into upstream.

Tizen distro ships iotivity as community contrib , check the packaged sources over there :

IoTivity in Tizen : as community contrib

zypper ar
zypper in iotivity-devel

Build Logs at :

Feel free to contact me for support :

Have fun

Status : It worked on various configurations

  • Tizen:3.0 : minnowboard max
  • Tizen:2.4:Mobile : TM1
  • Work in progress (@rzr)

Tizen:2.4:Mobile (TM1)

As linux process

0/ Setup tizen tools and profile profile.tizen_2_4_mobile-armv7l

1/ Rebuild dependencies if not in repos On issues switch to sandbox/pcoval/tizen_2.4

2/ Rebuild iotivity from tizen contrib repo

3/ Optionally rebuild sample iotivity-example and deploy to device

Demo :


IoTivity as Tizen native app

For general overview check 1st this presentation :

Here follows step by step explanations to reproduce demonstration using Samsung Z1 (client part at least) :

Note if you have unexpected issues with Tizen SDK, please check this page :

It might also work on GearS2 (but I don't have any to check).

Build RPMs

Using gbs build

sudo apt-get install git wget unp rpm make # linux tools
sudo apt-get install gbs # for tizen tools

If not familiar with tizen platform development, check this short “welcome presentation” :

Create Tizen native app using SDK

Use wizard from Tizen-SDK (Version : 2.4.0_Rev5 Build id : 20151223-1450)

File / New / Project / Tizen / Tizen Native Project / Next 
Template / Mobile 2.4 / Basic Ui / Project Name = IotivityExample

Then you should have your files in something like ~/workspace/IotivityExample

Optionally : rename sample source to src/main.cpp and fix casts issues :

  - appdata_s *ad = data;
  + appdata_s *ad = (appdata_s*) data;

TODO: need to report this to SDK team ? any contacts to share ? ?

import RPMs contents

Now go to project dir

cd  ~/workspace/IotivityExample

rm -rf usr lib
mkdir -p usr lib

# unpack rpm with cpio or unp :
unp ${rpmdir}/iotivity-${version}-*.${arch}.rpm
unp ${rpmdir}/iotivity-devel-${version}-*${arch}.rpm

ln -fs ${rootfs}/usr/include/boost usr/include/

cp -av ${rootfs}/usr/lib/  usr/lib/ 

# uuid1 is a hack to avoid overlap issue as uuid is already on platform 
# but not in SDK so it's renamed to prevent mismatch collisions
ln -fs ${rootfs}/usr/lib/ usr/lib/

# as ${ProjName}/lib is the default place holder :
rm -rf lib
ln -fs usr/lib lib

Note: To save space (and time) some files can be removed or excluded from project : lib/*.a and lib/debug but also other unused libs.

Update eclipse/CDT project

 Project / Properties / C/C++ Build / Tizen Settings / Configuration / All configuration
 Platform: Mobile 2.4 # or Wearable 2.3.1
 Architecture : ARM # x86 for emulator
 Toolchain : gcc-4.9

Note: Avoid LLVM it's not supported yet

Set a tizen symbol to be used in our tizen port:

 Project / Properties / Properties / C/C++ General / Configuration / All Configuration
 / Paths and Symbols / Symbols /
 / GNU C / Name / __TIZEN__  / Value / 1 / Add to all configuration
 / GNU C++ / Name / __TIZEN__  / Value / 1 / Add to all configuration

Set lang to C++ 11 :

 Project / Properties / C/C++ Build / Settings / Configuration / All Configuration
  / Tool Settings / C++ Compiler  / Dialect / Language Standard / C++11 --std=c++-0x / Apply

If not doing this you'll face errors when using new API (ie : std::enable_shared_from_this<IClientWrapper>)

You should add all needed paths :

 Properties / C/C++ General / Paths and Symbols / All configuration
  / Includes / C++ / Add (Make sure to set each as workspace path) :

And check libpath too :

Properties / C/C++ General / Paths and Symbols / All configurations /
 / Library Paths /


Now add libs to linker :

 Properties / C/C++ General / Paths and Symbols / Libraries :

Optionally : disable indexer :

 C/C++ General / Indexer / project specific settings : ON /
  / enable indexer : OFF / Apply

And this too :

 C/C++ General / Code Analysis / use project settings : ON / 
  / Problems Syntax and Semantic Errors: OFF / Apply


Make a tpk package :

Project / Build Package /

It should log something like :

< Options >
-Build directory = /home/philippe/workspace/IotivityExample/Debug
-Architecture = armel
-Package name = org.example.iotivityexample
-Package version = 1.0.0
-Package type = TPK
-Project name = IotivityExample
-Artifact name = iotivityexample

Initialize... OK
Copying files... OK
Signing... OK
Zip path: /home/philippe/workspace/IotivityExample/Debug/org.example.iotivityexample-1.0.0-arm.tpk
  adding: tizen-manifest.xml	(in=550) (out=276) (deflated 50%)
  adding: lib/ 	(in=4040932) (out=548884) (deflated 86%)
  adding: bin/iotivityexample 	(in=4866080) (out=1092162) (deflated 78%)
total bytes=141583493, compressed=15473348 -> 89% savings
Zipping... OK

If you fail to build tpk package, move your project elsewhere (/tmp/) , remove from IDE workspace and import it again (copy contents) and it will work again in ~/workspace/${ProjName} (see Tizen wiki).

Now you can exclude unused lib, at least exclude static libs will not be loaded :

Project Explorer View / ${PrjName} / lib / right click menu / Properties /
 / Resource / Resource Filter / Add / 
 / Exclude all / Files / Names / matches / *.a / OK

Optionally : Other unused libs can be also excluded, just keep the one the app link with.

Use IoTivity platform

Similarly to Linux, but maybe not in main loop (assync)


On trouble with Tizen SDK check this page too :

Tizen:2.3.2:Wearable (GearS3)

Similar to Tizen:2.3.1 procedure, Here is a procedure to test on emulator (x86)

Install tizen-studio subpackages (IDE and CLI)

Using IDE create and start emulator, then you can build and run without bothering with certificates:

git clone -b sandbox/pcoval/tizen/wearable-2.3.2
./ arch_family=x86 arch_suffix=i386

If you want to run on device, run again using default ARM configuration ( ./ ) and sign and deploy using IDE.

Tizen:2.3.1:Wearable (GearS2)

As tizen app: Work in progress



You can setup and and rebuild all from scratch using this sample project :

Note that current version is using IoTivity-1.2.0+RC3 from (1.2-rel branch)

1/ Setup dependencies for your GNU/Linux system (install Tizen's env GBS etc)

export MAKEFLAGS="-j1" # or try to fix makefiles
git clone && ./tizen-helper/bin/ setup

2/ Try to iotivity library and sample application :

branch=sandbox/pcoval/tizen/wearable-2.3.1 # or branch=sandbox/pcoval/tizen/mobile-2.4
git clone $url -b $branch && cd iotivity-example
./ # ask support on issues
ls lib/liboc*.so || ./ lib # there you have project ready to build using IDE
./ tpk # but keep building a package to be deployed on device (without certificates)

If any issues you can backup your current tizen-studio if already installed to make sure script will find what it expects and run again in empty directory.

zip -r ~/ ~/tizen-studio
zip -r ~/
rm -rf ~/tizen-studio ~/tizen-studio-data


But on commercialized products you need to setup certificates manually using IDE :(

rm -rf .sign Release Debug # we will rebuild it using IDE :(
~/tizen-studio/tools/sdb devices # observe your device SN, to replace instead of ${user}
List of devices attached 
# 0000FFFF0000FFFF         device          SM-Z200F
./ rule/installed/cert-add-on # Needed for Samsung certificates with IDE (not CLI?)
./ rule/installed/WEARABLE-2.3.1-NativeAppDevelopment
./ rule/installed/NativeIDE # should be pulled already
./ rule/installed/NativeToolchain-Gcc-4.9
~/tizen-studio/ide/ #
  • Help / about # 1.0.1 here
  • File / Import / General / Existing Project into Workspace / “iotivity-example” / Finish
  • (problem to be solved) at
  • Tools / Certificate manager / “+” / “Samsung” certificate type
    • “Mobile/Wearable” / Next / Create new certificate profile / ${user} (replace with yours)
    • create new author certificate / Name, Password, confirm / Apply same for dist
    • log in Samsung account
    • Backup path ~/tizen-studio-data/keystore/${user}
    • New distributor
    • Add DUID of your connected devices, see previous step how

If lucky you'll get ~/SamsungCertificate/${user}/ with author.p12, distributor.csr, distributor.p12, distributor.pri, author.crt, distributor.crt, author.pri,, author.csr

And backup ~/tizen-studio-data/keystore/author.p12 is same to ~/SamsungCertificate/user/author.p12

A file like this one, will be used to store password and sign your tpk

cat /home/user/workspace/.metadata/.plugins/org.tizen.common.sign/profiles.xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<profiles version="3.0">
<profile name="user">
<profileitem ca="" distributor="0" key="/home/user/SamsungCertificate/user/author.p12" password="${password}" rootca=""/>
<profileitem ca="" distributor="1" key="/home/user/tizen-studio/tools/certificate-generator/certificates/distributor/tizen-distributor-signer.p12" password="${password}" rootca=""/>
<profileitem ca="" distributor="2" key="" password="${password}" rootca=""/>


Then you need to plug device and run to it, like:

# ~ File / make package / run to device

Alternatively using CLI:

# Setup device: in settings app, enable developer mode, then setup wifi, note down ip (target_host)
# Deploy on device 
ping -c 1 ${target_host}
sdb connect ${target_host} # use target IP in Settings/WiFi/AP/... or nmap
sdb shell ls /home/developer/ # to check connection
./ run # GUI should appear on "known" device


For development purpose you can try to rebuild shared library with debug options:

profile=tizen_2_3_1_wearable # or profile=tizen_2_4_mobile
gbs_arch=armv7l # or gbs_arch=i586 
gbs_profile=${profile}_${gbs_arch} # or gbs_profile=profile.tizen_2_4_mobile_armv7l 
cd tmp/iotivity/ # relative to iotivity-example
HOME=$home \
  gbs build -P $gbs_profile -A $gbs_arch --include-all \
    --define 'LOGGING 1' --define 'RELEASE False'
./ rule/import
./ run # or deploy

sdb log | grep 'OIC'


You could find more interesting things in those development branches, at your own risks:

Server, will depend on this version (1.2.0) :

you can create a deb package from this, but I wont explain it now, just try :

git clone -b sandbox/pcoval/on/previous/debian ; cd *
make && sudo make install # DESTDIR=/usr/local/opt/iotivity

Then adapt iotivity.pc and use it using pkgconfig's path

Tizen:2.3:Wearable (GearS)

git clone -b sandbox/pcoval/tizen_2.3

Should work on Tizen GearS, hack/tune emulator to enable bridge mode, or run server on emulator too (TODO)

IoTivity-1.0.1 was used in previous demo.


Just uses meta-oic along tizen-distro

Status : It worked on various configuration

HowTo (Work in progress for RPI2) :

git clone -b sandbox/pcoval/test
make -C meta-yocto-demos rule/setup/all
make -C meta-yocto-demos rule/all

I am using this place to stage and test my patches and make sure everything is rebuilding fine from scratch as I saw that many complained about build issues.

I can also share my built images, just request.

Also you'll see a basic client in /opt/ would it help community to document all those steps ?

Demo :

References :


Tizen RT


Tizen Build Details / Gotchas

This is here to have it recorded someplace, should move somewhere else.

The tizen build as done by is quite confusing. First it calls the top-level script, which provisions a build environment, making sure the rpm specfile which is in git as tools/tizen/iotivity.spec is in a place it can be found. then calls “gbs build”, which launches an rpm build using the specfile. That build calls scons. That part of the build is relatively normal, things are heirarchically in the places you'd expect, but there is still an issue (noted after the next paragraph).

Then there are two more calls, this time directly to a subsidiary sconscript several levels deep in the tree. These each construct a call to, which provisions a tree - differently - which then calls gbs which calls rpmbuild which calls back into scons. These latter two builds have top-level scripts (SConstruct files) which their copied in from somewhere else, so these two do not use the standard build at all. Since they don't intend to build the whole tree - they are for examples - they also don't fully provision.

In all cases, gbsbuild is called with arguments relating to the options available for a normal iotivity build which are handled in a way such that they are supposed to eventually make it to the scons instance which does the building. They are interpreted in numerical order only so gbsbuild and the matching specfile have to be changed in sync, and all files are far from matching the current iotvity option set, which is defined in git in build_common/SConscript. Changing details of iotivity build arguments are almost certain to end up causing surprises in the tizen secondary builds. The two later builds also don't pick up the standard tizen script which sets options, so if you think you are setting a new option in build_common/tizen/SConscript, that will apply only to some of the build, and the build will in fact probably fail in surprising looking ways.

All of this has unpleasant side effects.

tizen.txt · Last modified: 2018/07/12 23:13 by mwichmann