IIP Attributes

Each IIP has a number of attributes:

Name - The name of the IIP.
Content version - The version of the IIP's content (such as binaries, application, firmware).
Architecture - The hardware/software architecture the IIP is intended for.
Version - The build version of the IIP.
Branch - The branch which the IIP was built on.
Date - The date when the IIP was built.
Time - The time when the IIP was built.
Dependencies - Specifies what other IIPs are required for this IIP to work.
Description - An XML file describing the IIP and it's parameters.
Installation scripts - One or more scripts used to install the IIP in a boot image at buildtime or at runtime.
Uninstallation script - A script used to uninstall the IIP at runtime.
Data - Files used by the installation script(s).

Name

All IIP names shall follow the following structure:

<product or vendor>-<type>[-<what>]

Product or vendor

If IIP is created by Motorola you'll see the word kreatv here, i.e. the name of the software stack. Put vendor, middleware or company name here if IIP is not created by Motorola. This part may consist of lower-case letters and numbers only.

Type

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.
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. More on finalizer IIPs is in IIP Building.

What

The <what> part may consist of lower-case letters, numbers and '-'.

Examples

kreatv-app-webkit: Webkit browser application.
kreatv-option-usb: USB support as an option.

Content version

The version of the IIP's content (such as application, binaries, firmware). Is used for DBL IIPs (kreatv-update-dbl-...).

Content version attribute is specified with iip_build option --content_version.

Version

The build version can have the following formats:

General KreaTV release version format: <major>.<minor>[.<flavour>][.<candidate>]
You will see this version if release is built upon a general KreaTV release. <major> and <minor> are rather self explanatory. The <flavour> is a string holding the flavour of this major.minor release. It may be the name of a release. <candidate> lists a release candidate number.

Development drop version format: <branch>.<revision>
A development drop IIP may have this version format. Specified is software branch name and KreaTV repository revision.

Custom format:Version format can be the result of an agreement with a customer or partner.

Examples

4.3: Release 4.3.
4.3.turtle.5: Release candidate 5 of 4.3 with flavour turtle.
trunk.205123: Revision 205123 of branch trunk.
Meatball.1.2: Customer release Meatball with version 1.2.

Version attribute is specified with iip_build option --version.

Branch

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.

Branch attribute is specified with iip_build option --branch.

Date

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)

Date attribute is specified with iip_build option --date.

Time

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)

Time attribute is specified with iip_build option --time.

Architecture

The architecture specifies which KreaTV STBs the IIP is intended for.

Architecture consists of:

Processor
Hardware compatibility
Firmware 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 STB hardware or software. Example of such an IIP would be one holding only configuration files.

Processor, hardware and firmware compatibility is further explained in the architecture and compatibility section.

Architecture is specified with iip_build options --processor, --hw_comp and --fw_comp.

Dependencies

Dependencies are used to specify the relationships between IIPs. This information is used when building boot images and also 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.

Dependency types
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.

The build_boot_image command makes sure that the IIPs are installed in the correct order if the dependencies are correct. All dependency types are by default fulfilled when building a boot image. Note that circular dependencies are strictly forbidden, they will cause the KreaTV IP-STB to fail.

Dependencies are specified with iip_build option --depends.

Description

The description of an IIP shall be in XML format. It holds a text describing what the IIP is good for and also a definition of all IIP parameters. Not specifying an IIP parameter used in a boot-image build results in a build error.

Description tags
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. DependencyOnly IIPs are not shown in SDK IIP documentation.
SanityCheck	`true \| false`	Set to false to disable sanity checks on parameters. Is true if not specified.

Parameter tags
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 -->

Description data is built into the IIP with iip_build option --description.

Installation

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.

Installation types
Type	Description
buildtime	Used to install an IIP into a rootdisk at build time (i.e. when building the rootdisk/boot image). The build_boot_image script which combines IIPs into a rootdisk and a boot image allows parameters to be sent to the installation script. These parameters can e.g be used to install different parts of the IIP or to configure the installed parts.
runtime	Used to install an IIP into a rootdisk at runtime using KreaTV Dynamic Download. Several runtime installation scripts can be used for the same IIP. If so, they will be appended to each other into one script in the order specified in the argument list given to the `iip_build` script.
kit	Used to install an IIP into a KreaTV SDK. This type is only used internally at Motorola.

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:

Buildtime installation scripts

IIP buildtime installation scripts.
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 \| prop(<name>)=<value> \| prop(<name>)-`	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:

install-app-in-rootdisk script parameters
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.
`prop(<name>)=<value>`	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.
`prop(<name>)-`	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.

Runtime installation scripts

IIP runtime installation scripts.
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.

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 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.

Installation scripts are built into the IIP with iip_build option --install.

Uninstallation

Each IIP can contain an uninstallation script to be used for uninstalling the IIP at runtime with KreaTV Dynamic Download. This script is used for application installation IIPs.

Uninstallation types
Type	Description
runtime	Used to uninstall an IIP at runtime.

The uninstallation script has to be individually written for every IIP.

Uninstallation scripts are built into the IIP with iip_build option --uninstall.

Data

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.

The layout of the data depends on its intended usage:

All files shall be copied into a rootdisk

In this case it is easiest to use the same layout in the data dir as in the rootdisk. You can then use the copy_data_to_rootdisk installation script which will copy the data into the rootdisk at build time.

This can also be done at runtime and the script to be used then is the move_data_at_runtime.sh installation script.

Only some files shall be copied to the rootdisk

In some cases it it easier to make an IIP installing only some of its files depending on the IIP parameters used. A typical example is the kreatv-option-streamclients IIP which installs one or more stream clients.

In this case you can use any layout of the data directory that you desire and let the installation script install it in the correct place in the rootdisk. You must write your own installation script to make this work.

Only modify the rootdisk

Some IIPs only modify the rootdisk. A typical example is the kreatv-tool-logging IIP which creates a file in the /etc directory based on the parameters given to the IIP.

In this case it is not necessary to have a data directory (it would be empty) so don't create one.

Data directory is specified with iip_build option --data_dir.