Though, this is a work in progress, and unexpected things, ranging from simple usability problems up to boot issues, might occur if something doesn’t go right. If you face an issue due to this module, make sure to report this to the developer so they can try to fix it.

Several custom ROM developers might already be working on implementing this on their OS as well. If you’re unsure if they will actually do so, make sure to ask them about it. Pay attention that Magisk modules conflicting with specific ROM features most probably will cause issues mentioned above on the ROM you’re using.

If you’re sure about these 2 disclaimers above and still want to go on, you need to make sure of a few things to avoid majority of issues;

1. Your device must be on Android 12, obviously.
2. Your current ROM must be as close as possible to AOSP. MIUI, ColorOS, and such are not supported. Highly customized ROMs like dotOS might work, but not guaranteed to.
3. Your ROM must be rooted with Magisk, for sure. Custom recovery isn’t too big of a requirement – don’t laugh at me, there are devices that don’t have custom ROMs and given GSIs’ existence, you can simply install a GSI build/port of a custom ROM through fastboot – but you would be a step ahead in case your device refuses to boot after flashing, or using, a Magisk module. You can also boot to safe mode so you have all Magisk modules disabled at once so you can uninstall the faulty module as well, but it’s more of a hassle compared to use of recovery mode.

If you meet these prerequisites, let’s begin with installation process.

Installing Magisk Module for Live Blur on Volume Panel

First of all, download the variant you wish from here. Each variant is named for their blur radius in pixel basis, so make sure you go with correct variant you want. You can check the screenshots at the beginning of this post if you want to see examples of them.

Once download finishes, transfer the file to your phone if you have downloaded it from your PC, open Magisk app and go to “Modules” tab, the puzzle icon.

Now choose “Install from storage” from the very top of the menu, and locate the module you have downloaded or transferred just now.

Once you choose the file, the installation will start. It shouldn’t take too long for it to install as this is a pretty small module. As soon as it installs, hit the “Reboot” button that will appear at the bottom right corner of your screen. Keep in mind that you can delay reboot process and install more modules, but I don’t recommend you to do so because, from my personal experience, installing possibly conflicting modules without rebooting and seeing their effects individually mostly causes severe damages to usability of the system.

Once you hit the reboot button, if everything goes right, your device should boot properly and you should have blur in volume panel now! As of now, there’s no way to tune this manually, and if you don’t like the variant you have chosen, because of the way Magisk works, you need to remove existing module, install new one and reboot the device when you need to switch variants.

Of course before we begin, I’ll be using several terms:

Linux distro: A Linux distribution in general, really.
GRUB2: Second version of GRUB bootloader, stands for “GRand Unified Boot manager”, a GNU project allowing you to boot anything Linux and manage multiboots more easily.
Brunch: An unofficial GRUB2 bootloader to patch installed version of Chrome OS and make it usable on your PC.
Kernel commandline: The “parameters” passed to the “kernel” for booting to your OS in a more stable or functional status. Brunch allows you to customize this to troubleshoot issues to occur during booting or using CrOS.
Crosh: Stands for “Chrome OS Shell”, the Linux-like terminal allowing you to do lots of stuff that aren’t available through graphical interface.
ARC: Stands for “Android Runtime for Chrome”, allowing you to use Android apps on Chrome OS — Just like “Windows Subsystem for Android” but for Chrome.
Crouton: The official Linux implementation for Chrome OS by Google. It has containers by themselves, which uses the Chrome OS drivers and backends for operating.
Brioche: Brunch’s Linux implementation for Chrome OS by the bootloader’s developer. It also has a container system, but uses the internal drivers and such for operating.
Wayland: Some modern “renderer” used to load desktop environment and such. If you’re a Linux user, you should be aware of this.

Introduction to Brunch

From my words, Brunch is a customized GRUB for installing Chrome OS and patching it for using it on your computer without running into severe issues. It allows you to select what patch to apply and what not by configuring it on live system so you can make it usable or even as stable as possible on your device — Like targeted installation feature for Debian, but you configure things on your own. It utilizes an extra partition (Namely “ROOTC”) to store patches and stuff; and an EFI partition to, well, boot the system of course. It’s a long-aged project, but there aren’t many reliable resources except their Wiki as a guide to utilize it sadly…

What do you need?

The following requirements must be met.

• You need a PC with UEFI firmware if possible. Legacy BIOS could also work, but keep in mind that it requires several patches and unexpected issues are to occur. Also check CPU families and suitable firmwares for them. Not all families are supported though. No, Nvidia GPUs will never work because ChromeOS utilizes Wayland as compositor and there isn’t the driver to get it working on Nvidia installed.
• You need 2 external drives. USB or SD card, doesn’t matter. One will hold a bootable live distro, the other will hold assets to install Brunch bootloader and CrOS.
• Then you need some familiarity with Linux command line, patience to go through documentations and time to find patches to apply.

Installing Brunch

Installation procedure depends on how do you want to utilize the system. I’ll assume you want to install it on your system drive, overwriting the existing OS. For dualbooting and further troubleshooting, though, I recommend you to check Brunch GitHub.
So, first of all, you need to flash a Linux installation image to your USB drive using either Rufus (Windows), command line or a USB image writer shipped with your distro (Linux). Also download latest Brunch release and the official Chrome OS image for your device, on another external drive. I use “grunt” for AMD APUs, as my laptop has AMD A4. If you have Intel CPU older than 8th gen, for example, you’ll need “rammus”. You can check Brunch wiki for more information and table of supported CPUs and images for those as well.
Boot from the Linux USB you just created.
Then, go into the path you downloaded Brunch release into, open a terminal in there, and do these commands in the order;

# Extract Brunch files and Chrome OS recovery image.

tar -xvf brunch_(...).tar.gz
unzip /path/to/chromeos_codename_(...).bin.zip

# Make Chrome OS installing script executable.

chmod +x chromeos-install.sh

# Assuming you have Ubuntu up. Install dependencies for the script.

sudo apt install cgpt pv

# And lastly, run the script. Replace sdX with the target disk (in /dev). Use Gparted to identify.

sudo ./chromeos-install.sh -src /path/to/chromeos_codename_(...).bin -dst /dev/sdX

Now sit back and have a cup of tea. This will take a while. Once it’s done, reboot the PC, and boot from internal disk. We’re not done yet. When you have Chrome OS booted, check if WiFi is up first. You can do so by clicking on system tray and “expanding” WiFi tile. Optionally check for Bluetooth too. If one of those isn’t up, especially WiFi, do Ctrl+Alt+F2 to drop into a Chrome OS Developer Shell and log in as “chronos”, then do this command and follow the on-screen instructions;

sudo edit-brunch-config

Simply put, you need to mark the card you have (for example “rtl8723de” for Realtek RTL8723DE) and several other options sounding cool to you. I personally mark these options;

• “enable_updates” to, well, enable updates for getting from Settings > About Chrome OS.
• “pwa” to enable use of Brunch PWA.
• “mount_internal_drives” for accessing files under any other partitions on the disk Chrome OS was installed on. Keep in mind that enabling this option might have Media Storage on ARC running for the whole time and cause drastically high CPU usage!
• “rtl8723de” for my laptop’s WiFi card (Realtek RTL8723DE)
• “acpi_power_button” for power button — If you have tablet/2in1, long pressing on power button does its work out of box. This is for laptop and desktop users for which long pressing on power button does nothing but short pressing usually works.
• “suspend_s3” for S3 state suspend. ChromeOS usually doesn’t handle suspension right when you have S3 suspension and not S0/S1/S2. You can check if you need this enabled or not by giving this command on Windows:

  powercfg /a

  If you get some output similar to this, you need to enable this config.

  

For explanation on all these options, you can refer to Brunch wiki as well.

Once you have fixed as much issues as possible using Troubleshooting section, you’re now ready to use Chrome OS on your device! Was it any hard? I don’t think it was. One thing you need to keep in mind, though, is that you need to check for updates to Brunch bootloader regularly. And update them whenever possible to avoid further issues when updating your Chrome OS installation.
I hope you liked it. I’m thinking of continuing this article series by other methods of installations, some experimentations that worked better than the way they’re intended to be done and so on. See you all in another one!

Thanks to this face of Android, you can have many new privacy-related features on your device and you will be able to get rid of Google applications.

Before we begin, there will be a bunch of terms I’ll be using.

microG: Actively developed open source version of Google Play Services – Not developed or supported by Google themselves though.

Signature spoofing: A feature letting apps impersonate themselves as another app. For this case, microG impersonates itself as Google Play Services whenever possible.

Vanilla: No Google apps included – AOSP level.

Degoogled: With correct punctuation, “De-Google’d” means it’s filtered out of everything Google, can be either by removing components entirely or replacing them with something open source.

OMS: Stands for “Overlay Management System”, dynamic system theming framework. Android 7 has it through projekt Theme Interfacer, and rootless Android 8 has it through Andromeda (paid app from Play Store).

Now, let’s come to the things /e/OS provides.

First of all, since /e/OS is based on Lineage, and continues active development of old versions like them, you get their privacy features regardless of the Android version you’re stuck at until Lineage discontinues that Android version.

Secondly, it provides microG and removes some tracking features both from AOSP and Lineage, so that’s a plus.

Thirdly, it provides an alternative to Google sync with /e/ Foundation’s own account system, namely /e/ account. One down side is though, you can’t use the data synced with your /e/ account on another ROM if they don’t provide support for it, which is unlikely to happen anyway.

Then there are some unofficial projects like “ExtendROM” (by steadfasterX) to customize your /e/OS build. For example, the one I’m showcasing has several parts modified through it.

After that, developers at /e/ Foundation also try to fill in the gaps with OSS alternatives like K-9 Mail, their own app store (namely /e/ App Store), and many more!

One of the critical features, /e/OS also provides custom DNS settings if you want to use one!

It also spoofs device ID when you log into your Google account from system settings, so Google doesn’t know the device you actually use!

And lastly, they have their own online shop, selling second-hand smartphones preloaded with /e/OS itself, which is the coolest part!

Okay, cool, there are some other ROMs like Graphene doing that too. But did you know that they provide pretty much the same functionally on legacy Android versions like Android Nougat too? They sure do!

Of course, every good thing has bad things as well.

For example, I personally don’t like their fork of Bliss Launcher. It looks too iOS and feels really out of place. You can’t also change wallpaper right from there, neither can you go into app info or some other screen. They didn’t even bother adding support for Quickstep!

Another thing is the icons and switch styles they use – iOS style again. For the Android version I have, Android 7, switches are too big and don’t feel right.

OMS lovers, this ROM might be the one you would use! Because they didn’t add OMS support! I mean yes, I understand, they’re privacy focused. But at least they could’ve added support for it. It doesn’t invade privacy from what I know.

All in all, to be fair, /e/OS is cool, but could be improved more. We’ll see how will they improve their project. But of course, their motto is the one you sure need to pay attention: “Your data is YOUR data.”

/e/OS sources are available at their own GitLab instance.

Let’s start with the terms I’ll be using first.

GApps: Short for “Google Apps”. The apps that are usually preinstalled on stock ROMs. For example Google Play Services, Google Play Store, Google app, Google Calendar Sync, Google Contacts Sync, Google Services Framework, and so on.

TWRP: Standing for “TeamWin Recovery Project”, TWRP is a modern custom recovery you need to have on your device in order to flash unsigned packages or the ones your stock recovery doesn’t allow installing (GApps packages or Magisk for example).

MIUI Recovery: As in its name, MIUI’s stock recovery image.

Now, there are 2 ways to accomplish this.

1st way is to enable it right in the system – There are MIUI ROMs providing GApps this way!

Firstly, open up Settings.

Secondly, scroll down until you see an entry named Accounts & Sync. Open it.

Thirdly, look for a section named GOOGLE, and for an entry named Basic Google services underneath. Open it.

And lastly, enable the only switch you see, namely Basic Google services. The reason why it says “It will slightly reduce battery life.” is because of Google Play Services always working in the background and apps you get from Play Store or utilizing Play Services in some way depending on them. Enable the switch.

And there you go! Now you should have Play Store popping up on your home screen now. If you can’t see Play Store, just download and install apk.

Video Guide

2nd way isn’t much complicated, but requires that you have TWRP installed and that it isn’t overwritten by MIUI with MIUI Recovery.

Install GApps via TWRP

Firstly, you need to get a GApps package to flash. We did the testing with Weeb GApps but you can try some other GApps packages as long as you’re careful with them. Ah, and make sure to download the GApps package for your Android version of course. Pretty much all packages have Android version they’re made for appended in their file names.

Once you get one, reboot into recovery – In this case, TWRP and choose “Install”, follow the path to the GApps installed. (We flashed Weeb GApps version 4.1.8 for Android 11, MIUI 12.x here.) And then swipe the slider to right.

After that’s done, tap on “Reboot system” and let the system to fully boot. Lastly, voila, you should have working GApps out of the box!

As a little information though, external GApps method might cause much shorter battery life than integrated one. So always prefer first way whenever possible.

Before we begin though, I need to explain several terms I’ll be using in this article.

“GH” stands for “GitHub”. This is where the tool’s name originates from as well, so it can’t be confused with Git itself. To explain what it does in general, you can create, fork, delete, browse repos; create pull requests; and many more. In case you can’t find a feature but also don’t want to leave terminal, it also provides a text-based browser for you to browse pages in GitHub.

“CLI” stands for “Command Line Interface”. That Terminal (or in Windows, Command Prompt) is one of them. If there’s a “CLI” appended next to an app name (“Git CLI” for this article), it means the app runs through terminal only. And “Git CLI” in this context is, well, the Git we know. Like the command we make commits or rebases with.

GUI stands for “Graphical User Interface” and it’s the interface we “navigate” on. Better said, a desktop environment in general is a GUI.

An “API key” is some kind of a secret string/file you use to authenticate to services. Beware that it bypasses 2 factor authentication and so on when you authenticate with it. So make sure to keep them safe and somewhere that’s out of reach by other means.

First of all, what is this tool? How does it handle operations we would do through Git CLI?

“gh” can be considered as an open source (Source Code) wrapper utilizing Git CLI itself and GitHub APIs to get things done. In fact, you can even pass parameters to the Git commands it uses! I’ll get into those later on.

Installing and setting up

Keep in mind that I’ll go through the installation using Termux. But the procedure should be pretty much the same as you could have on a Debian-based distro – Ubuntu has it on their official repos for example. For Windows, well, you need either CygWin or WSL I suppose. ¯\_(ツ)_/¯

# Let's install the tool first. Also installing Git as it's the backend
# for gh.
$ pkg install git gh -y

# Then before everything, we need to authenticate. This will save a
# new API key on the tool's database so you won't need to authenticate
# again. If you have already set GITHUB_TOKEN, this won't work so unset
# it first. :)
$ gh auth login

Now, before we continue here, I need to point out several things.

• Firstly, don’t choose “GitHub Enterprise Server” if you don’t have some kind of self-hosted GitHub.
• Secondly, use SSH instead of HTTPS if you have your public key added on your GitHub account. In case you lose the API key, you at least won’t lose your SSH key so it can be a good fallback method as well.
• Thirdly, choose logging in with browser only if you don’t have an API key on hand! Really, it wouldn’t make sense to have another key while you already have one.

Once you’re done setting things up, let’s tell Git CLI about it.

$ gh auth setup-git

This will make the necessary Git CLI configurations just in case your reflexes barge in and make you use Git instead of GH.

Some basic commands

Now that you’ve set up GH, let me teach you several basic commands in a story basis.

First of all, let’s say you want to create a pull request to my local manifests repo. You want to fork it first.

$ gh repo fork windowz414/platform_manifest
! windowz414/platform_manifest already exists
? Would you like to clone the fork? Yes
Cloning into 'platform_manifest'...
remote: Enumerating objects: 136, done.
remote: Counting objects: 100% (136/136), done.
remote: Compressing objects: 100% (81/81), done.
remote: Total 136 (delta 46), reused 89 (delta 12), pack-reused 0
Receiving objects: 100% (136/136), 30.70 KiB | 166.00 KiB/s, done.
Resolving deltas: 100% (46/46), done.
Updating upstream
From github.com:windowz414/platform_manifest
 * [new branch]      amyrom/rosie      -> upstream/amyrom/rosie
 * [new branch]      aosp-eleven       -> upstream/aosp-eleven
 * [new branch]      aosp-ten          -> upstream/aosp-ten
 * [new branch]      arrow-11.0        -> upstream/arrow-11.0
 * [new branch]      cm-14.1           -> upstream/cm-14.1
 * [new branch]      dot11             -> upstream/dot11
 * [new branch]      e/os/v1-nougat    -> upstream/e/os/v1-nougat
 * [new branch]      fluid-11          -> upstream/fluid-11
 * [new branch]      fox_7.1           -> upstream/fox_7.1
 * [new branch]      hentai-rika       -> upstream/hentai-rika
 * [new branch]      ion-pie           -> upstream/ion-pie
 * [new branch]      lineage-15.1      -> upstream/lineage-15.1
 * [new branch]      lineage-17.1      -> upstream/lineage-17.1
 * [new branch]      lineage-18.1      -> upstream/lineage-18.1
 * [new branch]      lineage-18.1_teos -> upstream/lineage-18.1_teos
 * [new branch]      lineage-19.0      -> upstream/lineage-19.0
 * [new branch]      main              -> upstream/main
 * [new branch]      mkn-mr1           -> upstream/mkn-mr1
 * [new branch]      revengeos-r11.0   -> upstream/revengeos-r11.0
 * [new branch]      stellar-S1        -> upstream/stellar-S1
 * [new branch]      teos-n            -> upstream/teos-n
 * [new branch]      weebprojekt-11    -> upstream/weebprojekt-11
✓ Cloned fork

Then let’s say you have a separate organization for your experiments called “wz414-labs”, that you didn’t fork on your personal profile yet and want to clone there then open pull request through there instead. You also want to clone the “cm-14.1” branch so you won’t need to do git-checkout to it again.

$ gh repo fork windowz414/platform_manifest --org="wz414-labs" -- --branch="cm-14.1"
✓ Created fork wz414-labs/platform_manifest
? Would you like to clone the fork? Yes
Cloning into 'platform_manifest'...
remote: Enumerating objects: 136, done.
remote: Counting objects: 100% (136/136), done.
remote: Compressing objects: 100% (81/81), done.
remote: Total 136 (delta 46), reused 89 (delta 12), pack-reused 0
Receiving objects: 100% (136/136), 30.70 KiB | 120.00 KiB/s, done.
Resolving deltas: 100% (46/46), done.
Updating upstream
From github.com:windowz414/platform_manifest
 * [new branch]      amyrom/rosie      -> upstream/amyrom/rosie
 * [new branch]      aosp-eleven       -> upstream/aosp-eleven
 * [new branch]      aosp-ten          -> upstream/aosp-ten
 * [new branch]      arrow-11.0        -> upstream/arrow-11.0
 * [new branch]      cm-14.1           -> upstream/cm-14.1
 * [new branch]      dot11             -> upstream/dot11
 * [new branch]      e/os/v1-nougat    -> upstream/e/os/v1-nougat
 * [new branch]      fluid-11          -> upstream/fluid-11
 * [new branch]      fox_7.1           -> upstream/fox_7.1
 * [new branch]      hentai-rika       -> upstream/hentai-rika
 * [new branch]      ion-pie           -> upstream/ion-pie
 * [new branch]      lineage-15.1      -> upstream/lineage-15.1
 * [new branch]      lineage-17.1      -> upstream/lineage-17.1
 * [new branch]      lineage-18.1      -> upstream/lineage-18.1
 * [new branch]      lineage-18.1_teos -> upstream/lineage-18.1_teos
 * [new branch]      lineage-19.0      -> upstream/lineage-19.0
 * [new branch]      main              -> upstream/main
 * [new branch]      mkn-mr1           -> upstream/mkn-mr1
 * [new branch]      revengeos-r11.0   -> upstream/revengeos-r11.0
 * [new branch]      stellar-S1        -> upstream/stellar-S1
 * [new branch]      teos-n            -> upstream/teos-n
 * [new branch]      weebprojekt-11    -> upstream/weebprojekt-11
✓ Cloned fork

You see I didn’t use “-b cm-14.1” and did the long argument instead. As of the date of this article, February 16, 2022, GH has a bug that it doesn’t pass short arguments to Git CLI correctly and so it needs to be done as long arguments instead.

Once that is done, you regularly entered the folder, did your changes, committed then pushed it, and are ready to do pull request. For this, all you need is a simple

$ gh pr create --branch="cm-14.1"

Creating pull request for wz414-labs:cm-14.1 into cm-14.1 in windowz414/platform_manifest

? Title teos: Change to Git-Polycule
? Body <Received>
? What's next? Submit
https://github.com/windowz414/platform_manifest/pull/1

If you don’t append “–branch=cm-14.1”, you would be creating PR towards “main” branch, which of course will cause issues when it’s not handled right.

And now, I need to merge this PR, right? So I first clone the repo, checkout to the branch assigned, and list PRs first.

# Cloning first.

$ git clone https://github.com/windowz414/platform_manifest
Cloning into 'platform_manifest'...
remote: Enumerating objects: 136, done.
remote: Counting objects: 100% (136/136), done.
remote: Compressing objects: 100% (81/81), done.
remote: Total 136 (delta 46), reused 89 (delta 12), pack-reused 0
Receiving objects: 100% (136/136), 30.70 KiB | 137.00 KiB/s, done.
Resolving deltas: 100% (46/46), done.

# Then checking out to the branch.

$ git checkout cm-14.1
branch 'cm-14.1' set up to track 'origin/cm-14.1'.
Switched to a new branch 'cm-14.1'

# And now listing PRs.

$ gh pr list

Showing 1 of 1 open pull request in windowz414/platform_manifest

#1  teos: Change to Git-Polycule  wz414-labs:cm-14.1

Now that we see there’s a PR to change remote to “Git-Polycule”, let’s see what has changed with it.

$ gh pr diff 1
diff --git a/teos.xml b/teos.xml
index b145fc0..3aadeb6 100644
--- a/teos.xml
+++ b/teos.xml
@@ -2,7 +2,7 @@
 <manifest>

   <remote  name="windowz414"
-           fetch="https://github.com/windowz414/"
+           fetch="https://git.polycule.co/windowz414/"
            revision="cm-14.1" />

   <!-- DEVICE TREES

Seems promising! Time to merge!

$ gh pr merge 1
? What merge method would you like to use? Rebase and merge
? What's next? Submit
✓ Rebased and merged pull request #1 (teos: Change to Git-Polycule)

Now that I merged it, you can delete your fork.

$ gh repo delete --confirm wz414-labs/platform_manifest
✓ Deleted repository wz414-labs/platform_manifest

You see that straight up deleted the repo with no confirmation request because I passed the “–confirm” parameter there. If you wouldn’t pass it, you would get this:

$ gh repo delete windowz414/systemd
? Type windowz414/systemd to confirm deletion:

And you would need to type the whole repo name. Time waste…

Summary

Simply put, `gh` is a pretty simplified Git CLI/Curl wrapper unifying simple Git operations and GitHub API things under the same roof. How do you utilize it? Does it look promising to you like it does to me? Looking forward to hear from you!