repo, made by Google. The primary function of
repois to read a manifest file located in Bliss OS's GitHub organization, and find what repositories you need to actually build Android.
mkdirto only create the directory if it does not exist in the first place. Now download the
bashcommand to read aliases, functions, and commands from the specified file. Typically, you'll supply
bashwith a configuration file such as
.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
lunch. Without those commands building would be significantly harder as you would have to memorize the long command to invoke a build manually!
bashcannot automatically detect changes in our files. To solve this, we either
sourceit or log out and log back in, forcing
bashto reload configuration files. Keep this in mind, because unlike configuration files, if you forget to
sourceinitialization files, build commands will not function!
repotool to be available anywhere, you will need to first download
repoto your home directory, move it with
sudoand give it executable permissions. The exact commands are as follows:
repowill now work anywhere, without any
.bashrcmodifications. However, these steps aren’t recommended as
repomight become a security risk if a vulnerability is found.
gitwho we are. Run the following commands, substituting your information:
repowhich manifest to read:
-bis for the branch, and we’re on
p9.0-x86, Android Pie. It’ll take a couple of seconds. You may need to type
yfor the color prompt.
-jis 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:
-cis 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.
repowill 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.
$ bash build-x86.sh options buildVariants blissBranch extraOptionsOptions:
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.
sourcethis file every time you log out and log back in, or launch a new
bullhead. You can check your specific device's codename on GitHub or on Google. Execute:
lunchinitializes the proper environmental variables required for the build tools to build your specific device. Things like
BLISS_DEVICEand other variables are set in this stage, and the changed variables will be shown as output.
x86_64is the specific device we are building. Finally,
userdebugmeans that we will build a user-debuggable variant. This is usually what most ROMs use for publishing their builds. Manufacturers typically use
userwhich disables most of the useful Android Logcats.
userdebugwon't print any
adb logcats. What gives?
eng, short for engineering builds. These builds will activate
adb logcatduring 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
makeonly runs with 1 thread.
mkais properly aliased to use all of your threads by checking
make -j#, replacing the hash with the number of threads (example of
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.
.isothat goes along the lines of
k4.19.50-ax86-gabranch, which has added commits from the GalliumOS project for Chromebooks
cdback to our main project folder
.isowith the target kernel we selected
.patchfiles from your additions, and add them to the mix. In the following example, we are going to generate patches from
packages/apps/Settingsand add them to the proper folder for live testing.
.patchfiles. For this example, we've added four commits on top of what was there after sync
vendor/x86. In this case, you will find it here:
make cleanand run the patch system from your main project folder.
repo syncto 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 foundor something along those lines.
build/envsetup.sh. This is especially common and worth suspecting if none of the build commands like
lunchwork. If you have
repo synced do this again.