Is Your Android Product Development Built to Scale Beyond One Product?

ByShivi Makrariya07/10/2026

When people talk about Android-based products, our minds just fetch the image of the latest smartphones, and yes, we all saw Android first ported into smartphones.

But now, Android utilizes into every product we are using such as smart TVs, wearables, automotive systems, medical devices, industrial equipment, and many other connected products. Android devices can vary based on their niche applications and their usage from an engineering perspective, but the base or foundation remains the same.

For Android product development, AOSP or Android Open-Source Platform is the starting point. This gives every Android product a basic software foundation, but before that, a lot needs to be engineered to make the product. We first need to bring Android up on the targeted SoC and the board to work with the vendor’s BSP, kernels, drivers, and hardware configuration.

Once Android starts booting, the real Android product development begins.

This is where we need to move beyond the AOSP baseline to a structured engineering approach to meet the product’s requirements.

At the same time, teams need to inspect product performance, power, memory, thermal behavior, and latency. These cannot work independently. Because if any of the layer or areas get affected, will affect the other layers too.

So, when we are talking about to make android product from AOSP baseline to finished product we need to understand each layer that how it works together.

From AOSP Foundation to Product Platform: What Actually Needs to Be Engineered?

So, the question is where does this product-specific engineering takes place?

When we are talking about android product, we first need to understand the below loop which is works as an entire Android product stack, where below layers contain Linux kernel and drivers where upper/top layer contains system UI and applications.

So, how these layers are arranged?

Linux Kernel & Drivers → HAL + Native Libraries → System Services → Framework → Applications & System UI

We are not treating these as separate six layers, as we said one layer change will affect others, so we need to work very closely with each layer throughout the stack.

We need to understand the clear boundaries and their dependencies on each other. Which helps us to avoid impacts or implications over other layers while we update/upgrade the stack layers.

So, here scalability also matters. As we move through the stack, we are not only discussing,

“How will this stack work for this current product?”

But we need to ask:

“How do we need to keep this part reusable when product requirement, user experience, or hardware changes?”

So, to answer this first understand the Android Stack Layers one by one:

Linux Kernel & Drivers: Start with the Hardware

Let’s begins with the most bottom layer: SoC and BSP, where our Android first meet with the actual device.

At this layer, we need to configure the board, set up device trees, integrate the Linux kernel, and firmware, also bring up the required drivers for hardware. We also need to look for display, camera, audio, storage, connectivity, and sensors along with power management and scheduling.

The major factor for keeping hardware-specific work closely to hardware, we need to make drivers enable to handle device-specific details instead of directly push over Android stack. This gives us the clear boundary to make platform easier to adapt when the hardware changes.

For example, if one product uses a 12MP camera and other uses 13MP camera, the hardware-specific configuration can be handled by device-tree and lower-level interfaces. So, here we should not change the entire Android stack to adopt simple hardware change.

• Scalability Point: Product’s hardware-specific customization can be done at the lower layers which can be handled independently without hurting or rework with other layers on stack.

HAL: Create the Hardware Boundary

Once the drivers are working, HAL gives the way to the Android to utilize hardware capabilities smoothly.

Hardware → Driver → HAL → Android Interface

We use the HAL to connect the hardware implementation over Android stack. This becomes important when the product includes hardware which is not supported by the Android directly, such as a proprietary sensor, industrial peripheral, medical instrument, automotive interface, or other custom hardware.

Here, we also need to validate the complete hardware path to make sure the interface works well as expected, and handles errors properly, and behaves reliable in all situations.

For example, if one product may use Bosch BME280 for temperature sense activity, where other product uses Sensirion SHTC3. The hardware-specific difference must be handled by the drivers and HAL, keeping Android-facing interface unchanged.

• Scalability Point: Need to keep stable and clear hardware interface so when peripheral changes occur, they must be handled below Android layers without juggling unnecessarily across platform.

Native Libraries: Handle the Processing-Heavy Work

Once the Android can utilize hardware through HAL, the next step is to process the data and use it appropriately within the product.

So, here Native Libraries plays the key role. They manage many of the heavy processing parts of the platform, like media and codecs, audio, graphics, connectivity, and other specific functions. When these Android libraries are not supporting based on the application, we need to redesign or make necessary changes deeper inside the native stack.

This is also where we need to see deeply at the optimization point of view; where below mentioned parameters needs to be focused:

Performance | Power | Memory | Thermal | Latency

For example, if we talk about smart TVs, maybe it uses based on different processing and memory requirements than automotive systems or industrial systems. So, optimization is applied based on the actual workload and product use cases than just focusing on single scenario.

• Scalability Point: To optimize our upgraded Android products and to make it sustainable in market, need to focus on performance-critical changes to be measurable and try to keep it carry forward in next hardware, features or Android version changes.

From AOSP Foundation to Product Platform

System Services: Turn Capabilities into Product Behaviour

Now we have the lower foundation layers with hardware and HAL capabilities, so, system services turn them into the real device behavior.

Here we can customize the service for power and display control, device state, permissions, policies, lifecycle management, and other product-specific system behavior.

The idea is to keep common device behavior into the platform as it is rather than building the same logic every time for different applications.

For example, if multiple applications on Android require the access to common device capability, then we can use the same system-level service rather than implementing variour/frequent changed behavior on system. This helps us when we build the same Android foundation for various applications.

Where platform will be common, and reusable, while product-specific behavior just needs to be configured through Android build system and can be adapted where it needs.

• Scalability Point: So, the same foundation of Android can be reused across various applications and products.

Framework: Expose Reusable Platform Capabilities 

Once the system services provide the necessary device-level behavior, the framework enables those capabilities available to the applications via defined Android interfaces.

Here the customization of Android framework can be done based on what is the product requirement. This customization covers framework APIs, Binder IPC, permission, and component changes like Activity Manager, Window Manager, or Package Manager.

The goal is to create an application in consistent way to use platform capabilities without affected by the changes happens inside implementation. So, the application works with the framework interface, while the lower layers handle the level of the capability delivery inside the stack.

When the platform evolves this separation becomes visible, and when the below part of hardware or implementation changes, we need to keep the framework interface stable whatever the capabilities changes.

• Scalability Point: Framework interfaces must be clear and reusable, so any application can use the platform consistently without being bound by and implementation changes.

Applications & System UI: Build the Product Experience

Finally, we reached to the application and system UI layer, where we can clearly experience the product.

This is the layer, where we work on launcher, systemUI, settings, product applications, branding, themes, user profiles, and multi-display experiences based on product requirements.

Users may face experience changes based on various devices, such as:

• a smart TV needs media-focused launcher and content experience,
• a wearable requires compact interface which is designed along with tiny display,
• an industrial device runs with controlled and simply UX HMI,
• where, an automotive system may require multi-display experience with various content and control access at same time.

At this layer, we bring various platform capabilities and transform them into an exceptional experience that matches how the product is expected and must be used.

• Scalability Point: Application and System UI layer must be designed like; it must be reusing the platform capabilities despite the application or product-specific experiences face changes.

After connecting with all these layers, leads us back to the main question that:

how do we manage this platform from the first boot through future product releases?

From First Boot to Future Releases: How MosChip's Android Program Approaches Android Product Development

After understanding the Android stack step-by-step and importantly, to answer the above question let us see how MosChip take the product development in phases.

At MosChip we enable Android Engineering and Device Software Engineering, where we do not bring up the AOSP as separate activity. For Android product development, AOSP is the starting point, we lead this product development process with product feature implementation, fix and optimize the platform, require certification, continue maintaining it once the product is launched.

We generally follow five stages roadmap:

Port → Integrate → Harden → Certify → Sustain

All these layers together working to develop proper Android product. Let us discuss all layers one by one:

Port: Bring AOSP onto the Target Hardware 

This is the first step to get AOSP running on the actual target hardware.

Let’s start with the target SoC and do bring up activity via silicon vendor’s BSP, board configuration, device tree, Linux kernel, GKI, drivers, and firmware.

Once all these pieces are integrated together, we need to work through the boot process and bring up the basic hardware paths.

Then we can verify the hardware, with display, storage, memory, connectivity, and other specific components required for the platform to run reliably.

Here the goal is simple: to establish stable Android baseline on the target board to build future product on it.

Integrate: Make Android work with the Product

Once the basic Android platform start running, we need to integrate the various features to make product real.

This includes camera, audio, sensors, connectivity, peripherals, and vehicle HAL as per the application. These capabilities can be connected via HAL, and it can be verified across various native layer, system services, framework, and applications.

For example, a camera sensor gives the response simply at the beginning, but when we make sure about HAL, media pipeline, framework APIs, permissions, and camera application needs to be work together properly.

So, we must follow the same approach to build the product features, we can also trace each feature through the stack layer by layer.

Here the goal is making sure the complete feature works reliably as single product, not into an individual hardware part.

Harden: Make It Ready for Real Use

This stage helps us to test the platform behavior under the real product conditions.        

Security is the key element of this stage. Based on the product, we need to work on various areas like, SELinux policies, Verified Boot, key provisioning, TEE integration, and authentication mechanisms.

We can also measure and optimize the boot time, memory usage, power consumption, stability, and performance. During basic functional testing we catch some issues which are not clearly visible but effective.

If we test beyond the normal use case the actual behavior can be identified where how the product will run and behave.

Here the goal is to make Android platform secure, stable and durable under any such conditions where product must remain sustained.

From First Boot to Future Releases

Certify: Check the Platform Against Requirements 

We seen testing happens throughout the development process from hardware paths, HALs, features, and system behavior to build the platform.

Now certification comes, where we need to check whether the complete Android platform meets the required compatibility and specific requirements.

Based on the product, the certification includes CTS, VTS, GTS, and GMS certification support. If the test fails, we need to trace the issues through the platform and need to understand whether it comes from the customization, from the vendor implementation, or any other system parameters. Then we need to fix it and test it again.

So, certification is not simply to run various tests across the platform. It is about the understand why something fails, how to fix it, and make sure that platform meets the desired standards.

Sustain: Keep Working After the Product Ships

Once the first product launched, the work doesn’t seem to be finished.

After launch, we need to handle all kind of security patches, Android version upgrades, OTA updates, field issues, regression testing, and maintenance of customized components.

If hardware or product variants changes it must be aligned with the existing platform.

For example, if the interface of an Android version changes based on the customized HAL or framework components, we need to understand what changed, which component affected, and then verify that how the existing product features still work as expected.

The same thing applies to security updates and field issues. All the changes need to be tested properly to make sure the new issues of feature updates must not be entered which is already in work. So, architecture we build earlier become important element.

So, what we have seen till now?

• Port gets Android running.
• Integrate makes it a product.
• Harden prepares it for production.
• Certify checks its readiness.
• Sustain keeps it evolving.

Wrap Up

Ultimately, when we see all these stages working side by side, Android product development begins from the platform to the complete product which allows customization based on the product and industry requirements, which is starting from the foundation AOSP and can adapt hardware, features, product requirements without dealing every time from scratch.

To know more about MosChip’s capabilities, drop us a line, and our team will get back to you.