Blog

I need to have a specific tool on my smartphone for my personal needs. As I did not find any such existing tool, I decided to develop it. My smartphone, an old Samsung Z1, is based on Tizen OS (it’s, actually, the very first Tizen smartphone), so I downloaded Tizen Studio 2.4 and started the journey.

Why Tizen? I hate Apple and Microsoft for their attempts to kill Linux and I just don’t like Java as a programming language. If Tizen dies, I’ll move to SailfishOS or PureOS — iOS, Android and Windows Phone are not options for me.

Last time, when I was about to start developing a mobile application for a Linux-based operating system, that OS… died (I hope, this does not mean, that the same is going to happen with Tizen). That was MeeGo (in fact, killed by Microsoft, by the way). So, when Samsung and Linux Foundation announced Tizen, I was really glad. I assumed, that this was going to be a really open source Linux OS with an IDE, that would run on Linux flawlessly. But, I was (slightly) wrong…

Tizen Studio is based on Eclipse, that works fine on Linux. But, it comes with such additional tools as Emulator, without which it would be impossible to develop for Tizen (you need to test your app somehow), and EDC Editor, that is used to design custom UI components. Both these tools just do not work out of the box. Well, Emulator works, but incredibly slowly. And, the EDC Editor halts without any error.

I spent days to figure out what was happening. Official docs of Tizen Studio do not mention any issues under Linux at all — they just claim, that it is supported. Obviously, Emulator was slow because the hardware virtualization was not used (while my computer supported it). Finally, I found, that this happened due to file permissions — Emulator did not have access to KVM. I managed to fix this by installing qemu-kvm package (in Debian), which handles that, and by adding my user to the kvm group. Regarding the EDC Editor issue: I managed to fix it by installing libjpeg8 from the oldoldstable Debian repository and disabling libxcb as suggested here (thanks Lev for sharing his findings).

After that, I was finally able to work in Tizen Studio and to run the developed tool in its Emulator. But then, I needed to test the tool on my real Tizen device. From what I read, it should have been easy:

1. Generate a certificate using the Certificate manager.
2. Right click on the project and use Build Signed Package.
3. Run Device manager and connect your real device to the computer (make also sure, that USB debugging is enabled in your smartphone).
4. Right click on the device and Permit to install applications (this should be done only once).
5. Using Install app in the same contextual menu find the tpk package in the Release subdirectory of your project and deploy it to the device.

And… this did not work! Actually, I’m not sure, where did I get the aforementioned steps, because at the moment of writings these words I could not find any official documentation with them. Anyway, this is not the only thing, which is missing in docs…

By the way, Device manager can sometimes fail to detect real device. If this happens, just unplug and plug it again (you may need to do this several times). This helped for me. Also note, that the device should be unlocked in order to be detected.

So… The deployment to the real device failed with: error 23: Signature verification failed. Eventually, it appeared, that the reason was in wrong certificate (the very first step). You see, to deploy Tizen packages to a real Samsung device you need to use a certificate of Samsung. And, to be able to generate a Samsung certificate you need to install Samsung Certificate Extension. But, surprise, no such extension was available in my Tizen Studio’s Package manager. In some time I discovered, that to make it available there, you first need to manually activate the repository with this extension in configuration of the Package manager (why isn’t activated by default?). Only after that, you’ll be able to find Samsung Certificate Extension under its Extension SDK tab.

To test your app on a real device, you need to generate author and distribution certificates, that are linked with the Samsung certificate. If the previously mentioned extension is installed, when you are about to create a certificate (by clicking on the plus icon), Certificate manager will suggest two options — Tizen and Samsung. The former is completely useless, as it appeared (it’s not needed for testing apps in Emulator and it won’t work on real devices). So, you have to choose the latter.

After you choose Samsung and after you enter certificate details, you will be asked to login into your Samsung account in the specially launched embedded browser window. But, another surprise, this does not work on Linux (at least for me)! Certificate manager reported the error: Browser cannot be initialized. And, that’s it. It did not explain the reason, why it failed, and did not suggest any solution (nothing also in the console output).

Eventually, I managed to bypass this problem by installing Tizen Studio with Certificate manager and Samsung Certificate Extension on… MacOS (yeah, I know). There, I created the needed certificates and then I just copied them to the Linux machine and imported them into its Certificate manager. After that, deploying to a real device finally worked.

When you generate a certificate for testing your apps on real devices, you need to specify DUIDs of all such devices. (This means, that you won’t be able to manually install your app to an arbitrary device without regenerating your certificate). You can determine the DUID of your device using the contextual menu in Device manager (use the menu item with the corresponding name).

But, that’s not all! Deploying to device worked, but not the app itself. It just did not run on the real device. At all! Luckily, Device manager can show logs, written by the device (a great feature, by the way). In these logs I was able to find the following errors: not found ppi and dlopen failed(<executable>: cannot open shared object file: No such file or directory). Please compile with -fPIE and link with -pie flag. Later, I found, that such errors may mean, that an executable, which was compiled for x86, is run on ARM. That was it! Emulator uses x86 architecture and real Samsung devices use ARM. Certainly, I expected that Tizen Studio should handle this, but it did not.

It appeared, that this can be fixed in the project’s properties: C/C++ Build → Tizen Settings → Platform tab → Architecture. There, I chose the Release configuration and made it use the ARM architecture. Now I have Debug configuration for testing and Emulator and Release — for real devices. (Still, I do not understand, why Release is configured to use x86 by default.) This helped — after that the app runs fine.

For some reason, however, the Release configuration sometimes “forgets”, that it should use ARM, and switches to x86 on its own. So, I need to fix it from time to time.

And, the last thing, for now: If your app saves some user data, e.g., into Sqlite3 database (as mine does), you will find out, that by default all such data will be purged, when you deploy a new version of the app to Emulator or a real device. This can be prevented by setting the Enable update mode option in Debug and Release run configurations (Run → Run configurations), which emulates “the Tizen Store update” (as explained by Samsung), i.e., makes it preserve the user data. Again, I have no idea, why this is not enabled by default.

Like with the previous configuration option, Tizen Studio can sometimes “forget”, that it should update instead of reinstalling (I had such situation, when the app crashed in Emulator). So, you should be very careful, when deploying your app to a real device (if it already stores some useful data).

All the mentioned issues are related only to setup and configuration — they are not really about development. But, Tizen development is not flawless either, what you’ll, probably, be able to read about in part 2, if it will ever be written (honesty, I’m not sure, if I’ll want to handle all the rest (development) issues). So, no wonder, that Tizen is so much behind Android and iOS (to be honest, it feels like it’s going to die; if this will happen — that’s the reason). I did not develop for Android/iOS though – so this is only my assumption, that it’s easier to work with them. Anyway, some things, that I see in Tizen Studio so far, are just not right.