Each IIP has a number of attributes:
All IIP names shall follow the following structure:
<company>-<type>[-<what>]
The <company> part may consist of lower-case letters and numbers only.
The <type> part may consist of lower-case letters and numbers only.
| Example | Description |
|---|---|
| hal | A Hardware Abstraction Layer. |
| platform | The KreaTV TV Software Platform. |
| app | Application registration package. |
| inst | Application installation package. |
| option | An option which usually gives the KreaTV IP-STB some extra feature(s). |
| tool | A tool which is used for testing/debugging purposes. |
| font | One or more fonts. |
| common | A package with parts that is shared between several other packages. |
| finalize | An IIP that is installed last. Finalizers usually does cleanup, verificiation of installation and other similar things that must be done when all normal IIPs have been installed. |
The <what> part may consist of lower-case letters, numbers and '-'.
The version of the IIP's content (such as binaries, e.g. firmware version). Is used for DBL IIPs (kreatv-update-dbl-...).
The build version has the following form:
<major>.<minor>[.<bugfix>][.<feature>][-<build>]
<major>, <minor> and <bugfix> are rather self explanatory. The <feature> is a string describing any additional functionality added. 2.1.hidden-navigator shall be seen as 2.1 with the addition of a hidden navigator. <build> is used if the same package has to be built again for example because of a build error the first time. It is then increased for each consecutive build with the same contents.
The build branch is a string containing the name of the branch from which the IIP is built. It is used for debug purposes only.
The build date is a string. It is used for debug purposes only. The format of the string is:
YYYYMMDD (%Y%m%d in Linux date command format)
The build time is a string. It is used for debug purposes only. The format of the string is:
hhmmss (%H%M%S in Linux date command format)
The architecture specifies which KreaTV IP-STBs the IIP is intended for.
Architecture has the following format:
<processor>[_<bootimage-compatibility>[_<DBL-compatibility>]]
Each architecture field specifies the target of the IIP even more. For instance, if the architecture string is empty, then the IIP can be used on any KreaTV IP-STB hardware or software. Examples of this are application registration packages.
An IIP can also be targeted at a specific processor (for example vip1500) in which case the IIP can be used on all KreaTV IP-STBs that use such processors. An example of this is the KreaTV TV Software Platform which can be used on different kinds of hardware with the same type of processor since the HAL abstracts away hardware differences.
IIPs designed to run on a specific hardware, add a bootimage-compatibility field (for example vip1500_11 for a KreaTV IP-STB 1510). A typical example of this is the KreaTV Hardware Abstraction Layer.
Dynamic boot loaders, DBLs, set up the hardware at boot. They may require yet more specific software. The DBL-compatibility field specifies this.
The valid values can be found in the architecture and compatibility.
Dependencies are used to specify the relationships between IIPs. This information is used when building boot images as well as when installing IIPs at runtime. At build time when adding an IIP to a boot image, the build_boot_image script will make sure that all needed IIPs are installed first (without explicitly mentioning them in the configuration). At runtime however, all dependencies (not dependency types) of an IIP are installed in parallell.
There are three types of dependencies, rootdisk- , execution- and finalize dependencies.
| Type | Description |
|---|---|
| Rootdisk | The rootdisk dependencies sets up the correct environment for the IIP and makes sure that the IIPs are installed in the appropriate order at buildtime. |
| Execution | The execution dependencies must be fulfilled in order to execute the content of an IIP. |
| Finalize | A finalize dependency can be specified in order to install a
finalizer IIP after all other IIPs at
build time.
Note! No guarantees are given that the finalizers are installed in a specific order, only that they are installed after all normal IIPs at buildtime. |
The division between the rootdisk- and execution dependency types makes dynamic IIP download, installation and uninstallation possible.
Example: A typical application has a registration IIP and an installation IIP, named "kreatv-app-name" and "kreatv-inst-name". The registration IIP is dependant of the IIP "kreatv-platform" at build time. When executing the application however, we also need the application binary which can be found in the installation IIP. This means that the registration IIP has a rootdisk dependency to "kreatv-platform" and an execution dependency to the installation IIP.
All dependency types are by default fulfilled when building a boot image. Execution dependencies can however be ignored. This is to facilitate dynamic IIP download, i. e. install the execution dependency when the e.g. the application shall be executed. The build_boot_image documentation has an example of this.
A finalizer is a special kind of IIP which at buildtime is installed after all normal IIPs. An IIP can specify that it has one or more finalizers that must be installed last.
The description of an IIP shall be in XML format. It also needs to contain all parameters of the IIP. Failing to do so will result in a build error when building a boot image.
| Tag | Valid values (bold is default) | Description |
|---|---|---|
| Iipdescription | String | Description of the IIP. |
| Parameter | Parameter tags | Container for the IIP parameters. |
| DependencyOnly | true | false | If set to true this IIP may only be used as a dependency for other IIPs. This is intended for IIPs that do not add functionality but only provide something needed by another IIP, for example shared libraries. |
| SanityCheck | true | false | If set to false, disable sanity checks on parameters. |
| Tag | Valid values | Description |
|---|---|---|
| Param | String | Name of parameter. |
| Repeat | Once | Multiple | The number of times the parameter can be repeated. |
| Example | String | Example use of the parameter. |
It is possible to include other xml files, see the example:
<Iipdescription>
Description goes here.
</Iipdescription>
<Parameter>
<Param>paramname</Param>
<Repeat>Once</Repeat>
<Description>
Parameter description goes here.
</Description>
<Example>paramname=thefileorvalueorwhateveryouwant</Example>
</Parameter>
<!-- @include /path/to/included/file -->
Each IIP can contain one or more installation scripts used to install the IIP under different circumstances. The different types of installation scripts included in an IIP defines its possible usage.
| Type | Description |
|---|---|
| buildtime | Used to install an IIP into a rootdisk at build time. |
| runtime | Used to install an IIP into a rootdisk at runtime using KreaTV Dynamic Download. |
You can write your own scripts if preferred. There are a number of predefined installation scripts available for the most common tasks of IIP installation:
| Name | Parameters | Description |
|---|---|---|
| copy_data_to_rootdisk | - | Used for simple IIPs that only need to copy some files into
the rootdisk.
Copies the data to the rootdisk. This means that the data needs to have the same directory structure as the rootdisk. |
| install_app_in_rootdisk | download | startinfront | start | uninstallable | |
Used for application registration packages.
Copies the data to the rootdisk. Registers the application in the Application Service. The prop(<name>)- parameters are used to remove default property values. Note that any values you set using prop(<name>)=<value> will also be removed. If extra installation is needed it is possible to add a script named extra/install to the data directory. Parameters not handled by install_app_in_rootdisk will be passed on to the extra installation script. At most one of the startinfront/start/download parameters is allowed for the same application. More information regarding the parameters can be found in the table below. |
These are the parameters that can be given to the install-app-in-rootdisk script:
| Parameter | Description |
|---|---|
| download |
The application will be downloaded (and installed) at platform
startup if this parameter is supplied.
This parameter requires the presence of the ignoredependency(execution)* parameter. Note! This parameter requires that application download is enabled on platform. |
| startinfront |
The application will be started in front at platform
startup. The application will also be downloaded and installed
if the ignoredependency(execution)* parameter is
supplied.
Note! At least one and at most two applications have this parameter set to true (in the latter case, one as an active popup-application and one as a visible application). Support for popup applications will be removed in TOI 2.1. |
| start | The application will be started at platform startup. The application will also be downloaded and installed if the ignoredependency(execution)* parameter is supplied. |
| uninstallable |
The application can be uninstalled from platform. Only one
uninstallable application is allowed to be installed on the
platform at a given moment. This means that the installation of
one uninstallable application will lead to the uninstallation of
another uninstallable application.
This parameter will add an <Uninstallable> property to the application property file included in the registration IIP. This parameter requires the presence of the ignoredependency(execution)* parameter. Note! This parameter requires that application download is enabled on platform. |
| The prop(<name>)=<value> parameters can be used to set/add properties in the application property file supplied to the Application Service. Note that any default value for a property (in the property file included in the registration package) will be replaced when using this parameter. | |
| The prop(<name>)- parameters are used to remove default property values. Note that any values you set using prop(<name>)=<value> will also be removed. |
* More info on ignoredependency(execution) can be found here.
| Name | Parameters | Description |
|---|---|---|
| move_data_at_runtime.sh | - | Used for simple IIPs that only needs to move some files into
the rootdisk.
Moves the data to the rootdisk rather than copies, this is to not "double up" the size of the IIP while installing. This also means that the data needs to have the same directory structure as the rootdisk. |
| install_ui_langs.sh | - | Installs UI languages for application installation IIPs
(kreatv-inst-...).
Finds all directories named "ui-langs" within the "data" directory of the IIP and copies the language files (eng.xml, swe.xml, spa.xml...) corresponding to the languages defined in the Information Service cfg.uilangs object (which is set by the IIP kreatv-option-ui-langs). English is always copied. |
The create_runtime_reg_app_script script is available
as a help script. It creates a runtime installation script for
application registration IIPs. The generated installation script will
register the application (to the Application Service) on the KreaTV
IP-STB using TOI Shell.
Usage:
create_runtime_reg_app_script <property_file_path> <script_destination>| Argument | Description |
|---|---|
property_file_path |
The application property file path as installed in the
rootdisk. Example: /usr/applications/tetris/properties_tetris.xml |
script_destination |
The destination path of the generated script. |
| Type | Description |
|---|---|
| runtime | Used to uninstall an IIP at runtime. |
The data is a number of files which the installation script can use to install the IIP in a rootdisk. It can copy the files, use them as data source or as extra scripts to apply on the rootdisk.