E-paper integration looks simple from the application side: send content, update the screen, and manage devices.
The reality is different.
Unlike LCDs, e-paper depends on waveform control, refresh strategy, temperature compensation, and platform-specific drivers. Without the right SDK layer, software teams often end up rebuilding display engineering instead of focusing on their application.
An e-paper SDK typically includes display drivers, waveform handling, refresh APIs, hardware abstraction layers, and integration tools that allow applications to control the display without managing panel-level behavior directly.
What Development Teams Typically Have to Handle
Without SDK support, a team building e-paper integration from scratch runs into problems that don’t show up with a standard display:
- Refresh isn’t a simple “draw and done” call. Full refresh, partial refresh, and how ghosting accumulates over successive updates all need explicit handling — covered in more depth in our development pitfalls guide. A team expecting to treat the display like a framebuffer discovers this the hard way, usually after ghosting has already become visible in a demo.
- Rendering location is an architecture decision, not a default. Whether content gets rendered locally or shipped pre-rendered from the cloud changes what the edge hardware needs to be capable of — our edge vs. cloud rendering guide covers the trade-off, but it’s a decision that needs to be made deliberately, not inherited by accident from whatever’s easiest to prototype first.
- Telemetry has to be built in, not bolted on. Battery status, connectivity state, and temperature (which directly affects waveform driving parameters) all need to be readable by whatever’s managing the fleet — easy to skip in a prototype, expensive to retrofit once units are already deployed in the field.
- Platform integration isn’t uniform. Android, Linux, and RTOS-based hardware all require genuinely different integration approaches, covered below — a team building for one platform can’t assume the same code, or even the same architecture, carries over to another.
This is the gap an SDK is actually meant to close: it’s not just a convenience layer, it’s the accumulated handling for problems that are specific to how e-paper physically works, which a general display API was never built to account for.
Platform Integration, in Practice
Android
On an Android-based platform (MyGica’s EPC3566, running Android 11 as one of two supported OS options), integration looks like working with a native library wrapped for use from Java or Kotlin — the SDK exposes functions your app calls directly, similar to integrating any other hardware peripheral SDK into an Android application. This is the most straightforward path if your team already has Android development experience.
Linux
On the Linux build of that same platform (running Debian 11), integration is typically via a C/C++ shared library with headers, or in some architectures, a local daemon exposing a socket or command-line interface — a good fit for a custom application or service built around the display rather than a general-purpose OS running multiple apps.
RTOS (ESP32-S3, RTL8711-based platforms)
This is where “integration” means something different. On RTOS-based platforms like EPC-ESP32, there’s no separate app layer to integrate an SDK into — application logic gets written in C directly against the driver API, as part of the same firmware running the device. Plan for embedded firmware development effort here, not a drop-in library call.
A Note on Windows
MyGica’s current platform lineup doesn’t include Windows support — our SoC and MCU platforms run Android, Linux, or RTOS. If a project specifically requires a Windows-based host, flag that early in a quote request rather than discovering it after development has started.
Why OEMs Need an E-Paper SDK Partner
None of the problems above are exotic — they’re well understood, solvable, and already solved. That’s the actual case for working with a partner rather than building this layer from scratch: waveform-aware refresh handling, platform-specific driver integration, and fleet telemetry are specialized, one-time engineering problems that don’t need to be re-solved per project. MyGica supports OEM e-paper projects with custom SDK development, TCON integration, firmware optimization, and cloud connectivity — built by a team that’s already worked through these issues across multiple deployments, including real off-grid, SDK-integrated projects. That lets a development team focus on the application logic that’s actually specific to their product, instead of rebuilding e-paper driver fundamentals that have nothing to do with their core business.
This is also where SDK/API integration and a hosted CMS genuinely diverge as options, covered in more depth in our customization guide: SDK integration makes sense once a team has — or is building — its own backend and wants the display layer handled without reinventing driver-level work; a hosted platform makes more sense when that backend doesn’t exist yet and speed to a working deployment matters more than owning the full stack. Either way, it’s worth specifying explicitly in an OEM quotation request rather than leaving it as an assumption on either side.
Quick Reference
| Platform | Integration Style | Best Fit |
|---|---|---|
| Android (EPC3566) | Native library called from an app | Teams with existing Android app development experience |
| Linux (same platform, Debian build) | C/C++ library or local daemon interface | Custom kiosk-style or dedicated-purpose applications |
| RTOS (EPC-ESP32) | Firmware-level C API, no separate app layer | Lightweight, battery-oriented deployments needing embedded firmware work |
| Windows | Not currently supported | — |
FAQ
Does MyGica’s SDK support Windows?
No — current platforms run Android, Linux, or RTOS. If a project requires Windows specifically, flag this early when requesting a quote.
What’s the biggest thing teams underestimate when building e-paper integration without SDK support?
Refresh handling — treating the display like a standard framebuffer rather than accounting for ghosting, partial-refresh scheduling, and waveform behavior, which usually surfaces as a visible quality problem after most of the integration work is already done.
Is RTOS integration harder than Android or Linux integration?
It’s different rather than strictly harder — it requires embedded firmware development skills rather than app-layer integration, since there’s no separate app framework to plug an SDK into on RTOS-based platforms.
Do I need a hosted CMS if I integrate via SDK?
No — SDK/API integration is specifically for teams that want to connect the display to their own existing or planned backend rather than use a hosted content platform. Which approach fits depends on whether that backend infrastructure already exists.