The Kernel Developer’s Guide describes how to create a MicroEJ Multi-Sandbox Firmware, i.e. a firmware that can be extended (statically or dynamically) to run and control the execution of new applications (called Sandboxed Applications).

The intended audience of this document are java developers and system architects who plan to design and build their own firmware.

Here is a non-exhaustive list of the activities to be done by Multi-Sandbox Firmware Developers:

  • Defining a list of APIs that will be exposed to applications
  • Managing lifecycles of applications (deciding when to install, start, stop and uninstall them)
  • Integrating applications (called System Applications)
  • Defining and applying permissions on system resources (rules & policies)
  • Managing connectivity
  • Controlling and monitoring resources

This document takes as prerequisite that a MicroEJ Platform is available for the target device (see Platform Developer Guide). This document also assumes that the reader is familiar with the development and deployment of MicroEJ Applications (see Application Developer Guide) and specifics of developing Sandboxed Applications (see Sandboxed Application).

Terms and Definitions

A System Application is a Sandboxed Application that is linked into a Multi-Sandbox Firmware.

A Multi-Sandbox Platform is a Platform with the Multi Sandbox capability of the MicroEJ Core Engine enabled (see the chapter Multi-Sandbox of the Platform Developer Guide). A Multi-Sandbox Firmware can only be built with a Multi-Sandbox Platform.

A Mono-Sandbox Firmware is produced by building and linking a Standalone Application with a Platform.

A Virtual Device is the Multi-Sandbox Firmware counterpart for developing a Sandboxed Application in MicroEJ Studio. It provides the firmware functional simulation part. Usually it also provides a mean to directly deploy a Sandboxed Application on the target device running a Multi-Sandbox Firmware (this is called Local Deployment). In case of dynamic application deployment, the Virtual Device must be published on MicroEJ Forge instance in order to execute an internal batch applications build for this device.

Overall Architecture

Firmware Boundary Overview

Firmware Boundary Overview

Firmware Input and Output Artifacts

Firmware Input and Output Artifacts

Multi-Sandbox Build Flow

Firmware Build Flow

The Firmware build is composed of two phases:

  • the build of the Kernel,
  • the build of Sandboxed Application which is linked and append to the Firmware as a System Application (repeatable).
Firmware Build Flow (Kernel + System Applications)

Firmware Build Flow (Kernel + System Applications)

Virtual Device Build Flow

The Virtual Device is automatically built at the same time than the Firmware (see Multi-Sandbox Firmware Creation).

The Virtual Device builder performs the following steps:

  • Remove the embedded part of the platform (compiler, linker and runtime).
  • Append Add-On Libraries and System Applications into the runtime classpath. (See Ivy Configurations) for specifying the dependencies).
  • Turn the Platform (MicroEJ SDK) license to Virtual Device (MicroEJ Studio) license so that it can be freely distributed.
  • Generate the Runtime Environment from the Kernel APIs.
Virtual Device Build Flow

Virtual Device Build Flow

Firmware Implementation Libraries

Firmware implementations must cover the following topics:

  • The firmware’s kernel entry point implementation, that deals with configuring the different policies, registering kernel services and converters, and starting applications.
  • The storage infrastructure implementation: mapping the Storage service on an actual data storage implementation. There are multiple implementations of the data storage, provided in different artifacts that will be detailed in dedicated sections.
  • The applications management infrastructure: how application code is stored in memory and how the lifecycle of the code is implemented. Again, this has multiple alternative implementations, and the right module must be selected at build time to cover the specific firmware needs.
  • The simulation support: how the Virtual Device implementation reflects the firmware implementation, with the help of specific artifacts.
  • The Kernel API definition: not all the classes and methods used to implement the firmware’s kernel are actually exposed to the applications. There are some artifacts available that expose some of the libraries to the applications, these ones can be picked when the firmware is assembled.
  • The Kernel types conversion and other KF-related utilities: Kernel types instances owned by one application can be transferred to another application through a Shared Interface. For that to be possible, a conversion proxy must be registered for this kernel type.
  • Tools libraries: tools that plug into MicroEJ Studio or SDK, extending them with feature that are specific to the firmware, like deployment of an application, a management console, …
  • System Applications: pre-built applications that can be embedded as System Apps into a firmware. Some of them are user-land counter parts of the Kernel, implementing the application lifecycle for the firmware’s application framework (e.g. the Wadapps Framework). These “Kernel System Applications” rely on a dedicated set of interfaces to interact with the Kernel, this interface being defined in a dedicated module.