Android OS
Who needs custom Android OS development?
“Android is the OS on my smartphone.” (Or watch, possibly car dashboard)
Yes it is. Unless you have an iPhone. However, a lot of other products with embedded software run Android as their OS. Often these are non-consumer devices and it is not made obvious that Android is running on them, such as kiosks and healthcare wearables. Instead of providing a home screen to launch the usual selection of apps, such devices are often setup to boot Android and launch straight into one specific app created for the device. Usually that app runs alongside Android system services also written for the device, to perform lower level actions requiring system permissions.
To use Android in this way, developers need to customise it to run on bespoke hardware. This is not the app development people think of when normally thinking about working with Android. Porting and supporting Android on new hardware requires Android OS development, which is a much rarer skill.
Yes it is. Unless you have an iPhone. However, a lot of other products with embedded software run Android as their OS. Often these are non-consumer devices and it is not made obvious that Android is running on them, such as kiosks and healthcare wearables. Instead of providing a home screen to launch the usual selection of apps, such devices are often setup to boot Android and launch straight into one specific app created for the device. Usually that app runs alongside Android system services also written for the device, to perform lower level actions requiring system permissions.
To use Android in this way, developers need to customise it to run on bespoke hardware. This is not the app development people think of when normally thinking about working with Android. Porting and supporting Android on new hardware requires Android OS development, which is a much rarer skill.
The main challenges of custom android os development
Restrictions due to security
Using Android on a specific purpose device can be careful balance between security and functionality. Certain functionality needed in the main app often must be split off into a separate Android service which can run with system privileges. Custom SELinux policies are usually then needed to allow the service to access the required files or device nodes in the system to control unusual hardware.
Harder to customise
For a specific purpose device, the AOSP (Android Open Source Project) source code collection will contain a lot of apps and services which are not needed. It is usually best to remove a lot of that from the build of the OS for that device configuration. The AOSP is a very large code base made up of hundreds of git repositories, the required changes to HALs and Java frameworks can span across that code, anything changed then needs to be hosted locally in forks of the affected repositories.
Performance
Due to Android’s large range of out of the box functionality, it has a lot of layers and services running which can slow things down. It is possible to configure everything for high performance, however this requires experience in order to know what to change and where, again given the size of the code base.
3 key elements you need for your custom Android OS development
An Android BSP
The easiest solution is to have the Android OS source code already setup to run on your custom hardware, or something as close to it as possible. That is where an Android Board Support Package (BSP) comes in handy. As it happens, Witekio has plenty of experience providing Android BSPs on behalf of silicon and board vendors, and providing customised BSPs for device makers
A list of requirements for the Android port
It is important to identify all of the features Android provides which should be supported on your device and plan that work ahead of time. This is best practice in any development project, but due to the size and complexity of the Android OS, it is especially important to identify the full scope of the work, to avoid slippage at the end of the project.
Experience
As mentioned above, customising the Android OS effectively is a much rarer skill than app development. Familiarity is need with the many intermediate layers of Java framework code, the lower level HAL libraries and the IPC mechanisms specific to Android for making calls between them, SELinux policy authoring and changes to default settings in device configuration XML files.
SUCCESS STORY
Datalogic, build a brand new Android data capturing solution
The development of the Datalogic DL-Axist™, a rugged PDA featuring advanced barcode data collection and imaging technology, presented several challenges. These included the need for seamless Android KitKat porting, hardware integration with Linux, and improvements in product reliability and power management. To address these, Datalogic sought a partner with deep expertise in Android and Linux development, as well as experience with Texas Instruments OMAP™ architectures. Witekio provided a comprehensive solution, delivering a customized and reliable BSP for Android KitKat, integrating necessary hardware with Linux, supporting PMIC and gas gauge controllers, enhancing the Android hardware abstraction layer, and optimizing power management. This collaboration ensured the DL-Axist met its technical requirements with enhanced performance and reliability.
Best practices of custom Android OS development on embedded platforms
Stay up-to-date
To make the most of the security benefits of basing a device on Android, it is important to stay up to date with the latest major version whenever possible. This can be made easier by planning the changes made to support your hardware carefully, restricting those changes to the device configuration repository where possible. The fewer repositories that require changes in the AOSP, the less you need to fork and host yourself. Also, fewer modified repositories means less chance of compatibility issues when moving those modifications to the next release of Android.
Switch on SELinux early
When making changes to port the OS and support new features, it is tempting to switch off SELinux, which avoids security violations that prevent things working. However, if SELinux is left off, it gradually becomes a larger and larger job at the end of the project to amend all of the policy files, in order to be able to switch it back on whilst keeping the required functionality that has been added. This can lead to a long delay, or the decision to leave it off and proceed to a release, which will leave gaping holes in the security of the device. Again, make sure this is captured in the requirements and planned in to the project, to avoid slippage later on.
Use existing APIs and HAL infrastrucure wherever possible
When creating an app for the custom device, it may be tempting to “go around” the app APIs provided by Android in order to control something specific, for example opening a file or device node directly. It is advised to avoid that and instead try to add support to existing HAL interfaces and through the official APIs as far as possible. Firstly because it is becoming increasing harder to be able to take such shortcuts, due to security restrictions becoming tighter on newer versions of Android. But also, your app(s) will be more portable, allowing a cleaner platforming approach and easier upgrade path to newer versions of Android (assuming you follow the first point above).
Why run Android on Embedded devices?
Ease of application development
Once you have Android running on your device, apps can be written for it in the usual way, against clear well documented APIs and abstraction layers, which allow those apps to be run on any device running Android with minimal modification. In practice the device application is often written by a seperate “App team” who can develop and test it in parallel on a pre-existing Android consumer device, until the custom device with Android OS port are ready.
Also, developers with experience in Android app development are much easier to find and hire.
Out-of-the-box support for common embedded device features
Modern devices often require a similar baseline set of functionality, such as:
Security – Older versions of Android (Like many OS’s) contain vulnerabilities which have been identified over time. But overall, the Android OS provides a good baseline level of security by default:
Over the air update – software on the device to retrieve and securely authenticate update packages, then install them. Not only that though, also set up by default is a partition arrangement providing two copies of each read only partition, the standard update installer will then only update the inactive copy, for A:B rollback protection in the case of a bad update
Network management – Allowing the user or device appliation code to define how addresses are setup for wifi, cellular and Ethernet network interfaces on the device. Also, RF killswitch for “Airplane mode”.
Battery charging/management – Easily overlooked in a product development, but can cause issues if not dealt with properly. Android has a lot of support built in for this.
There is still work needed to customise these things for a particular system, but the inclusion of all this functionality provides a significant head start. Developers creating a device using other OS’s can often find they need to spend time researching solutions to these and other problems. Or worse, ending up “re-inventing the wheel” and creating new code from scratch for features which every IoT device needs that don’t really add specific value to the device, aside from keeping it secure, online and charged up.
Security – Older versions of Android (Like many OS’s) contain vulnerabilities which have been identified over time. But overall, the Android OS provides a good baseline level of security by default:
- SELinux for mandatory access controls to all files and resources
- Apps partitioned into seperate runtime sandboxes with seperate user and group IDs to enable access policy enforcements
- Trusted Execution Environment support based on Trusty OS, with APIs to make use of it in a known and consistent manner for a number of common usecases
- Secure boot – preventing un-official/rogue code being run on your device. Android provides this through Android Verified Boot (AVB), which is a generic framework utilising the secure boot mechanisms provided in the specific System-on-chips supported by Android.
Over the air update – software on the device to retrieve and securely authenticate update packages, then install them. Not only that though, also set up by default is a partition arrangement providing two copies of each read only partition, the standard update installer will then only update the inactive copy, for A:B rollback protection in the case of a bad update
Network management – Allowing the user or device appliation code to define how addresses are setup for wifi, cellular and Ethernet network interfaces on the device. Also, RF killswitch for “Airplane mode”.
Battery charging/management – Easily overlooked in a product development, but can cause issues if not dealt with properly. Android has a lot of support built in for this.
There is still work needed to customise these things for a particular system, but the inclusion of all this functionality provides a significant head start. Developers creating a device using other OS’s can often find they need to spend time researching solutions to these and other problems. Or worse, ending up “re-inventing the wheel” and creating new code from scratch for features which every IoT device needs that don’t really add specific value to the device, aside from keeping it secure, online and charged up.
Witekio can support your custom Android OS development
Witekio can handle all of the above issues for you, providing a working Android build with all required features for your hardware. This will avoid you having to spend time building up this specialised knowledge internally, and instead your team can spend that time focusing instead on the core value of your product.
Over time we have developed strong partnerships with the biggest microprocessors, microcontrollers, and reference card vendors our clients build their Android OS on. Market leaders like Texas Instruments have relied on Witekio to develop the Android KitKat and Android Marshmallow BSPs for their Sitara-based platforms. Many companies have also launched innovative products using our BSPs for the TI AM335x, TI AL437x, and TI AM57x processors available for self-service download on the Witekio website.
Over time we have developed strong partnerships with the biggest microprocessors, microcontrollers, and reference card vendors our clients build their Android OS on. Market leaders like Texas Instruments have relied on Witekio to develop the Android KitKat and Android Marshmallow BSPs for their Sitara-based platforms. Many companies have also launched innovative products using our BSPs for the TI AM335x, TI AL437x, and TI AM57x processors available for self-service download on the Witekio website.
Our Embedded software expertise
Your trusted embedded software, application and connectivity partner
4 countries
ISO 27001 certified
