Most Android devices — Android phones, tablets, laptops — are sold with a stock version of the open-source operating system (OS). No matter where you get the devices from — Samsung, Xiaomi, Lenovo — they come with a stock version of Android OS. After booting up a device loaded with stock Android OS for any use case, some customization is possible for certain aspects of the experience. You can download applications and change the settings. But, you can’t change the system behavior with a stock OS. For example, you can’t change the animation that’s displayed when the device is booting up. 

A custom operating system (OS) gives Android DevOps teams significantly greater control over system behavior and updates. You have the potential for full control of the device experience appearance, performance, custom recovery, and you can also achieve improved support for new features, firmware, hardware, and functionality. 

4 Benefits of a Custom Android OS

1. Superior Support for Hardware and Peripherals

To understand why a custom Android operating system (OS) can improve support for vertical hardware and peripherals, it’s important to look toward the structure of the Android OS. The kernel of an interface between the device hardware and the Android OS. The kernel plays a key role in supporting device hardware. For example, in order for a smartphone camera to function, the kernel needs to support the camera driver for the Android OS to recognize the hardware.

An operating system can be crucial for successfully deploying single-purpose use cases, which involve non-traditional Android hardware or peripheral devices. Stock Android OS may not support programming boards or single-board computers or other hardware with different components. Custom Android OS provides the flexibility to add support for any new supported device or hardware component.

2. Less Bloatware

Tablets and smartphones with the latest version of the stock Android OS are typically shipped from the manufacturer loaded up with bloatware – or, unneeded apps that are installed automatically the first time a device is booted up. Bloatware isn’t necessary for single-purpose device use cases. It takes up device memory, and in some cases, bloatware apps could be a security risk.

A custom OS can eliminate the risks of bloatware from the equation by letting DevOps teams pick which applications are loaded on the device from the moment it’s booted up. It removes bloatware from the equation and offers the possibility to easily provision devices to Android kiosk mode or multi-app kiosk mode. 

3. Superior Performance and Battery Life

A custom Android OS can provide the baseline to optimize performance and battery life, although the specifics can vary depending on the hardware and use case. 

In the case of a retail kiosk, a custom Android OS that’s linked to your cloud management tools can provide the possibility to optimize how power is consumed by the device. If a device is idle, DevOps teams can force Android 6.0+ devices into deep sleep mode, also known as LPM (Least Power Mode). For use cases where kiosks remain idle for hours each day while a store or restaurant is closed to the public, it can lead to battery optimization and minimal power consumption. 

4. Hardware and Software Security

A custom Android OS is linked to superior hardware security, especially in single-purpose device use cases. It provides the ability to control user access to hardware components, such as blocking access to the 3.5mm audio jack.

Also, custom OS admins protect the device from the arbitrary execution of code, which delivers protection from malicious code execution. There are many other opportunities to improve software security with customized OS within the context of hardware and use case. 

Image by Gerd Altmann from Pixabay

Considerations for a Custom Android OS

When you create or use a custom Android OS on a GMS-certified device, you need to make certain accommodations to pass the Android Safetynet. This is a Google-provided API for GMS-certified Android devices that provides DevOps teams with real-time insight into device tampering and security status. A rooted device with an unlocked bootloader may fail Google’s CTS profile tests to determine whether a device is capable of handling lay Store apps.

For a device to offer GMS apps and services, it needs to pass CTS tests for Safetynet. It’s an important consideration to keep in mind for many single-purpose use cases that involve Google APIs or apps.

Also, it’s important to carefully control against any chances of bugs or inadvertently bricking a device with a custom Android OS. These risks depend on how you build the OS and where the source code is from. Khadas has released the source code for the Khadas board to protect customers from this possibility. If you are taking the code from AOSP, you need to tune the source code to be compatible with the hardware.

How to Identify a Trustworthy Custom Android OS

The single most-important factor in identifying a trustworthy custom OS is the source. One way to determine source legitimacy is to verify hardware compatibility after booting the device with any app that has passed Safetynet. A Safetynet-passed app will tell you whether CTS tests are passed or not. If the CTS has passed, it’s a strong sign that your custom Android OS is reliable. 

Safetynet can also be used to test the legitimacy of a custom OS source. When installing a Custom OS, you are actually installing a binary image which has been built from the source code. So you can inspect the source code to see if it’s reliable. 

Can You Revert to Stock ROM After Adding a Custom Android OS? 

AOSP source code is Vanilla and does not support any hardware. You will need to add the support for the hardware via ‘Device Bring up,’ the process of converting AOSP to a hardware-targeted build. After that, your ability to revert to Stock ROM without encountering issues depends entirely on the hardware manufacturer.

If the bootloader is locked, you cannot flash a custom Android OS to the device. In other cases, some manufacturers offer limited ability to relock the bootloader, which means that a flashed device will be permanently unlocked after bringing up a custom Android OS. This means the safety net parameter will fail since it relies on checking the basic integrity of the device according to bootloader lock status and CTS profile tests.

So sometimes when you try to revert back to the original Stock ROM, your bootloader status will remain unlocked and you will not be allowed to lock it. This means that the integrity of your device is permanently compromised.

Esper has teamed up with some of the world’s leading Android device innovators like Lenovo, Zebra, Honeywell, and more to offer our custom Android OS, Esper Foundation for Android, off-the-shelf on devices for countless single-purpose use cases. To learn more, request a demo or check out our growing selection of GMS-certified and AOSP (non-GMS) Android hardware with custom OS.