Building Android in Artix ‐ take 1

This guide is mainly written by Mick Faustin; with me testing the ensuing build and helping with documenting stuff.

Last updated : 17/4/2026 (cancel building crDroid‐revived)

Introduction

Personally, I kind of wanted to be an Android developer, but the entrance seems to be rather challenging. So I settled by building an existing custom ROM and having someone else in the vicinity to test it. Fortunately, Garry just so happened to get his OP5T assembled (minus the missing IMEI but we won't need it) so I can also use him as my guinea pig for my builds... after I convinced him to volunteer his OP5T for the task, which is easier said than done (and please don't get me started on his G710EAW, that thing is his daily).

Prerequisites

• Any Android device with unlocked bootloader, which you will flash the build into.
• The best computer you got.
• >16GB RAM with ≥32GB swap.
For the record, Google builds on 64GB RAM & 72‐core machines (all of which are WAY out of our reach). We could probably rent out a build server, but as our end goal is to build & develop on our own this approach is not viable.


• At least 512GB SSD, though I got 1TB (2.5' SATA) to account for stuff like ccache & SWAP. More may be required if we were to build for more devices.
• Definitely some gaming‐grade processors (with as much physical CPU cores as viably possible)... and now I get my greatest hurdle as I am stuck with a shitty A475 and its A12‐9800 APU (with my main laptop having only 1 M.2 NVME slot & no internal 2.5' bay). Android officially requires a 64‐bit x86 system which I think our systems are.
Just so you know; B0ss daily drove A475 as well, so I'll send your regards to him. ‐ Garry


• This guide assumes you're running Artix Linux, with Artix lib32 and Arch extra & multilib enabled.
Mostly because nowadays the only Linux distro I'm familiar with is Artix. This could've translated to Arch but I won't bother with systemd's madness. ‐ Garry


• The greatest internet access your computer can access (mostly to make faster repo sync downloads, but also STFW in case shit fucks up). And no, I'm not talking about the ethernet, but the entire network stack.
• Unlimited spare time, especially when you're compiling on potatoes instead of supercomputers and/or gaming rigs. Not to mention the time required to research & fix build issues & stuff...
• Reliable electricity especially on whatever computer is compiling.
• Familiarity with Linux terminal commands, including the stuff commonly used in Arch & Artix Linux.
• Familiarity with basic Android operation & terminology in case it needs to be searched up.

Dependencies

pacman stuff

# pacman ‐S repo bc ccache git‐lfs gitg gperf gradle jdk11‐openjdk lib32‐zlib lib32‐ncurses lib32‐readline libxcrypt‐compat lzop maven ninja noto‐fonts perl‐switch pngcrush schedtool sdl squashfs‐tools rsync ttf‐dejavu vim

• Any Java stuff installations (gradle, jdk11, maven) will also install openjdk as dependency. We went with jdk11‐openjdk, which provides Java runtime and JDK 25.
• The packages are scraped from aosp‐devel & lineageos‐devel AUR metapackages, though installing those 2 are actually optional.
• ccache is mainly used to speed up subsequent builds and is normally considered optional.
• gitg (or any user interface for Git) : Optional, but if you're familiar with Git commit (and/or intend to develop) it will be quite useful.

AUR stuff (Android Studio(?),ncurses5‐compat‐libs, lib32‐ncurses5‐compat‐libs, xml2)

AUR helpers (like yay) can be used in lieu of this guide, but it is not covered here (mostly because we had zero experience with them).

• Required PGP keys for ncurses5‐compat packages :
• $ gpg recv‐keys 2167BE03


• Android Studio (optional?) :
• $ git clone https://aur.archlinux.org/android‐studio.git ~/AUR/androidstudio
• $ cd ~/AUR/androidstudio
• Read PKGBUILD (optional)
• $ makepkg ‐sirc


• ncurses5‐compat‐libs :
• $ git clone https://aur.archlinux.org/ncurses5‐compat‐libs.git ~/AUR/ncurses5
• $ cd ~/AUR/ncurses5
• Read PKGBUILD (optional)
• $ makepkg ‐sirc


• lib32‐ncurses5‐compat‐libs :
• $ git clone https://aur.archlinux.org/ncurses5‐compat‐libs.git ~/AUR/ncurses5
• $ cd ~/AUR/ncurses5
• Read PKGBUILD (optional)
• $ makepkg ‐sirc


• xml2 :
$ git clone https://aur.archlinux.org/xml2.git ~/AUR/xml2
• $ cd ~/AUR/xml2
• Read PKGBUILD (optional)
• $ makepkg ‐sirc

Other preparations

• Git setup (identity & lfs)
• $ git config ‐‐global user.email "email@example.com"
• $ git config ‐‐global user.name "Your Name"
• $ git config ‐‐global trailer.changeid.key "Change‐Id" (optional, may be necessary if developing custom ROM)
• $ git lfs install


• ccache
• $ export USE_CCACHE=1
• $ export CCACHE_EXEC=/usr/bin/ccache
• nano ~/.bashrc (enter the 2 listed entries into bashrc)
• $ ccache ‐M 100G (at least 25G)


• mke2fs
• # nano /etc/mke2fs.conf
• remove metadata_csum_seed & orphan_file if those entries exist. The issue seems to be orphan_file.
• Reboot after editing mke2fs.conf?


• Entering build environment
• $ mkdir ~/android/$rom
• $ cd ~/android/$rom

Building the ROM

If you're not in build environment, please cd there. All operations in this part happens there.

Repo initializations

Repo init targets

• LineageOS 18.1 : $ repo init ‐u https://github.com/LineageOS/android.git ‐b 18.1 ‐‐git‐lfs ‐‐no‐clone‐bundle

Source code downloads

• $ repo sync ‐c
‐j 4 by default (4 simultaneous connections/threads); ‐c by default to pull only the current branch (but explicitly entered)

• First repo syncs also downloads the source codes so it takes a while (≥60 minutes), especially on potato internets (I think I remember letting it go for 6 hours?). Do something else in the mean time.
After the first long repo sync...


• $ source build/envsetup.sh
• Test out croot
• $ cd ~/android/$rom/$dir (cd to any directory within repository)
• $ croot
You should be back in ~/android/$rom.

Manifest initialization

We give a shout‐out to MSe1969 for solving our manifest headaches. In a previous attempt (my 1st repo sync), we just copied over the 5T entries into a roomservice.xml in local_manifests & did $ breakfast dumpling, only to fuck up the entire local repo with /vendor aimed at root. Lesson learned ‐ NEVER breakfast when compiling from someone else's tree, and repo sync after making the manifests.

• local_manifests
• $ cd ~/android/$rom/.repo
• $ mkdir ~/android/$rom/.repo/local_manifests


• OnePlus 5(T) (cheeseburger/dumpling by SirRGB)
• $ cd ~/android/$rom/.repo/local_manifests
• $ curl https://raw.githubusercontent.com/SirRGB/local_manifests/refs/heads/main/cheeseburgerdumpling/A11Crdroid2.xml > cheesedumpling.xml (if you initially did not have the manifest available; though if you do you can just copy the manifest file to local_manifests)


• repo sync and have it prepare our device codes (instead of breakfast)
• $ croot
• $ repo sync ‐‐no‐tags

Compiling

Prerequisites I found out after booting (or rebooting), if I shut down the computer and/or rebooted :

• cd ~/android/$rom
• $ source build/envsetup.sh
• Test out croot
• $ cd ~/android/$rom/$dir (cd to any directory within repository)
• $ croot
You should be back in ~/android/$rom.



• $ make clean (after failed compilation)

ROM compiling

• OnePlus 5(T) (cheeseburger/dumpling by SirRGB)
• $ brunch dumpling
logged stuff on builds

Conclusion

Welp, that is about it. After bashing our heads over the hidden elitism LineageOS developers had against self‐builders (by not documenting important upstream issues & leaving them as mere comments up Reddit threads) we finally got a ROM running. Granted, we went with Lineage instead of crDroid‐revived thanks to a certain issue, but there's that.

That said, we don't have any other bad feelings (aside from the above & neverending push towards latest Android) against LineageOS and its developers. In fact, we are grateful to them, because if it weren't for them we won't be having any ROMs to flash in the first place.

To‐do list (Garry's addendum)

Though let's be honest, this is still a long way to go since neither of us are developers (let alone capable of developing Android) in the first place.

• Delete all forms of Pixel spoofing and preferably make it a Git commit so repo sync doesn't undo the deletion.
That is, if we're basing off crDroid. We'll skip this as we're on Lineage now. ‐ Mick


• Maybe replace microG with GmsCompat, but this will require testing with GApps. This may eventually clash with preventing OS‐based age verification.
And with vanilla LineageOS we're halfway there, we just need to borrow MSe1969's scripts. ‐ Mick


• Keep age verification things out. Though this may also permanently deny support for GApps and contradict our plans for GmsCompat.
• Implement properly deniable network permission (like GrapheneOS), optimize them to limit and/or eliminate ensuing app crashes from denying network permission, then delete per‐app data restriction to remove redundancies.
• Speaking of permissions, integrate sensors permission (again, like GrapheneOS).
• Change default connections in a way it can still be changed with settings command. And make those options available in GUI (like how one would manually change Private DNS).
• Move animation scale settings from Developer options to Display so we don't need to keep Developer options enabled unnecessarily. And maybe implement the slider version (which was used by crDroid & various others) instead of the fixed speeds.
• Replace most LineageOS apps with better established ones. And maybe actually begin developing a superior music app based off Simple Music 5.17.1 because every other music app sucked (and sticking to AIMP 3.10.1052 isn't sustainable in the long term especially if the APK is lost.).
• Speaking of music, we intend to completely wipe the volume limiter. That way, the user will have full control over how loud their audio gets and must take full responsibility for their own hearing.
• Rebranding.
• Publish our repo in some public Git repo. Not fucking GitHub though, I don't want microslop fucking our shit up any more than it already had.
That said, Codeberg won't do either considering its recent reliability issues & longstanding cuckflare support.


• Find reliable mirrors to upload the builds (and/or mirror stuff) into.
• Build some sort of public support channel if we're making this a thing and find ways to prevent said channels from burning us out.
We considered xdaforums, but the cuckflare (hcaptcha) is an issue. And we cannot consider Discord, Signal, and/or Telegram for their inaccessibility (which is an even bigger issue than the privacy issues they had).


• Get device(s) for development. Arguably the hardest part considering the required efforts & research.

...yeah. This is a very long list. And it looked short.

Known issues

• Invalid filesystem option set: has_journal,extent,huge_file,flex_bg,metadata_csum_seed,64bit,dir_nlink,extra_isize,orphan_file
This issue singlehandedly caused most of our failed compilations (on 24GB RAM & 39GB SWAP), with the workaround documented above. orphan_file seemed to be the issue (archive.org).

• (crDroid‐Revived) API level 1000
Does not show on the search engines. And our lack of knowledge in debugging this weird issue (and the lack of results in STFW) caused us to fuck off crDroid.

Main Page