➡ Android’s complex structure includes a vendor layer, bootloader, and partitions. The vendor layer and bootloader are not open source. Android devices are installed in groups of files segmented by partitions and directories. The Android build process involves assembling modules and binaries from around a thousand git repositories, some from Linux, Google, and the original equipment manufacturer (OEM). This process creates a flashable image. Lineage OS and other operating systems modify the Android framework, not the underlying Linux code. GrapheneOS is unique as it modifies code outside of the Android framework, hardening the tools against security threats. However, this hardening may not be possible moving forward, particularly on Pixel devices.

➡ BraxTech is working on enhancing phone software security beyond just the Android framework. They’re merging their LunarOS with EOD OS and Ubuntu Touch to create a secure system for the Brax 3 phone. This open-source project allows other developers to contribute to the hardening of the system, benefiting a larger community. BraxTech, supported by its community and offering products like De Google Pixel Phones and Brax Virtual Phone, invites anyone interested in porting their AOSP-based project to Brax 3 to join them.

If some of you are expecting this video to be a drama or a feud between me and the GrapheneOS community, you can run along now as that is not what this is about. GrapheneOS and previously others like it, like Calixos, are specific builds of modified Android that were focused on privacy and security and they were able to accomplish this on Pixels because Google allowed open access to the code of a Google Pixel. But as many of you have heard, Google locked the source code down on pixels starting with Android 16. The effect of this is to basically stop the prior approach taken by grapheneos and Calixos in building their versions of Android.

While this is a negative milestone, it doesn’t stop everything and certainly doesn’t prevent making privacy and security focused Androids. It doesn’t stop all custom ROMs either. Lineage OS still flourishes. GrapheneOS is sticking to its prior methods so far, but it doesn’t have much of a choice because of their different goals on a pixel. I will take a very detailed approach here and that is really the distinguishing characteristic of this channel. We’ll do a deep dive into the Android architecture and build process. I will warn you that this is a very technical discussion of the Android architecture.

If you have some knowledge of flashing custom ROMs or are a user of these custom ROMs or are interested in GrapheneOS, this will be important for you. But even if you’re not technically savvy to this level, the conclusions here are extremely important as it provides a roadmap to privacy and security versions of Android for the long haul. Stay right there. By the way, this is such a complex topic that it is possible that I got some parts wrong. Unfortunately a lot of pieces here were not openly documented, so there is a little bit of OSINT required.

If so, just tell me in the comments nicely and I’ll make sure to spread the word as this is likely going to be a multi video topic today I’m specifically focusing on GrapheneOS because unlike all other custom ROMs, they took a different approach and that makes them unique and allowed them to make specific claims about hardening Android against cyber attacks. Just to state this openly, the mentally unstable leader of GrapheneOS has spent his time attacking others and me in particular. I don’t care about his attacks or the lies he spreads about me, but forgetting his attacks and the negative cult he cultivates, it is in fact a boon to the privacy and security community that there is a project that focuses on finding ways to make our phones more private and secure.

GrapheneOS is great. As a project I’ve spent a lot of time examining the source code changes and if some other developer on some other custom ROM agrees with with the security or privacy benefit of what has been documented, then those changes could be easily applied to another project. This is the great benefit of an open source approach. But what truly differentiates Graphene OS is that instead of just changing portions of Android called the Android Framework, which is typically the only thing changed by other custom ROMs, they change the actual low level code in the Android device itself and this means accessing the Linux layer and deeper parts of the Android source code.

These modules are typically written in C and I appreciate that as I have coded enterprise systems entirely in C in my career. Unfortunately, Graphinos relied on Google maintaining their behavior of releasing the complete source code of Android for the Pixel, but now Google changed. Google could have deliberately made this decision to cut off grapheneos and Calixos. Maybe it’s because of other reasons we don’t know of course, but the end result is that the Linux level source code in Android is now inaccessible on pixels. The effect of this on GrapheneOS is that while it can still make changes to the open source called AOSP or otherwise known as the Android Framework, low level device code can no longer be altered on a Google Pixel.

This has so many effects including killing features like verified boot, changing the LIBC libraries or low level Linux functions. And there’s other changes disabling features of device drivers that GrapheneOS utilized. Most of these features relate to the hardening of Android against cyber attacks, but typically do not affect the privacy benefits. By the way, the main privacy changes to Android which relate to removing Google Spyware are mostly in the Android framework and can be changed by all custom ROMs including Calix OS, EOD OS and Linux OS. And this is why other privacy focused OSes are not affected as much.

Before I get into a complete explanation of that, let me tell you the basics of the Android architecture and its build process. Android Architecture this chart shows the architecture of Android. The green layer encompassing several modules is called the Framework and that is basically the source code available. If you look into the source code of Android Open Source Project aosp, this framework supports the Android apps, those included in AOSP and those created by third party developers. @ this level the apps are often downloaded as APK files and apps at this layer are developed using Java or Kotlin.

The apps are divided into two groups. System apps are pre installed on your device and third party apps are downloaded from Google Play Store by the way, later on in the release process, Google overlays those system apps with its own proprietary versions, and that’s where all the Google spyware is shown in red. There’s a layer called the Android Runtime, or art that converts the Android app code into fast executing code that can execute functions made available by the framework. So Android apps can only run code that calls the framework functions. There’s no direct access to the hardware.

Everything has to go through the Android runtime, and each app is granted permission but by the framework. In order to access hardware like the screen, the touch interface, the microphone, speakers, camera, sensors, cell service, Internet, the framework connects to the low level functions provided under Linux itself. The Linux section is in yellow, but before the framework can talk to Linux functions, there is a translation layer, and this is called the Hardware abstraction layer, or HAL, which I show in purple. HAL’s job is to communicate directly with Linux drivers and Linux functions to make it available to the framework layer.

This layer is built using an interface that Google called HIDL HAL Interface Description Language, or now AIDL Android Interface Definition Language. The purpose of this language is for an OEM or a vendor making the SOC system on a chip like Qualcomm or MediaTek to compile a layer to communicate with Linux level drivers. By standardizing this communication method, but allowing it to be developed separately, it creates a consistent translation layer but allows for independent updates. Since this is actually created by the oem, some functions in the framework can talk directly to Linux functions using HAL but not connected to a vendor.

And I presume some framework functions can call Linux directly without HAL if they’re stable and never change, like the C library functions. Now let’s talk about the Linux layer which I show here in yellow. In essence, from here all the coding is essentially standard C as used in Linux. Linux is independent of Android, but is part of the Android device build to make Android run on an Android compatible device. It has a standard Linux kernel which is currently Linux 6.1 and that is used on the new versions of Android device manufacturers, for example those that make touchscreens, fingerprint readers, Bluetooth radios, GPS radios, speakers, microphones, cell basedband modems, and so on.

Write their device interface code in in C. Typically, those device drivers used in laptop and desktop computers are submitted to Linux itself and Linux Torvalds gets to integrate them into the base Linux kernel that Linux users know as Mainline Linux. However, plenty of device manufacturers do not mainline their drivers, thus the lingo that says they don’t submit their drivers upstream for inclusion into The Linux kernel, because sending it to Linux means the device driver has to be in source code format, because of course once they do that, then the internals of how their devices work are exposed to competitors.

For this reason, the Linux installed in Android is actually made up of two sections. First you get the mainline Linux kernel, which includes standardized drivers, which by the way can still be modified by Google with newer changes called upstreaming. And then the second section of Linux is where the OEM proprietary drivers are installed in. And these are all compiled modules and are closed source. This is standard on all Androids. Now the purpose of explaining all this to this degree is to show you where the open source code is. The entire Linux distribution, including its libraries and mainline drivers, are all open source, but not by Google.

They are open source from Linux itself. And this is something that Google has to abide by since it is tied to their use of Linux and the GPL license. The actual AOSP is also open sourced by Google, which as I said is really only the Android framework. And as I said, the vendor layer includes only binary executable code from the oem, and these are never open source, even on current pixels. Now, the last layer of the Android architecture is the bootloader, which I show in gray. The bootloader is a piece of code that actually starts the OS and initializes Linux.

While this is standardized on many x86 computers, for example, using Coreboot on Android, each OEM creates their own bootloader and this is integrated into the Android rom. The bootloader is not open source. Android partitions the theoretical architecture I’ve just described gives you a big picture of how things are connected. But now let’s enter the real world. I will start backwards here and start from the knowledge base of someone flashing a custom rom. We will bring you to the physical reality by showing you how these translate into the actual content you see. Or on an Android storage device which is made up of partitions and files, though in the end everything ends up as thousands of individual files.

On an Android device, the standard way they are installed are in groups of files segmented by partitions and further directories. Some of you have experience using the Adbug tool provided by Google, which allows you to replace the OS image in in the Android storage. Typically, a person installing a custom ROM would put the device in fastboot mode and then you use ADB to flash the image to the device. First you would allow replacing of the ROM image using an option OEM unlock on the current version of Android. Then you would use some tool provided by the bootloader, or you replace the bootloader with a custom1 like twrp.

You put the device in something called fast boot mode and then using a compatible tool, you either flash a complete image onto the device, or, depending on the device, you install segments of the OS as separate partitions. Just to give you a view of this, these are the separate partition images typically available when you install Lineage os. I’m just giving you generic names here for some of the partitions, as each OEM may change this and I also show you the associated flashable image associated with it. This kind of organization actually was thought out over time and has evolved from the early versions of Android.

The reason for this separation is to allow owners of each partition to update their sections independently. The system partition is what actually contains the Android framework, so this is the actual result of compiling the Android open source project by itself. Another term for this is a GSI or generic system image, and this isolation of all things framework related to this one partition allowed a standardized Android to be installed on multiple devices simply by replacing a stable framework image and then tweaking the behavior of the framework for a specific device using XML files called overlays. This is actually how much of Lineage OS is made, so the only thing modified by Lineage OS is the framework.

This is an important distinction that we’ll come back to later. Now, just to leave Theory for a moment using adb, I will show you the different directories. Sam to give you a complete big picture of how one creates a complete image for an Android device, I will describe what is called the build process of Android. Some of this is assembly of the modules and binaries, and some of it actually creates executable code which is called compiling. If I were a manufacturer of a phone, I would have access to all the source code needed to create a build, and today this is done via git repositories.

I believe there are approximately a thousand git repositories tied to Android, meaning there are 1,000 separate projects, some from Linux, many from Google, and some from the oem. There’s a standard procedure for creating a list of related projects that need to be included in the build. Rather than get complicated in identifying specific agents like Kita soon ninja or makefiles and BP files, etc. The complex structuring of a thousand projects making up Android means that something assembles a complete list called a manifest, and then you specify what you want to build as an end product, and then your device will clone all the git repositories with all all the latest code and then this is clone on a machine that will build the project using the manifest as a procedure map and several hours later you have your flashable image.

So in the big picture sense, the only people who can build a complete flashable image are those that have access to all the thousand or so repositories. And in the case of Graphene os, it also includes access to their own repositories which are added to the build process and replaces the applicable repositories provided by Google. The new reality is that those relying on this build process needs access to the pixel repositories beyond just the framework. The framework is always available in aosp. For those interested, the actual git repositories for AOSP are in Android.googlesource.com and I can show you that here.

But without complete access to the entire collection of repositories, Graphene OS cannot do a complete build of the entire image. Now, the reason this is not important to Lineage OS is that Lineage OS that don’t actually build the entire Android for each device from source. My understanding is that Lineage OS takes the original flashable image files like dtbo, that image vendor image, OEM image and simply replaces the system image file, which as I already said is the Android framework or Android generic system image gsi. They just extract these images from an existing phone without rebuilding them.

So those files are original from the manufacturer and then when the OEM updates them, Lineage OS just updates their copy and then they flash it back to the device. However, in order to allow this, depending on the oem, they may need to replace the bootloader or boot that image with some open version like twrp. TWRP and the device boots like normal, those using EOD os, Calaxos and even Ubuntu Touch are taking all the image files from Lineage OS and basically are reconstructing all the standard images coming from the OEM and then replacing the system image. This approach by Lineage OS creates some differences from the GrapheneOS solution.

First, the vendor or Linux portions are never modified on Lineage os. Second, because it is not built together, the signatures of each image will not match what is originally noted by the vendor and this leads to the problem of verified boot. Thus, Android devices using this method cannot be bootloader locked since the modules are no longer original original and those using Linux OS will encounter some scary message to that effect which we all have ignored. This is not a problem of any build process that has the entire source code repositories since the signatures are part of the build.

But the Lineage OS hack will not allow this. And as I already said, Linux OS and other OSes based on it are just modifying the Android framework and not the underlying Linux code or hal. Assuming a bootloader is unlocked, Linux OS will work using the method I described. Many phone models of course never unlock their bootloader and an example of that is Samsung what it means for Low level code changes this has profound implications for grapheneos. I believe it is the only open source project currently in existence that modifies code outside of the Android framework. GrapheneOS modified Linux libraries directly by changing the standard C library functions with the intent of hardening the tools against buffer overruns and so forth, or clearing memory Every so often.

GrapheneOS couldn’t modify the drivers provided by the vendor in vendor related partitions, but it was for example possible for certain drivers to be intercepted and disabled at the Linux level so that those drivers are not active. For example, GrapheneOS modified the build so that the USB C port only enables charging when the phone is locked or if some new sensor is added to the phone it would be possible to disable that sensor at the linux level. So grapheneOS build features would be important for high security level individuals like Snowden types and honestly I commend them for it.

Calixos though they use this same full build process as GrapheneOS did not in my observation modify low level Linux code so it doesn’t affect them much to go with the Lineage OS approach of just modifying the framework. So it sounds like Kallax switched to integrating Lineage OS in their build process to fill in the blanks on pixels. This appears to be their solution as Lineage OS is now referenced as a source on their website, though it will affect their previous verified boot claim which I presume will be removed for Android 16 and up. This is also what was originally done by EODA os so it matches what Calixos appears to be doing now.

Since the hardening claims of grapheneos are tied to modifying Linux source code for Android, then that claim can no longer be possible moving forward, at least not on a pixel. It would seem that those interested in Android hardening will have lost a choice. All is not lost. While some may describe this situation as an obituary not just for GrapheneOS but any other phone project that may believe in hardening the phone software beyond just the Android framework. Let me reveal why the doors are just opening if people want to do it. To demonstrate this I will describe our relationship with EOD OS and also currently with Ubuntu Touch.

The difference here is that we have the source code for the complete Android compile of a Brax 3 phone in the final OS image we create for this is called LunarOS. For some of you with a Brax2 phone this was called Brax OS which was just a fork of Lunar os. EOD OS made modifications to AOSP or the framework, but instead of using the Linux OS method of taking files from the OEM and adding a framework, our dev team actually takes the IODOS repository and adds it to the build process, thus combining lunaros in EOD os.

Let me repeat that the lunaros and EOD OS are merged with with EOD OS replacing the entire system partition during build. This means that the final result is a complete EOD image for flashing Android on Rax 3 and appears as a manufacturer authentic code complete with verified boot and lockable bootloader. We will be doing the same with Ubuntu Touch as well and whoever else wants to port their AOSP variant to Brax 3. So the base code which has the Linux kernel and all the associated code that was available on Pixels is also available on LunarOS. The dev team is organizing this now, but the end result should be that other parties could integrate hardening code in the LunarOS repository which is open source and as I said has all the code previously available to GrapheneOS and then these hardening changes can then benefit a larger community and it will not be a dead end.

Obviously any hardening of the non framework related code on LunarOS gets automatically integrated into builds of EOD OS, Ubuntu Touch and so on. Now the days of GrapheneOS for pixels may be numbered. They can keep going with the source code available from Android 15, but going forward it becomes more difficult. Community developers though who are interested in helping a larger pool of people can still be able to contribute to an Android hardening project just on a different device. So the future is still open. If you want to port your AOSP based project to a Brax 3 or any other future device we make, then you are welcome and feel free to contact the team at BraxTech.

I expect that there will be more devices available to this project in the future, so stay tuned folks. While other channels sustain themselves via sponsorships, we are actively sustained solely by this community. Thank you to those who provide financial support directly to us through patreon locals and YouTube memberships. We have also taken the approach of actually creating an organization you can trust by creating products that support your goal and ours of achieving privacy and offering it with the best possible service at a reasonable price. And this is how we chose to sustain this channel. For those Interested in the Brax3 project that is handled by the site braxtech.net and you can see the current status of the project there, which currently started shipping we have other products that you will find in our community area.

On Braxme there are over 120,000 users that are part of our community that discuss security and privacy issues in a safe environment. Many of you believe in us and so this community is growing. Some have been involved for more than 10 years in our store. There you will find products like De Google Pixel Phones, Brax Virtual Phone, braxmail and Vice vpn. These are an essential base to building your personal privacy and of course support the creation of content on this channel. Thank you for watching and see you next time.
[tr:tra].

See more of Rob Braxman Tech on their Public Channel and the MPN Rob Braxman Tech channel.