Using Android for Embedded Systems – Then and Now

Back in 2011, Android had already made a name for itself in the mobile space—and was beginning to stir interest in other markets. Google’s release of Honeycomb (Android 3.0), tailored for tablets, marked a strategic shift: Android was no longer just for phones. It was on a path to conquer broader embedded systems.

This post—part of a series—looks at the question: “Where could Android go next in the embedded space, and why should we pay attention?”

Android vs. “Google Android”: Know the Difference

It’s important to distinguish between:

• Android – the open-source OS under GPL2 and Apache licenses.

• Google Android – the Google-blessed version, with proprietary services like the Play Store, YouTube, Gmail, Maps, and more.

You can freely use Android’s source code to build products. But to use Google’s services, branding, or app ecosystem, you need explicit permission and must pass Google’s Compatibility Test Suite (CTS). This process isn’t always straightforward and often favors high-volume OEMs.

Two Strategic Paths for Product Developers

If you’re considering Android for your next non-mobile embedded product, you typically face two choices:

1. Partner with Google Build a product aligned with Google's roadmap, gain access to Google services, and go through the certification process.

2. Go Fully Open Source Use the Android source code independently and invest in building or modifying components specific to your product, minus the Google ecosystem.

Whichever path you take, staying aligned with Google's evolving Android strategy is critical. Why? Because Google’s decisions can impact the relevance—or redundancy—of your product overnight.

Case in point: Imagine you’ve built a tablet-friendly UI on Android 2.2 in early 2011, only for Google to release Honeycomb (3.0) weeks before your launch. Overnight, your platform could look outdated—impacting user interest and support.

Mapping Android’s Role Across Embedded Verticals

The embedded systems landscape spans a range of verticals—consumer, industrial, communications, and mission-critical devices. Not all are a natural fit for Android.

Where Android won’t go:

• Routers, firewalls, switches, and most headless devices typically run OSes like Linux, VxWorks, or Windows CE. Android isn’t built for these.

Where Android can thrive:

• Consumer electronics like Smart TVs, media players, infotainment systems, and connected devices—especially those needing rich UIs and app ecosystems—are strong candidates.

• As form factors blur (e.g., PMPs merging into smartphones/tablets), Android’s role is likely to grow.

Why This Still Matters Today

While this was written in 2011, the strategic lens still holds: Android continues to evolve beyond mobile—with its influence expanding into automotive (Android Auto), smart home, wearables, and industrial IoT.

If you’re building an embedded product today, the questions remain:

• Are you aligning with Google’s roadmap—or betting on independence?

• Are you building on Android’s flexibility—or depending on Google’s ecosystem?

Understanding this difference can make or break your go-to-market strategy.