When working with mobile operating systems, a developer will typically pick the hardware they are targeting so they can test. When building your own device there is no pre-defined list of devices to select from so KOS Studio provides a way to define a new target device. For a single node device, this is a simple process of defining the device type and some hardware characteristics. For multi-node devices*, this provides a way to define the overall shape of the device. What types of nodes are there, how many of each node, are some nodes optional, and so on. This allows studio to know what a release looks like, how to simulate your device and define all the areas that need to be configured to build a working device.

KOS is an assembly based operating system that uses collections of artifacts referenced by a manifest. To support this, KOS has a standard format for all artifacts which is a KAB file. This is a file that contains files, similar to a zip, but has a type, is digitally signed and is uniquely identified by a UUID. Everything in KOS is a KAB, including the Linux kernel. Being assembly based, any device can be installed from a manifest and the collection of KABs referenced in the manifest. As there is no build step to construct a monolithic image, it is very easy to swap out individual KABs for testing.

To facilitate the distribution of KABs and avoid the need to manually share KABs between developers, KOS Studio provides a KAB registry in the form of artifacts and instances. Each organization can define artifacts that represent the components they are building, and then use the KOS Studio provided publish tool on their build server to tell KOS Studio that the KAB exists, what version it is, and where it was placed. Users can then browse this registry and build manifests by selecting artifacts from the registry. KOS Studio can then automatically download all the required KABs when the user wants to run a particular device. The tooling will track versions, architecture types, and so on, so that the correct KABs are downloaded for the correct target, allowing any user to run any device in a simulator or on real hardware without needing to install anything other than KOS Studio.

As KOS is entirely manifest driven, a key focus of KOS Studio is to provide tools for constructing manifests in the form of images. An image is a way to describe everything that should be in a manifest, including where to get the KABs from, which versions, which architectures and so on. A single device many have multiple images available to choose from. For example, one image may include all the latest build artifacts from the build server. This can be used by QA to test the latest build with a single click of a button. Another image may combine build server artifacts for java components with UI KABs from local disk, directly from a developer source tree, allowing real time testing of local code. Images are shared across the organization allowing standard images to be setup for certain use cases and the consumed by the team. It’s even possible to create child images from another image, allowing the user to quickly inherit everything in the parent image but just change one thing for testing. This is a very easy way to leverage a shared team image to quickly try a new version of KOS without impacting the rest of the team.

KOS Studio is a collaborative environment. All instances of KOS Studio in an organization are synchronized in real time, ensuring changes propagate to the entire team instantly. Many features in studio are designed to facilitate and streamline common use cases. For example, when adding a new java developer to the team, they need to install tools and checkout source trees. Using the KOS Studio team direct shortcuts feature, an image can be setup to use relative paths within a source repository. When a new user tries the use the image, the are asked to provide the base directory to the source tree on their local disk and the image will be available to run.

KOS Studio also supports tags, allowing users of various roles to automatically see related devices and images. There is support for multiple projects with user level access controls to allow different groups to work together or independently. Users can even be members of more than one organization, which drastically streamlines working with partners.

One of the highest friction interactions when working with hardware is deploying new software onto a device. KOS Studio makes this as easy as picking a target from a list and hitting the run button. KOS provides standard bootloaders for various boards and these are installed using the standard board vendor procedure. Once installed, all future updates can occur directly from KOS Studio. Even when using the same device image on different targets (x86 simulator on laptop, arm single board computer, etc…) KOS Studio probes the target and selects the correct variant of each artifact to make sure what gets installed matches the target, resulting in a seamless experience for the end user regardless of hardware type.

The application-centric model of KOS opens the opportunity to develop reusable applications that can be used by multiple organizations. To this end, KOS Studio includes support for a digital market in which artifacts can be made available to other organizations. Market artifacts can either be public or restricted. Public artifacts are available to everyone while restricted artifacts can be granted on a per-organization basis. Artifacts in the market behave the same as local artifacts. Users can select them for inclusion in an image and they will automatically be downloaded and installed like any other artifact.