Many development platforms provide studio applications. These are typically development tools geared towards writing and debugging software. KOS also provides a studio application, but the focus is less on the development process and more on device-level processes such as defining a device, constructing a release, and deploying to a simulator or real hardware. There are plenty of robust IDEs for developers, and a key objective of KOS is to meet developers where they are. This means allowing developers to use their favorite tools in the same way they would for typical desktop development. KOS Studio focuses on the high friction areas of device development, which typically exist around building a release that can be deployed in a simulator or on real hardware for testing and then providing tools to interact with that device. The sections below outline key functionalities in KOS studio that make the development process more manageable.
Device Definition
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 the studio to know what a release looks like, how to simulate your device, and define all the areas that need configuring to build a working device.
Artifacts and Images
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: a KAB file. This file contains files similar to 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, swapping out individual kabs for testing is easy.
To facilitate the distribution of KABs and avoid manually sharing 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 installing 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 may have multiple images available to choose from. For example, one image may include all the latest build artifacts from the build server. QA can 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 a 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 set up for specific use cases and consumed by the team. It’s even possible to create child images from another image, allowing the user to inherit everything in the parent image quickly but change one thing for testing. This is a straightforward way to leverage a shared team image to quickly try a new version of KOS without impacting the rest of the team.
Collaboration
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 the studio are designed to facilitate and streamline common use cases. For example, when adding a new Java developer to the team, they must install tools and check source trees. Using the KOS Studio team direct shortcuts feature, an image can be set up to use relative paths within a source repository. When a new user tries to use the image, they 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 see related devices and images automatically. 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 multiple organizations, drastically streamlining working with partners.
Deployment
Deploying new software onto a device is one of the highest friction interactions when working with hardware. 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 that 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.
Market
The application-centric model of KOS opens the opportunity to develop reusable applications that multiple organizations can use. To this end, KOS Studio supports a digital market where artifacts can be available to other organizations. Market artifacts can either be public or restricted. Public artifacts are available to everyone while restricted artifacts can be granted per organization. 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.