A Revolution in Custom ROMs: How Project Treble makes Porting Android Oreo a 1 Day Job
The XDA forums have been the central gathering of custom ROM development for years. It’s thanks to the hard work of developers on our forums that many older Android smartphones are kept alive by custom ROMS sometimes years after devices were abandoned by the device maker. Though most manufacturers release bootloader unlocking methods these days, frequent delays in kernel source releases has stifled custom ROM development on many smartphones. That may soon change, however, thanks to something called “Project Treble” which was announced near the release of Android Oreo. Thanks to Project Treble, the time it takes to port an AOSP ROM onto a device should no longer take weeks or months—instead it should take merely days.
For those of you who have followed the custom ROM scene for years, you might already be aware with how significant this news is. XDA Recognized Developer OldDroid called this revelation a “breakthrough” in custom AOSP ROM development. Thanks to Project Treble support, for example, I was able to boot a nearly fully functioning Android 8.0 Oreo ROM on the Huawei Mate 9—a device that until now hadn’t even seen a single AOSP Android Nougat ROM.
We may soon be seeing a revolution in custom ROM development thanks to the initial development efforts on this front by XDA Senior Member phhusson. After 20 hours of work researching, developing, and debugging with me, phhusson created a system image that can be booted on multiple devices from different manufacturers and with completely different SoCs. For example, the same system image that I booted on my own Huawei Mate 9 also boots on the Honor 8 Pro, Honor 9, Sony Xperia XZ1 Compact, and the Essential Phone. That’s 3 different OEMs (Huawei/Honor, Sony, and Essential) and 2 different SoCs (HiSilicon Kirin 960 and Qualcomm Snapdragon 835) where this single system image can successfully boot.
It’s possible that in the future, we could be seeing a single system image that can work on dozens of different Android smartphones, much like how Microsoft Windows can run on nearly any computer hardware. In order to encourage more development on this front, we’ve opened up a new forum dedicated to Project Treble enabled devices. The forum is geared towards developers at this moment, so please refrain from starting a new thread unless you are interested in contributing to development. If you wish to help test Treble-compatible system images, then feel free to leave comments on existing threads.
Given the significance of this development and the complexity of the topic, I thought I would approach this article a bit differently than the others. I’ll be running down a bullet point list explaining some common questions people might have as well as point out key facts regarding this latest development.
What is Project Treble?
Project Treble is most commonly described as an attempt by Google to modularize the Android OS framework to separate vendor specific code. Let’s break things down a bit more:
- The full update process to bring a new Android version to devices is a long and complex topic, but Sony has done a great job with this infographic which outlines the basic steps.
- The “vendor” usually refers to silicon-manufacturers such as Qualcomm, but can also refer to the maker of any other proprietary hardware found in a device. The “device maker” or “OEM” usually needs to wait for the vendor to update their code so the proprietary hardware works with the Android OS framework in a newer version of Android.
- However, what is happening with Project Treble is that Google is requiring that any vendor-specific code be separated from the Android OS framework and instead live in its own vendor implementation. Usually this means that there is now a separate /vendor partition on Treble-enabled smartphones that contains a bunch of HALs (Hardware Abstraction Layers).
- Furthermore, vendors must implement code that lets the Android OS framework communicate with HALs in a standardized way. This is done via HIDL (HAL Interface Definition Language). With this in place, an OEM can work on an Android update without having to wait on vendors to update their HALs. Theoretically, this should speed up the entire Android update process as vendors can update their code at any time through the Play Store, for example.
- To help understand what a HAL is and how it relates to Android, let’s consider an analogy. Imagine a car. The steering wheel and brakes are the HAL while the driver is the Android OS framework. The driver (Android) moves the steering wheel and presses on the brakes (the HAL) in order to control the movement of the car (the hardware).
- Now imagine if we lived in a world where every car manufacturer decided to design their steering wheels or re-arrange their brakes in a completely different way. If you put a driver in a new car, they may be confused with how to initially handle the vehicle. But thanks to standards, every driver should be familiar with how to operate a steering wheel and brakes on almost any car. Further, driving school teaches all drivers the proper way to operate a vehicle. In this analogy, the vehicle standards are Project Treble and driving school is HIDL.
What devices will get Project Treble support?
- All devices that launch with Android 8.0 Oreo or above must fully support Project Treble.
- All devices that upgrade to Android 8.0 Oreo are not required to fully support Project Treble.
- The devices that have updates (official releases or closed betas) to Android 8.0 Oreo and do support Treble include the following:
- It is unlikely for any devices to unofficially receive Project Treble support via custom ROM development. HALs are not open source after all.
Why is Project Treble so important for AOSP ROMs?
- To ensure that the vendor code is properly separated from the Android OS framework in the manner that Project Treble requires, Google has set up a Vendor Test Suite (VTS) which devices must pass in order to be certified by Google. Google certification is important because without it a device are not allowed to ship with Google Play apps and services pre-installed.
- One of the requirements in the VTS is that a Treble-enabled device must be able to boot a raw, generic AOSP build. Because of this requirement, OEMs have to ship devices that can boot AOSP without any issues.
- Although the exact ROM that Google uses and shares with OEMs for VTS is not public, XDA Senior Member phhusson was able to figure out how to recreate this ROM from source.
- Thus, we now have a working AOSP ROM that is guaranteed to be bootable on Project Treble devices. Most of the work was done by OEMs and vendors already, so no longer do independent developers on our forums need to mess around with kernel source code or HAL hackery. In theory, an AOSP ROM should “just work” which we’ve shown to be basically true on the devices we’ve tested.
- At the moment, compatibility is not 100% with all devices the system image can be booted on. There are also some race conditions that need to be figured out. However, Project Treble significantly cuts down on the amount of development work that is needed to port AOSP ROMs onto non-Google devices. With the collaboration of more developers in our Project Treble forum, we expect to see Treble device development go a long way.
How do I try out Android Oreo on my device now?
If you’re really adventurous and want to try out one of these Project Treble builds on your phone right now, phhusson has the system images you need to download over on his thread in our Project Treble forum. There are a few things you need to keep in mind, though:
- You will need an unlocked bootloader and need to be familiar with using fastboot commands to flash images.
- Your device must already be running Android Oreo. These system images do not “upgrade” your device. If you are running one of the Huawei/Honor devices mentioned in this article, you can look on our forums for a guide or use the FunkyHuawei.club service to unofficially update your phone to one of the closed Oreo beta builds.
- You must be willing to lose data or reflash factory images while testing. The best way to ensure this boots is to wipe the userdata partition, which includes wiping all of the contents on your internal storage. Of course you can make backups and transfer them over once you’re done.
- These AOSP builds are currently not meant for use as daily drivers. They are extremely bare bones and do not offer many features or apps pre-installed. You will have to flash Google apps yourself. You will have to manually input your carrier’s APN settings to make mobile data work (if it works). Things will be buggy until more development effort is put forth.
Google wasn’t kidding when they said that Project Treble was perhaps one of the biggest changes ever to the way Android works. We can see for ourselves, right here and now, just how much of an impact it can have. Treble might be the push the development community needs to revitalize the custom ROM scene. It took less than 1 day to boot a nearly fully functioning AOSP ROM on the Huawei Mate 9. I’m excited to see the work that will be done for other Treble-enabled devices.