In today’s digital world, customer needs and product demands keep changing rapidly, which pushes industries to develop smarter and more capable products.
To keep up, manufacturers sometimes need to upgrade the hardware that runs their existing products. Let’s understand it with the help of a case.
Imagine an industry producing various products based on a single Android version. Now, they think they need to switch to a new System-on-Chip (SoC). Maybe the factory is facing some challenges with the existing chip, such as discontinued chip processing, the cost needs to come down, better performance requirements, or the product roadmap needs a new hardware platform.
Whatever the reason behind switching to a new SoC, one question comes early in the starting phase of the process:
Do we need to rebuild the entire Android software stack, or can we reuse what we already have?
In many cases, Android porting doesn’t need to start from scratch. We can utilize many existing software and hardware parts and port them directly to the new platform. But the challenging part is that some components are mostly dependent on and designed based on the original hardware, which needs to be changed or redeveloped.
So, for engineers, the real challenge is to bifurcate all the components: which parts they can reuse from the existing platform and where they need additional engineering efforts to rework.
In our last conversation, we already discussed the Android software stack.
So, where do we begin?
We need to begin by understanding the existing Android platform and its components and identify which software components we can carry forward and which need to be reworked.
What Can Be Reused from the Existing Android Platform?
We discussed the scope for migration, the first step which we need to consider is to look at the software which we have already built and tested. A change in SoC during Android porting does not lead to changing the entire Android product from the foundation.
Inside the product, many components are designed based on product features and users’ demands rather than a specific chip, which makes them good parts for reuse.
Let us see what specific parts manufacturers can reuse without change:
1. Applications and Product Features
Let’s begin with the application layer.
Manufactures having their existing applications, UI designs, launchers, business logic, and user-based workflows that can be carry forwarded because they are independent to any hardware-specific features.
For example, there is an application that is running on an existing SoC platform and showing constant information without intervals, which manages user preferences and some critical information, and it must run the same if we change the SoC platform without major changes.
But the question is: Can we reuse all the components? Or does it depend on any factors?
So, we need to consider some factors before reusing it: any specific camera, audio interface, graphical capability, or vendor-specific API; we need to check its level of dependencies.
2. Framework Customization and System Services
The same approach applies to Android framework customization and system services.
If there are any product-specific changes to SystemUI, internal system settings like connectivity, display, sound, power, etc., and other framework components, the same can be used for the new platform.
We can continue this work if our target Android version supports the required interfaces and the customization is not dependent on services or behaviors of the original hardware.
If the Android version or dependent interfaces change, some adaptation may be necessary.
3. Common Software Components and Engineering Assets
After framework customization, we can also reuse the test automation/test frameworks, OTA update logic, and AI or voice processing workflows. Here, we need to check what these depend on.
Application behaviour testing can stay effective with the new SoC with minimal changes, while hardware-specific tests and workflows require adaptations on the new SoC platform, which can support all the necessary libraries for various applications, runtimes, and hardware speedup.
What should we check before reusing a component?
Before reusing any other components on a new SoC platform, we need to verify a few things:
Hardware Dependencies: Is there any component having dependencies on the specific peripherals, driver, chipset feature, or vendor library?
Interface Compatibility: Are the APIs, HAL interfaces, and service contracts still dependent on what they support?
Android Version: If any framework is customized, will those newly mounted components work with the target Android launch? Or does it need any specific changes or rebuilding?
Target Platform Support: If the target platform changed/restructured, will the required libraries, runtimes, codecs, and hardware acceleration features sustain the new SoC environment?
These types of checks help us investigate whether the software can adapt to the same platform components or requires redevelopment. Yes, reusable components or existing code are valuable, but we cannot simply predict that components will behave in the same way as the previously existing system.
Our goal is to achieve:
- Reduce development efforts/work,
- Accelerate the SoC Migration timeline (Accelerate time-to-market),
- Retain existing software,
- Leverage existing test setups and test automation frameworks,
- Minimize migration cost,
- Focus only on hardware-specific component redevelopment
Once we establish what we need to reuse, we can now focus on the next challenge: what needs to be changed/rebuild?
This brings us to the next challenging part:
Which hardware-dependent components must be reworked, and what additional engineering and validation are needed to get the Android product ready for release on the new SoC?
Engineering the Tech Stack for Android Products
Engineering the Tech Stack for Android Products Engineering the Tech Stack for Android Products From...
Watch Webinar: Engineering the Tech Stack for Android Products - MosChip®
What Must Be Reworked on the New SoC?
We identified which software we can reuse; now the next step is to deep dive into the components that will connect Android to the hardware. This is where Android porting requirements increase.
Now we are shifting the SoC platform, so the new platform may adopt different boot processes, kernel configuration, driver set, or vendor implementations. Even if we carry the same existing application and framework code, the hardware-facing components still need to be reworked properly to run on the new platform.
Let us discuss the key areas where we need to re-engineer the layers.
1. BSP, Bootloader, Kernel, and Drivers
This is the first part where we need to discuss the bring-up activity of the Board Support Package (BSP) and the software on the new SoC hardware.
But if we take a practical scenario, it is a very rare situation where our existing bootloader, kernel configuration, device tree, firmware, and drivers become compatible within the new SoC environment, because these components are specific to the platform-specific.
Now the question is: How do we need to start rework on this?The rework highly depends on how the design may be shaped from the existing platform. If we want to reuse some configurations, drivers, or integrated parts, the same peripherals and devices must be reusable for that. To fulfil this, the new platform must adapt to changes in BSL, board configuration, and hardware structure.
Now, the other components like storage, USB, display, camera, audio, and connectivity must be reviewed once when the drivers and interfaces need to be updated to support the new SoC. This means we need to ensure that the booting process and kernel can support and adapt to new memory and storage interfaces. Yet, it does not necessarily mean that everything from the previous SoC and board will be usable in the new one.
2. HAL and Hardware Integration
This is the layer where we need to do more migration.
Some components often require updates, like the camera, audio, display, graphics, sensors, and connectivity, because the new SoC platform may use different drivers, vendor libraries, interfaces, or hardware capabilities.
For example, the application may be reusable, but the HAL, hardware setup, processing pipeline, and vendor-specific software may need modification.
The goal is to preserve existing product functionality wherever possible while adapting the hardware-facing software and validating that Android, vendor services, and drivers continue to work correctly on the new platform.
3. Performance, Power, and Multimedia
Till now, we have reworked the hardware recognition part for BSP, bootloader, etc., and the required features too. But it does not mean the product is ready. We also need to verify that our product meets expectations for performance, power efficiency, and multimedia experience.
As we discussed above, a new SoC may have a different GPU, memory architecture, video codec support system, camera pipeline, or power management system.
Now engineers ask: Will this affect our new SoC platform performance?Yes, it may create differences in application performance in terms of response times, video playback, image quality, audio performance, and overall resource usage. Also, thermal behaviour can be affected, particularly when the product demands more workload for extended periods.
Let us understand it with an example: if we launch an application properly on a new platform, but it runs sluggishly (long response time) because of variation in graphics performance or memory handling. In the same manner, video playback may work slowly, but hardware decoding, frame rates, or power consumption may not meet the product’s exact requirements without appropriate fine-tuning.
So, we need to profile the system, measure the right performance under real workload situations, and fine-tune it with relevant components. For that, we require graphics optimization, codec configuration, memory management, power management, or thermal tuning.
Now, the important point is that we need to certify it; we need to validate the actual user experience, not only confirm the individual feature tasks.
4. Security and Certification
Along with functionality and performance, we need to assess whether our new SoC platform is compatible and ready to meet the product’s security and updated requirements.
When we move to a different SoC from the same vendor, or we change both the vendor and SoC platform, that requires new security mechanisms that depend on the hardware-specific features.
Secure Boot, Android Verified Boot, SELinux policies, and other security configurations should be reviewed by us. It also requires confirming that the boot process, partitions, vendor code, etc., meet the security needs for the platform.
Testing is another critical stage. CTS (Compatibility Test Suite) tests Android, and VTS (Vendor Test Suite) can assist in validating vendor interfaces. Other testing, GMS (Google Mobile Services) readiness, and certifications may be required depending on the product.
If we are talking about automotive products, the work may extend to vehicle-specific interfaces and integration with various ECUs (electronic control units), as well as validation of functions that require vehicle operations to run appropriately.
So, when we discover these areas early, we can easily assess component-level and platform-level compatibility or certification challenges during development, and they can be fixed easily so they cannot affect the entire product.
Assessing the Rework Before Migration
Ultimately, the rework depends on the target SoC platform, vendor support. Existing software architecture, and product requirements. We need to make some minor changes to some components; on the other hand, some components need redevelopment and additional testing.
Android booting is the first step in starting product development. So, what do we need to validate first?We need to validate the product’s performance, power efficiency, security, stability, and compatibility before launch.
Now the question is: To achieve this, what kind of approach do we need to adopt for new SoC migration?A Practical Approach to Android SoC Migration
After understanding the bifurcation between reuse and rework during Android porting to a new SoC, we can plan the migration process step by step. This process helps us to identify various issues such as quality, performance, and compatibility before they get worse and affect the product.
Existing Platform Assessment: This is the first step where we need to do the bifurcation process of what we need to reuse and what needs to be reworked based on the assessment of the software stack, hardware dependencies, and product customization.
Evaluate the target SoC: Here in this step, we can identify the target SoC gaps by checking the availability of the BSP, Android version support, capabilities of hardware, and vendor dependencies.
Android Bring-up and Integration: We developed a working Android on new hardware, adapted drivers and HALs, and integrated the required features of the product.
Optimize and Validate: After this, we need to test the integrated platform under realistic situations and need to address the issues related to performance, power consumption, thermal nature, security, and compatibility.
Prepare for Launch and Maintenance: This is the final stage where we need to complete the required certification activities, update verification and recovery processes, and need to plan for further platform updates/fix.
One thing to keep in mind that these steps may get overlap, when the integration issues arises or testing results identifies the loopholes some areas to be changed.
Once we follow this systematic path, it leads us to make informed reuse decisions, also reducing rework and extra engineering efforts. This process requires experience across the Android stack, from low-level hardware integration to product-level testing.
This is where the right engineering partner can help bring the pieces together.
How MosChip Supports Android Porting and Migration
At MosChip, our Android engineering offerings include SoC porting, customization of AOSP, integration of BSP and HAL, kernel and driver development, performance and power optimization, security and certification, and post-product launch maintenance.
Also, we support our Android engineering with various embedded products such as automotive, Android TV, mobile, wearables, XR, IoT, and others. As we previously saw, we worked on the whole Android stack, from AOSP customization, BSP integration, HAL integration, to framework customization.
We also focus on preparing proven software foundation, such as applications, framework customization, test suites, where we just need to address the change in hardware which is required for new SoC while porting. This helps teams to avoid unnecessary redevelopment and starting from scratch, where we can integrate and validate the targeted platform easily.
To know more about MosChip’s capabilities, drop us a line, and our team will get back to you.
