What is a Custom OS?

A custom OS (operating system) can generally be defined as a version of a computer operating system that has been built with specific goals in mind. These are usually based on open source software like Android or Linux, though heavily modified versions of closed source operating systems could also be considered “custom” in some cases.

A customized Android OS gives you 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. 

Most Android devices — Android phones and tablets, for example — are sold with a version of the OS that can’t be fully customized. After booting up any device, 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 of the preinstalled OS. For example, you can’t change the animation that’s displayed when the device is booting up. 

That’s where a custom OS really excels. If you want full control of the software on your devices both functionally and aesthetically, a custom OS is the way to go.

Esper Foundation for Android

Benefits of a Custom Android OS

There are numerous benefits to going for a custom Android OS on your devices — regardless of whether you’re building for a handful of devices or 10,000. 

Superior Support for Hardware and Peripherals

By default, Android supports a wide variety of hardware devices and peripherals, but in many cases, specific features are needed from additional hardware. A custom Android OS offers the ability to bake new hardware support at the ground level — in the kernel. The kernel plays a key role in supporting device hardware at the OS level. 

For example, standard Android builds may not support certain hardware for custom devices — like a specific logic board. A custom Android OS provides the flexibility to add support for nearly any hardware component. 

Less Bloatware

Consumer tablets and smartphones are typically loaded up with bloatware — unneeded apps that are pre-installed on the device. Bloatware isn’t necessary for single-purpose device use cases. It takes up storage space, 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 developers pick which applications are loaded on the device from the moment it’s booted up. With bloatware removed from the equation, your devices are faster and more secure.  

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, Android 6.0+ devices can be put into device idle mode, also known as Doze 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. 

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 or disabling the volume rocker.

Also, custom OS admins can protect the device from the arbitrary execution of code by restricting the applications that can be used on the device. There are many other opportunities to improve software security with customized OS within the context of hardware and use case. 

Considerations for a custom Android OS

When you deploy a custom Android OS onto a GMS-certified device, you need to consider how your app will behave from the lack of  Google’s SafetyNet Attestation API. 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. Rooting or unlocking the bootloader of a device may cause it to fail SafetyNet Attestation, in which case certain apps relying on the API may refuse to run. 

For a device to offer GMS apps and services, which includes the SafetyNet API, it needs to pass CTS (Compatibility Test Suite). 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

Identifying a trustworthy, secure, and compatible custom Android OS requires a holistic evaluation of source code – no one test or suite can tell you an OS distro is “safe.” However, compatibility testing can provide some insights. 

The Android Compatibility Test Suite (Android CTS) can determine if a custom operating system based on open source AOSP code is “compatible” with Android under the definitions established by Google in the Android Compatibility Definition Document (Android CDD). The CTS does not determine if your custom OS contains backdoors, unpatched exploits, or is properly configured to your organization’s security requirements. The Android CTS merely says your custom OS build should work normally and be compatible with properly built Android applications (including GMS). 

Even if your custom OS passes the Android CTS, that does not give you permission to distribute GMS, and it does not mean your devices will pass SafetyNet checks when running your custom OS. Both GMS and SafetyNet require an active Mobile Application Distribution Agreement (MADA) with Google, which is the contract that allows a device maker (OEM) to ship Google Mobile Services and related Google apps on their devices. 

Failing SafetyNet does not make a custom OS “unsafe,” however; just that apps requiring SafetyNet attestation will not run. Failing the Android CTS could be greater cause for concern, but that depends entirely on the exact reasons your build failed compatibility testing.

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 that SafetyNet Attestation will fail since it relies on checking the basic integrity of the device according to, among other things, the bootloader lock status.

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 because a malicious actor with physical access could theoretically flash their own images onto the device.

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.

What is an embedded OS?

When talking about custom operating systems, the term “embedded OS” comes up quite often. In definition, an embedded OS sounds very similar to a custom OS: it’s an operating system designed to perform a specific function. Historically, the primary difference with embedded OSes is that they usually run on devices that aren’t traditional computers — think ATMs, ticketing booths, etc. However, as technology advances, these devices are becoming increasingly smarter and often use more computer-like systems to power more advanced features.

So, can an embedded OS be modified?

It’s possible to update, change, or even replace an embedded OS, but the level of difficulty will depend on the type of device. For example, a modern point of sale system may use an embedded operating system that runs on computer-like hardware, making it easier to replace with a custom OS designed specifically for that hardware. An ATM, on the other, will likely be much harder to build for, as the embedded OS is specifically built for security. Making it easily replaceable would be a security flaw, so it’s unlikely you’d be able to do so easily (if at all).

Esper Foundation for Android