An Introduction to Tizen Compliance

There is a whole world of smart devices out there, and Tizen has been built to run on many of them, including phones, televisions, cameras, appliances, cars, and more. The software that runs on top of these intelligent devices is what powers the new and interesting functionality that make up the Internet of Things. The latest generations of mobile devices have introduced new methods of installing apps in ways that allow them to be used on a wide range of devices, and this article will take a look at how Tizen makes sure that apps run on as many device types as possible through the Tizen Compliance program.

How an App is Installed

At the root of this is how apps are installed on an operating system. Traditional UNIX/Linux systems have several methods to install applications.

  • One method is to hunt for the source code, build it, and run something like “make install.”
  • Another method is to get a prepackaged installer, that handles all of the technical details, from a vendor who knows how to put things in the right places for their app.
  • Yet another method is to install from a repository: a known location on the Internet that the package software on your system knows how to retrieve and install from. The system or distribution provider, or other groups and vendors that package software for your type of system can provide these repositories.

The App Store Model

On mobile devices, the story is normally considerably more constrained. The first method does not work well because you typically do not have a build environment on your device. Additionally, unless you have a “jailbroken” device, you don’t usually have the admin rights to do installations anyways; this prevents both options one and two. Regardless, 3rd party installer packages have some disadvantages, among them the challeng of keeping  software updated. This has been demonstrated with things like the Java Runtime Environment, where security updates have often been very slow to deploy because system owners might not notice there is an update needing to be installed.

Instead, mobile device installation happens from a special curated repository, colloquially called an App Store; a concept that will be quite familiar to users of Apple and Android phones.  These operate using close cooperation between a client already installed on the device and the app store servers. The result is the user is presented with only the packages that are available to install on their specific device.  For example, packages that require a higher pixel count, on a large screen, with accelerated graphics hardware can be filtered out for devices that don’t have these graphical capabilities.

The app store model works best if there is a high degree of compatibility between different devices of a similar type. For differences between devices, the application should be coded to adapt to those differences and “just work”. If there are differences which do need to be exposed, there needs to be a clear method for indicating which device capabilities an application requires, as in the example in the preceding paragraph. For example, app developers should not need to make different versions of their app for phones built by HTC, Samsung, Sony, and so on. Nor should they be required to make a different version for each new Tizen API version. An ecosystem where these two scenarios are necessary is said to be fragmented, and the goal should be to reduce or eliminate fragmentation to improve platform adoption.

How Tizen Reduces Fragmentation

The effort to reduce fragmentation in Tizen is called the Tizen Compliance program.  The term compliance is a little overloaded, for example it is often associated with financial accounting standards. In terms of using open source software, it refers to assuring the specific license the code is released under is being followed. If we define compliance as “acting in accordance with a rule, policy, regulation, standard or law,”  both uses make sense. In Tizen, the Tizen Compliance Specification aims to ensure that implementations of Tizen are compatible with one another, and most importantly, are able to run applications that follow the standard.

When a particular version of Tizen is released, the general code base is referred to as the Platform. The adaptation of the platform to a specific device category is called a Profile. The Application Programing Interface (API) and application execution environment for that profile are called a Compliance Profile. The Tizen Compliance Specification (TCS) is what defines this compliance profile. For the Tizen 2.3 platform, there is a TCS for the Mobile Profile, and a TCS for the TV Profile.  Each TCS precisely describes the profile-specific supported API set (including mandatory and optional elements) that devices must provide, as well as some additional necessary details such as codecs, mandatory and optional hardware elements and their relationship to APIs, and portability aids such as the feature and privilege declarations used by packages. This sets up a predictable environment to program applications for. The Tizen team wants to keep the number of profiles as small as possible, and to maintain a high degree of compatibility between versions.

What Does it Take to be a Tizen Device?

In order to complete the set of compliance deliverables, a series of tests are packaged together to confirm that a device actually follows the TCS. This is called the Tizen Compliance Tests (TCT).  Use of the Tizen trademark is tied to passing the TCS, and it’s designed as a self-test set of tools. Vendors are not required to pay authorized testing labs as they can run the tests themselves.

TCS and TCT are released together for each new Tizen platform version and matching profiles. Their combination clarifies what exactly it means to be Tizen. Applications do not have their own compatibility test, but app stores can force compliance with certain rules as a condition of submission.

I hope this article has made it clear what it takes for something to be a Tizen device. Check out the Tizen Compliance page to learn more about the program and to see the current specifications. In the next article on this subject, I’ll dive into some of the specific details of how applications can use Tizen Compliance to make portable Tizen packages.

Author: Mats Wichmann

Mats worked on compliance/compatibility programs for Tizen and the Open Interconnect Consortium (IoT).

2 thoughts on “An Introduction to Tizen Compliance”

Comments are closed.