Tempo2Market 
Why industrial teams end up on Android
If you build industrial devices — HMIs, panels, gateways, connected machines — there's a good chance you didn't choose Android so much as inherit it. You sourced a capable hardware platform, often from an Asian SoC or board vendor, and it arrived with a custom Android image built on the SoC's board support package (BSP). That image already booted, already drove the display, already exposed the touchscreen, and gave your application team a familiar runtime to build a UI against.
That is a real advantage, and it's worth naming honestly: Android is excellent at getting you to a working demo. Your developers know it. The UI toolkits are mature. You can stand up a convincing prototype on real hardware in weeks instead of quarters. For the prototype problem — "can we make this device do the thing and show it to stakeholders?" — Android is hard to beat.
The trouble is that the prototype problem is the easy problem. It's the one with the shortest timeline and the most forgiving requirements. The problems that actually determine whether your product is profitable and defensible show up after launch, and they run for the entire service life of the device — typically seven years, often ten.
This article is about that second set of problems, and why a vendor-custom Android image is the wrong foundation for them. It compares Android specifically against Tempo2Market (T2M), hexDEV's industrial device platform — not against generic AOSP or smartphone Android, but against the kind of adapted Android image a hardware vendor actually hands you.
The hidden problem: cheap at prototype time, expensive over the lifecycle
A vendor-custom Android image is optimized for a moment in time. It captures a working stack at the date the BSP was frozen. What it does not come with is an answer to the questions that dominate an industrial product's economics:
Who ships security patches in year four, year seven, year ten? SoC vendors maintain a BSP for a window that is rarely aligned with an industrial product's service life. When that window closes, the security-maintenance obligation doesn't disappear — it lands on you.
How do you actually deliver an update to deployed devices? A vendor handing you image drops is not the same as having a customer-controlled, governed update pipeline with staged rollout and rollback.
How do you support a device that's behind a customer's firewall, on a factory floor, three countries away?
How do you prove, to an auditor or a regulator, what software is running where, and that you can patch it? Do you remember Stuxnet?
None of these are answered by "the device boots and runs our app." Yet under the EU Cyber Resilience Act (CRA), they are increasingly answered by law. The CRA pushes the centre of gravity in embedded product development from "does it work at launch" to "can you keep it secure and accountable across its supported lifetime." A frozen Android BSP with an uncertain maintenance path is precisely the posture the regulation is designed to discourage.
So the real comparison isn't "Android app runtime vs. something else." It's "a one-time operating-system image vs. a maintained product lifecycle." Those are different categories of thing — and Tempo2Market can now preserve Android as an application runtime without leaving a vendor-custom Android in charge of the product lifecycle.
Why industrial devices need a different platform model
There's an economic reason this gap exists, and it's worth being blunt about, because it's the crux of the whole argument.
Smartphone Android works because the maintenance cost of a platform is amortized across tens or hundreds of millions of units. Carrier certification, security backports, fleet tooling — all of it is justified by scale that an industrial OEM will never have.
You are not shipping ten million phones. You are shipping a few thousand devices — and you need to support each of them for the better part of a decade.
At that volume, the smartphone economics invert. The per-device cost of independently maintaining an aging BSP, building your own OTA backend, standing up fleet management, and assembling remote-support plumbing is brutal precisely because there are so few devices to spread it over. The work is nearly fixed; your unit count is small. This is the structural reason "we'll just keep the vendor Android going" tends to get more expensive every year a product stays in the field.
The way out is not to do all of that work yourself at small scale. It's to adopt a platform where that lifecycle infrastructure already exists and is shared across many industrial products. That is the model Tempo2Market is built around.
How Tempo2Market replaces Android — by problem solved
Tempo2Market is not "another OS image." It's a device platform with three parts that matter to a CTO: a maintainable Linux foundation on the device, an on-device runtime and API anchor (ttmdaemon) with the hex-browser kiosk runtime for display products, and a cloud control plane (fleetwarden.de) for fleet operations and support.
Here's how those pieces answer the post-launch problems.
A maintainable foundation instead of a frozen image
Tempo2Market builds a slim, purpose-built Linux distribution with OpenEmbedded/Yocto, using a mainline-oriented kernel strategy and explicit, pinned software inputs. Two things follow. First, security and maintenance work stays feasible over the product lifetime rather than being gated by one vendor's BSP calendar. Second, the build is reproducible and the release artifacts are traceable — versions, hashes, signatures, and supported-hardware metadata — which is exactly the evidence base CRA-style patch management asks for. A general-purpose Android stack also carries services and attack surface a fixed industrial product simply doesn't need; a slim image means fewer components to validate and fewer to patch.
Updates as a product feature, not a project
Security patching only matters if you can deliver it. Tempo2Market ships software as signed bundles. Devices check for updates and report status; fleetwarden.de stores, displays, and deploys them. Updates install to a redundant system slot with A/B layout and rollback, so a bad update doesn't brick a device or force an immediate on-site visit. Immutable system software is separated from persistent device data, so an update doesn't wipe configuration, logs, or UI assets. And rollouts are governed: deployment plans with effective dates, completion criteria, version constraints, and targeting by fleet, group, or region — so you validate on a subset before going wide. When connectivity is restricted, local and offline update paths exist too. The question to put to any Android supplier is simply: is updateability a maintained workflow you can hand me, or a custom project I have to build?
Manufacturing that produces a fleet-ready device
A device coming off the line shouldn't merely prove it booted. Tempo2Market's provisioning workflow gives each unit a trusted identity, serial and product metadata, branding, and optional assignment to a fleet — and an OEM manufacturing API reports newly built devices into fleetwarden.de, so contract manufacturers integrate cleanly into your DeviceOps instead of relying on manual onboarding after shipment. End-of-line validation can check baseline connectivity and lifecycle readiness, not just power-on. The contrast with a typical Android factory flash is the difference between "an image was installed" and "an updatable, identifiable, supportable device entered the field."
ttmdaemon as the stable device API
Product apps shouldn't reimplement drivers, update mechanics, telemetry, and cloud integration on every hardware platform. ttmdaemon starts early and acts as the integration point between application, device, and cloud, exposing REST and WebSocket APIs. Your application builds against stable device concepts — configuration, update state, network status, device mode — while the platform absorbs the low-level lifecycle complexity. It also provides reusable building blocks: Shared Values for fleet-wide, auditable configuration and state, and Log Streams for telemetry and diagnostics that buffer locally under intermittent connectivity and sync when possible. On Android, each of those is something you and your backend team build and then own forever.
hex-browser for industrial HMIs
Most industrial display products want a controlled, fixed HMI — not a consumer tablet experience. hex-browser is a Chromium-based kiosk runtime tuned for embedded use: predictable startup, locked-down navigation, multiple predefined pages and tabs, multi-touch, and 24/7 display controls for brightness, rotation, scaling, screensaver, and energy behavior. Crucially, your team keeps building the UI in web technology they already know — the familiar-runtime advantage that drew people to Android in the first place — but without making a general-purpose OS the base of the product. Browser configuration is managed on-device and centrally through fleetwarden.de, so changing a kiosk URL or behavior doesn't mean rebuilding firmware. For products that need native or hardware-near elements, Qt/QML apps, helper services, and hex-browser plugins integrate through the same ttmdaemon APIs.
Keep your Android app. Change the platform beneath it.
Moving to Tempo2Market no longer means leaving a proven Android app behind. Since June 2026, Tempo2Market can run Android apps through the Waydroid integration in hex-browser. The app remains part of your product, while Tempo2Market provides the maintained foundation around it — from device updates and fleet operations to remote support. You protect the application investment you have already made without tying the next decade of the product to the original vendor Android image.
fleetwarden.de for fleet operations
This is the DeviceOps layer Android vendors generally don't supply. fleetwarden.de gives you a searchable device inventory (name, UID, region, group, software and hardware version, last check-in), grouping by fleet/region/group, mass configuration with import/export, per-device detail with update and state history, certificate validity, and device check-in with pending-change tracking for offline units. Access is governed — user roles, fleet-scoped permissions, invitations, and mandatory second factor authentication — so the power to push updates and open support sessions is tied to responsibility, not a shared password. Device identity is renewable over the product's life through a certificate renewal workflow, rather than hard-coded at manufacturing.
Remote support without opening the device to the internet
Industrial devices usually sit behind customer firewalls and must not expose inbound services. Tempo2Market uses an outbound, controlled tunnel model: the device connects out, and authorized users connect through governed, scopeable sessions. On top of it, fleetwarden LIVE provides a browser-based terminal, VNC remote desktop, and file browser — so L1 support can see what the user sees, and L2/L3 can diagnose at the command line, all without a VPN, permanent open ports, or ADB exposure. For technical workflows there's raw TCP port forwarding and a CLI client for accessing local services. The tunnel is built for real industrial networks: it handles reconnection gracefully on flaky links, and supports outbound connections through an enterprise HTTP proxy. Ask whether the Android approach delivers governed remote support, or whether it means VPNs, firewall changes, and third-party remote-control tools.
Support and enablement so Linux doesn't become your problem
The reason Android feels easy is that it hides platform complexity at prototype time. Tempo2Market's answer is not to expose that complexity later — it's to keep it managed. hexDEV provides engineering services across embedded Linux and Yocto, BSP and kernel/driver work, security and compliance orientation, hardware and peripheral integration, and HMI delivery, plus architecture and API documentation and reference apps. And adoption is modular: you can take the whole platform, or start with fleetwarden.de, the provisioning workflow, ttmdaemon, or the Yocto baseline — so replacing Android can be stepwise rather than all-or-nothing.
Android vendor image vs. Tempo2Market, by problem solved
Every row is something you own once the device is in the field — across a seven-to-ten-year service life.
| Problem you own after launch | warning_amber Vendor-custom Android image | verified Tempo2Market |
|---|---|---|
| Security patches for 7–10 years | Tied to the SoC vendor's BSP window; afterward, your problem | Maintainable, mainline-oriented Yocto base designed to keep patching feasible |
| Reusing an existing Android app | Runs natively, but remains tied to the vendor image and its lifecycle | Runs through Waydroid inside the managed hex-browser kiosk shell |
| Delivering updates to the field | Often image drops; OTA pipeline is yours to build | Signed bundles, A/B + rollback, governed rollouts via fleetwarden.de |
| Not bricking devices on a bad update | Varies; rarely a maintained, fail-safe workflow you're handed | A/B layout with rollback; system/data separation |
| Manufacturing a fleet-ready device | Factory flashing; identity/onboarding extra | Provisioning + identity + OEM manufacturing API + EOL validation |
| Fleet inventory and DeviceOps | Build or buy an MDM | Inventory, groups/regions, mass config, history in fleetwarden.de |
| Remote support behind a firewall | VPN / ADB / third-party tools | Outbound tunnel, browser terminal/VNC/file browser, port forwarding |
| Governed access | Risk of default credentials / debug access | Roles, 2FA, scoped sessions, renewable device certificates |
| Compliance evidence (CRA) | Hard to produce from a frozen image | Reproducible builds, signed artifacts, traceable versions, access control |
The pattern is consistent: Android gives you the device. Tempo2Market gives you the device plus the apparatus to keep it secure, updated, supported, and accountable — the parts you would otherwise build, own, and maintain yourself at a volume too small to justify it.
The objections worth answering
"Our developers already know Android and Flutter."
They keep that advantage. Tempo2Market supports native Flutter, and existing Android apps can now run inside hex-browser, so your team can continue with familiar tools and proven application code instead of starting over. You keep the speed that made Android attractive; Tempo2Market adds the updates, fleet operations, and long-term support needed after launch.
"The hardware vendor already gives us Android."
They do — for the prototype. Ask them the lifecycle questions in writing: how many years of security patches, at what price, with what SLA? Who maintains the BSP after the SoC vendor stops? Do you get signed OTA, A/B rollback, staged rollouts, fleet targeting, manufacturing provisioning, and governed remote support — or just images? The gap between the answers and your product's service life is the cost you're quietly absorbing.
"Yocto sounds harder than Android."
At prototype time, often yes — which is why hexDEV's services and the ttmdaemon abstraction exist, and why UI work stays in familiar web tech. Over the lifecycle, the comparison flips: the genuinely hard job is maintaining an abandoned Android BSP for years with no upstream support. Tempo2Market's clean separation of platform, board, and product layers is designed to make those years tractable rather than heroic.
"We only sell a few thousand devices."
That's the strongest reason to switch, not against it. Smartphone-scale Android economics assume you can spread platform maintenance across millions of units. You can't. At a few thousand units, building and running your own BSP maintenance, OTA backend, fleet tooling, and remote-support stack is the most expensive path available. A shared lifecycle platform is how small industrial series get enterprise-grade DeviceOps at a viable cost.
The honest verdict
Android answers one question well — can we get this device demonstrating quickly? — and for that, it earns its place in many a prototype. But shipping an industrial product is a ten-year commitment, and the questions that decide whether it succeeds are about security maintenance, updateability, manufacturing, fleet operations, remote support, and legal accountability under regimes like the CRA. A vendor-custom Android image doesn't answer those. It freezes a moment and leaves the decade to you.
Tempo2Market is built for the decade. It replaces Android not as an app runtime, but as the industrial product platform — the maintained foundation, the update pipeline, the manufacturing flow, the device API, the kiosk runtime, the fleet control plane, and the remote-support model, delivered together and supported by hexDEV. If your problem is the demo, Android is fine. If your problem is the seven-to-ten years after the demo, that's the problem Tempo2Market exists to solve.
By now, you may think choosing Tempo2Market means leaving Android behind—along with a familiar way of solving problems and the many jobs Android already does well. The truth is, you don't have to choose.
Let's plan the device you'll still support in year ten.
Bring your target hardware, existing app, UI requirements, update model, and compliance horizon. We'll map a realistic path from a vendor Android to a maintained Tempo2Market product.