repo, made by Google. The primary function of repo is to read a manifest file located in Bliss OS's GitHub organization, and find what repositories you need to actually build Android.~/bin directory for repo:-p flag instructs mkdir to only create the directory if it does not exist in the first place. Now download the repo tool into ~/bin:repo executable:source the file:source?source is a bash command to read aliases, functions, and commands from the specified file. Typically, you'll supply bash with a configuration file such as .bashrc or .bash_profile, or an initialization file such as envsetup.sh. The difference is that while the configuration file lists configuration and user-defined aliases and functions, initialization files typically hold build commands such as breakfast, brunch, and lunch. Without those commands building would be significantly harder as you would have to memorize the long command to invoke a build manually!bash cannot automatically detect changes in our files. To solve this, we either source it or log out and log back in, forcing bash to reload configuration files. Keep this in mind, because unlike configuration files, if you forget to source initialization files, build commands will not function!repo globally?repo tool to be available anywhere, you will need to first download repo to your home directory, move it with sudo and give it executable permissions. The exact commands are as follows:repo will now work anywhere, without any .bashrc modifications. However, these steps aren’t recommended as repo might become a security risk if a vulnerability is found.repo and git who we are. Run the following commands, substituting your information:repo which manifest to read:-b is for the branch, and we’re on p9.0-x86, Android Pie. It’ll take a couple of seconds. You may need to type y for the color prompt.-j is for threads. Typically, your CPU core count is your thread count, unless you’re using an older Intel CPU with hyperthreading. In that case, the thread count is double the count of your CPU cores. Newer CPUs have dropped hyperthreading unless you have the i9, so check how many threads you have. If you have four threads, you would run:-c is for pulling in only the current branch, instead of the entire history. This is useful if you need the downloads fast and don’t want the entire history to be downloaded. This is used by default unless specified otherwise.repo will start downloading all the code. That’s going to be slow, even on a fiber network. Expect downloads to take more than a couple hours.nproc.$ bash build-x86.sh options buildVariants blissBranch extraOptions Options:already applied or conflict. This is normal behavior and will not effect the build process if you continue to the next step without addressing any of the conflicts.vendor/x86.source this file every time you log out and log back in, or launch a new bash/Terminal instance.bullhead. You can check your specific device's codename on GitHub or on Google. Execute:lunch initializes the proper environmental variables required for the build tools to build your specific device. Things like BLISS_DEVICE and other variables are set in this stage, and the changed variables will be shown as output. x86 or x86_64 is the specific device we are building. Finally, userdebug means that we will build a user-debuggable variant. This is usually what most ROMs use for publishing their builds. Manufacturers typically use user which disables most of the useful Android Logcats.userdebug won't print any adb logcats. What gives?eng, short for engineering builds. These builds will activate adb logcat during boot, and will show you exactly what is going wrong, where, and why. However, these builds are NOT recommended for normal usage as they are not securely hardened, have log spam that will slow down your device, and other unexpected problems like userspace utilities crashing during runtime. If you want to submit your device for mainline, do NOT submit an eng build!mka iso_imgmka and not make?make only runs with 1 thread. mka is properly aliased to use all of your threads by checking nproc.make -j#, replacing the hash with the number of threads (example of make -j4).make, or it succeeds and you see the Bliss logo in ASCII. If you encounter the former, you need to go back and fix whatever it's complaining about. Typically, 90% of the time the problem will be in your device tree. For the other 10%, submit a bug report to the ROM developers. Be sure to include the full log of your build to help diagnose the problem, and your device tree..iso that goes along the lines of Bliss-v11.9--OFFICIAL-20190801-1619_x86_64_k-k4.9.153_m-18.3.5-pie-x86-llvm80_f-dev-kernel.org.iso.BR-x86 repok4.19.50-ax86-ga branch, which has added commits from the GalliumOS project for Chromebookscd back to our main project folder.iso with the target kernel we selectedvendor/x86/utils..patch files from your additions, and add them to the mix. In the following example, we are going to generate patches from packages/apps/Settings and add them to the proper folder for live testing..patch files. For this example, we've added four commits on top of what was there after syncvendor/x86. In this case, you will find it here:make clean and run the patch system from your main project folder.repo sync to make your repository up to date. Sometimes, the Internet connection between you and GitHub can be flaky. In rare cases a commit merge might be ongoing, and you might've grabbed an incomplete merge. Mostly, this should fix the issue 70% of the time.shared/linked library not found or something along those lines.build/envsetup.sh. This is especially common and worth suspecting if none of the build commands like breakfast and lunch work. If you have repo synced do this again.croot.