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.