FAQ

Frequently asked questions during Kernel and Applications development.

Glossary

App(s)/Application(s): Short for Sandboxed Application.

Security & Sandboxing

How is Applications’ code isolated from the rest of the device code?

The MEJ32 container executes the so-called Managed Code, where there are no instructions to directly manipulate memory pointers.

Also, read and write memory accesses are only performed in dedicated memory sections, statically defined at link time. See the list of MEJ32 sections.

How do we protect against malicious code injection in the App?

Any built app binary goes through the Binary Code Verifier tool, that rejects any noncompliant code, stopping the Application binary build process.

After verification, the pre-linked app must be placed in a location where its integrity is maintained.

An on-device signing and checksum comparison is usually set up before execution to enforce integrity checks.

Can you outline what the Application integrity check does?

For Applications installed in persistent memory, the integrity check is performed at MEJ32 boot time.

It is a checksum-based computation on the linked App(s)’ content. This ensures the App’s code has not been altered after the installation phase.

See Feature Persistency sequence diagram for more information.

Are the Apps Signed?

Yes, MicroEJ provides an app signature mechanism. After the build process, the application binary (.fo) is signed (the .fo file is wrapped in a .sfo file).

Once the application is available on the device, the .sfo authenticity is verified before installing it.

Contact our support team for implementing this feature in your product.

I want to open app development to 3rd parties. How can I control API access from Apps?

API access can be controlled at different levels:

Build time: the Kernel declares the list of APIs exposed to the Apps (see Kernel APIs).
Runtime: the Kernel provides APIs access control using the Standard Java Security Manager mechanism.

All standard libraries implement a security checkpoint before accessing native resources (e.g., Socket creation, File access, …).

You can add your own security checks for custom Kernel APIs. See instructions in Implement a Security Manager Permission Check and Define a Security Policy.

Any recommendation about app deployment?

Just like any data sent over the devices, the app must be transferred through a secure channel. This is usually done automatically when the app is transferred using a protocol that natively supports encryption (e.g. TLS/HTTPS…).

Additionally, the App .fo file can be encrypted before being sent to the network and decrypted on the device using the crypto APIs.

What kind of isolation exists between applications?

MEJ32 implements the Kernel & Features Specification (KF), ensuring applications are fully isolated from each other by design. Applications cannot keep direct references to objects, threads, code, resources owned by other Applications, allowing the Kernel to dynamically stop / uninstall an application at any time and in any application state.

Also, Applications can only call their own code and the Runtime Environment API methods that are explicitly exposed by the Kernel. They don’t have access to other device code.

Inter-App Communication & APIs

How can Applications communicate with each other?

The Kernel & Features Specification (KF) provides a built-in mechanism called Shared Interfaces.

This mechanism allows 2 or more Apps to self-define an API contract using Java Interfaces, without involving the Kernel.

How can we get and differentiate installed applications?

When the Kernel installs an Application, it returns a Feature object that represents the application. On a Feature object, you can get the Application’s information (name, version, …). The Kernel can retrieve the list of all installed Applications using Kernel.getAllLoadedFeatures().

How can I implement specific Kernel Policies depending on the calling Application?

In the Kernel code, you can get the API method caller at any time using Kernel.getContextOwner().

For example, in the Security Manager check method, it is used to set up a specific security policy depending on the calling application.

Is there a way to extend Kernel APIs? (provide new APIs in new libraries dynamically)

The Kernel APIs are fixed and cannot be extended directly. Updating a Kernel API requires updating the Kernel.

Scheduling & Resource Management

What is the behavior of the scheduler when several apps are running?

The Core Engine uses a priority-preemptive scheduling policy with round-robin time-slicing for equal-priority threads, see Scheduler for more information.

All threads have the same priority by default, so none will prevent the others from executing. However, a thread’s priority can be customized either when creating the thread with a specific constructor or dynamically by calling Thread.setPriority().

In a Multi-Sandbox context the Kernel can restrict Applications from setting their own thread priority, the possible approaches are:

Remove the Thread.setPriority() API from the Kernel APIs, to prevent the Apps from calling it.
Pre-define Applications’ thread priority range in the Kernel, controlled by Security Manager permissions, see Applications Security Policies for more information. Allowing Applications to define their own thread priorities within the allowed range.

A typical thread priority policy:

The Kernel runs with the highest thread priority, allowing it to execute code at any time.
All the Apps have the same priority, and the round-robin ensures that they are all executed.

Moreover, the Execution Quota mechanism allows allocating CPU usage per application. That way, even if an Application runs with a higher priority thread compared to others, it will be paused when its Execution Quota is reached, to let the others run.

To achieve that, a Kernel can assign an Execution Quota to an application using Feature.setExecutionQuota().

App Deployment & Compatibility

How is Application compatibility ensured to prevent runtime linking errors?

By default, an Application is built on the Kernel it is intended to run on. If the Application build succeeds, the Application is guaranteed to run on the Kernel it has been built on.

An Application built over Kernel N can remain compatible with a future Kernel N+1, provided that Feature Portability Control is enabled.

If Kernel N+1 becomes incompatible with the Application, the Kernel build will fail to prevent incompatible Kernels to be generated.

What happens if a `.fo` is found to be incompatible? Is there an event or programmatic way to detect this?

During the installation (calling Kernel.install() method), the system raises an Exception if an incompatibility is detected. The Kernel can handle it programmatically (e.g., by logging the error, notifying a management server, deleting the incompatible app, …).

My Kernel exposes the `widget` library as a Kernel API. My application has a dependency on the `widget` library. Will the code of the library be embedded into my app?

No. According to the Class Spaces, from Kernel & Features semantics, a class exposed as a Kernel API is considered before a class loaded from the application classpath. So the widget library will not be embedded twice.

However, if only a subset of the widget library classes are open as Kernel APIs, all other classes used by your Application will be embedded into your Application code.

Can I pre-install applications in my device firmware?

Yes, a pre-installed Application is actually an Application that has already been installed on the device, and is available at its first startup.

To achieve that, refer to Preinstalled Applications documentation.

Can the Kernel access the app’s resources before they are started?

Yes, the Feature.getResourceAsStream(“resource_path”) method allows access to resources as soon as the app is installed (not yet started).

How to access application metadata before installing it? (e.g. name, version, description)

The metadata should be provided alongside the Application binary during deployment. Then, a custom mechanism should be implemented, often related to the manufacturer device update infrastructure.

As an example, the metadata can be wrapped with the Application binary in a .zip archive.

Can I stop an Application at any time?

Yes, the KF specification ensures isolation between Applications.

It allows stopping an Application at any time, independently of the other ones running, even if inter-application calls are on-going (cf. Shared Interfaces). In that case, the connection is stopped and an Exception is raised and caught by the caller application.

When an application is stopped, a hook allows the Kernel to clean up any remaining Application’s object references before uninstallation (listeners, services, callbacks, …).

Can applications be used across different manufacturers?

Yes, an Application is bundled and distributed in a standard binary-portable format (Java bytecode).

Such Applications can be built on any Kernel manufacturer providing the same API level, independently of the implementation.