Building an Android-like Platform for Embedded Linux Devices — Without Docker

Every embedded Linux project seems to start the same way:

SSH into the device
Install dependencies
Configure services
Set up OTA updates
Handle networking
Build custom APIs
Repeat everything again for the next project

After rebuilding the same infrastructure multiple times across different edge and IoT projects, we decided to create a platform that abstracts all of that into a unified runtime.

That platform became Orbit OS.

What is Orbit OS?

Orbit OS is an embedded Linux platform designed to bring an Android-like experience to edge devices such as Raspberry Pi systems and other ARM-based hardware.

Instead of using Docker containers, Orbit OS uses a lightweight native runtime called Gravity RT and a custom package format called .orb.

The idea is simple:

Install Orbit OS once, and the device gains:

Remote application deployment
OTA updates
Fleet management
Sandboxed applications
Unified hardware APIs
Built-in Edge AI support (TFLite & ONNX)
Application Store
Real-time remote development tools

Why Not Docker?

Most existing edge platforms are built around containers.

Containers are powerful, but for constrained edge devices they also introduce additional RAM, storage, startup, management overhead, and OTA size.

Orbit OS was designed for environments where devices may only have 128–256MB of RAM available.

Instead of Docker, applications run directly through Gravity RT using lightweight .orb packages (like Android .apk).

This allows:

Lower memory usage
Faster startup
Smaller packages
Native hardware access
Simpler deployment model

Gravity RT Architecture

Gravity RT runs on top of an existing Linux distribution and acts as the system runtime for all applications.

Core architecture:

Hardware
└── Linux
    └── Gravity RT
        ├── Gravity Server (Go)
        ├── gRPC APIs
        ├── UDS communication
        ├── mTLS external APIs
        ├── Lazy-loaded JVM
        ├── Lazy-loaded Python VM
        └── Built-in TFLite and ONNX runtime
            └── Orbit OS Ecosystem
                ├── Unified Multi-language .orb packages
                ├── Orbit Studio
                ├── Orbit OS Store (Certified Aplications)
                └── Orbit OS HW Marketplace* (Certified Hardware Devices)

The Gravity Server is written in Go and remains always active as the parent process for all .orb applications.

It manages:

Application lifecycle
Restart policies
OTA coordination
Security
Logging
Package management

Real-Time Remote Development

One of the most interesting parts of Orbit OS is the development workflow.

Traditional embedded development usually looks like this:

Write code → Compile → Deploy → Run → Debug → Repeat

Orbit OS changes this model completely.

With Orbit Studio (VS Code extension), developers write code locally while executing directly against real hardware in real time.

Laptop
├── Write code locally
├── SDK connects to device via gRPC/mTLS
├── Code runs on live hardware instantly
├── Logs stream back in real time
└── Generate the .orb package only when ready

The device becomes a real-time execution target instead of a deployment target.

No SSH.

No file transfers.

No deployment loop during development.

▶️ Orbit OS — Orbit Studio First App | Real-Time Remote Development, GPIO LED Control & Deploy

The .orb Package Format

Orbit OS applications are distributed as signed .orb packages.

A package contains:

Executable binaries
NV data like AI models
Resources
Manifest
Cryptographic signatures

The structure is intentionally similar to Android APKs.

Built-In Edge AI

TensorFlow Lite and ONNX support are included directly in the platform,
accessible via the AI Manager SDK API.

Applications do not need to bundle inference runtimes or manage dependencies.
Apps only bring the model and the logic — the platform handles the rest.

The AI Manager automatically selects the correct backend based on the model type:

.tflite models → TensorFlow Lite runtime
.onnx models → ONNX runtime

Current AI applications already available in the Store:

YOLOv8 object detection
Face recognition

All inference runs locally on-device. No cloud. No external APIs.

OTA Updates

Orbit OS uses OSTree for runtime updates.

This provides:

Atomic updates
Rollback support
Immutable runtime layers
Safe recovery

The runtime can update itself without rebooting the full Linux system.

Orbit OS Store

Orbit OS includes a centralized application store where developers can publish .orb applications and users can remotely install them across devices linked to their account.

Features currently implemented:

One-click installation
Remote deployment
App updates
OTA runtime updates
Fleet management
Multi-device deployment

Apps Available Today

KS0212 4-Channel Relay Shield — Web UI, Modbus TCP server, MQTT with Home Assistant auto-discovery. One click, zero configuration.
Mochi MQTT Broker — Lightweight MQTT broker with integrated Web UI. Configure ports, users and settings from the browser.
Edge AI — Smart Image Detection — YOLOv8 COCO object detection using TFLite. Runs locally, no cloud, no external APIs.
Edge AI — Face Recognition — Real-time face recognition with any connected camera. Enroll faces in under 10 seconds. 100% offline.
MCP Server — Manage your device with AI Agents.
And more...

App Example — Edge AI Smart Image Detection

Edge AI – Smart Image Detection is an Orbit OS application that performs
real-time object detection locally on edge devices using YOLOv8 TensorFlow
Lite models.

Users can remotely install the application from the Orbit OS Store with a
single click on any device linked to their account.

After being installed in seconds, users can upload images directly from the browser, detect and label objects with bounding boxes, inspect inference timing, and view the raw JSON output generated by the AI service.

The application runs entirely on-device through the Orbit OS AI Manager API using YOLOv8 / COCO TensorFlow Lite models, with no cloud processing, Docker containers, or manual setup required.

This video demonstrates the application running simultaneously on two different devices: a Raspberry Pi 5 vs Arduino UNO Q.
Same App, same Model. Different hardware, different performance.