Why We Chose Linux Over Android for the HoloBox

We chose Armbian — a Debian-based Linux distribution optimized for ARM single-board computers — over Android for the Jinn HoloBox because it gives us full control over the software stack, lower baseline memory usage, and a 10+ year update path without depending on Google's release cycle. This decision shaped everything from our boot time to our update mechanism, and it came with real trade-offs we had to engineer around.

Why do most smart displays run Android?

It is a fair question. The Amazon Echo Show, Google Nest Hub, and most Chinese smart displays run Android or Android-derived systems. Android offers a mature touch UI framework, a massive app ecosystem, a well-understood security model, and millions of developers who know how to build for it.

According to a 2025 analysis by MicroEJ, Android remains the dominant choice for consumer-facing embedded devices that need polished touchscreen interfaces, particularly in smart home, digital signage, and wearable markets.

So why did we go the other way?

What are the concrete advantages of Linux for the HoloBox?

Lower memory footprint

This was the deciding factor. Our RK3566 has 4 GB of RAM, and our application stack (Chromium, Node.js, Go) is already memory-hungry. Android's framework layer — the Java runtime (ART), SurfaceFlinger compositor, SystemUI, and system services — consumes 800 MB to 1.2 GB before a single app launches.

Armbian's base system boots into roughly 180-250 MB of RAM usage (kernel + systemd + core services). That gives our application stack an extra 600-900 MB of headroom compared to Android — the difference between a smooth experience and OOM kills.

Faster boot time

The HoloBox is an always-on appliance, but it does reboot — for updates, after power outages, or during debugging. Armbian boots to our application UI in approximately 12 seconds on eMMC. An equivalent Android AOSP build on the same RK3566 hardware took 28-35 seconds in our testing, primarily because of Zygote preloading and the ART compiler warming up.

For context, Amazon's first-generation Echo Show (2017) was reported to take 45+ seconds to boot. While newer models are faster, the Linux advantage in boot time is structural — there is simply less framework to initialize.

Predictable long-term updates

This is the hidden cost of Android in embedded devices. Google releases a new Android version annually, and each release can introduce breaking changes to the HAL (Hardware Abstraction Layer), requiring BSP (Board Support Package) updates from the SoC vendor. Qualcomm's 2024 developer documentation notes that Android BSP updates typically take 3-6 months to validate for a new Android version, and many SoC vendors stop providing them after 2-3 years.

Armbian, built on Debian stable, follows Debian's release cycle with 5+ years of security support per release. More importantly, kernel updates are decoupled from userspace updates. We can upgrade from Linux 6.12 to 6.18 without rebuilding our entire application stack — something that is practically impossible on Android without a full BSP refresh.

Direct hardware access

On Android, accessing hardware peripherals (GPIO, I2C, SPI, DSI) requires going through the HAL or writing custom JNI bindings. On Linux, hardware is exposed through standard interfaces: /dev, /sys, sysfs, and device tree overlays.

When we needed to tune DSI display timing parameters to fix a horizontal wrapping artifact on our panel, we could modify device tree properties, rebuild the overlay, and test within minutes. On Android, this would have required modifying the HAL, rebuilding the system image, and flashing — a cycle measured in hours.

What did we give up by choosing Linux?

Honesty matters here. Choosing Linux cost us real things:

No native touch UI framework

Android's View system, Material Design components, and touch gesture handling are best-in-class. On Linux, there is no equivalent out of the box. Our solution: we render the entire UI in Chromium (kiosk mode) using Next.js. This works well — web technologies are excellent for UI — but it means we carry the full weight of a browser engine. Chromium on ARM is not lightweight: it uses 400-600 MB of RAM for our avatar page.

A native toolkit like Flutter or Qt would use less memory, but would require rewriting our entire web-based UI. We chose the web stack because it lets us share code between the HoloBox, our mobile app, and the cloud-hosted version.

Smaller ecosystem for media codecs

Android ships with hardware-accelerated codecs for every common media format. On Armbian, we had to ensure the RK3566's VPU (Video Processing Unit) had proper kernel driver support. The Hantro and rkvdec drivers in mainline Linux now cover H.264, H.265, and VP9 decoding, but setup required more kernel configuration than Android's plug-and-play approach.

No Google Play Services

This sounds obvious, but it matters for integrations. Google Assistant, Chromecast, and many smart home protocols assume Play Services is available. We chose Home Assistant as our smart home integration layer instead, which is Linux-native and protocol-agnostic.

Steeper learning curve for contributors

Most embedded developers know Android. Fewer are comfortable with systemd service files, device tree overlays, and Debian packaging. Our contributor documentation has to be more thorough as a result.

Security patching cadence

Android's monthly security bulletins are a well-oiled machine — Google identifies vulnerabilities, patches them, and pushes updates to OEMs. On Debian/Armbian, security patches come through the standard Debian security team, which is thorough but operates on a different cadence. Critical CVEs are typically patched within days, but less severe issues may take weeks. We supplement this with our own monitoring of the NVD (National Vulnerability Database) for packages in our dependency tree, and we maintain a private patch queue for anything that affects our specific hardware configuration.

How does the Armbian base system work?

Armbian provides a minimal Debian (or Ubuntu) userspace optimized for ARM SBCs. Key features we rely on:

How do we handle OTA updates?

Android has a well-tested A/B partition OTA update system. On Linux, we built our own using a combination of:

This is more complex than Android's A/B system, but it gives us granular control — we can update just the Node.js runtime worker without touching the kernel, or vice versa.

How does the development workflow differ?

On Android, the standard development loop is: edit code in Android Studio, build an APK or system image, flash to the device via ADB, test. A full AOSP build takes 30-60 minutes on a powerful workstation (according to Google's AOSP build documentation, 64 GB RAM and 400 GB disk are recommended).

On Armbian, our development loop is: edit code locally, rsync changed files to the device over SSH, restart the affected systemd service. Turnaround time is 5-15 seconds. For kernel changes, we cross-compile on a build server (Armbian's build framework on a 16-core workstation compiles a kernel in ~8 minutes) and deploy the resulting .deb package.

This faster iteration cycle compounds over months of development. We estimate the Linux development workflow saved us 2-3 hours per day compared to the Android build-flash-test cycle during the intensive EVT phase.

Would we make the same choice again?

Yes, but with a caveat. For a consumer product where the primary interaction is voice and a simple visual UI, Linux is the right foundation. The memory savings alone justify the choice — that 600-900 MB of extra headroom is the difference between running the AI stack comfortably and fighting the OOM killer.

However, if we were building a device where users install third-party apps, consume media from streaming services, or expect a phone-like touch experience, Android would be the pragmatic choice. The HoloBox is not a tablet — it is an AI appliance — and that distinction makes Linux the better fit.

Key takeaways