Motorola Mobility Confidential Restricted.

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 its 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 an IIP is created by Motorola, you will see the word kreatv here, i.e. the name of the software stack. Put vendor, middleware or company name here if the IIP is not created by Motorola. This part may consist of lower-case letters and numbers only.

Type

The <type> part may only consist of lower-case letters and numbers.

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 are shared between several other packages.
finalize	An IIP that is installed last. Finalizers usually perform cleanup, verification 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>[.<flavor>][.<candidate>]
You will see this version if release is built upon a general KreaTV release. <major> and <minor> are rather self explanatory. The <flavor> is a string describing the flavor 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 flavor 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 containing 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 parallel.

There are three types of dependencies: rootdisk, execution and finalize.

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 depends on the IIP "kreatv-platform" at build time. However, when executing the application, we also need the application binary, which can be found in the installation IIP. This means that the registration IIP has a rootdisk dependency on "kreatv-platform" and an execution dependency on 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 is XML file with a textual description of the purpose of vhe IIP and also a definition of all available parameters to the IIP. All possible IIP parameters must be documented (unless AllowAnyParameters is specified).

XML elements in an IIP description file
Element	Valid values	Required	Description
Description	Any string (possibly containing escaped HTML text)	Yes	Description of the IIP.
Parameter	See the table below	No	An optional parameter to the IIP.
DependencyOnly		No	Add this element to indicate that this IIP only may 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 the SDK IIP documentation.
AllowAnyParameters		No	Add this element to indicate that any parameters can be specified for the IIP. If not present (i.e. by default), only parameters described in the Parameter elements are allowed for this IIP. Usage of AllowAnyParameters is not recommended since less consistency checks will be performed.

Parameter elements
Element	Valid values	Required	Description
Name	String	Yes	Name of the parameter.
Description	Any string (possibly containing escaped HTML text)	Yes	Description of the IIP.
Repeat	`Once \| Multiple`	No	The number of times the parameter can be repeated.
Default	String	No	Default value of the parameter. If present, a parameter with this value will be sent to the install script unless the parameter is explicitly specified in the boot image configuration.
Example	Any string (possibly containing escaped HTML text)	No	Example use of the parameter.

It is possible to include other XML files with a special @include comment syntax (see the example below).

Example


<IipInterface>
  <Description>
    Description goes here. <![CDATA[<b>Note</b>: If you want to
    include HTML markup in any of the Description or Example fields, you must
    quote it, preferably using the
    CDATA construction.]]>
  </Description>
  <Parameter>
    <Name>paramname</Name>
    <Repeat>Once</Repeat>
    <Description>
      Parameter description goes here.
    </Description>
    <Default>somedefaultvalue</Default>
    <Example>paramname=thefileorvalueorwhateveryouwant</Example>
  </Parameter>
  <DependencyOnly/>
  <AllowAnyParameters/>
  <!-- @include /path/to/included/file -->
</IipInterface>

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