
The KOS Studio application is the primary piece of the development environment for KOS software developers.
KOS Studio:
Is an application (Windows or Mac) that runs on a software developer’s workstation
Allows developers to define and package up KOS applications
Allows developers to share components with each other
Provides the ability to test KOS apps by running inside a built-in simulator
Provides the ability to deploy apps to actual hardware (for example, a Raspberry Pi SBC)
Does not provide an IDE or code editor
Allows you to debug and step through your code by working with your IDE
To get started, your organization must have a KOS account, which involves the following steps:
Your organization is created by the KOS administrator
Your organization’s leader is given an administrative account
Your organization’s administrator adds and removes user (developer) accounts
To install Studio, follow the instructions on the Install KOS Studio page.
Your organization’s account and information about its projects are stored on the KOS Studio Server, illustrated in the following diagram.
This section introduces terms and concepts that must be understood before higher-level subjects make sense. Later articles go into detail about each of these concepts and why they are needed.
A KOS application (app) is a complete set of code and dependencies that executes on the KOS runtime system. Some components of an application include:
Linux kernel, initrd, and base file system (always required)
Java runtime
Chromium browser
artifacts from your team, the market, or yourself
Your custom backend Java code
Your custom frontend React code
Your custom native C code
Applications are packaged into an image which is executable in both the built-in simulator and on real hardware.
An image is a series of KOS components stacked up to make a runnable operating system stack. Using Studio, that stack can be executed inside a simulator on your desktop computer, or can be pushed to a piece of hardware, for example, a Raspberry Pi. Studio makes these two (simulator and hardware) interchangable.
Each of these stackable components in an image is also known as a "card". Here’s what they look like:
We will learn a lot more about these cards as we progress.
A KAB (KOS archive bundle, pronounced "cab") is a single file that contains an uncompressed collection of other files. Each KAB is digitally signed and tagged with metadata for use within the KOS ecosystem. Everything in KOS is packaged in a KAB file, and these KABs are assembled into applications. For more info, see Concept: KAB Files.
A layer is a KAB file of type "kab.layer" that contains a single squashfs file, which is a compressed read-only file system, mountable by Linux. Any number of layers are joined together in a "union", which allows a larger file system to be composed of individual pieces.
The KOS API is a set of classes, interfaces, and annotations that you use to compile your Java code against.
There are three APIs: core, dispense, and freestyle. Core is always required, while dispense and freestyle are optional extensions.
Here’s how they would appear in your Java project’s Maven POM file:
<dependencies>
<dependency>
<groupId>com.kosdev.kos.sdk.api</groupId>
<artifactId>api-core</artifactId> (1)
<version>${kos.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.kosdev.kos.sdk.api</groupId>
<artifactId>api-dispense</artifactId> (2)
<version>${kos.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.kosdev.kos.sdk.api</groupId>
<artifactId>api-freestyle</artifactId> (3)
<version>${kos.version}</version>
<scope>provided</scope>
</dependency>
</dependencies>
1 | The core API is required |
2 | The dispense extension is optional |
3 | The freestyle extension is optional |
Version numbers must match
The version number of each API must be identical. |