In previous concepts we visited KAB files and how KOS is an assembly based platform that is driven from a manifest. This document describes manifests in a bit more detail, including the various types of manifests and how they work together to allow delegation of authority to allow external systems, such as device management platforms, to customize releases on a per-device basis. This provides the underlying capability for rules engines to customize content / app delivery without requiring custom software builds.

A KOS release is defined using KOS Studio and consists of collections of KABs in named groups called sections. Some section names have special meaning within KOS, such as the kos.system section which contains the system application, while other sections have developer defined names and can be used for any developer defined purpose. One common pattern is to look for data in one section and then fall back to default data in another section if the first section is not available. This simple concept forms the basis of a customized release. Developers simply need to decide what types of customization they want to support and define section names that can be used for overrides. Building this release from KOS Studio results in a manifest no custom content as none of the override sections actually exist. However, the resulting device manifest KAB is created, contains the list of KABs required to run the device in default mode, is properly signed by your organization and will be bootable on your device.

Knowing the UUID of the device manifest KAB, it’s possible for another system, such as device management, or content generation system to define another manifest that adds content to the device manifest. This type of manifest is called a chained manifest because it contains the UUID of the manifest that it builds upon. The chained manifest does not actually need the original manifest, it can simply take metadata about the device, such as who owns it, where it’s located and so on, and add sections to the chained manifest. This manifest is then generated as a KAB and the UUID of this KAB can be used to install the device. KOS will pull down all the manifests in the chain, evaluate all the sections from all the manifests to construct the actual running manifest on the device, which now contains custom content or applications. This process is not constrained to a single chained manifest which means that a given device may be customized in many ways across multiple external services and the device simply needs to know the UUID of the first manifest in the chain to install everything.

This description is somewhat simplified as there are controls in place to ensure that only trusted manifests signed by known organizations can actually add content, and even then, in a developer defined way that can never disrupt the underlying device manifest. However, it illustrates one of the key advantages that come from an assembly based build and the ease of stacking custom content on top of a base release.