Manifest Section
As described in Device Manifests, every kOS device boots from a manifest chain that describes the entire collection of KABs that make up the release. kOS will ignore all other KABs on the device and may even garbage collect other KABs if it needs space to install a new release.
However, while manifests define which KABs can be used, kOS has limited understanding of what to do with the KABs, leaving much of the policy to developer applications.
When KABs are added to a manifest, they are placed into named collections called sections.
By applying meaning to the section names, applications can easily apply fairly complex semantics to collections of KABs, which can be used for anything from loading multiple user interfaces to managing dynamically discovered content to loading platform plugins described by external systems.
System Application and Autostarts
The simplest example of this is the kOS system application.
Every kOS device must have exactly one system application which is the first application loaded by kOS during the boot process.
The kOS system application KAB is identified by placing it into a section called kos.system. kOS simply searches for this section and finds the first KAB with a type of kos.system and loads it.
This is the primary mechanism of handing execution to developer code once kOS boots.
Similarly, any section named kos.autostart.* will also be detected by kOS during the boot process. Each section will be examined for a KAB of type kos.app, and the app will be loaded automatically after the system app is loaded.
Developer Sections
For a simple device with a single system application, a single section may suffice, but a complex device may support multiple user interfaces that the user may switch between, or multiple sets of content, or even multiple applications that can be dynamically started and stopped as needed.
Each of these KABs may then depend on data in other related KABs.
Sections can be used to structure these KABs into meaningful groups with special meaning to the system application, which may then search or index these sections to determine what functions it can perform.
For example, consider a system application that supports plugins, where each plugin may contain both a user interface module and a back end java application. The device may even let the user select from the available plugins, dynamically loading each plugin when enabled, and unloading them when disabled. By using sections to gather these related KABs together it becomes quite simple to index and manage them. For example, the application may look for all sections named ui.plugin.* and simply examine each section for an application and ui KAB based on KAB type.
Chained Manifest Sections
The pattern searching for well known sections or sections with a known prefix also makes it very easy for external systems to inject customized content and functionality into a manifest chain.
This is because chained manifests have the ability to inject new sections of KABs into the effective manifest.
Continuing the plugin example above, a particular software release may ship with only one defined plugin, but, as the manifest passes through external systems, such as CMS or device management, each applying device specific rules, additional chained manifest may be created by each of these systems which include additional plugin sections.
When deployed onto the device, kOS presents a unified view of the manifest chain and the custom content and functionality will be automatically consumed by the developer application.
Again, while the concept of sections are quite simple, their ability to be injected in a controlled and secure way from external systems as part of a manifest chain makes them quite powerful.
