diff --git a/Bliss OS/troubleshooting/index.html b/Bliss OS/troubleshooting/index.html
index 26228ff..aad53df 100644
--- a/Bliss OS/troubleshooting/index.html
+++ b/Bliss OS/troubleshooting/index.html
@@ -529,13 +529,13 @@
                 <h1 id="troubleshooting">Troubleshooting</h1>
 <h2 id="32-bit-processors-only-intel-atom-and-similar">32-bit processors only (Intel Atom and similar)</h2>
 <ol>
-<li>Install Android-x86 32-bit OS from https://www.android-x86.org/ (doesn't matter which version, as long as it's 32-bit)</li>
+<li>Install <a href="https://www.android-x86.org/">Android-x86 32-bit OS from here</a> (doesn't matter which version, as long as it's 32-bit)</li>
 <li>Update with Bliss OS 32-bit (current version is 11.9). After reboot you should be able to access the <code>grub</code> menu.</li>
 <li>In <code>grub</code> menu select "Debug mode"</li>
 <li>Run the following commands:
     <pre><code>mount -o remount, rw /mnt
 cd /mnt/grub
-vi menu.lst</code></pre></li>
+nano menu.lst</code></pre></li>
 <li>Add <code>nomodeset</code> before every "SCR=**" line. For example, your configuration should look something like this:
     <pre><code>nomodeset
 SCR=700
diff --git a/search/search_index.json b/search/search_index.json
index 5bf81eb..85bb962 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"Index Welcome to the documentation, written by developers of Team Bliss! Bliss OS (x86) Don't know how to install? We've got you covered. Install didn't go as smoothly as you expected? Troubleshoot why. Want Netflix? Want Gapps? You need the extras. Ready to build? Start here with our build Guide. BlissRoms (arm/arm64) First time building? Let's get started. Need some tips? Optimize your builds! Common Documentation Before anything else, learn how to maintain proper authorship. Start with this essential guide, which teaches you about the fundamentals of ROM building. Getting tired of reviewing commits? Try mass reviewing commits. Check back later for more content! We're always updating the documentation with more helpful tips and information!","title":"Home"},{"location":"#index","text":"Welcome to the documentation, written by developers of Team Bliss!","title":"Index"},{"location":"#bliss-os-x86","text":"Don't know how to install? We've got you covered. Install didn't go as smoothly as you expected? Troubleshoot why. Want Netflix? Want Gapps? You need the extras. Ready to build? Start here with our build Guide.","title":"Bliss OS (x86)"},{"location":"#blissroms-armarm64","text":"First time building? Let's get started. Need some tips? Optimize your builds!","title":"BlissRoms (arm/arm64)"},{"location":"#common-documentation","text":"Before anything else, learn how to maintain proper authorship. Start with this essential guide, which teaches you about the fundamentals of ROM building. Getting tired of reviewing commits? Try mass reviewing commits. Check back later for more content! We're always updating the documentation with more helpful tips and information!","title":"Common Documentation"},{"location":"Bliss OS/","text":"Index New? Start here with the Installation Guide. Troubleshooting your new install? Check out the Troubleshooting section. Want some extra tips? Look no further! Ready to build? Start here with our build Guide.","title":"Index"},{"location":"Bliss OS/#index","text":"New? Start here with the Installation Guide. Troubleshooting your new install? Check out the Troubleshooting section. Want some extra tips? Look no further! Ready to build? Start here with our build Guide.","title":"Index"},{"location":"Bliss OS/build-guide/","text":"Build Guide Introduction This is the official guide to build Bliss OS for PCs. In this guide, we will only cover building for x86 & x86_64 devices. We will also go over the details of using the patch system for testing and recompiling a build with a different kernel branch. The golden rule to building is patience. If something breaks, pay attention to the console output or take logs of the issue and ask for guidance in our build support chat. Let\u2019s get started. Preparation To get started, you need a computer with Ubuntu 18.04 (LTS), at least 200GB space of HDD, and at least 8GB RAM. A decent CPU (or CPUs if you have a server motherboard) is recommended. Other distros can work but is not officially supported in this guide. Underpowered machines may crash during compilation. If that happens, you may try and restart the build as most crashes are caused by lack of memory. If your storage space has run out, then you will need to build on a different hard drive. Install the JDK Install OpenJDK: sudo apt install openjdk-8-jdk Install build tools To install the required build tools, run the following command: sudo apt-get install git-core gnupg flex bison maven gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip squashfs-tools python-mako libssl-dev ninja-build lunzip syslinux syslinux-utils gettext genisoimage gettext bc xorriso libncurses5 Install source code tools Now we need to get the source code via a program named 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. Create a ~/bin directory for repo : mkdir -p ~/bin The -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 : curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo Make repo executable: chmod a+x ~/bin/repo And add it to PATH: nano .bashrc Scroll to the end of the file and type these lines: # Export ~/bin export PATH=~/bin:$PATH Ctrl-O and enter to save, then Ctrl-X to exit nano. Now either logout and login again (or reboot), or source the file: source .bashrc Which can be shortened to: . .bashrc What is 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! But why do you need to run it after modifying a file? Well, 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! What if I need repo globally? If you need the 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: curl https://storage.googleapis.com/git-repo-downloads/repo > ~/repo sudo mv ~/repo /usr/bin/ chmod a+x /usr/bin/repo repo will now work anywhere, without any .bashrc modifications. However, these steps aren\u2019t recommended as repo might become a security risk if a vulnerability is found. Now we\u2019re ready to download the source code. Download Create a directory for the source: mkdir -p ~/blissos/p9.0 cd ~/blissos/p9.0 Before we download, we need to tell repo and git who we are. Run the following commands, substituting your information: git config --global user.email \u201crandy.mcrandyface@hotmail.net\u201d git config --global user.name \u201cRandy McRandyface\u201d Now, we\u2019re ready to initialize. We need to tell repo which manifest to read: repo init -u https://github.com/BlissRoms-x86/manifest.git -b p9.0-x86 -b is for the branch, and we\u2019re on p9.0-x86 , Android Pie. It\u2019ll take a couple of seconds. You may need to type y for the color prompt. Sync repo : repo sync -j24 -c --no-tags --no-clone-bundle Problems syncing? : repo sync -j4 -c --no-tags --no-clone-bundle --force-sync -j is for threads. Typically, your CPU core count is your thread count, unless you\u2019re 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: repo sync -j4 -c -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\u2019t want the entire history to be downloaded. This is used by default unless specified otherwise. I still don't know how much CPU threads I have. How do I check? Run nproc . The output should be something like this: mybuildbox@test:~$ nproc 24 This means that there are 24 threads in your machine. repo will start downloading all the code. That\u2019s going to be slow, even on a fiber network. Expect downloads to take more than a couple hours. Easy Build Instructions This will build an x86 based .ISO for PCs. Usage: $ bash build-x86.sh options buildVariants blissBranch extraOptions Options: -c | --clean : Does make clean && make clobber and resets the efi device tree -s | --sync: Repo syncs the rom (clears out patches), then reapplies patches to needed repos -p | --patch: Just applies patches to needed repos -r | --proprietary: build needed items from proprietary vendor (non-public) BuildVariants: android_x86-user : Make user build android_x86-userdebug |: Make userdebug build android_x86-eng : Make eng build android_x86_64-user : Make user build android_x86_64-userdebug |: Make userdebug build android_x86_64-eng : Make eng build BlissBranch: select which bliss branch to sync, default is p9.0 ExtraOptions: foss : packages microG & FDroid with the build go : packages Gapps Go with the build gapps : packages OpenGapps with the build gms : packages GMS with the build (requires private repo access) none : force all extraOption flags to false. To start, you must first use the -s (--sync) flag, then on following builds, it is not needed. Initial generation of the proprietary files from ChromeOS are also needed on the first build. We are able to use the -r (--proprietary) flag for that. This step needs to be on its own because the mounting process requires root permissions, so keep a look out for it asking for your root password . First you must sync with the new manifest changes: bash build-x86.sh -p This will do initial patching. Some of the patches will show as 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. The only times you should worry about the conflicts is when you are adding or changing patches in vendor/x86 . Next step is to download the proprietary files from ChromeOS: mkdir vendor/bliss_priv/proprietary mkdir vendor/bliss_priv/source bash build-x86.sh -r android_x86_64-userdebug After that, you can build your release file: bash build-x86.sh android_x86_64-userdebug (to build the userdebug version for x86_64 CPUs) Advanced Build Instructions Set up the build environment: . build/envsetup.sh This is the initialization file we talked about earlier up top. This \"initializes\" the environment, and imports a bunch of useful build commands required to build your device. Again, you need to remember to source this file every time you log out and log back in, or launch a new bash /Terminal instance. Define what device you\u2019re going to build. For example, the Nexus 5X, has a codename of bullhead . You can check your specific device's codename on GitHub or on Google. Execute: For 32 bit devices: lunch android_x86-userdebug For 64 bit devices: lunch android_x86_64-userdebug Let's break down the command. 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. My device isn't booting, and userdebug won't print any adb logcat s. What gives? There is a third build variant called 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! If this is the first time you're running the build, you're going to want to run the proprietary build command first from the easy build instructions. Alternatively, you could also run those commands manually. mkdir vendor/bliss_priv/proprietary && mkdir vendor/bliss_priv/source Then: lunch android_x86_64-userdebug mka update_engine_applier mka proprietary After that is complete, we can start the main building process. Run: mka iso_img And the build should start. The build process will take a long time. Prepare to wait a few hours, even on a decent machine. Why mka and not make ? make only runs with 1 thread. mka is properly aliased to use all of your threads by checking nproc . If you want to customize your thread count (maybe you're building with a fan-screaming laptop in a quiet coffee shop), use make -j# , replacing the hash with the number of threads (example of make -j4 ). After building There are two outcomes to a build - either it fails and you get a red error message from 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. If you face the latter, congratulations! You've successfully built BlissRoms for your device. Grab the artifacts for your device: cd out/target/product/x86_64/ In here, you\u2019ll find an .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 . Changing the target kernel branch Sometimes, you might be working on a device that requires a different kernel branch. In order to switch kernels effectively on Bliss OS, they need to be compiled with the OS at build time. Switching the kernel branch Start off by entering the kernel folder cd kernel Then pull all the available kernel branched from your target repo. In this case, we are using the default BR-x86 repo git fetch BR-x86 Then after that is finished, we need to checkout our target branch, and in this example we are choosing our k4.19.50-ax86-ga branch, which has added commits from the GalliumOS project for Chromebooks git checkout BR-x86/k4.19.50-ax86-ga Next step is to clean out any configs or generated files from the previously checked out kernel. To do this, run these commands make clean make mrproper Once that is done, we can cd back to our main project folder cd .. And run our build command again to generate the .iso with the target kernel we selected rm -rf out/target/product/x86_64/kernel mka iso_img Using the patch system for testing We use a patching method we adapted for Bliss from Intel's Project Celadon & phh-treble. This patching system allows us to bring in a good number of commits to add to the OS, and test how they apply or if there are any conflicts. Our intention was to make a system that can add all the needed x86/x86_64 commits to BlissROM, as well as other ROMs too. The majority of this system is found in vendor/x86/utils . From here, you simply generate the .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. From your Project folder: cd packages/apps/Settings And generate your .patch files. For this example, we've added four commits on top of what was there after sync git format-patch -4 Then copy those files to the proper folder in vendor/x86 . In this case, you will find it here: vendor/x86/utils/android_p/google_diff/x86 After that is complete, you can make clean and run the patch system from your main project folder. make clean bash build-x86.sh -p This should start patching all the source files. Once that is complete, you can rebuild. Troubleshooting If your build failed, there are a couple things you can try. Try a fresh 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. Make sure your dependencies are installed correctly. Error messages help out a lot here! Often it will say shared/linked library not found or something along those lines. Make sure you sourced 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 sync ed do this again. Make sure you\u2019re at the root of the build tree. Again, to quickly jump there, use croot . Make sure your computer itself isn\u2019t faulty. HDDs usually die first, followed by RAM. SSDs rarely die but failure is not unheard of. In extremely rare cases, your CPU may have a defect. If you're unsure, run a stress test using a program like Prime95. If something goes wrong and you've tried everything above, first use Google to look up your error! Most of the errors you encounter is due to misconfiguration and wrong commands entered. More often than not, Google will have the answer you are looking for. If you're still stuck and nothing fixes the problem, then ask us via our Telegram Build Support chat. Conclusion Building a ROM is very hard and tedious and the results are very rewarding! If you managed to follow along, congratulations! After you finish building, you can try out the Git Started guide. Make changes, commit, and send them off to our GitHub for Bliss OS repos & our Gerrit for review on BlissROMs repos! Or better yet, download experimental commits not ready for the mainline repositories and review them! Again, ROM building is a fun project you can work with. I hope this guide was a lot of fun to run through!","title":"Build Guide"},{"location":"Bliss OS/build-guide/#build-guide","text":"","title":"Build Guide"},{"location":"Bliss OS/build-guide/#introduction","text":"This is the official guide to build Bliss OS for PCs. In this guide, we will only cover building for x86 & x86_64 devices. We will also go over the details of using the patch system for testing and recompiling a build with a different kernel branch. The golden rule to building is patience. If something breaks, pay attention to the console output or take logs of the issue and ask for guidance in our build support chat. Let\u2019s get started.","title":"Introduction"},{"location":"Bliss OS/build-guide/#preparation","text":"To get started, you need a computer with Ubuntu 18.04 (LTS), at least 200GB space of HDD, and at least 8GB RAM. A decent CPU (or CPUs if you have a server motherboard) is recommended. Other distros can work but is not officially supported in this guide. Underpowered machines may crash during compilation. If that happens, you may try and restart the build as most crashes are caused by lack of memory. If your storage space has run out, then you will need to build on a different hard drive.","title":"Preparation"},{"location":"Bliss OS/build-guide/#install-the-jdk","text":"Install OpenJDK: sudo apt install openjdk-8-jdk","title":"Install the JDK"},{"location":"Bliss OS/build-guide/#install-build-tools","text":"To install the required build tools, run the following command: sudo apt-get install git-core gnupg flex bison maven gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip squashfs-tools python-mako libssl-dev ninja-build lunzip syslinux syslinux-utils gettext genisoimage gettext bc xorriso libncurses5","title":"Install build tools"},{"location":"Bliss OS/build-guide/#install-source-code-tools","text":"Now we need to get the source code via a program named 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. Create a ~/bin directory for repo : mkdir -p ~/bin The -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 : curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo Make repo executable: chmod a+x ~/bin/repo And add it to PATH: nano .bashrc Scroll to the end of the file and type these lines: # Export ~/bin export PATH=~/bin:$PATH Ctrl-O and enter to save, then Ctrl-X to exit nano. Now either logout and login again (or reboot), or source the file: source .bashrc Which can be shortened to: . .bashrc","title":"Install source code tools"},{"location":"Bliss OS/build-guide/#what-is-source","text":"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! But why do you need to run it after modifying a file? Well, 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!","title":"What is source?"},{"location":"Bliss OS/build-guide/#what-if-i-need-repo-globally","text":"If you need the 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: curl https://storage.googleapis.com/git-repo-downloads/repo > ~/repo sudo mv ~/repo /usr/bin/ chmod a+x /usr/bin/repo repo will now work anywhere, without any .bashrc modifications. However, these steps aren\u2019t recommended as repo might become a security risk if a vulnerability is found. Now we\u2019re ready to download the source code.","title":"What if I need repo globally?"},{"location":"Bliss OS/build-guide/#download","text":"Create a directory for the source: mkdir -p ~/blissos/p9.0 cd ~/blissos/p9.0 Before we download, we need to tell repo and git who we are. Run the following commands, substituting your information: git config --global user.email \u201crandy.mcrandyface@hotmail.net\u201d git config --global user.name \u201cRandy McRandyface\u201d Now, we\u2019re ready to initialize. We need to tell repo which manifest to read: repo init -u https://github.com/BlissRoms-x86/manifest.git -b p9.0-x86 -b is for the branch, and we\u2019re on p9.0-x86 , Android Pie. It\u2019ll take a couple of seconds. You may need to type y for the color prompt. Sync repo : repo sync -j24 -c --no-tags --no-clone-bundle Problems syncing? : repo sync -j4 -c --no-tags --no-clone-bundle --force-sync -j is for threads. Typically, your CPU core count is your thread count, unless you\u2019re 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: repo sync -j4 -c -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\u2019t want the entire history to be downloaded. This is used by default unless specified otherwise.","title":"Download"},{"location":"Bliss OS/build-guide/#i-still-dont-know-how-much-cpu-threads-i-have-how-do-i-check","text":"Run nproc . The output should be something like this: mybuildbox@test:~$ nproc 24 This means that there are 24 threads in your machine. repo will start downloading all the code. That\u2019s going to be slow, even on a fiber network. Expect downloads to take more than a couple hours.","title":"I still don't know how much CPU threads I have. How do I check?"},{"location":"Bliss OS/build-guide/#easy-build-instructions","text":"This will build an x86 based .ISO for PCs. Usage: $ bash build-x86.sh options buildVariants blissBranch extraOptions Options: -c | --clean : Does make clean && make clobber and resets the efi device tree -s | --sync: Repo syncs the rom (clears out patches), then reapplies patches to needed repos -p | --patch: Just applies patches to needed repos -r | --proprietary: build needed items from proprietary vendor (non-public) BuildVariants: android_x86-user : Make user build android_x86-userdebug |: Make userdebug build android_x86-eng : Make eng build android_x86_64-user : Make user build android_x86_64-userdebug |: Make userdebug build android_x86_64-eng : Make eng build BlissBranch: select which bliss branch to sync, default is p9.0 ExtraOptions: foss : packages microG & FDroid with the build go : packages Gapps Go with the build gapps : packages OpenGapps with the build gms : packages GMS with the build (requires private repo access) none : force all extraOption flags to false. To start, you must first use the -s (--sync) flag, then on following builds, it is not needed. Initial generation of the proprietary files from ChromeOS are also needed on the first build. We are able to use the -r (--proprietary) flag for that. This step needs to be on its own because the mounting process requires root permissions, so keep a look out for it asking for your root password . First you must sync with the new manifest changes: bash build-x86.sh -p This will do initial patching. Some of the patches will show as 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. The only times you should worry about the conflicts is when you are adding or changing patches in vendor/x86 . Next step is to download the proprietary files from ChromeOS: mkdir vendor/bliss_priv/proprietary mkdir vendor/bliss_priv/source bash build-x86.sh -r android_x86_64-userdebug After that, you can build your release file: bash build-x86.sh android_x86_64-userdebug (to build the userdebug version for x86_64 CPUs)","title":"Easy Build Instructions"},{"location":"Bliss OS/build-guide/#advanced-build-instructions","text":"Set up the build environment: . build/envsetup.sh This is the initialization file we talked about earlier up top. This \"initializes\" the environment, and imports a bunch of useful build commands required to build your device. Again, you need to remember to source this file every time you log out and log back in, or launch a new bash /Terminal instance. Define what device you\u2019re going to build. For example, the Nexus 5X, has a codename of bullhead . You can check your specific device's codename on GitHub or on Google. Execute: For 32 bit devices: lunch android_x86-userdebug For 64 bit devices: lunch android_x86_64-userdebug Let's break down the command. 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.","title":"Advanced Build Instructions"},{"location":"Bliss OS/build-guide/#my-device-isnt-booting-and-userdebug-wont-print-any-adb-logcats-what-gives","text":"There is a third build variant called 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! If this is the first time you're running the build, you're going to want to run the proprietary build command first from the easy build instructions. Alternatively, you could also run those commands manually. mkdir vendor/bliss_priv/proprietary && mkdir vendor/bliss_priv/source Then: lunch android_x86_64-userdebug mka update_engine_applier mka proprietary After that is complete, we can start the main building process. Run: mka iso_img And the build should start. The build process will take a long time. Prepare to wait a few hours, even on a decent machine.","title":"My device isn't booting, and userdebug won't print any adb logcats. What gives?"},{"location":"Bliss OS/build-guide/#why-mka-and-not-make","text":"make only runs with 1 thread. mka is properly aliased to use all of your threads by checking nproc . If you want to customize your thread count (maybe you're building with a fan-screaming laptop in a quiet coffee shop), use make -j# , replacing the hash with the number of threads (example of make -j4 ).","title":"Why mka and not make?"},{"location":"Bliss OS/build-guide/#after-building","text":"There are two outcomes to a build - either it fails and you get a red error message from 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. If you face the latter, congratulations! You've successfully built BlissRoms for your device. Grab the artifacts for your device: cd out/target/product/x86_64/ In here, you\u2019ll find an .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 .","title":"After building"},{"location":"Bliss OS/build-guide/#changing-the-target-kernel-branch","text":"Sometimes, you might be working on a device that requires a different kernel branch. In order to switch kernels effectively on Bliss OS, they need to be compiled with the OS at build time.","title":"Changing the target kernel branch"},{"location":"Bliss OS/build-guide/#switching-the-kernel-branch","text":"Start off by entering the kernel folder cd kernel Then pull all the available kernel branched from your target repo. In this case, we are using the default BR-x86 repo git fetch BR-x86 Then after that is finished, we need to checkout our target branch, and in this example we are choosing our k4.19.50-ax86-ga branch, which has added commits from the GalliumOS project for Chromebooks git checkout BR-x86/k4.19.50-ax86-ga Next step is to clean out any configs or generated files from the previously checked out kernel. To do this, run these commands make clean make mrproper Once that is done, we can cd back to our main project folder cd .. And run our build command again to generate the .iso with the target kernel we selected rm -rf out/target/product/x86_64/kernel mka iso_img","title":"Switching the kernel branch"},{"location":"Bliss OS/build-guide/#using-the-patch-system-for-testing","text":"We use a patching method we adapted for Bliss from Intel's Project Celadon & phh-treble. This patching system allows us to bring in a good number of commits to add to the OS, and test how they apply or if there are any conflicts. Our intention was to make a system that can add all the needed x86/x86_64 commits to BlissROM, as well as other ROMs too. The majority of this system is found in vendor/x86/utils . From here, you simply generate the .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. From your Project folder: cd packages/apps/Settings And generate your .patch files. For this example, we've added four commits on top of what was there after sync git format-patch -4 Then copy those files to the proper folder in vendor/x86 . In this case, you will find it here: vendor/x86/utils/android_p/google_diff/x86 After that is complete, you can make clean and run the patch system from your main project folder. make clean bash build-x86.sh -p This should start patching all the source files. Once that is complete, you can rebuild.","title":"Using the patch system for testing"},{"location":"Bliss OS/build-guide/#troubleshooting","text":"If your build failed, there are a couple things you can try. Try a fresh 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. Make sure your dependencies are installed correctly. Error messages help out a lot here! Often it will say shared/linked library not found or something along those lines. Make sure you sourced 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 sync ed do this again. Make sure you\u2019re at the root of the build tree. Again, to quickly jump there, use croot . Make sure your computer itself isn\u2019t faulty. HDDs usually die first, followed by RAM. SSDs rarely die but failure is not unheard of. In extremely rare cases, your CPU may have a defect. If you're unsure, run a stress test using a program like Prime95. If something goes wrong and you've tried everything above, first use Google to look up your error! Most of the errors you encounter is due to misconfiguration and wrong commands entered. More often than not, Google will have the answer you are looking for. If you're still stuck and nothing fixes the problem, then ask us via our Telegram Build Support chat.","title":"Troubleshooting"},{"location":"Bliss OS/build-guide/#conclusion","text":"Building a ROM is very hard and tedious and the results are very rewarding! If you managed to follow along, congratulations! After you finish building, you can try out the Git Started guide. Make changes, commit, and send them off to our GitHub for Bliss OS repos & our Gerrit for review on BlissROMs repos! Or better yet, download experimental commits not ready for the mainline repositories and review them! Again, ROM building is a fun project you can work with. I hope this guide was a lot of fun to run through!","title":"Conclusion"},{"location":"Bliss OS/extras/","text":"Extras Setting up Taskbar on Bliss OS (Pie) If you would like to use Taskbar as your default launcher, you will need to first go into \"Settings > Blissify > Gestures\", and enable something like Carbon Gestures (we recommend setting up three-finger swipes: Right for Back, Down for Home, & Up for Recents), then you can go to \"Blissify > Buttons\" and switch the navigation mode to SmartBar, then go back and disable the navigation bar from there by switching off \"Allow Navigation Bar on the top\". At this point, you need to switch to your home screen, so swipe up with your gesture, or tap the Windows key (or Windows-Esc). Then launch Taskbar, enable it, set to launch on boot. We recommend disabling hiding. Enable a couple other settings in the \"Freeform\" and \"Advanced\" screens as required. Setting it up this way will prevent any crashes from happening on initial launch. And it allows you to also use the Quickstep launcher as the main background. Here's a video tutorial on how to do it properly: Setting up Gapps See this thread from @wrwolf2! Watching Netflix - FOSS & GMS Builds Netflix considers our rooted OS as an \"incompatible\" device, according to their support articles. This version of Netflix seems to work great , as long as you don't update it. If it prompts you, click on \"Cancel\".","title":"Extras"},{"location":"Bliss OS/extras/#extras","text":"","title":"Extras"},{"location":"Bliss OS/extras/#setting-up-taskbar-on-bliss-os-pie","text":"If you would like to use Taskbar as your default launcher, you will need to first go into \"Settings > Blissify > Gestures\", and enable something like Carbon Gestures (we recommend setting up three-finger swipes: Right for Back, Down for Home, & Up for Recents), then you can go to \"Blissify > Buttons\" and switch the navigation mode to SmartBar, then go back and disable the navigation bar from there by switching off \"Allow Navigation Bar on the top\". At this point, you need to switch to your home screen, so swipe up with your gesture, or tap the Windows key (or Windows-Esc). Then launch Taskbar, enable it, set to launch on boot. We recommend disabling hiding. Enable a couple other settings in the \"Freeform\" and \"Advanced\" screens as required. Setting it up this way will prevent any crashes from happening on initial launch. And it allows you to also use the Quickstep launcher as the main background. Here's a video tutorial on how to do it properly:","title":"Setting up Taskbar on Bliss OS (Pie)"},{"location":"Bliss OS/extras/#setting-up-gapps","text":"See this thread from @wrwolf2!","title":"Setting up Gapps"},{"location":"Bliss OS/extras/#watching-netflix-foss-gms-builds","text":"Netflix considers our rooted OS as an \"incompatible\" device, according to their support articles. This version of Netflix seems to work great , as long as you don't update it. If it prompts you, click on \"Cancel\".","title":"Watching Netflix - FOSS &amp; GMS Builds"},{"location":"Bliss OS/installation-guide/","text":"Installation Guide Preface These instructions are based on the Android-x86 project's installation guide. We have not changed the installer, so the procedure of installation is similar. We also thank @bg260 for his contributions - this guide was adapted partially from his work. Warning! Team Bliss does NOT accept any responsibility . Users must read and understand the instructions, as the installation modifies core system files and carries a significant risk. You accept all responsibility , including but not limited to data loss and other malfunctions by continuing beyond this point. Any questions, install issues, bug reports, etc. MUST be accompanied with the following things: Log Device info Build info (file name) Installation method (exact steps used) Any other relevant information REQUIRED to diagnose your issue as NOT user error If the following information is not supplied, your inquiry will be ignored. These instructions have changed quite a bit for Android Pie, so consider this section a work in progress. Thank you for your patience! Bootable installation method - MBR/UEFI/ESP (32/64-bit) This is the current recommended method! Overview of the steps: Download the ISO file Use Rufus or similar to burn to USB drive Disable Secure Boot, Bitlocker, and any other boot security software such as Veracrypt Boot into the USB drive. Run Bliss OS in Live mode to test things out. If all is well, continue to next step Boot into the USB drive, and choose Bliss OS Install Let's get started! Part 1 - Gather Your Tools Please note that this method is not supported on all machines. Download Rufus and the 32-bit .iso or 64-bit .iso / .img file of Bliss OS, depending on the architecture of the machine you are installing Bliss OS on. You will need a decent speed USB drive (4 GB or larger is recommended). Part 2 - Flashing Bliss OS to the USB drive Plug in your USB drive, and load up Rufus. Once loaded, click on the icon next to the ISO Image dropdown menu. Now browse to where you have your Bliss OS (32-bit) .iso , or your Bliss OS (64-bit) .iso / .img file. Once chosen, the dropdown should switch to the correct image type, and fill the rest in for you. Once you are ready, click Start. Part 3 - Testing Bliss OS on your system This is very important! If you, as a user, do NOT test the OS first to make sure it is compatible with your device, please do NOT expect us to help you if you happen to install it blindly and something goes wrong. Reboot your machine, and enter the BIOS. Most motherboards have the default key as \"F2\". Change the boot order so that the USB is the first thing the device will boot to. Once the boot orders are changed, reboot. If everything goes well, you should see a grub boot screen. Select the \"Live CD\" option, and if your machine is compatible, you should then see a little bit of text, and then the Bliss OS boot animation. This will go on for a few minutes, but should eventually boot to Bliss OS. If the system never boots to Bliss OS, this is a bad sign that your system might not be compatible. If it does boot, and you would like to install it, continue to the next step. For those wanting to use root, you will need to install the OS and be running of that install. Root will not function properly in Live Mode. Troubleshooting - Booting from the USB kicks me back to BIOS, or back to my Windows/macOS/Linux installation. Your drive is incompatible or you have formatted it incorrectly. Try flashing the image again to the drive with Rufus. If that does not work, your device does not support booting from USB and you will have to try an alternate method. Part 3 (alternate) - Using Bliss OS from your USB drive If you choose to use Bliss from the USB drive, the data you modify or create on the live install will be in an ephemeral state unless you create a data.img to store the data. You can create a data.img in the root directory of the USB drive (make sure you have a minimum of 4-5 GB free on the drive). We suggest using a tool like RMXtools from XDA to create it (version 1.7 is recommended). Check the tool's thread for detailed usage instructions. You will want to create your data.img inside the root directory of your USB drive, with all the other .img files. From there, just boot into live mode, setup your system the way you want, and the data should be persistant across reboots. Part 4 - Setting up and Installing Bliss OS on your HDD/SSD/SD card Quick warning again, in case you missed it. Team Bliss is NOT responsible , directly or indirectly, for any damages caused by this guide. By continuing, you automatically agree to these terms. This is where things start to get a little tricky, especially with how devices vary. Make sure you have a backup plan in case something goes wrong. Start off by opening your favorite partition management software, such as Disk Management in Windows, and create a new partition, making it the size you want (suggested minimum is 8 GB). Just format it to NTFS for now, because it will be formatted by the installer later into the process anyway. Remember what drive you have created here as it's important later on. For Windows machines, it will typically be sda4 or sda5 . Also create another 300 MB FAT32 partition for the grub bootloader to install to. (This part might require a third-party partition manager as Windows Disk Management might not let it be that small.) Boot up the Bliss OS USB, and select the \"Installation\" option in grub . (It is the second one down, usually.) The installer will load, and you will have an option to choose the partition you created earlier. Pick it, and select ext4 . DO NOT blindly choose the partition, as an incorrect flash can mess up your drive and cause serious data loss. You do NOT want to get this step wrong. If you are unsure, boot back into Windows/macOS/Linux and write it down. When it asks if you want to install system as R/W, select \"YES\" if you want to use root (SuperSU), and \"No\" if you do not need root. When it asks if you want to install grub , select \"Grub for Legacy BIOS boot type\", \"Grub2 for UEFI boot type\", or neither if you are already running a Linux system. If you chose to install grub , the installer will allow you to choose the partition to install grub to. Make sure you select the 300 MB partition you set up earlier for grub . The process will install and create the data directory/image, so be patient. When finished, the installer will then ask if you want to run Android-x86. You can just reboot here. Make sure you remove the USB drive. If we have followed all the directions correctly, you should be presented with a grub boot menu. You can choose your bliss_android_x86 option (or android-x86 ), and it will boot into Bliss OS. If you want to customize your grub boot entry, search the web first. We use the same grub setup that the Android-x86 project uses, so their forums will contain just about all the info you will need. Congratulations! We hope you enjoy using Bliss OS. Windows-based installer - UEFI/ESP (64-bit) This method is no longer supported due to too many people not understanding computer basics and breaking things. Proceed at your own risk. This method might be the easiest currently if you understand what you are doing. For the overall instructions on using this method, please refer to the tool's original thread . The tools have been updated by Team Bliss for easy installation on UEFI/ESP machines. The builds we produce can be found here. And the source for those builds can be found here. This tool should work on Remix OS as well, but this has not been tested yet. Part 1 - Using the Installer The installer has been updated to accept the .iso files for our 8.x/10.x/11.x releases. Just follow the prompts the installer gives. Refer to the original thread for any questions, and please search before asking. If you plan on using root, the process will require you to manually extract the system.img from within the system.sfs file. Then you must delete the system.sfs file after extracting. Warning - for Pie, you will need to add androidboot.hardware=android_x86_64 to the grub entry in order to boot! Part 2 - Switching the UEFI/EFI boot entry Option one is to use the EasyUEFI tool, then switch the UEFI/EFI entry it created to boot first. Close and reboot. Option two is to use your BIOS to select the added UEFI boot entry. Use syslinux EFI to run Bliss OS 7.x/10.x/11.x Thanks to @IcedCube for the original post! This method is NOT recommended as it is fairly bleeding-edge and experimental, but it should help booting on Chinese tablets that do not want to run grub . Use a Linux installation for the following procedure. Part 1 - Grab the required tools Install unsquashfs (part of squashfs-tools ). Part 2 - Get Bliss OS Grab the latest build of Bliss OS 7.x/10.x/11.x. Part 3 - Get the syslinux EFI bootstrap Grab the .zip file from @IcedCube's original post , and extract it to the root of the USB drive. This will bootstrap syslinux EFI onto it. Then, make a folder called android . Now, open up the .iso in an archive program. Extract the following files form the root directory of the .iso image to the USB drive's android folder: initrd.img ramdisk.img kernel Extract system.sfs to a folder somewhere, such as /tmp . Open a terminal and change directory (using cd ) to /tmp . Run ls and confirm that system.sfs is shown in the file list. If there is no output, start over as the file is misplaced. Run the following: unsquashfs ./system.sfs This will make a new directory called squashfs_root . Part 4 - Version specific If you are using Bliss 7.x Change directory to squashfs_root and run ls . There should only be one file - a system.img inside the directory. Copy the file to the USB's android folder. If you are using Bliss 10.x Change directory to squashfs_root . The structure is a complete Android root filesystem. To install Bliss OS, the files will need to be in a system image. The following steps will guide you through creating a 2 GB system.img file, formatting it, mounting it, and copying the contents of squashfs_root into the new disk image. Execute: mkdir /mnt/tempMount truncate /tmp/system.img --size=2G mkfs.ext4 -m0 /tmp/system.img sudo mount -o loop /tmp/system.img /mnt/tempMount sudo cp -prv /tmp/squashfs_root/* /mnt/tempMount/ sync sudo umount /mnt/tempMount The sync command might take some time. Now copy the /tmp/system.img file to your USB's Android folder. Part 5 - Creating the data image First, find where your USB drive is mounted. It is usually in /mnt or /media (ex. /media/USB ). cd into the android folder. We will create a 3 GB data image file. You can attempt to create a 4 GB image but FAT32 maxes out at 4 GB per file. If your system supports exFAT or NTFS, you may try and use it. truncate data.img --size=3G mkfs.ext4 -m0 data.img sync This will be an completely empty ext4 disk image, but will be enough to run Bliss. Finally, check to ensure everything is in structured like so: <ROOT> - syslinux.cfg - android/ -- kernel -- system.img -- data.img -- ramdisk.img -- initrd.img - EFI/ -- BOOT/ --- bootia32.efi --- bootx64.efi --- ldlinux.e32 --- ldlinux.e64 Need to add some kernel parameters? Open syslinux.cfg and add them before the initrd=/android/initrd.img statement. Unmount the USB from your computer. Plug it into your device and use the BIOS to boot from your UEFI USB Drive, partition 1. If all goes well, you will get a black screen with small white text saying \"Booting Android...\" followed by loading files. You should get the Linux kernel text, then see the Bliss boot animation play after a couple minutes depending on your USB drive read/write speed. Custom Install - Bliss OS 8.x/10.x/11.x UEFI/ESP (64-bit) Just as a reminder, Team Bliss is NOT responsible for any damage caused by this guide. By continuing, you automatically agree to these terms. Part 1 - Mounting Your UEFI/ESP Partition You will want to make sure you can view hidden and system files in Explorer options. Once you do that, hit the start menu, and type in cmd . Once \"Command Prompt\" shows up, right click on it and choose \"Open as administrator\". cmd is not showing up, what should I do? Press the Windows key and the R key to bring up the \"Run...\" dialog. Type in cmd , and then press Ctrl-Shift-Enter. Press \"Yes\" on the UAC popup. Run the following: mountvol X: /S Then check to see if it is mounted already. Run \"Task Manager\" by either Pressing Ctrl-Alt-Del and then clicking on \"Task Manager\", or Pressing Ctrl-Shift-Esc Click on \"File\", \"Run new task\", \"Browse\", \"This computer\", and SYSTEM (X or type in X: in the filepath bar. If you cannot access X: , then that could mean one of three things. You have an ESP setup (follow the installation method below) You have a legacy MBR setup Your setup has a custom boot sequence Part 1 (alternate) - ESP setup Windows 10 sometimes has an EFI partition already mounted under drive letter Z: , hidden. A very quick and easy way to access the ESP (EFI System Partition) in Windows 10 without using the command line is to start \"Task Manager\" (check above if you forgot the steps), and then click on \"File\", \"Run new task\", \"Browse\", \"This computer\", and SYSTEM (Z or type in Z: in the filepath bar). Now go to boot/grub/grub.cfg and edit it accordingly with Notepad++ or another text editor. Save the file and your're ready to go! Part 1 (alternate) - Killing the explorer.exe Run cmd as admin and enter the following command: taskkill /im explorer.exe /f This will kill the explorer.exe process - don't be surprised if it shows a warning. This step is sometimes required, because by default explorer.exe is ran by the currently logged in user, and it has to be run by the \"Administrator\" in order to view the mounted system drive. The \"Administrator\" account is not the same as an account with administrative privileges. mountvol X: /s This will mount the system partition that usually consists of UEFI related files. X: is the letter of the drive - you can use whatever letter you want, but it has to be free for assignment. Then type: explorer This will run explorer as \"Administrator\" and will allow you to browse the mounted system partition. The above may not work for all devices, as some handle UEFI differently. Part 2 - UEFI installation Let's start by downloading the required files. Here is a customized UEFI boot for 32/64-bit machines. Please note that if you came from our Nougat builds to our Bliss OS 8.x builds, you will have to edit the grub.cfga . If you are using Bliss OS 8.x/10.x, please use the grub entry below as a guide: menuentry 'Bliss-x86' --class android { search --file --no-floppy --set=root /AndroidOS/system.sfs linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 quiet DATA= initrd /AndroidOS/initrd.img } If you are installing on ext3 / ext4 , due to a bug in the install you will have to use the following grub entry setup: menuentry 'Bliss-x86' --class android { search --file --no-floppy --set=root /AndroidOS/system.sfs linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 quiet DATA= initrd /AndroidOS/initrd.img } Now that we have the partition mounted, we can copy that BOOT directory to your UEFI partition using explorer as the Administrator or by using the \"New Task\" dialog from Task Manager. (See above if you forgot the steps!) Once it is copied, go back to the Administrator cmd prompt and type: mountvol X: /D or if you used Z: , type: mountvol Z: /D This will dismount the UEFI/ESP volume for safe reboot. We then suggest you use EasyUEFI here to create the UEFI boot entry. Open the app, and create a new entry. Select your UEFI partition, and in the \"File\" Path, click \"Browse\" and use the file manager window to browse to your BOOT/grub/grubx64.efi file. Click OK, and then choose the new grub entry and move it to the top. Make sure Secure Boot is turned off or else it likely will just boot back to Windows. Part 4 - The Manual Blissification of Your PC To do a manual \"Wubi like\" install of Bliss OS after you install the UEFI entry, you will need to open the Bliss OS .iso / .img with 7zip, and then drag all the .img & .sfs files to C:/android-x86 or whatever your target drive is (make sure your grub entries match where you are putting these). Then create your data.img . We suggest using a tool like RMXtools (use version 1.7) from XDA to create it. Check the tool's thread for detailed instructions. You will want to create your data.img inside that android-x86 folder. You can now reboot if you have installed the custom UEFI entry right and selected it using EasyUEFI. You should boot right to the Android-x86 grub theme. There, you can use up and down to select, and return to boot that entry. You can also hit e to edit the selected entry. You will want to pay attention to which entry you select, since there will be one for Bliss-x86(32bit) and one or Bliss-x86_64(64bit) . Install Bliss OS on a VM (virtualbox) This method does require some beefy PC specs, so it might not work for all. Thanks to Chih-Wei Huang from Android-x86 Project for the detailed information! This method is currently being worked on. Check back later for more information! Befor we proceed, if things don't work out, check cat /proc/cpuinfo to determine if your CPU is compatible with virtualization. Specific Surface model instructions Reference posts here and here . Many of you have a Surface device and would like to run Android on it. You're in luck, because this project was started with a Surface Pro 3 to test with back in Android Nougat. The device has since been retired and development has continued on a Surface Book, an IPTS device. This means it requires a specific set of firmware for proper functioning. For all other Surface models, the user must upgrade their own firmware, because it is too large of a burden to build for all Surface models without having those devices to test with. To start, you will need to grab the right firmware for your device. Surface Series Devices: Series 5 devices: Surface Book 2 Surface Pro 2017 Series 4 devices Surface Book Surface Pro 4 Surface Laptop Series 3 devices: Surface Pro 3 For the ipts_firmware files (series 4/5 devices only), please select the correct version for your device: v76 for the Surface Book v78 for the Surface Pro 4 v79 for the Surface Laptop v101 for Surface Book 2 15\" v102 for the Surface Pro 2017 v137 for the Surface Book 2 13\" For the i915_firmware files (series 3/4/5 devices), please select the correct version for your device: kbl for series 5 devices skl for series 4 devices bxt for series 3 devices All firmware files can be found here. For Surface Go users, you will have to remove some files and replace with @jakeday's firmware. Please see this thread on Reddit for detailed information. Once you have the right firmware you need, you should copy it to a folder on your Bliss install ( SD_card_root/surface ), making sure to put the right firmware in the right folders: IPTS firmware: SD_card_root/surface/intel/ipts ath10k firmware (some models): SD_card_root/surface/ath10k mrvl firmware (some models): SD_card_root/surface/mrvl mwlwifi firmware (some models): SD_card_root/surface/mwlwifi nvidia firmware for SB2: SD_card_root/surface/nvidia Next, open a terminal (we include one you can enable in \"Developer Options\"). In the terminal, enter the following commands, giving permission to the superuser popup dialog when prompted: su mv -f SD_card_root/surface/* system/lib/firmware/ Then you can restart: reboot It should recognize and load the correct firmware versions for your device upon reboot if you did everything correctly. Conclusion Thanks for following along! If you want to check out the next guide, click here! Having problems with your new installation? Check out Troubleshooting.","title":"Installation Guide"},{"location":"Bliss OS/installation-guide/#installation-guide","text":"","title":"Installation Guide"},{"location":"Bliss OS/installation-guide/#preface","text":"These instructions are based on the Android-x86 project's installation guide. We have not changed the installer, so the procedure of installation is similar. We also thank @bg260 for his contributions - this guide was adapted partially from his work.","title":"Preface"},{"location":"Bliss OS/installation-guide/#warning","text":"Team Bliss does NOT accept any responsibility . Users must read and understand the instructions, as the installation modifies core system files and carries a significant risk. You accept all responsibility , including but not limited to data loss and other malfunctions by continuing beyond this point. Any questions, install issues, bug reports, etc. MUST be accompanied with the following things: Log Device info Build info (file name) Installation method (exact steps used) Any other relevant information REQUIRED to diagnose your issue as NOT user error If the following information is not supplied, your inquiry will be ignored. These instructions have changed quite a bit for Android Pie, so consider this section a work in progress. Thank you for your patience!","title":"Warning!"},{"location":"Bliss OS/installation-guide/#bootable-installation-method-mbruefiesp-3264-bit","text":"This is the current recommended method! Overview of the steps: Download the ISO file Use Rufus or similar to burn to USB drive Disable Secure Boot, Bitlocker, and any other boot security software such as Veracrypt Boot into the USB drive. Run Bliss OS in Live mode to test things out. If all is well, continue to next step Boot into the USB drive, and choose Bliss OS Install Let's get started!","title":"Bootable installation method - MBR/UEFI/ESP (32/64-bit)"},{"location":"Bliss OS/installation-guide/#part-1-gather-your-tools","text":"Please note that this method is not supported on all machines. Download Rufus and the 32-bit .iso or 64-bit .iso / .img file of Bliss OS, depending on the architecture of the machine you are installing Bliss OS on. You will need a decent speed USB drive (4 GB or larger is recommended).","title":"Part 1 - Gather Your Tools"},{"location":"Bliss OS/installation-guide/#part-2-flashing-bliss-os-to-the-usb-drive","text":"Plug in your USB drive, and load up Rufus. Once loaded, click on the icon next to the ISO Image dropdown menu. Now browse to where you have your Bliss OS (32-bit) .iso , or your Bliss OS (64-bit) .iso / .img file. Once chosen, the dropdown should switch to the correct image type, and fill the rest in for you. Once you are ready, click Start.","title":"Part 2 - Flashing Bliss OS to the USB drive"},{"location":"Bliss OS/installation-guide/#part-3-testing-bliss-os-on-your-system","text":"This is very important! If you, as a user, do NOT test the OS first to make sure it is compatible with your device, please do NOT expect us to help you if you happen to install it blindly and something goes wrong. Reboot your machine, and enter the BIOS. Most motherboards have the default key as \"F2\". Change the boot order so that the USB is the first thing the device will boot to. Once the boot orders are changed, reboot. If everything goes well, you should see a grub boot screen. Select the \"Live CD\" option, and if your machine is compatible, you should then see a little bit of text, and then the Bliss OS boot animation. This will go on for a few minutes, but should eventually boot to Bliss OS. If the system never boots to Bliss OS, this is a bad sign that your system might not be compatible. If it does boot, and you would like to install it, continue to the next step. For those wanting to use root, you will need to install the OS and be running of that install. Root will not function properly in Live Mode.","title":"Part 3 - Testing Bliss OS on your system"},{"location":"Bliss OS/installation-guide/#troubleshooting-booting-from-the-usb-kicks-me-back-to-bios-or-back-to-my-windowsmacoslinux-installation","text":"Your drive is incompatible or you have formatted it incorrectly. Try flashing the image again to the drive with Rufus. If that does not work, your device does not support booting from USB and you will have to try an alternate method.","title":"Troubleshooting - Booting from the USB kicks me back to BIOS, or back to my Windows/macOS/Linux installation."},{"location":"Bliss OS/installation-guide/#part-3-alternate-using-bliss-os-from-your-usb-drive","text":"If you choose to use Bliss from the USB drive, the data you modify or create on the live install will be in an ephemeral state unless you create a data.img to store the data. You can create a data.img in the root directory of the USB drive (make sure you have a minimum of 4-5 GB free on the drive). We suggest using a tool like RMXtools from XDA to create it (version 1.7 is recommended). Check the tool's thread for detailed usage instructions. You will want to create your data.img inside the root directory of your USB drive, with all the other .img files. From there, just boot into live mode, setup your system the way you want, and the data should be persistant across reboots.","title":"Part 3 (alternate) - Using Bliss OS from your USB drive"},{"location":"Bliss OS/installation-guide/#part-4-setting-up-and-installing-bliss-os-on-your-hddssdsd-card","text":"Quick warning again, in case you missed it. Team Bliss is NOT responsible , directly or indirectly, for any damages caused by this guide. By continuing, you automatically agree to these terms. This is where things start to get a little tricky, especially with how devices vary. Make sure you have a backup plan in case something goes wrong. Start off by opening your favorite partition management software, such as Disk Management in Windows, and create a new partition, making it the size you want (suggested minimum is 8 GB). Just format it to NTFS for now, because it will be formatted by the installer later into the process anyway. Remember what drive you have created here as it's important later on. For Windows machines, it will typically be sda4 or sda5 . Also create another 300 MB FAT32 partition for the grub bootloader to install to. (This part might require a third-party partition manager as Windows Disk Management might not let it be that small.) Boot up the Bliss OS USB, and select the \"Installation\" option in grub . (It is the second one down, usually.) The installer will load, and you will have an option to choose the partition you created earlier. Pick it, and select ext4 . DO NOT blindly choose the partition, as an incorrect flash can mess up your drive and cause serious data loss. You do NOT want to get this step wrong. If you are unsure, boot back into Windows/macOS/Linux and write it down. When it asks if you want to install system as R/W, select \"YES\" if you want to use root (SuperSU), and \"No\" if you do not need root. When it asks if you want to install grub , select \"Grub for Legacy BIOS boot type\", \"Grub2 for UEFI boot type\", or neither if you are already running a Linux system. If you chose to install grub , the installer will allow you to choose the partition to install grub to. Make sure you select the 300 MB partition you set up earlier for grub . The process will install and create the data directory/image, so be patient. When finished, the installer will then ask if you want to run Android-x86. You can just reboot here. Make sure you remove the USB drive. If we have followed all the directions correctly, you should be presented with a grub boot menu. You can choose your bliss_android_x86 option (or android-x86 ), and it will boot into Bliss OS. If you want to customize your grub boot entry, search the web first. We use the same grub setup that the Android-x86 project uses, so their forums will contain just about all the info you will need. Congratulations! We hope you enjoy using Bliss OS.","title":"Part 4 - Setting up and Installing Bliss OS on your HDD/SSD/SD card"},{"location":"Bliss OS/installation-guide/#windows-based-installer-uefiesp-64-bit","text":"This method is no longer supported due to too many people not understanding computer basics and breaking things. Proceed at your own risk. This method might be the easiest currently if you understand what you are doing. For the overall instructions on using this method, please refer to the tool's original thread . The tools have been updated by Team Bliss for easy installation on UEFI/ESP machines. The builds we produce can be found here. And the source for those builds can be found here. This tool should work on Remix OS as well, but this has not been tested yet.","title":"Windows-based installer - UEFI/ESP (64-bit)"},{"location":"Bliss OS/installation-guide/#part-1-using-the-installer","text":"The installer has been updated to accept the .iso files for our 8.x/10.x/11.x releases. Just follow the prompts the installer gives. Refer to the original thread for any questions, and please search before asking. If you plan on using root, the process will require you to manually extract the system.img from within the system.sfs file. Then you must delete the system.sfs file after extracting. Warning - for Pie, you will need to add androidboot.hardware=android_x86_64 to the grub entry in order to boot!","title":"Part 1 - Using the Installer"},{"location":"Bliss OS/installation-guide/#part-2-switching-the-uefiefi-boot-entry","text":"Option one is to use the EasyUEFI tool, then switch the UEFI/EFI entry it created to boot first. Close and reboot. Option two is to use your BIOS to select the added UEFI boot entry.","title":"Part 2 - Switching the UEFI/EFI boot entry"},{"location":"Bliss OS/installation-guide/#use-syslinux-efi-to-run-bliss-os-7x10x11x","text":"Thanks to @IcedCube for the original post! This method is NOT recommended as it is fairly bleeding-edge and experimental, but it should help booting on Chinese tablets that do not want to run grub . Use a Linux installation for the following procedure.","title":"Use syslinux EFI to run Bliss OS 7.x/10.x/11.x"},{"location":"Bliss OS/installation-guide/#part-1-grab-the-required-tools","text":"Install unsquashfs (part of squashfs-tools ).","title":"Part 1 - Grab the required tools"},{"location":"Bliss OS/installation-guide/#part-2-get-bliss-os","text":"Grab the latest build of Bliss OS 7.x/10.x/11.x.","title":"Part 2 - Get Bliss OS"},{"location":"Bliss OS/installation-guide/#part-3-get-the-syslinux-efi-bootstrap","text":"Grab the .zip file from @IcedCube's original post , and extract it to the root of the USB drive. This will bootstrap syslinux EFI onto it. Then, make a folder called android . Now, open up the .iso in an archive program. Extract the following files form the root directory of the .iso image to the USB drive's android folder: initrd.img ramdisk.img kernel Extract system.sfs to a folder somewhere, such as /tmp . Open a terminal and change directory (using cd ) to /tmp . Run ls and confirm that system.sfs is shown in the file list. If there is no output, start over as the file is misplaced. Run the following: unsquashfs ./system.sfs This will make a new directory called squashfs_root .","title":"Part 3 - Get the syslinux EFI bootstrap"},{"location":"Bliss OS/installation-guide/#part-4-version-specific","text":"","title":"Part 4 - Version specific"},{"location":"Bliss OS/installation-guide/#if-you-are-using-bliss-7x","text":"Change directory to squashfs_root and run ls . There should only be one file - a system.img inside the directory. Copy the file to the USB's android folder.","title":"If you are using Bliss 7.x"},{"location":"Bliss OS/installation-guide/#if-you-are-using-bliss-10x","text":"Change directory to squashfs_root . The structure is a complete Android root filesystem. To install Bliss OS, the files will need to be in a system image. The following steps will guide you through creating a 2 GB system.img file, formatting it, mounting it, and copying the contents of squashfs_root into the new disk image. Execute: mkdir /mnt/tempMount truncate /tmp/system.img --size=2G mkfs.ext4 -m0 /tmp/system.img sudo mount -o loop /tmp/system.img /mnt/tempMount sudo cp -prv /tmp/squashfs_root/* /mnt/tempMount/ sync sudo umount /mnt/tempMount The sync command might take some time. Now copy the /tmp/system.img file to your USB's Android folder.","title":"If you are using Bliss 10.x"},{"location":"Bliss OS/installation-guide/#part-5-creating-the-data-image","text":"First, find where your USB drive is mounted. It is usually in /mnt or /media (ex. /media/USB ). cd into the android folder. We will create a 3 GB data image file. You can attempt to create a 4 GB image but FAT32 maxes out at 4 GB per file. If your system supports exFAT or NTFS, you may try and use it. truncate data.img --size=3G mkfs.ext4 -m0 data.img sync This will be an completely empty ext4 disk image, but will be enough to run Bliss. Finally, check to ensure everything is in structured like so: <ROOT> - syslinux.cfg - android/ -- kernel -- system.img -- data.img -- ramdisk.img -- initrd.img - EFI/ -- BOOT/ --- bootia32.efi --- bootx64.efi --- ldlinux.e32 --- ldlinux.e64 Need to add some kernel parameters? Open syslinux.cfg and add them before the initrd=/android/initrd.img statement. Unmount the USB from your computer. Plug it into your device and use the BIOS to boot from your UEFI USB Drive, partition 1. If all goes well, you will get a black screen with small white text saying \"Booting Android...\" followed by loading files. You should get the Linux kernel text, then see the Bliss boot animation play after a couple minutes depending on your USB drive read/write speed.","title":"Part 5 - Creating the data image"},{"location":"Bliss OS/installation-guide/#custom-install-bliss-os-8x10x11x-uefiesp-64-bit","text":"Just as a reminder, Team Bliss is NOT responsible for any damage caused by this guide. By continuing, you automatically agree to these terms.","title":"Custom Install - Bliss OS 8.x/10.x/11.x UEFI/ESP (64-bit)"},{"location":"Bliss OS/installation-guide/#part-1-mounting-your-uefiesp-partition","text":"You will want to make sure you can view hidden and system files in Explorer options. Once you do that, hit the start menu, and type in cmd . Once \"Command Prompt\" shows up, right click on it and choose \"Open as administrator\".","title":"Part 1 - Mounting Your UEFI/ESP Partition"},{"location":"Bliss OS/installation-guide/#cmd-is-not-showing-up-what-should-i-do","text":"Press the Windows key and the R key to bring up the \"Run...\" dialog. Type in cmd , and then press Ctrl-Shift-Enter. Press \"Yes\" on the UAC popup. Run the following: mountvol X: /S Then check to see if it is mounted already. Run \"Task Manager\" by either Pressing Ctrl-Alt-Del and then clicking on \"Task Manager\", or Pressing Ctrl-Shift-Esc Click on \"File\", \"Run new task\", \"Browse\", \"This computer\", and SYSTEM (X or type in X: in the filepath bar. If you cannot access X: , then that could mean one of three things. You have an ESP setup (follow the installation method below) You have a legacy MBR setup Your setup has a custom boot sequence","title":"cmd is not showing up, what should I do?"},{"location":"Bliss OS/installation-guide/#part-1-alternate-esp-setup","text":"Windows 10 sometimes has an EFI partition already mounted under drive letter Z: , hidden. A very quick and easy way to access the ESP (EFI System Partition) in Windows 10 without using the command line is to start \"Task Manager\" (check above if you forgot the steps), and then click on \"File\", \"Run new task\", \"Browse\", \"This computer\", and SYSTEM (Z or type in Z: in the filepath bar). Now go to boot/grub/grub.cfg and edit it accordingly with Notepad++ or another text editor. Save the file and your're ready to go!","title":"Part 1 (alternate) - ESP setup"},{"location":"Bliss OS/installation-guide/#part-1-alternate-killing-the-explorerexe","text":"Run cmd as admin and enter the following command: taskkill /im explorer.exe /f This will kill the explorer.exe process - don't be surprised if it shows a warning. This step is sometimes required, because by default explorer.exe is ran by the currently logged in user, and it has to be run by the \"Administrator\" in order to view the mounted system drive. The \"Administrator\" account is not the same as an account with administrative privileges. mountvol X: /s This will mount the system partition that usually consists of UEFI related files. X: is the letter of the drive - you can use whatever letter you want, but it has to be free for assignment. Then type: explorer This will run explorer as \"Administrator\" and will allow you to browse the mounted system partition. The above may not work for all devices, as some handle UEFI differently.","title":"Part 1 (alternate) - Killing the explorer.exe"},{"location":"Bliss OS/installation-guide/#part-2-uefi-installation","text":"Let's start by downloading the required files. Here is a customized UEFI boot for 32/64-bit machines. Please note that if you came from our Nougat builds to our Bliss OS 8.x builds, you will have to edit the grub.cfga . If you are using Bliss OS 8.x/10.x, please use the grub entry below as a guide: menuentry 'Bliss-x86' --class android { search --file --no-floppy --set=root /AndroidOS/system.sfs linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 quiet DATA= initrd /AndroidOS/initrd.img } If you are installing on ext3 / ext4 , due to a bug in the install you will have to use the following grub entry setup: menuentry 'Bliss-x86' --class android { search --file --no-floppy --set=root /AndroidOS/system.sfs linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 quiet DATA= initrd /AndroidOS/initrd.img } Now that we have the partition mounted, we can copy that BOOT directory to your UEFI partition using explorer as the Administrator or by using the \"New Task\" dialog from Task Manager. (See above if you forgot the steps!) Once it is copied, go back to the Administrator cmd prompt and type: mountvol X: /D or if you used Z: , type: mountvol Z: /D This will dismount the UEFI/ESP volume for safe reboot. We then suggest you use EasyUEFI here to create the UEFI boot entry. Open the app, and create a new entry. Select your UEFI partition, and in the \"File\" Path, click \"Browse\" and use the file manager window to browse to your BOOT/grub/grubx64.efi file. Click OK, and then choose the new grub entry and move it to the top. Make sure Secure Boot is turned off or else it likely will just boot back to Windows.","title":"Part 2 - UEFI installation"},{"location":"Bliss OS/installation-guide/#part-4-the-manual-blissification-of-your-pc","text":"To do a manual \"Wubi like\" install of Bliss OS after you install the UEFI entry, you will need to open the Bliss OS .iso / .img with 7zip, and then drag all the .img & .sfs files to C:/android-x86 or whatever your target drive is (make sure your grub entries match where you are putting these). Then create your data.img . We suggest using a tool like RMXtools (use version 1.7) from XDA to create it. Check the tool's thread for detailed instructions. You will want to create your data.img inside that android-x86 folder. You can now reboot if you have installed the custom UEFI entry right and selected it using EasyUEFI. You should boot right to the Android-x86 grub theme. There, you can use up and down to select, and return to boot that entry. You can also hit e to edit the selected entry. You will want to pay attention to which entry you select, since there will be one for Bliss-x86(32bit) and one or Bliss-x86_64(64bit) .","title":"Part 4 - The Manual Blissification of Your PC"},{"location":"Bliss OS/installation-guide/#install-bliss-os-on-a-vm-virtualbox","text":"This method does require some beefy PC specs, so it might not work for all. Thanks to Chih-Wei Huang from Android-x86 Project for the detailed information! This method is currently being worked on. Check back later for more information! Befor we proceed, if things don't work out, check cat /proc/cpuinfo to determine if your CPU is compatible with virtualization.","title":"Install Bliss OS on a VM (virtualbox)"},{"location":"Bliss OS/installation-guide/#specific-surface-model-instructions","text":"Reference posts here and here . Many of you have a Surface device and would like to run Android on it. You're in luck, because this project was started with a Surface Pro 3 to test with back in Android Nougat. The device has since been retired and development has continued on a Surface Book, an IPTS device. This means it requires a specific set of firmware for proper functioning. For all other Surface models, the user must upgrade their own firmware, because it is too large of a burden to build for all Surface models without having those devices to test with. To start, you will need to grab the right firmware for your device. Surface Series Devices: Series 5 devices: Surface Book 2 Surface Pro 2017 Series 4 devices Surface Book Surface Pro 4 Surface Laptop Series 3 devices: Surface Pro 3 For the ipts_firmware files (series 4/5 devices only), please select the correct version for your device: v76 for the Surface Book v78 for the Surface Pro 4 v79 for the Surface Laptop v101 for Surface Book 2 15\" v102 for the Surface Pro 2017 v137 for the Surface Book 2 13\" For the i915_firmware files (series 3/4/5 devices), please select the correct version for your device: kbl for series 5 devices skl for series 4 devices bxt for series 3 devices All firmware files can be found here. For Surface Go users, you will have to remove some files and replace with @jakeday's firmware. Please see this thread on Reddit for detailed information. Once you have the right firmware you need, you should copy it to a folder on your Bliss install ( SD_card_root/surface ), making sure to put the right firmware in the right folders: IPTS firmware: SD_card_root/surface/intel/ipts ath10k firmware (some models): SD_card_root/surface/ath10k mrvl firmware (some models): SD_card_root/surface/mrvl mwlwifi firmware (some models): SD_card_root/surface/mwlwifi nvidia firmware for SB2: SD_card_root/surface/nvidia Next, open a terminal (we include one you can enable in \"Developer Options\"). In the terminal, enter the following commands, giving permission to the superuser popup dialog when prompted: su mv -f SD_card_root/surface/* system/lib/firmware/ Then you can restart: reboot It should recognize and load the correct firmware versions for your device upon reboot if you did everything correctly.","title":"Specific Surface model instructions"},{"location":"Bliss OS/installation-guide/#conclusion","text":"Thanks for following along! If you want to check out the next guide, click here! Having problems with your new installation? Check out Troubleshooting.","title":"Conclusion"},{"location":"Bliss OS/troubleshooting/","text":"Troubleshooting 32-bit processors only (Intel Atom and similar) Install Android-x86 32-bit OS from https://www.android-x86.org/ (doesn't matter which version, as long as it's 32-bit) Update with Bliss OS 32-bit (current version is 11.9). After reboot you should be able to access the grub menu. In grub menu select \"Debug mode\" Run the following commands: mount -o remount, rw /mnt cd /mnt/grub vi menu.lst Add nomodeset before every \"SCR=**\" line. For example, your configuration should look something like this: nomodeset SCR=700 nomodeset SCR=716 nomodeset SCR=795 Press Ctrl+O to save, and then Ctrl+X to close. Type reboot -f You should be finished! If all goes well you will boot into Bliss OS on your 32-bit machine. grub2 kernel parameters and options You will want to pay attention here! With Bliss OS on the PC, we tend to use quite a few command line options to get things working right. We've gathered a few of them here to explain them a little bit. A full list of available kernel parameters can be found here. Brief options overview: parameter : Description root= : Root filesystem. rootflags= : Root filesystem mount options. initrd= : Specify the location of the initial ramdisk. init= : Run specified binary instead of /sbin/init (symlinked to systemd in Arch) as init process. init=/bin/sh : Boot to shell. systemd.unit= : Boot to a specified target. nomodeset : Disable kernel mode setting (useful for fixing video driver panics) This will load mostly everything in software rendering/support mode. No hardware acceleration. Good for debugging. panic= : Time before automatic reboot on kernel panic. debug : Enable kernel debugging (events log level). mem= : Force usage of a specific amount of memory to be used. maxcpus= : Maximum number of processors that an SMP kernel will bring up during bootup. selinux= : Disable or enable SELinux at boot time. netdev= : Network devices parameters. video=<videosetting> : Override framebuffer video defaults. sleep=1 : This will enable the system.prop value for sleep.earlysuspend=1 , and on some machines, it enables the proper sleep state. acpi_sleep=s3_bios,s3_mode : Sometimes needed for older machines to enter sleep mode properly SETUPWIZARD=0 : This command will skip SetupWizard on boot. (Only needs to be run once!) AUTO_LOAD=old : This will load android-x86 variants using the old modprobe method to init devices. We sometimes use this to debug devices not starting. DEBUG=1 & DEBUG=2 : These enable verbose console debugging, giving another command shell after loading kernel modules, but before Android init vga=xxx & video= : These are the common video modes that you can boot into if it doesn't pick the best choice automagically. You can also use video= as resolution parameters: video=LVDS-1:d video=1366x800 . Learn more from our own Henri Koivuneva! HWACCELL=1 : This will disable graphics hardware acceleration, enabling rendering through Swiftshader. (Must use this if running headless) buildvariant=eng, user, userdebug : This is the commandline parameter to run the current build as eng , userdebug , or user DPI=xxx : This will manually set the DPI on init. Use this if things are too big/small for you. fbcon=variablename : This is to configure framebuffer to use various options. Usually used to help fix video settings, etc. Even default rotation on some Atom tablets. Example: video=efifb fbcon=rotate:1 VULKAN=1 : Required for Vulkan-supported chipsets. This enables hwcomposer to work right with screenshots and other things. As an example, here are a few of the boot options used in testing: menuentry 'Bliss-x86 Test-Oreo' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng quiet sleep.earlysuspend=2 DATA= initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo AUTO_LOAD=old' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng quiet DATA= AUTO_LOAD=old initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo - SETUP_WIZARD=0' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive buildvariant=eng SETUPWIZARD=0 quiet DATA= initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo - debug=1' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng SETUPWIZARD=0 quiet DATA= DEBUG=1 initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo - debug=2' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng SETUPWIZARD=0 quiet DATA= DEBUG=2 initrd /AndroidOS/initrd.img }","title":"Troubleshooting"},{"location":"Bliss OS/troubleshooting/#troubleshooting","text":"","title":"Troubleshooting"},{"location":"Bliss OS/troubleshooting/#32-bit-processors-only-intel-atom-and-similar","text":"Install Android-x86 32-bit OS from https://www.android-x86.org/ (doesn't matter which version, as long as it's 32-bit) Update with Bliss OS 32-bit (current version is 11.9). After reboot you should be able to access the grub menu. In grub menu select \"Debug mode\" Run the following commands: mount -o remount, rw /mnt cd /mnt/grub vi menu.lst Add nomodeset before every \"SCR=**\" line. For example, your configuration should look something like this: nomodeset SCR=700 nomodeset SCR=716 nomodeset SCR=795 Press Ctrl+O to save, and then Ctrl+X to close. Type reboot -f You should be finished! If all goes well you will boot into Bliss OS on your 32-bit machine.","title":"32-bit processors only (Intel Atom and similar)"},{"location":"Bliss OS/troubleshooting/#grub2-kernel-parameters-and-options","text":"You will want to pay attention here! With Bliss OS on the PC, we tend to use quite a few command line options to get things working right. We've gathered a few of them here to explain them a little bit. A full list of available kernel parameters can be found here. Brief options overview: parameter : Description root= : Root filesystem. rootflags= : Root filesystem mount options. initrd= : Specify the location of the initial ramdisk. init= : Run specified binary instead of /sbin/init (symlinked to systemd in Arch) as init process. init=/bin/sh : Boot to shell. systemd.unit= : Boot to a specified target. nomodeset : Disable kernel mode setting (useful for fixing video driver panics) This will load mostly everything in software rendering/support mode. No hardware acceleration. Good for debugging. panic= : Time before automatic reboot on kernel panic. debug : Enable kernel debugging (events log level). mem= : Force usage of a specific amount of memory to be used. maxcpus= : Maximum number of processors that an SMP kernel will bring up during bootup. selinux= : Disable or enable SELinux at boot time. netdev= : Network devices parameters. video=<videosetting> : Override framebuffer video defaults. sleep=1 : This will enable the system.prop value for sleep.earlysuspend=1 , and on some machines, it enables the proper sleep state. acpi_sleep=s3_bios,s3_mode : Sometimes needed for older machines to enter sleep mode properly SETUPWIZARD=0 : This command will skip SetupWizard on boot. (Only needs to be run once!) AUTO_LOAD=old : This will load android-x86 variants using the old modprobe method to init devices. We sometimes use this to debug devices not starting. DEBUG=1 & DEBUG=2 : These enable verbose console debugging, giving another command shell after loading kernel modules, but before Android init vga=xxx & video= : These are the common video modes that you can boot into if it doesn't pick the best choice automagically. You can also use video= as resolution parameters: video=LVDS-1:d video=1366x800 . Learn more from our own Henri Koivuneva! HWACCELL=1 : This will disable graphics hardware acceleration, enabling rendering through Swiftshader. (Must use this if running headless) buildvariant=eng, user, userdebug : This is the commandline parameter to run the current build as eng , userdebug , or user DPI=xxx : This will manually set the DPI on init. Use this if things are too big/small for you. fbcon=variablename : This is to configure framebuffer to use various options. Usually used to help fix video settings, etc. Even default rotation on some Atom tablets. Example: video=efifb fbcon=rotate:1 VULKAN=1 : Required for Vulkan-supported chipsets. This enables hwcomposer to work right with screenshots and other things. As an example, here are a few of the boot options used in testing: menuentry 'Bliss-x86 Test-Oreo' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng quiet sleep.earlysuspend=2 DATA= initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo AUTO_LOAD=old' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng quiet DATA= AUTO_LOAD=old initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo - SETUP_WIZARD=0' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive buildvariant=eng SETUPWIZARD=0 quiet DATA= initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo - debug=1' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng SETUPWIZARD=0 quiet DATA= DEBUG=1 initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo - debug=2' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng SETUPWIZARD=0 quiet DATA= DEBUG=2 initrd /AndroidOS/initrd.img }","title":"grub2 kernel parameters and options"},{"location":"BlissRoms/","text":"Index New to building? Start here with the Build Guide. Want to build more efficiently? Find out some helpful optimization tips.","title":"Index"},{"location":"BlissRoms/#index","text":"New to building? Start here with the Build Guide. Want to build more efficiently? Find out some helpful optimization tips.","title":"Index"},{"location":"BlissRoms/build-guide/","text":"Build Guide Updated for Pie (p9.0) Introduction This is the official guide to build BlissRoms for your device. In this guide, we will only cover official devices with actual maintainers. We will not delve into porting devices. The golden rule to building is patience. If something breaks, wait for your maintainer to fix it, send a polite message to your maintainer, or better yet, try and fix it yourself. Then you can make a merge request and contribute! Let\u2019s get started. Preparation To get started, you need a computer with Ubuntu 18.04 (LTS), at least 200GB space of HDD, and at least 8GB RAM. A decent CPU (or CPUs if you have a server motherboard) is recommended. Other distros can work but is not officially supported in this guide. Underpowered machines may crash during compilation. If that happens, you may try and restart the build as most crashes are caused by lack of memory. If your storage space has run out, then you will need to build on a different hard drive. Install the JDK Install OpenJDK: sudo apt install openjdk-8-jdk Install build tools To install the required build tools, run the following command: sudo apt install git gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev lib32z1-dev ccache libgl1-mesa-dev libxml2 libxml2-utils xsltproc unzip squashfs-tools python python-mako libssl-dev ninja-build lunzip syslinux syslinux-utils gettext genisoimage bc xorriso liblz4-tool libncurses5-dev libsdl1.2-dev libwxgtk3.0-dev lzop maven pngcrush schedtool lib32readline-dev Install source code tools Now we need to get the source code via a program named repo , made by Google. The primary function of repo is to read a manifest file located in BlissRoms's GitHub organization, and find what repositories you need to actually build Android. Create a ~/bin directory for repo : mkdir -p ~/bin The -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 : curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo Make repo executable: chmod a+x ~/bin/repo And add it to PATH: nano .bashrc Scroll to the end of the file and type these lines: # Export ~/bin export PATH=~/bin:$PATH Ctrl-O and enter to save, then Ctrl-X to exit nano. Now either logout and login again (or reboot), or source the file: source .bashrc Which can be shortened to: . .bashrc What is 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! But why do you need to run it after modifying a file? Well, 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! What if I need repo globally? If you need the 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: curl https://storage.googleapis.com/git-repo-downloads/repo > ~/repo sudo mv ~/repo /usr/bin/ chmod a+x /usr/bin/repo repo will now work anywhere, without any .bashrc modifications. However, these steps aren\u2019t recommended as repo might become a security risk if a vulnerability is found. Now we\u2019re ready to download the source code. Download Create a directory for the source: mkdir -p ~/bliss/p9.0 cd ~/bliss/p9.0 Before we download, we need to tell repo and git who we are. Run the following commands, substituting your information: git config --global user.email \u201crandy.mcrandyface@hotmail.net\u201d git config --global user.name \u201cRandy McRandyface\u201d Now, we\u2019re ready to initialize. We need to tell repo which manifest to read: repo init -u https://github.com/BlissRoms/platform_manifest.git -b p9.0 -b is for the branch, and we\u2019re on p9.0 , Android Pie. It\u2019ll take a couple of seconds. You may need to type y for the color prompt. Then sync the source: repo sync -j24 -c -j is for threads. Typically, your CPU core count is your thread count, unless you\u2019re 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: repo sync -j4 -c -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\u2019t want the entire history to be downloaded. This is used by default unless specified otherwise. I still don't know how much CPU threads I have. How do I check? Run nproc . The output should be something like this: rwaterspf1@test:~$ nproc 24 This means that there are 24 threads in your machine. repo will start downloading all the code. That\u2019s going to be slow, even on a fiber network. Expect downloads to take more than a couple hours. Build Set up the build environment: . build/envsetup.sh This is the initialization file we talked about earlier up top. This \"initializes\" the environment, and imports a bunch of useful build commands required to build your device. Again, you need to remember to source this file every time you log out and log back in, or launch a new bash /Terminal instance. Define what device you\u2019re going to build. For example, the Nexus 5X, has a codename of bullhead . You can check your specific device's codename on GitHub or on Google. Execute: breakfast bullhead What does this do? breakfast searches repositories for your device \"tree\", which contains all the details needed to make the build suitable for your device. CPU, kernel info, device screen size, whether the board has Bluetooth, NFC, what frequencies the build needs for Wi-Fi, and a bunch of other things. breakfast will automatically search in the BlissRoms-Devices GitHub repository, and grab your device tree for you. Okay, so we have the device tree set up. Feel free to browse around the source code to see what changed. You should see folders added to device/ , kernel/ and vendor/ . A shortcut: croot will dump you back in the root of the source code tree. So if you\u2019ve been going through folders and don\u2019t have any idea where you are, you can use the above command. This command, however, requires you to have source d build/envsetup.sh earlier. We're ready to build, but before we teach you the easy command to execute a build, we will first try the manual method. To set up the current terminal environment for building your particular device, execute: lunch bliss_bullhead-userdebug Let's break down the command. 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. bliss_ is the ROM that we are building. As convention, all devices will have this prefix. bullhead is the specific device we are building - in this case, the Nexus 5X. 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. My device isn't booting, and userdebug won't print any adb logcat s. What gives? There is a third build variant called 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! All set? Let's start the building process. Run: mka blissify And the build should start. The build process will take a long time. Prepare to wait a few hours, even on a decent machine. Why mka and not make ? make only runs with 1 thread. mka is properly aliased to use all of your threads by checking nproc . If you want to customize your thread count (maybe you're building with a fan-screaming laptop in a quiet coffee shop), use make -j# , replacing the hash with the number of threads (example of make -j4 ). I get an error about no blissify targets to build against, what's wrong? If you are building other ROMs, it is usually make bacon . For BlissRoms, we chose the build target of blissify . If that doesn't work, sometimes there is a bug, or the ROM developers do not implement a bacon target to build against. In this case, you will need to find what name they use to initialize a full build of the ROM. Conventionally, it is supposed to be bacon , but some ROM developers change this name inadvertently, or actually have a bug that causes the build target to never be found. If you cannot locate the build target, ask the developers of the ROM. Alternatively, you can try poking around in build/make/core/Makefile to see what the build target name is. But this is out of the scope of this article as you're not supposed to be building other ROMs (that's not what this tutorial is for, sorry!) All right, but that's annoying. You had to type three commands to build it all. What about running one command? blissify bullhead But what is blissify ? It is a compact form of these commands: breakfast bullhead lunch bliss_bullhead-userdebug make blissify Sounds great, right? Once you have run the command, jump over to the next section. After building There are two outcomes to a build - either it fails and you get a red error message from 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. If you face the latter, congratulations! You've successfully built BlissRoms for your device. Grab the artifacts for your device: cd out/target/product/bullhead/ In here, you\u2019ll find a .zip that goes along the lines of Bliss-v11.9-Stable-bullhead-UNOFFICIAL-20190531.zip . Install TWRP, flash the build to your device, and enjoy! Troubleshooting If your build failed, there are a couple things you can try. Try a fresh 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. Make sure your dependencies are installed correctly. Error messages help out a lot here! Often it will say shared/linked library not found or something along those lines. Make sure you sourced 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 sync ed do this again. Make sure you\u2019re at the root of the build tree. Again, to quickly jump there, use croot . Make sure you ran breakfast correctly and it did not error out. Missing device files will prevent successful builds. Make sure your computer itself isn\u2019t faulty. HDDs usually die first, followed by RAM. SSDs rarely die but failure is not unheard of. In extremely rare cases, your CPU may have a defect. If you're unsure, run a stress test using a program like Prime95. If something goes wrong and you've tried everything above, first use Google to look up your error! Most of the errors you encounter is due to misconfiguration and wrong commands entered. More often than not, Google will have the answer you are looking for. If you're still stuck and nothing fixes the problem, then ask us via our Telegram Build Support chat. Conclusion Building a ROM is very hard and tedious and the results are very rewarding! If you managed to follow along, congratulations! After you finish building, you can try out the Git Started guide. Make changes, commit, and send them off to our Gerrit for review! Or better yet, download experimental commits not ready for the mainline repositories and review them! Again, ROM building is a fun project you can work with. I hope this guide was a lot of fun to run through! -- Eric Park (ideaman924) Looking for the next tutorial? Check out some tips to optimize your build experience.","title":"Build Guide"},{"location":"BlissRoms/build-guide/#build-guide","text":"","title":"Build Guide"},{"location":"BlissRoms/build-guide/#updated-for-pie-p90","text":"","title":"Updated for Pie (p9.0)"},{"location":"BlissRoms/build-guide/#introduction","text":"This is the official guide to build BlissRoms for your device. In this guide, we will only cover official devices with actual maintainers. We will not delve into porting devices. The golden rule to building is patience. If something breaks, wait for your maintainer to fix it, send a polite message to your maintainer, or better yet, try and fix it yourself. Then you can make a merge request and contribute! Let\u2019s get started.","title":"Introduction"},{"location":"BlissRoms/build-guide/#preparation","text":"To get started, you need a computer with Ubuntu 18.04 (LTS), at least 200GB space of HDD, and at least 8GB RAM. A decent CPU (or CPUs if you have a server motherboard) is recommended. Other distros can work but is not officially supported in this guide. Underpowered machines may crash during compilation. If that happens, you may try and restart the build as most crashes are caused by lack of memory. If your storage space has run out, then you will need to build on a different hard drive.","title":"Preparation"},{"location":"BlissRoms/build-guide/#install-the-jdk","text":"Install OpenJDK: sudo apt install openjdk-8-jdk","title":"Install the JDK"},{"location":"BlissRoms/build-guide/#install-build-tools","text":"To install the required build tools, run the following command: sudo apt install git gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev lib32z1-dev ccache libgl1-mesa-dev libxml2 libxml2-utils xsltproc unzip squashfs-tools python python-mako libssl-dev ninja-build lunzip syslinux syslinux-utils gettext genisoimage bc xorriso liblz4-tool libncurses5-dev libsdl1.2-dev libwxgtk3.0-dev lzop maven pngcrush schedtool lib32readline-dev","title":"Install build tools"},{"location":"BlissRoms/build-guide/#install-source-code-tools","text":"Now we need to get the source code via a program named repo , made by Google. The primary function of repo is to read a manifest file located in BlissRoms's GitHub organization, and find what repositories you need to actually build Android. Create a ~/bin directory for repo : mkdir -p ~/bin The -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 : curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo Make repo executable: chmod a+x ~/bin/repo And add it to PATH: nano .bashrc Scroll to the end of the file and type these lines: # Export ~/bin export PATH=~/bin:$PATH Ctrl-O and enter to save, then Ctrl-X to exit nano. Now either logout and login again (or reboot), or source the file: source .bashrc Which can be shortened to: . .bashrc","title":"Install source code tools"},{"location":"BlissRoms/build-guide/#what-is-source","text":"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! But why do you need to run it after modifying a file? Well, 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!","title":"What is source?"},{"location":"BlissRoms/build-guide/#what-if-i-need-repo-globally","text":"If you need the 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: curl https://storage.googleapis.com/git-repo-downloads/repo > ~/repo sudo mv ~/repo /usr/bin/ chmod a+x /usr/bin/repo repo will now work anywhere, without any .bashrc modifications. However, these steps aren\u2019t recommended as repo might become a security risk if a vulnerability is found. Now we\u2019re ready to download the source code.","title":"What if I need repo globally?"},{"location":"BlissRoms/build-guide/#download","text":"Create a directory for the source: mkdir -p ~/bliss/p9.0 cd ~/bliss/p9.0 Before we download, we need to tell repo and git who we are. Run the following commands, substituting your information: git config --global user.email \u201crandy.mcrandyface@hotmail.net\u201d git config --global user.name \u201cRandy McRandyface\u201d Now, we\u2019re ready to initialize. We need to tell repo which manifest to read: repo init -u https://github.com/BlissRoms/platform_manifest.git -b p9.0 -b is for the branch, and we\u2019re on p9.0 , Android Pie. It\u2019ll take a couple of seconds. You may need to type y for the color prompt. Then sync the source: repo sync -j24 -c -j is for threads. Typically, your CPU core count is your thread count, unless you\u2019re 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: repo sync -j4 -c -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\u2019t want the entire history to be downloaded. This is used by default unless specified otherwise.","title":"Download"},{"location":"BlissRoms/build-guide/#i-still-dont-know-how-much-cpu-threads-i-have-how-do-i-check","text":"Run nproc . The output should be something like this: rwaterspf1@test:~$ nproc 24 This means that there are 24 threads in your machine. repo will start downloading all the code. That\u2019s going to be slow, even on a fiber network. Expect downloads to take more than a couple hours.","title":"I still don't know how much CPU threads I have. How do I check?"},{"location":"BlissRoms/build-guide/#build","text":"Set up the build environment: . build/envsetup.sh This is the initialization file we talked about earlier up top. This \"initializes\" the environment, and imports a bunch of useful build commands required to build your device. Again, you need to remember to source this file every time you log out and log back in, or launch a new bash /Terminal instance. Define what device you\u2019re going to build. For example, the Nexus 5X, has a codename of bullhead . You can check your specific device's codename on GitHub or on Google. Execute: breakfast bullhead What does this do? breakfast searches repositories for your device \"tree\", which contains all the details needed to make the build suitable for your device. CPU, kernel info, device screen size, whether the board has Bluetooth, NFC, what frequencies the build needs for Wi-Fi, and a bunch of other things. breakfast will automatically search in the BlissRoms-Devices GitHub repository, and grab your device tree for you. Okay, so we have the device tree set up. Feel free to browse around the source code to see what changed. You should see folders added to device/ , kernel/ and vendor/ . A shortcut: croot will dump you back in the root of the source code tree. So if you\u2019ve been going through folders and don\u2019t have any idea where you are, you can use the above command. This command, however, requires you to have source d build/envsetup.sh earlier. We're ready to build, but before we teach you the easy command to execute a build, we will first try the manual method. To set up the current terminal environment for building your particular device, execute: lunch bliss_bullhead-userdebug Let's break down the command. 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. bliss_ is the ROM that we are building. As convention, all devices will have this prefix. bullhead is the specific device we are building - in this case, the Nexus 5X. 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.","title":"Build"},{"location":"BlissRoms/build-guide/#my-device-isnt-booting-and-userdebug-wont-print-any-adb-logcats-what-gives","text":"There is a third build variant called 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! All set? Let's start the building process. Run: mka blissify And the build should start. The build process will take a long time. Prepare to wait a few hours, even on a decent machine.","title":"My device isn't booting, and userdebug won't print any adb logcats. What gives?"},{"location":"BlissRoms/build-guide/#why-mka-and-not-make","text":"make only runs with 1 thread. mka is properly aliased to use all of your threads by checking nproc . If you want to customize your thread count (maybe you're building with a fan-screaming laptop in a quiet coffee shop), use make -j# , replacing the hash with the number of threads (example of make -j4 ).","title":"Why mka and not make?"},{"location":"BlissRoms/build-guide/#i-get-an-error-about-no-blissify-targets-to-build-against-whats-wrong","text":"If you are building other ROMs, it is usually make bacon . For BlissRoms, we chose the build target of blissify . If that doesn't work, sometimes there is a bug, or the ROM developers do not implement a bacon target to build against. In this case, you will need to find what name they use to initialize a full build of the ROM. Conventionally, it is supposed to be bacon , but some ROM developers change this name inadvertently, or actually have a bug that causes the build target to never be found. If you cannot locate the build target, ask the developers of the ROM. Alternatively, you can try poking around in build/make/core/Makefile to see what the build target name is. But this is out of the scope of this article as you're not supposed to be building other ROMs (that's not what this tutorial is for, sorry!) All right, but that's annoying. You had to type three commands to build it all. What about running one command? blissify bullhead But what is blissify ? It is a compact form of these commands: breakfast bullhead lunch bliss_bullhead-userdebug make blissify Sounds great, right? Once you have run the command, jump over to the next section.","title":"I get an error about no blissify targets to build against, what's wrong?"},{"location":"BlissRoms/build-guide/#after-building","text":"There are two outcomes to a build - either it fails and you get a red error message from 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. If you face the latter, congratulations! You've successfully built BlissRoms for your device. Grab the artifacts for your device: cd out/target/product/bullhead/ In here, you\u2019ll find a .zip that goes along the lines of Bliss-v11.9-Stable-bullhead-UNOFFICIAL-20190531.zip . Install TWRP, flash the build to your device, and enjoy!","title":"After building"},{"location":"BlissRoms/build-guide/#troubleshooting","text":"If your build failed, there are a couple things you can try. Try a fresh 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. Make sure your dependencies are installed correctly. Error messages help out a lot here! Often it will say shared/linked library not found or something along those lines. Make sure you sourced 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 sync ed do this again. Make sure you\u2019re at the root of the build tree. Again, to quickly jump there, use croot . Make sure you ran breakfast correctly and it did not error out. Missing device files will prevent successful builds. Make sure your computer itself isn\u2019t faulty. HDDs usually die first, followed by RAM. SSDs rarely die but failure is not unheard of. In extremely rare cases, your CPU may have a defect. If you're unsure, run a stress test using a program like Prime95. If something goes wrong and you've tried everything above, first use Google to look up your error! Most of the errors you encounter is due to misconfiguration and wrong commands entered. More often than not, Google will have the answer you are looking for. If you're still stuck and nothing fixes the problem, then ask us via our Telegram Build Support chat.","title":"Troubleshooting"},{"location":"BlissRoms/build-guide/#conclusion","text":"Building a ROM is very hard and tedious and the results are very rewarding! If you managed to follow along, congratulations! After you finish building, you can try out the Git Started guide. Make changes, commit, and send them off to our Gerrit for review! Or better yet, download experimental commits not ready for the mainline repositories and review them! Again, ROM building is a fun project you can work with. I hope this guide was a lot of fun to run through! -- Eric Park (ideaman924)","title":"Conclusion"},{"location":"BlissRoms/build-guide/#looking-for-the-next-tutorial","text":"Check out some tips to optimize your build experience.","title":"Looking for the next tutorial?"},{"location":"BlissRoms/build-tips/","text":"Build Tips Here's a collective list of things you can try to improve your builds. Have fun! repo optimization tips Threads By default, repo only utilizes four threads (or whatever the ROM manifest declares.) If you have a stronger machine with more threads, you can increase this number. So, for example, if you have 24 threads, you would type: repo sync -j24 Current history only This should be set by default in your ROM manifest, but just in case, you can tell repo to only fetch recent changes. This allows for smaller downloads, which makes the sync quicker. Add the flag: repo sync -c Force Warning! Dangerous option. Read before proceeding! Sometimes, your local history may go out of sync with remote repositories. This wouldn't be a problem if repo can handle it gracefully, but it doesn't and gives off a sync error. If you do not commit much, it may be worthwhile to add the force flags. Be warned though, any changes you make to the repositories WILL BE DELETED. Later down the line, if you commit a lot, you may want to remove this flag. To force sync, add the flag: repo sync -f --force-sync Minimal fetch To disable syncing clone bundles and tags, use: repo sync --no-clone-bundle --no-tags More documentation on this required, but for most developers these flags will be OK to use. This makes the sync faster as there is less information to sync over. Putting it all together repo sync -c -f -j24 --force-sync --no-clone-bundle --no-tags That's quite long! How about we add this to our .bashrc as a alias? That way, we only have to type one phrase for bash to automatically type that out for us. Open up ~/.bashrc and add these lines: # Alias to sync alias reposync='repo sync -c -f -j24 --force-sync --no-clone-bundle --no-tags' This way, next time you want to sync, just type reposync and bash will substitute the command for you. Easy! Just don't forget to source ~/.bashrc otherwise bash will not know of this new alias. Reset tree Warning! Very destructive tip. Do not use if you don't know what you are doing! While messing around with device specific folders, you may break something and the build process might not work. Or, you may have multiple devices synced and you want to delete it all and start over. However, you might have limited bandwidth, and might not want to download the source over again. Add this function to your ~/.bashrc : # Script to clean the source function resettree() { rm -rf device kernel vendor out .repo/local_manifests reposync } Let's go over what this does, word by word: rm -rf : Destructive command to erase all of the following: device folder: Holds all device-related files kernel folder: Holds all kernel-related files for devices vendor folder: Holds all vendor-related files for devices AND ROM-specific vendor customizations out folder: Stores artifacts of builds .repo/local_manifests folder: Stores \"manifest\" information of devices to sync. reposync : Executes the repo sync alias we made earlier. The last line is important, because by deleting the vendor folder, we also delete some crucial files for building Bliss. To fix that, we rerun a sync. Note that because we did not delete any other folders, syncing and updating files only take a fraction of a time compared to starting from scratch. To use this, after copying, don't forget to source ~/.bashrc . Then, run resettree at the base folder of the source code. Once you're done, don't forget to initialize a new device using breakfast <devicename> . GitHub cherry-pick Thanks to @blueyes for providing the script! Copy the following into your ~/.bashrc : function gcp() { COMMIT=`echo \"$1\" | cut -d/ -f6` GH=`echo \"$1\" | cut -d/ -f1-3` if [ \"$COMMIT\" != \"commit\" ]; then echo -e \"Please use a commit URL.\" elif [ \"$GH\" != \"https://github.com\" ]; then echo -e \"Please use an https://github.com/ URL.\" else PROJECT=`echo \"$1\" | cut -d/ -f1-5` git fetch $PROJECT CP=`echo \"$1\" | cut -d/ -f7` git cherry-pick $CP fi } To use this, source ~/.bashrc and then run gcp <GitHub commit URL here> . Make and go inside This is a quick way to create and go inside a folder. Once again, copy this to your ~/.bashrc : function mkcdir () { mkdir -p -- \"$1\" && cd -P -- \"$1\" } Don't forget to source , and run mkcdir <directory name> .","title":"Build Tips"},{"location":"BlissRoms/build-tips/#build-tips","text":"Here's a collective list of things you can try to improve your builds. Have fun!","title":"Build Tips"},{"location":"BlissRoms/build-tips/#repo-optimization-tips","text":"","title":"repo optimization tips"},{"location":"BlissRoms/build-tips/#threads","text":"By default, repo only utilizes four threads (or whatever the ROM manifest declares.) If you have a stronger machine with more threads, you can increase this number. So, for example, if you have 24 threads, you would type: repo sync -j24","title":"Threads"},{"location":"BlissRoms/build-tips/#current-history-only","text":"This should be set by default in your ROM manifest, but just in case, you can tell repo to only fetch recent changes. This allows for smaller downloads, which makes the sync quicker. Add the flag: repo sync -c","title":"Current history only"},{"location":"BlissRoms/build-tips/#force","text":"Warning! Dangerous option. Read before proceeding! Sometimes, your local history may go out of sync with remote repositories. This wouldn't be a problem if repo can handle it gracefully, but it doesn't and gives off a sync error. If you do not commit much, it may be worthwhile to add the force flags. Be warned though, any changes you make to the repositories WILL BE DELETED. Later down the line, if you commit a lot, you may want to remove this flag. To force sync, add the flag: repo sync -f --force-sync","title":"Force"},{"location":"BlissRoms/build-tips/#minimal-fetch","text":"To disable syncing clone bundles and tags, use: repo sync --no-clone-bundle --no-tags More documentation on this required, but for most developers these flags will be OK to use. This makes the sync faster as there is less information to sync over.","title":"Minimal fetch"},{"location":"BlissRoms/build-tips/#putting-it-all-together","text":"repo sync -c -f -j24 --force-sync --no-clone-bundle --no-tags That's quite long! How about we add this to our .bashrc as a alias? That way, we only have to type one phrase for bash to automatically type that out for us. Open up ~/.bashrc and add these lines: # Alias to sync alias reposync='repo sync -c -f -j24 --force-sync --no-clone-bundle --no-tags' This way, next time you want to sync, just type reposync and bash will substitute the command for you. Easy! Just don't forget to source ~/.bashrc otherwise bash will not know of this new alias.","title":"Putting it all together"},{"location":"BlissRoms/build-tips/#reset-tree","text":"Warning! Very destructive tip. Do not use if you don't know what you are doing! While messing around with device specific folders, you may break something and the build process might not work. Or, you may have multiple devices synced and you want to delete it all and start over. However, you might have limited bandwidth, and might not want to download the source over again. Add this function to your ~/.bashrc : # Script to clean the source function resettree() { rm -rf device kernel vendor out .repo/local_manifests reposync } Let's go over what this does, word by word: rm -rf : Destructive command to erase all of the following: device folder: Holds all device-related files kernel folder: Holds all kernel-related files for devices vendor folder: Holds all vendor-related files for devices AND ROM-specific vendor customizations out folder: Stores artifacts of builds .repo/local_manifests folder: Stores \"manifest\" information of devices to sync. reposync : Executes the repo sync alias we made earlier. The last line is important, because by deleting the vendor folder, we also delete some crucial files for building Bliss. To fix that, we rerun a sync. Note that because we did not delete any other folders, syncing and updating files only take a fraction of a time compared to starting from scratch. To use this, after copying, don't forget to source ~/.bashrc . Then, run resettree at the base folder of the source code. Once you're done, don't forget to initialize a new device using breakfast <devicename> .","title":"Reset tree"},{"location":"BlissRoms/build-tips/#github-cherry-pick","text":"Thanks to @blueyes for providing the script! Copy the following into your ~/.bashrc : function gcp() { COMMIT=`echo \"$1\" | cut -d/ -f6` GH=`echo \"$1\" | cut -d/ -f1-3` if [ \"$COMMIT\" != \"commit\" ]; then echo -e \"Please use a commit URL.\" elif [ \"$GH\" != \"https://github.com\" ]; then echo -e \"Please use an https://github.com/ URL.\" else PROJECT=`echo \"$1\" | cut -d/ -f1-5` git fetch $PROJECT CP=`echo \"$1\" | cut -d/ -f7` git cherry-pick $CP fi } To use this, source ~/.bashrc and then run gcp <GitHub commit URL here> .","title":"GitHub cherry-pick"},{"location":"BlissRoms/build-tips/#make-and-go-inside","text":"This is a quick way to create and go inside a folder. Once again, copy this to your ~/.bashrc : function mkcdir () { mkdir -p -- \"$1\" && cd -P -- \"$1\" } Don't forget to source , and run mkcdir <directory name> .","title":"Make and go inside"},{"location":"common/","text":"Index Before you start working on open source projects, learn how to maintain proper authorship. New to committing? Start with this Git and Gerrit guide! Learn how to mass-review commits with a child's toy.","title":"Index"},{"location":"common/#index","text":"Before you start working on open source projects, learn how to maintain proper authorship. New to committing? Start with this Git and Gerrit guide! Learn how to mass-review commits with a child's toy.","title":"Index"},{"location":"common/git-started/","text":"Git Started Foreword This guide helps people learn git commands and how to get the features you want into your favorite ROM and make your own builds. This will help new people get started and will be a great refresher for veteran git users and has instructions for Arch Linux users as well. The document will be ever-changing and evolving because even we will be learning new material and will be putting it in here. Installation In order to use git review we need it installed on our local machine. For Ubuntu we use the package manager to install it. sudo apt-get install git-review Or for Arch based installs, use: sudo pacman -S git-review Get the terminal set up First, let's make sure our local git and Gerrit have the same email address associated. cd cat .gitconfig This command should show something along those lines: [user] email = you@youremail.com name = Your Name Edit any incorrect details. Your email and name is used to sign off commits, various changes, etc, so it is important that they are the same ones found on Gerrit and GitHub. Next we will create a SSH key named \u201cgerrit\u201d to communicate with the Gerrit server. ssh-keygen -t rsa -C you@youremail.com -f ~/.ssh/gerrit Again, note the email address must be the same here, your .gitconfig , and on Gerrit. Register at Gerrit Open your favorite browser and go to http://review.blissroms.com . You will see a \u201cSign In\u201d button on the top right - click that and register with GitHub. Please note that you will need to use the same email address that you registered with GitHub for your terminal interactions with Gerrit. Now we need to add our SSH key to Gerrit. Your name will be on the top right of the page. Click your name and you should see \u201cSettings\u201d. Once there click on the link \u201cSSH Public Keys\u201d on the left sidebar. Once it loads, click \"Add Key\" on the right. Let's copy the key from the terminal and paste it into the browser. cat ~/.ssh/gerrit.pub This should show something like: ssh-rsa AAAABBBBBBBBBBCCCCCCCCCCCCCCCCCCDjhl8768usdfsdfuhf/BlahBlahBlah/ThIs+1s/A/fAk3+k3Y/Hdhs+PlCesTvQqfaqHTHwdzGhn2lKVt14WYvQEDKVM9JoE9e8xarNWYa0ZspB1MGn2RVJ3xRp0+Q/pA237uBCl62yTbVGtKQBZB6Q+7A54z795U+G2wCb1rAQnI5yn5q/pQ4NhB0BLml/QRmjn/S8PldEge9Hfdh4Ifdk4r9DKSiicf7IK56jklDHKkJDFkjh/3345L10sTyre3JOeZyvr5SJdyqMtmMv+uSGF28fgZ6/OEO/yBY/eYEI/XVRDaRRat8nGHGae0T4dx me@myemail.com Starting with the line beginning with ssh-rsa and ending with the email, paste that bit into the browser and click \u201cAdd\u201d. Gerrit shows an error about the key! Are you sure you used the correct key? Do not use the \"private\" key. The private key should be kept private as it is the key that allows you to authenticate yourself against servers like Gerrit. When you authenticate using your private key, the servers send out requests encrypted with your \"public\" key that only your \"private\" key can decrypt. This is the basis behind SSH authentication. So keep your private key safe, and try pasting the public key! Most public keys end with the characters .pub . Then, add the new SSH key to your local identity in terminal. eval `ssh-agent` This should print off a bunch of lines. We\u2019re doing this to launch the ssh-agent before adding the key. ssh-add ~/.ssh/gerrit This will result in something along the lines of: Identity added: /home/yourusername/.ssh/gerrit (/home/yourusername/.ssh/gerrit) If you don\u2019t get this, and get this instead: Could not open a connection to your authentication agent. Or this: Error connecting to agent: No such file or directory. This is because in recent versions of Ubuntu, you need to change how you launch ssh-agent . Run the command below, then try adding your SSH key again. eval \u201c$(ssh-agent)\u201d Now we should be ready to use git review . Reviewing Code Just cd to your source code directory and find the package you want to look at from Gerrit. I\u2019ll use frameworks/base as an example. # cd into source code directory cd ~/bliss/p9.0 # Find project to work on cd frameworks/base Let\u2019s setup the remote to Gerrit: git review -s This should create a gerrit remote. If you added a passphrase to your SSH key you will have to enter that. However, if this command outputs something like this: Could not connect to gerrit. Enter your gerrit username: And after you input your username, it shows something like this: Trying again with ssh://username@review.blissroms.com:29418/platform_frameworks_base.git <traceback object at 0x7f7f95ea9e18> We don't know where your gerrit is. Please manually create a remote named \"gerrit\" and try again. Could not connect to gerrit at ssh://username@review.blissroms.com:29418/platform_frameworks_base.git Traceback (most recent call last): File \"/usr/bin/git-review\", line 10, in <module> sys.exit(main()) File \"/usr/lib/python2.7/dist-packages/git_review/cmd.py\", line 1534, in main sys.exit(e.EXIT_CODE) AttributeError: 'GitReviewException' object has no attribute 'EXIT_CODE' Why does this happen? This is because the ssh-agent process got killed after prolonged use of the system, so you need to restart it. As a quick and dirty fix, run this again: eval \u201c$(ssh-agent)\u201d This should fix it. If not, then you need to go back to Chapter 1 and add your existing key. Don\u2019t make a new key, then you\u2019d need to add a new public key to the Bliss Gerrit. Now let\u2019s see if there are any changes we can review. git review -l This outputs: 2433 new-mm6.0 SystemUI: fix double tap power launching custom lockscreen icon 2432 new-mm6.0 SystemUI: remove extraneous debug log Found 2 items for review My output is blank (or different.) Why? This is because right now, there are no changes to be reviewed in frameworks/base (or there are different commits to be reviewed.) This is completely normal and to be expected, as we merge and submit new commits frequently. The guide will probably be out of sync with current changes by the time you are reading this. Now you have a list of commits sorted by change number with a description of what changes were made. We have a few choices of how to pick commits. Cherry-picking commits to current branch git review -x changenumber will cherry-pick that commit to the current branch you are in. A benefit of this is the next time you repo sync \u2013force-sync , it will discard the commits you picked. Cherry-picking commits to new branch git review -d changenumber will cherry-pick to a new branch based on the submitter\u2019s name and change ID. If you choose this route the change will be in its own branch and when you are done you can just delete that branch. Switched to a new branch review/yourusername/changenumber Now you can review the change. Follow these guidelines: Did the ROM build with the change incorporated? Did the added feature or fix work in the new build? Did the new commit break any other aspects of the build? After reviewing these guidelines, log into Gerrit via your web browser, and click on the commit you reviewed. Select the \u2018Reply\u2019 button on the top and choose your score. +1 if it works as intended, -1 if not. Be sure to leave comments on why you gave your score (such as \u201ccommit A does not show in 320 DPI\u201d, etc) Once you're done, return to the base directory ( croot ) to follow along with the next example! Submitting code Go to the directory of the package or app you want to make changes to. We will use frameworks/base as an example. cd frameworks/base Setup the remote to Gerrit if you haven\u2019t already: git review -s Next, make sure you are on the correct branch: git branch -t p9.0 BlissRoms/p9.0 This makes sure that your local branch follows the remote branch. -t stands for tracking. Now we need to checkout , to switch to that new branch we tracked. You usually do not need to do the above command, but it is a nice check to do if something is going south. git checkout p9.0 This should output: Changed to new branch p9.0 tracking upstream BlissRoms/p9.0 Now make your changes, cherry-picks, etc. and commit them. If you need a guide to do that, check out Picking from other sources . When you\u2019re done, come back here! Then all you have to do to send it to gerrit is: git review If you are submitting multiple commits it will ask if you really want to, just type \u201cyes\u201d at the prompt. Picking from other sources So you\u2019ve successfully learned how to commit and send it to Bliss Gerrit. But you need to find something to commit. Thankfully, there are lots of examples you can try out. You can check other teams\u2019 Gerrits and cherry-pick from them. For this demonstration, I\u2019m going to use LineageOS's Gerrit. Find the commit you want, and note down the commit ID. Now, we need to add LOS\u2019s repositories. If you\u2019re pulling over a commit, you must make sure that we track the repository by going to Bliss\u2019s Gerrit and checking in Projects > List. If the repository is not there, it usually means we aren\u2019t tracking it. git remote add los https://github.com/LineageOS/\u2026\u2026(your repo name) git remote fetch los lineage-16.0 We\u2019ve finished adding LOS\u2019s repositories. Now you need to grab the commit ID you copied earlier and paste it on the command underneath. git cherry-pick 9ff831 Replace 9ff831 with your own commit ID. If git complains about duplicate revisions, paste the full SHA1 hash instead of the shorthand git uses. Before pushing and submitting, we need to check if our commit was successfully committed. Type the bottom command: git log --oneline After you check that your commit is there, you can push q to quit. Then you can follow the instructions from Submitting code again. Conclusion Don\u2019t worry if you don\u2019t get it at once. It\u2019s a fairly long process of submitting and reviewing at Gerrit. Read the guide again and again and you\u2019ll start to remember commands without looking at this. I will continue with this as I learn more things, I hope this has helped someone. -- Vaughn (rwaterspf1) -- Eric Park (ideaman924) -- Jon West (electrikjesus)","title":"Git Started"},{"location":"common/git-started/#git-started","text":"","title":"Git Started"},{"location":"common/git-started/#foreword","text":"This guide helps people learn git commands and how to get the features you want into your favorite ROM and make your own builds. This will help new people get started and will be a great refresher for veteran git users and has instructions for Arch Linux users as well. The document will be ever-changing and evolving because even we will be learning new material and will be putting it in here.","title":"Foreword"},{"location":"common/git-started/#installation","text":"In order to use git review we need it installed on our local machine. For Ubuntu we use the package manager to install it. sudo apt-get install git-review Or for Arch based installs, use: sudo pacman -S git-review","title":"Installation"},{"location":"common/git-started/#get-the-terminal-set-up","text":"First, let's make sure our local git and Gerrit have the same email address associated. cd cat .gitconfig This command should show something along those lines: [user] email = you@youremail.com name = Your Name Edit any incorrect details. Your email and name is used to sign off commits, various changes, etc, so it is important that they are the same ones found on Gerrit and GitHub. Next we will create a SSH key named \u201cgerrit\u201d to communicate with the Gerrit server. ssh-keygen -t rsa -C you@youremail.com -f ~/.ssh/gerrit Again, note the email address must be the same here, your .gitconfig , and on Gerrit.","title":"Get the terminal set up"},{"location":"common/git-started/#register-at-gerrit","text":"Open your favorite browser and go to http://review.blissroms.com . You will see a \u201cSign In\u201d button on the top right - click that and register with GitHub. Please note that you will need to use the same email address that you registered with GitHub for your terminal interactions with Gerrit. Now we need to add our SSH key to Gerrit. Your name will be on the top right of the page. Click your name and you should see \u201cSettings\u201d. Once there click on the link \u201cSSH Public Keys\u201d on the left sidebar. Once it loads, click \"Add Key\" on the right. Let's copy the key from the terminal and paste it into the browser. cat ~/.ssh/gerrit.pub This should show something like: ssh-rsa AAAABBBBBBBBBBCCCCCCCCCCCCCCCCCCDjhl8768usdfsdfuhf/BlahBlahBlah/ThIs+1s/A/fAk3+k3Y/Hdhs+PlCesTvQqfaqHTHwdzGhn2lKVt14WYvQEDKVM9JoE9e8xarNWYa0ZspB1MGn2RVJ3xRp0+Q/pA237uBCl62yTbVGtKQBZB6Q+7A54z795U+G2wCb1rAQnI5yn5q/pQ4NhB0BLml/QRmjn/S8PldEge9Hfdh4Ifdk4r9DKSiicf7IK56jklDHKkJDFkjh/3345L10sTyre3JOeZyvr5SJdyqMtmMv+uSGF28fgZ6/OEO/yBY/eYEI/XVRDaRRat8nGHGae0T4dx me@myemail.com Starting with the line beginning with ssh-rsa and ending with the email, paste that bit into the browser and click \u201cAdd\u201d.","title":"Register at Gerrit"},{"location":"common/git-started/#gerrit-shows-an-error-about-the-key","text":"Are you sure you used the correct key? Do not use the \"private\" key. The private key should be kept private as it is the key that allows you to authenticate yourself against servers like Gerrit. When you authenticate using your private key, the servers send out requests encrypted with your \"public\" key that only your \"private\" key can decrypt. This is the basis behind SSH authentication. So keep your private key safe, and try pasting the public key! Most public keys end with the characters .pub . Then, add the new SSH key to your local identity in terminal. eval `ssh-agent` This should print off a bunch of lines. We\u2019re doing this to launch the ssh-agent before adding the key. ssh-add ~/.ssh/gerrit This will result in something along the lines of: Identity added: /home/yourusername/.ssh/gerrit (/home/yourusername/.ssh/gerrit) If you don\u2019t get this, and get this instead: Could not open a connection to your authentication agent. Or this: Error connecting to agent: No such file or directory. This is because in recent versions of Ubuntu, you need to change how you launch ssh-agent . Run the command below, then try adding your SSH key again. eval \u201c$(ssh-agent)\u201d Now we should be ready to use git review .","title":"Gerrit shows an error about the key!"},{"location":"common/git-started/#reviewing-code","text":"Just cd to your source code directory and find the package you want to look at from Gerrit. I\u2019ll use frameworks/base as an example. # cd into source code directory cd ~/bliss/p9.0 # Find project to work on cd frameworks/base Let\u2019s setup the remote to Gerrit: git review -s This should create a gerrit remote. If you added a passphrase to your SSH key you will have to enter that. However, if this command outputs something like this: Could not connect to gerrit. Enter your gerrit username: And after you input your username, it shows something like this: Trying again with ssh://username@review.blissroms.com:29418/platform_frameworks_base.git <traceback object at 0x7f7f95ea9e18> We don't know where your gerrit is. Please manually create a remote named \"gerrit\" and try again. Could not connect to gerrit at ssh://username@review.blissroms.com:29418/platform_frameworks_base.git Traceback (most recent call last): File \"/usr/bin/git-review\", line 10, in <module> sys.exit(main()) File \"/usr/lib/python2.7/dist-packages/git_review/cmd.py\", line 1534, in main sys.exit(e.EXIT_CODE) AttributeError: 'GitReviewException' object has no attribute 'EXIT_CODE' Why does this happen? This is because the ssh-agent process got killed after prolonged use of the system, so you need to restart it. As a quick and dirty fix, run this again: eval \u201c$(ssh-agent)\u201d This should fix it. If not, then you need to go back to Chapter 1 and add your existing key. Don\u2019t make a new key, then you\u2019d need to add a new public key to the Bliss Gerrit. Now let\u2019s see if there are any changes we can review. git review -l This outputs: 2433 new-mm6.0 SystemUI: fix double tap power launching custom lockscreen icon 2432 new-mm6.0 SystemUI: remove extraneous debug log Found 2 items for review","title":"Reviewing Code"},{"location":"common/git-started/#my-output-is-blank-or-different-why","text":"This is because right now, there are no changes to be reviewed in frameworks/base (or there are different commits to be reviewed.) This is completely normal and to be expected, as we merge and submit new commits frequently. The guide will probably be out of sync with current changes by the time you are reading this. Now you have a list of commits sorted by change number with a description of what changes were made. We have a few choices of how to pick commits.","title":"My output is blank (or different.) Why?"},{"location":"common/git-started/#cherry-picking-commits-to-current-branch","text":"git review -x changenumber will cherry-pick that commit to the current branch you are in. A benefit of this is the next time you repo sync \u2013force-sync , it will discard the commits you picked.","title":"Cherry-picking commits to current branch"},{"location":"common/git-started/#cherry-picking-commits-to-new-branch","text":"git review -d changenumber will cherry-pick to a new branch based on the submitter\u2019s name and change ID. If you choose this route the change will be in its own branch and when you are done you can just delete that branch. Switched to a new branch review/yourusername/changenumber Now you can review the change. Follow these guidelines: Did the ROM build with the change incorporated? Did the added feature or fix work in the new build? Did the new commit break any other aspects of the build? After reviewing these guidelines, log into Gerrit via your web browser, and click on the commit you reviewed. Select the \u2018Reply\u2019 button on the top and choose your score. +1 if it works as intended, -1 if not. Be sure to leave comments on why you gave your score (such as \u201ccommit A does not show in 320 DPI\u201d, etc) Once you're done, return to the base directory ( croot ) to follow along with the next example!","title":"Cherry-picking commits to new branch"},{"location":"common/git-started/#submitting-code","text":"Go to the directory of the package or app you want to make changes to. We will use frameworks/base as an example. cd frameworks/base Setup the remote to Gerrit if you haven\u2019t already: git review -s Next, make sure you are on the correct branch: git branch -t p9.0 BlissRoms/p9.0 This makes sure that your local branch follows the remote branch. -t stands for tracking. Now we need to checkout , to switch to that new branch we tracked. You usually do not need to do the above command, but it is a nice check to do if something is going south. git checkout p9.0 This should output: Changed to new branch p9.0 tracking upstream BlissRoms/p9.0 Now make your changes, cherry-picks, etc. and commit them. If you need a guide to do that, check out Picking from other sources . When you\u2019re done, come back here! Then all you have to do to send it to gerrit is: git review If you are submitting multiple commits it will ask if you really want to, just type \u201cyes\u201d at the prompt.","title":"Submitting code"},{"location":"common/git-started/#picking-from-other-sources","text":"So you\u2019ve successfully learned how to commit and send it to Bliss Gerrit. But you need to find something to commit. Thankfully, there are lots of examples you can try out. You can check other teams\u2019 Gerrits and cherry-pick from them. For this demonstration, I\u2019m going to use LineageOS's Gerrit. Find the commit you want, and note down the commit ID. Now, we need to add LOS\u2019s repositories. If you\u2019re pulling over a commit, you must make sure that we track the repository by going to Bliss\u2019s Gerrit and checking in Projects > List. If the repository is not there, it usually means we aren\u2019t tracking it. git remote add los https://github.com/LineageOS/\u2026\u2026(your repo name) git remote fetch los lineage-16.0 We\u2019ve finished adding LOS\u2019s repositories. Now you need to grab the commit ID you copied earlier and paste it on the command underneath. git cherry-pick 9ff831 Replace 9ff831 with your own commit ID. If git complains about duplicate revisions, paste the full SHA1 hash instead of the shorthand git uses. Before pushing and submitting, we need to check if our commit was successfully committed. Type the bottom command: git log --oneline After you check that your commit is there, you can push q to quit. Then you can follow the instructions from Submitting code again.","title":"Picking from other sources"},{"location":"common/git-started/#conclusion","text":"Don\u2019t worry if you don\u2019t get it at once. It\u2019s a fairly long process of submitting and reviewing at Gerrit. Read the guide again and again and you\u2019ll start to remember commands without looking at this. I will continue with this as I learn more things, I hope this has helped someone. -- Vaughn (rwaterspf1) -- Eric Park (ideaman924) -- Jon West (electrikjesus)","title":"Conclusion"},{"location":"common/maintaining-proper-authorship/","text":"One of the most important things you need to keep in mind while working on open-source projects is maintaing correct authorship. In this article, we'll show you why maintaining proper authorship is important, give you a couple examples on correct and incorrect commits, and show you the overall procedure of correctly pulling in commits from others. What is kanging? Kanging is a term used in the Android development community for the action of passing off someone else's code as one's own, intentionally or unintentionally. Why is kanging bad? Kanging is bad because the developers who worked hard on the commits do not get the recognition they deserve. Over time, this may cause the developer to quit releasing public source code or even retire from the Android development community. Kanging examples (what you should NOT) do Example 1: You're trying to cherry-pick some commits from a different repository, but keep running into git merge issues. Out of frustration, you copy the code from the commit, and then just commit it using git commit -a . Satisfied, you push it up to GitHub. Example 2: You bring up a bunch of commits, and squash them before pushing to GitHub. Example 3: You intentionally want to pass off another developer's work as your own. You cherry-pick the commit, and then amend the commit to rewrite the author information. Let's go over why this is wrong. Example 1 is an example of an unintentional kang. You didn't want to resolve the git merge issues, so decided to just copy the code and commit it as your own. This is bad because the author information does not get transferred over with your copy, which you have to specify manually. Example 2 is more of an accident. If you squash multiple commits, all authorship information for the range of commits is lost. In addition, it becomes a real headache for other developers if something in the range of your commits is wrong. Because you cannot individually revert commits in a squash, squashing is very much discouraged and should ONLY be used when you have a lot of commits that you committed yourself and are small in nature. Example 3 is an example of an intentional kang. We won't explain why because it should be fairly obvious. How to maintain proper authorship The process is fairly simple yet important to understand. If you are cherry-picking commits, the authorship information is transferred automatically. Provided that you are running git cherry-pick <commit-id> , the entire commit information, down to when the commit was created, is picked into your repository. You don't have to do anything in this case. If you are committing someone else's code yourself, then you must manually specify who the author is. There are a lot of reasons why you would do this, from merge issues to incompatible code with the existing codebase. To manually specify an author, follow the steps below. Finally, do NOT squash a range of commits that are not your own. This completely wipes authorship information from the range of commits and causes a massive headache for other developers. Manually specifying an author You need to first determine the original author's name and email address. GitHub no longer shows the author information when you mouse over the profile picture, which is quite unfortunate. However, there is an easy workaround. Go to the commit that you want to pick. We'll use my commit as an example. Add the word .patch , with the period, to the end of the URL and press Enter to navigate to the raw patch. In the patch, find the section that contains the author. It should be at the top of the page. Now, it's time to commit with the correct author information. Make the necessary changes, and then commit using this command: git commit --author=\"AUTHOR_INFORMATION_HERE\" Following the example, I would write: git commit --author=\"Eric Park <ideamaneric@gmail.com>\" Once done, push to GitHub or Gerrit.","title":"Maintaining proper authorship"},{"location":"common/maintaining-proper-authorship/#what-is-kanging","text":"Kanging is a term used in the Android development community for the action of passing off someone else's code as one's own, intentionally or unintentionally.","title":"What is kanging?"},{"location":"common/maintaining-proper-authorship/#why-is-kanging-bad","text":"Kanging is bad because the developers who worked hard on the commits do not get the recognition they deserve. Over time, this may cause the developer to quit releasing public source code or even retire from the Android development community.","title":"Why is kanging bad?"},{"location":"common/maintaining-proper-authorship/#kanging-examples-what-you-should-not-do","text":"Example 1: You're trying to cherry-pick some commits from a different repository, but keep running into git merge issues. Out of frustration, you copy the code from the commit, and then just commit it using git commit -a . Satisfied, you push it up to GitHub. Example 2: You bring up a bunch of commits, and squash them before pushing to GitHub. Example 3: You intentionally want to pass off another developer's work as your own. You cherry-pick the commit, and then amend the commit to rewrite the author information. Let's go over why this is wrong. Example 1 is an example of an unintentional kang. You didn't want to resolve the git merge issues, so decided to just copy the code and commit it as your own. This is bad because the author information does not get transferred over with your copy, which you have to specify manually. Example 2 is more of an accident. If you squash multiple commits, all authorship information for the range of commits is lost. In addition, it becomes a real headache for other developers if something in the range of your commits is wrong. Because you cannot individually revert commits in a squash, squashing is very much discouraged and should ONLY be used when you have a lot of commits that you committed yourself and are small in nature. Example 3 is an example of an intentional kang. We won't explain why because it should be fairly obvious.","title":"Kanging examples (what you should NOT) do"},{"location":"common/maintaining-proper-authorship/#how-to-maintain-proper-authorship","text":"The process is fairly simple yet important to understand. If you are cherry-picking commits, the authorship information is transferred automatically. Provided that you are running git cherry-pick <commit-id> , the entire commit information, down to when the commit was created, is picked into your repository. You don't have to do anything in this case. If you are committing someone else's code yourself, then you must manually specify who the author is. There are a lot of reasons why you would do this, from merge issues to incompatible code with the existing codebase. To manually specify an author, follow the steps below. Finally, do NOT squash a range of commits that are not your own. This completely wipes authorship information from the range of commits and causes a massive headache for other developers.","title":"How to maintain proper authorship"},{"location":"common/maintaining-proper-authorship/#manually-specifying-an-author","text":"You need to first determine the original author's name and email address. GitHub no longer shows the author information when you mouse over the profile picture, which is quite unfortunate. However, there is an easy workaround. Go to the commit that you want to pick. We'll use my commit as an example. Add the word .patch , with the period, to the end of the URL and press Enter to navigate to the raw patch. In the patch, find the section that contains the author. It should be at the top of the page. Now, it's time to commit with the correct author information. Make the necessary changes, and then commit using this command: git commit --author=\"AUTHOR_INFORMATION_HERE\" Following the example, I would write: git commit --author=\"Eric Park <ideamaneric@gmail.com>\" Once done, push to GitHub or Gerrit.","title":"Manually specifying an author"},{"location":"common/using-dippy-bird/","text":"Using dippy-bird If you want to review commits quickly on our Gerrit, use the dippy-bird.php script created by the WikiMedia foundation. Thanks to Vaughn Newman (@rwaterspf1) for the original instructions! Installation Make sure you have PHP installed. Download the script and put it in an easily-accessible place. Usage Reviewing commits (code-review only) To review commits, run: php dippy-bird.php --username=ideaman924 --server=review.blissroms.com --port=29418 -q=\"status:open topic:test\" -a=review --review=+1 --verify=0 This will review all commits that match the following criteria: Is open for review (not closed, merged, or abandoned) Has the topic test And will apply +1 code-review and no verify, indicating that you have a successful build with the commits included. Reviewing commits (code-review and verification) To review commits with verification, run: php dippy-bird.php --username=ideaman924 --server=review.blissroms.com --port=29418 -q=\"status:open topic:test\" -a=review --review=+2 --verify=+1 This will review all commits that match the following criteria: Is open for review (not closed, merged, or abandoned) Has the topic test And will apply +2 code-review and +1 verify, indicating that you have tested the commits on an actual device. This means that the commits are now ready for merging.","title":"Using `dippy-bird`"},{"location":"common/using-dippy-bird/#using-dippy-bird","text":"If you want to review commits quickly on our Gerrit, use the dippy-bird.php script created by the WikiMedia foundation. Thanks to Vaughn Newman (@rwaterspf1) for the original instructions!","title":"Using dippy-bird"},{"location":"common/using-dippy-bird/#installation","text":"Make sure you have PHP installed. Download the script and put it in an easily-accessible place.","title":"Installation"},{"location":"common/using-dippy-bird/#usage","text":"","title":"Usage"},{"location":"common/using-dippy-bird/#reviewing-commits-code-review-only","text":"To review commits, run: php dippy-bird.php --username=ideaman924 --server=review.blissroms.com --port=29418 -q=\"status:open topic:test\" -a=review --review=+1 --verify=0 This will review all commits that match the following criteria: Is open for review (not closed, merged, or abandoned) Has the topic test And will apply +1 code-review and no verify, indicating that you have a successful build with the commits included.","title":"Reviewing commits (code-review only)"},{"location":"common/using-dippy-bird/#reviewing-commits-code-review-and-verification","text":"To review commits with verification, run: php dippy-bird.php --username=ideaman924 --server=review.blissroms.com --port=29418 -q=\"status:open topic:test\" -a=review --review=+2 --verify=+1 This will review all commits that match the following criteria: Is open for review (not closed, merged, or abandoned) Has the topic test And will apply +2 code-review and +1 verify, indicating that you have tested the commits on an actual device. This means that the commits are now ready for merging.","title":"Reviewing commits (code-review and verification)"},{"location":"infrastructure/","text":"Index There doesn't seem to be anything here... check back later for more content!","title":"Index"},{"location":"infrastructure/#index","text":"There doesn't seem to be anything here... check back later for more content!","title":"Index"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"Index Welcome to the documentation, written by developers of Team Bliss! Bliss OS (x86) Don't know how to install? We've got you covered. Install didn't go as smoothly as you expected? Troubleshoot why. Want Netflix? Want Gapps? You need the extras. Ready to build? Start here with our build Guide. BlissRoms (arm/arm64) First time building? Let's get started. Need some tips? Optimize your builds! Common Documentation Before anything else, learn how to maintain proper authorship. Start with this essential guide, which teaches you about the fundamentals of ROM building. Getting tired of reviewing commits? Try mass reviewing commits. Check back later for more content! We're always updating the documentation with more helpful tips and information!","title":"Home"},{"location":"#index","text":"Welcome to the documentation, written by developers of Team Bliss!","title":"Index"},{"location":"#bliss-os-x86","text":"Don't know how to install? We've got you covered. Install didn't go as smoothly as you expected? Troubleshoot why. Want Netflix? Want Gapps? You need the extras. Ready to build? Start here with our build Guide.","title":"Bliss OS (x86)"},{"location":"#blissroms-armarm64","text":"First time building? Let's get started. Need some tips? Optimize your builds!","title":"BlissRoms (arm/arm64)"},{"location":"#common-documentation","text":"Before anything else, learn how to maintain proper authorship. Start with this essential guide, which teaches you about the fundamentals of ROM building. Getting tired of reviewing commits? Try mass reviewing commits. Check back later for more content! We're always updating the documentation with more helpful tips and information!","title":"Common Documentation"},{"location":"Bliss OS/","text":"Index New? Start here with the Installation Guide. Troubleshooting your new install? Check out the Troubleshooting section. Want some extra tips? Look no further! Ready to build? Start here with our build Guide.","title":"Index"},{"location":"Bliss OS/#index","text":"New? Start here with the Installation Guide. Troubleshooting your new install? Check out the Troubleshooting section. Want some extra tips? Look no further! Ready to build? Start here with our build Guide.","title":"Index"},{"location":"Bliss OS/build-guide/","text":"Build Guide Introduction This is the official guide to build Bliss OS for PCs. In this guide, we will only cover building for x86 & x86_64 devices. We will also go over the details of using the patch system for testing and recompiling a build with a different kernel branch. The golden rule to building is patience. If something breaks, pay attention to the console output or take logs of the issue and ask for guidance in our build support chat. Let\u2019s get started. Preparation To get started, you need a computer with Ubuntu 18.04 (LTS), at least 200GB space of HDD, and at least 8GB RAM. A decent CPU (or CPUs if you have a server motherboard) is recommended. Other distros can work but is not officially supported in this guide. Underpowered machines may crash during compilation. If that happens, you may try and restart the build as most crashes are caused by lack of memory. If your storage space has run out, then you will need to build on a different hard drive. Install the JDK Install OpenJDK: sudo apt install openjdk-8-jdk Install build tools To install the required build tools, run the following command: sudo apt-get install git-core gnupg flex bison maven gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip squashfs-tools python-mako libssl-dev ninja-build lunzip syslinux syslinux-utils gettext genisoimage gettext bc xorriso libncurses5 Install source code tools Now we need to get the source code via a program named 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. Create a ~/bin directory for repo : mkdir -p ~/bin The -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 : curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo Make repo executable: chmod a+x ~/bin/repo And add it to PATH: nano .bashrc Scroll to the end of the file and type these lines: # Export ~/bin export PATH=~/bin:$PATH Ctrl-O and enter to save, then Ctrl-X to exit nano. Now either logout and login again (or reboot), or source the file: source .bashrc Which can be shortened to: . .bashrc What is 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! But why do you need to run it after modifying a file? Well, 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! What if I need repo globally? If you need the 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: curl https://storage.googleapis.com/git-repo-downloads/repo > ~/repo sudo mv ~/repo /usr/bin/ chmod a+x /usr/bin/repo repo will now work anywhere, without any .bashrc modifications. However, these steps aren\u2019t recommended as repo might become a security risk if a vulnerability is found. Now we\u2019re ready to download the source code. Download Create a directory for the source: mkdir -p ~/blissos/p9.0 cd ~/blissos/p9.0 Before we download, we need to tell repo and git who we are. Run the following commands, substituting your information: git config --global user.email \u201crandy.mcrandyface@hotmail.net\u201d git config --global user.name \u201cRandy McRandyface\u201d Now, we\u2019re ready to initialize. We need to tell repo which manifest to read: repo init -u https://github.com/BlissRoms-x86/manifest.git -b p9.0-x86 -b is for the branch, and we\u2019re on p9.0-x86 , Android Pie. It\u2019ll take a couple of seconds. You may need to type y for the color prompt. Sync repo : repo sync -j24 -c --no-tags --no-clone-bundle Problems syncing? : repo sync -j4 -c --no-tags --no-clone-bundle --force-sync -j is for threads. Typically, your CPU core count is your thread count, unless you\u2019re 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: repo sync -j4 -c -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\u2019t want the entire history to be downloaded. This is used by default unless specified otherwise. I still don't know how much CPU threads I have. How do I check? Run nproc . The output should be something like this: mybuildbox@test:~$ nproc 24 This means that there are 24 threads in your machine. repo will start downloading all the code. That\u2019s going to be slow, even on a fiber network. Expect downloads to take more than a couple hours. Easy Build Instructions This will build an x86 based .ISO for PCs. Usage: $ bash build-x86.sh options buildVariants blissBranch extraOptions Options: -c | --clean : Does make clean && make clobber and resets the efi device tree -s | --sync: Repo syncs the rom (clears out patches), then reapplies patches to needed repos -p | --patch: Just applies patches to needed repos -r | --proprietary: build needed items from proprietary vendor (non-public) BuildVariants: android_x86-user : Make user build android_x86-userdebug |: Make userdebug build android_x86-eng : Make eng build android_x86_64-user : Make user build android_x86_64-userdebug |: Make userdebug build android_x86_64-eng : Make eng build BlissBranch: select which bliss branch to sync, default is p9.0 ExtraOptions: foss : packages microG & FDroid with the build go : packages Gapps Go with the build gapps : packages OpenGapps with the build gms : packages GMS with the build (requires private repo access) none : force all extraOption flags to false. To start, you must first use the -s (--sync) flag, then on following builds, it is not needed. Initial generation of the proprietary files from ChromeOS are also needed on the first build. We are able to use the -r (--proprietary) flag for that. This step needs to be on its own because the mounting process requires root permissions, so keep a look out for it asking for your root password . First you must sync with the new manifest changes: bash build-x86.sh -p This will do initial patching. Some of the patches will show as 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. The only times you should worry about the conflicts is when you are adding or changing patches in vendor/x86 . Next step is to download the proprietary files from ChromeOS: mkdir vendor/bliss_priv/proprietary mkdir vendor/bliss_priv/source bash build-x86.sh -r android_x86_64-userdebug After that, you can build your release file: bash build-x86.sh android_x86_64-userdebug (to build the userdebug version for x86_64 CPUs) Advanced Build Instructions Set up the build environment: . build/envsetup.sh This is the initialization file we talked about earlier up top. This \"initializes\" the environment, and imports a bunch of useful build commands required to build your device. Again, you need to remember to source this file every time you log out and log back in, or launch a new bash /Terminal instance. Define what device you\u2019re going to build. For example, the Nexus 5X, has a codename of bullhead . You can check your specific device's codename on GitHub or on Google. Execute: For 32 bit devices: lunch android_x86-userdebug For 64 bit devices: lunch android_x86_64-userdebug Let's break down the command. 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. My device isn't booting, and userdebug won't print any adb logcat s. What gives? There is a third build variant called 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! If this is the first time you're running the build, you're going to want to run the proprietary build command first from the easy build instructions. Alternatively, you could also run those commands manually. mkdir vendor/bliss_priv/proprietary && mkdir vendor/bliss_priv/source Then: lunch android_x86_64-userdebug mka update_engine_applier mka proprietary After that is complete, we can start the main building process. Run: mka iso_img And the build should start. The build process will take a long time. Prepare to wait a few hours, even on a decent machine. Why mka and not make ? make only runs with 1 thread. mka is properly aliased to use all of your threads by checking nproc . If you want to customize your thread count (maybe you're building with a fan-screaming laptop in a quiet coffee shop), use make -j# , replacing the hash with the number of threads (example of make -j4 ). After building There are two outcomes to a build - either it fails and you get a red error message from 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. If you face the latter, congratulations! You've successfully built BlissRoms for your device. Grab the artifacts for your device: cd out/target/product/x86_64/ In here, you\u2019ll find an .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 . Changing the target kernel branch Sometimes, you might be working on a device that requires a different kernel branch. In order to switch kernels effectively on Bliss OS, they need to be compiled with the OS at build time. Switching the kernel branch Start off by entering the kernel folder cd kernel Then pull all the available kernel branched from your target repo. In this case, we are using the default BR-x86 repo git fetch BR-x86 Then after that is finished, we need to checkout our target branch, and in this example we are choosing our k4.19.50-ax86-ga branch, which has added commits from the GalliumOS project for Chromebooks git checkout BR-x86/k4.19.50-ax86-ga Next step is to clean out any configs or generated files from the previously checked out kernel. To do this, run these commands make clean make mrproper Once that is done, we can cd back to our main project folder cd .. And run our build command again to generate the .iso with the target kernel we selected rm -rf out/target/product/x86_64/kernel mka iso_img Using the patch system for testing We use a patching method we adapted for Bliss from Intel's Project Celadon & phh-treble. This patching system allows us to bring in a good number of commits to add to the OS, and test how they apply or if there are any conflicts. Our intention was to make a system that can add all the needed x86/x86_64 commits to BlissROM, as well as other ROMs too. The majority of this system is found in vendor/x86/utils . From here, you simply generate the .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. From your Project folder: cd packages/apps/Settings And generate your .patch files. For this example, we've added four commits on top of what was there after sync git format-patch -4 Then copy those files to the proper folder in vendor/x86 . In this case, you will find it here: vendor/x86/utils/android_p/google_diff/x86 After that is complete, you can make clean and run the patch system from your main project folder. make clean bash build-x86.sh -p This should start patching all the source files. Once that is complete, you can rebuild. Troubleshooting If your build failed, there are a couple things you can try. Try a fresh 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. Make sure your dependencies are installed correctly. Error messages help out a lot here! Often it will say shared/linked library not found or something along those lines. Make sure you sourced 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 sync ed do this again. Make sure you\u2019re at the root of the build tree. Again, to quickly jump there, use croot . Make sure your computer itself isn\u2019t faulty. HDDs usually die first, followed by RAM. SSDs rarely die but failure is not unheard of. In extremely rare cases, your CPU may have a defect. If you're unsure, run a stress test using a program like Prime95. If something goes wrong and you've tried everything above, first use Google to look up your error! Most of the errors you encounter is due to misconfiguration and wrong commands entered. More often than not, Google will have the answer you are looking for. If you're still stuck and nothing fixes the problem, then ask us via our Telegram Build Support chat. Conclusion Building a ROM is very hard and tedious and the results are very rewarding! If you managed to follow along, congratulations! After you finish building, you can try out the Git Started guide. Make changes, commit, and send them off to our GitHub for Bliss OS repos & our Gerrit for review on BlissROMs repos! Or better yet, download experimental commits not ready for the mainline repositories and review them! Again, ROM building is a fun project you can work with. I hope this guide was a lot of fun to run through!","title":"Build Guide"},{"location":"Bliss OS/build-guide/#build-guide","text":"","title":"Build Guide"},{"location":"Bliss OS/build-guide/#introduction","text":"This is the official guide to build Bliss OS for PCs. In this guide, we will only cover building for x86 & x86_64 devices. We will also go over the details of using the patch system for testing and recompiling a build with a different kernel branch. The golden rule to building is patience. If something breaks, pay attention to the console output or take logs of the issue and ask for guidance in our build support chat. Let\u2019s get started.","title":"Introduction"},{"location":"Bliss OS/build-guide/#preparation","text":"To get started, you need a computer with Ubuntu 18.04 (LTS), at least 200GB space of HDD, and at least 8GB RAM. A decent CPU (or CPUs if you have a server motherboard) is recommended. Other distros can work but is not officially supported in this guide. Underpowered machines may crash during compilation. If that happens, you may try and restart the build as most crashes are caused by lack of memory. If your storage space has run out, then you will need to build on a different hard drive.","title":"Preparation"},{"location":"Bliss OS/build-guide/#install-the-jdk","text":"Install OpenJDK: sudo apt install openjdk-8-jdk","title":"Install the JDK"},{"location":"Bliss OS/build-guide/#install-build-tools","text":"To install the required build tools, run the following command: sudo apt-get install git-core gnupg flex bison maven gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip squashfs-tools python-mako libssl-dev ninja-build lunzip syslinux syslinux-utils gettext genisoimage gettext bc xorriso libncurses5","title":"Install build tools"},{"location":"Bliss OS/build-guide/#install-source-code-tools","text":"Now we need to get the source code via a program named 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. Create a ~/bin directory for repo : mkdir -p ~/bin The -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 : curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo Make repo executable: chmod a+x ~/bin/repo And add it to PATH: nano .bashrc Scroll to the end of the file and type these lines: # Export ~/bin export PATH=~/bin:$PATH Ctrl-O and enter to save, then Ctrl-X to exit nano. Now either logout and login again (or reboot), or source the file: source .bashrc Which can be shortened to: . .bashrc","title":"Install source code tools"},{"location":"Bliss OS/build-guide/#what-is-source","text":"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! But why do you need to run it after modifying a file? Well, 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!","title":"What is source?"},{"location":"Bliss OS/build-guide/#what-if-i-need-repo-globally","text":"If you need the 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: curl https://storage.googleapis.com/git-repo-downloads/repo > ~/repo sudo mv ~/repo /usr/bin/ chmod a+x /usr/bin/repo repo will now work anywhere, without any .bashrc modifications. However, these steps aren\u2019t recommended as repo might become a security risk if a vulnerability is found. Now we\u2019re ready to download the source code.","title":"What if I need repo globally?"},{"location":"Bliss OS/build-guide/#download","text":"Create a directory for the source: mkdir -p ~/blissos/p9.0 cd ~/blissos/p9.0 Before we download, we need to tell repo and git who we are. Run the following commands, substituting your information: git config --global user.email \u201crandy.mcrandyface@hotmail.net\u201d git config --global user.name \u201cRandy McRandyface\u201d Now, we\u2019re ready to initialize. We need to tell repo which manifest to read: repo init -u https://github.com/BlissRoms-x86/manifest.git -b p9.0-x86 -b is for the branch, and we\u2019re on p9.0-x86 , Android Pie. It\u2019ll take a couple of seconds. You may need to type y for the color prompt. Sync repo : repo sync -j24 -c --no-tags --no-clone-bundle Problems syncing? : repo sync -j4 -c --no-tags --no-clone-bundle --force-sync -j is for threads. Typically, your CPU core count is your thread count, unless you\u2019re 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: repo sync -j4 -c -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\u2019t want the entire history to be downloaded. This is used by default unless specified otherwise.","title":"Download"},{"location":"Bliss OS/build-guide/#i-still-dont-know-how-much-cpu-threads-i-have-how-do-i-check","text":"Run nproc . The output should be something like this: mybuildbox@test:~$ nproc 24 This means that there are 24 threads in your machine. repo will start downloading all the code. That\u2019s going to be slow, even on a fiber network. Expect downloads to take more than a couple hours.","title":"I still don't know how much CPU threads I have. How do I check?"},{"location":"Bliss OS/build-guide/#easy-build-instructions","text":"This will build an x86 based .ISO for PCs. Usage: $ bash build-x86.sh options buildVariants blissBranch extraOptions Options: -c | --clean : Does make clean && make clobber and resets the efi device tree -s | --sync: Repo syncs the rom (clears out patches), then reapplies patches to needed repos -p | --patch: Just applies patches to needed repos -r | --proprietary: build needed items from proprietary vendor (non-public) BuildVariants: android_x86-user : Make user build android_x86-userdebug |: Make userdebug build android_x86-eng : Make eng build android_x86_64-user : Make user build android_x86_64-userdebug |: Make userdebug build android_x86_64-eng : Make eng build BlissBranch: select which bliss branch to sync, default is p9.0 ExtraOptions: foss : packages microG & FDroid with the build go : packages Gapps Go with the build gapps : packages OpenGapps with the build gms : packages GMS with the build (requires private repo access) none : force all extraOption flags to false. To start, you must first use the -s (--sync) flag, then on following builds, it is not needed. Initial generation of the proprietary files from ChromeOS are also needed on the first build. We are able to use the -r (--proprietary) flag for that. This step needs to be on its own because the mounting process requires root permissions, so keep a look out for it asking for your root password . First you must sync with the new manifest changes: bash build-x86.sh -p This will do initial patching. Some of the patches will show as 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. The only times you should worry about the conflicts is when you are adding or changing patches in vendor/x86 . Next step is to download the proprietary files from ChromeOS: mkdir vendor/bliss_priv/proprietary mkdir vendor/bliss_priv/source bash build-x86.sh -r android_x86_64-userdebug After that, you can build your release file: bash build-x86.sh android_x86_64-userdebug (to build the userdebug version for x86_64 CPUs)","title":"Easy Build Instructions"},{"location":"Bliss OS/build-guide/#advanced-build-instructions","text":"Set up the build environment: . build/envsetup.sh This is the initialization file we talked about earlier up top. This \"initializes\" the environment, and imports a bunch of useful build commands required to build your device. Again, you need to remember to source this file every time you log out and log back in, or launch a new bash /Terminal instance. Define what device you\u2019re going to build. For example, the Nexus 5X, has a codename of bullhead . You can check your specific device's codename on GitHub or on Google. Execute: For 32 bit devices: lunch android_x86-userdebug For 64 bit devices: lunch android_x86_64-userdebug Let's break down the command. 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.","title":"Advanced Build Instructions"},{"location":"Bliss OS/build-guide/#my-device-isnt-booting-and-userdebug-wont-print-any-adb-logcats-what-gives","text":"There is a third build variant called 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! If this is the first time you're running the build, you're going to want to run the proprietary build command first from the easy build instructions. Alternatively, you could also run those commands manually. mkdir vendor/bliss_priv/proprietary && mkdir vendor/bliss_priv/source Then: lunch android_x86_64-userdebug mka update_engine_applier mka proprietary After that is complete, we can start the main building process. Run: mka iso_img And the build should start. The build process will take a long time. Prepare to wait a few hours, even on a decent machine.","title":"My device isn't booting, and userdebug won't print any adb logcats. What gives?"},{"location":"Bliss OS/build-guide/#why-mka-and-not-make","text":"make only runs with 1 thread. mka is properly aliased to use all of your threads by checking nproc . If you want to customize your thread count (maybe you're building with a fan-screaming laptop in a quiet coffee shop), use make -j# , replacing the hash with the number of threads (example of make -j4 ).","title":"Why mka and not make?"},{"location":"Bliss OS/build-guide/#after-building","text":"There are two outcomes to a build - either it fails and you get a red error message from 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. If you face the latter, congratulations! You've successfully built BlissRoms for your device. Grab the artifacts for your device: cd out/target/product/x86_64/ In here, you\u2019ll find an .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 .","title":"After building"},{"location":"Bliss OS/build-guide/#changing-the-target-kernel-branch","text":"Sometimes, you might be working on a device that requires a different kernel branch. In order to switch kernels effectively on Bliss OS, they need to be compiled with the OS at build time.","title":"Changing the target kernel branch"},{"location":"Bliss OS/build-guide/#switching-the-kernel-branch","text":"Start off by entering the kernel folder cd kernel Then pull all the available kernel branched from your target repo. In this case, we are using the default BR-x86 repo git fetch BR-x86 Then after that is finished, we need to checkout our target branch, and in this example we are choosing our k4.19.50-ax86-ga branch, which has added commits from the GalliumOS project for Chromebooks git checkout BR-x86/k4.19.50-ax86-ga Next step is to clean out any configs or generated files from the previously checked out kernel. To do this, run these commands make clean make mrproper Once that is done, we can cd back to our main project folder cd .. And run our build command again to generate the .iso with the target kernel we selected rm -rf out/target/product/x86_64/kernel mka iso_img","title":"Switching the kernel branch"},{"location":"Bliss OS/build-guide/#using-the-patch-system-for-testing","text":"We use a patching method we adapted for Bliss from Intel's Project Celadon & phh-treble. This patching system allows us to bring in a good number of commits to add to the OS, and test how they apply or if there are any conflicts. Our intention was to make a system that can add all the needed x86/x86_64 commits to BlissROM, as well as other ROMs too. The majority of this system is found in vendor/x86/utils . From here, you simply generate the .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. From your Project folder: cd packages/apps/Settings And generate your .patch files. For this example, we've added four commits on top of what was there after sync git format-patch -4 Then copy those files to the proper folder in vendor/x86 . In this case, you will find it here: vendor/x86/utils/android_p/google_diff/x86 After that is complete, you can make clean and run the patch system from your main project folder. make clean bash build-x86.sh -p This should start patching all the source files. Once that is complete, you can rebuild.","title":"Using the patch system for testing"},{"location":"Bliss OS/build-guide/#troubleshooting","text":"If your build failed, there are a couple things you can try. Try a fresh 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. Make sure your dependencies are installed correctly. Error messages help out a lot here! Often it will say shared/linked library not found or something along those lines. Make sure you sourced 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 sync ed do this again. Make sure you\u2019re at the root of the build tree. Again, to quickly jump there, use croot . Make sure your computer itself isn\u2019t faulty. HDDs usually die first, followed by RAM. SSDs rarely die but failure is not unheard of. In extremely rare cases, your CPU may have a defect. If you're unsure, run a stress test using a program like Prime95. If something goes wrong and you've tried everything above, first use Google to look up your error! Most of the errors you encounter is due to misconfiguration and wrong commands entered. More often than not, Google will have the answer you are looking for. If you're still stuck and nothing fixes the problem, then ask us via our Telegram Build Support chat.","title":"Troubleshooting"},{"location":"Bliss OS/build-guide/#conclusion","text":"Building a ROM is very hard and tedious and the results are very rewarding! If you managed to follow along, congratulations! After you finish building, you can try out the Git Started guide. Make changes, commit, and send them off to our GitHub for Bliss OS repos & our Gerrit for review on BlissROMs repos! Or better yet, download experimental commits not ready for the mainline repositories and review them! Again, ROM building is a fun project you can work with. I hope this guide was a lot of fun to run through!","title":"Conclusion"},{"location":"Bliss OS/extras/","text":"Extras Setting up Taskbar on Bliss OS (Pie) If you would like to use Taskbar as your default launcher, you will need to first go into \"Settings > Blissify > Gestures\", and enable something like Carbon Gestures (we recommend setting up three-finger swipes: Right for Back, Down for Home, & Up for Recents), then you can go to \"Blissify > Buttons\" and switch the navigation mode to SmartBar, then go back and disable the navigation bar from there by switching off \"Allow Navigation Bar on the top\". At this point, you need to switch to your home screen, so swipe up with your gesture, or tap the Windows key (or Windows-Esc). Then launch Taskbar, enable it, set to launch on boot. We recommend disabling hiding. Enable a couple other settings in the \"Freeform\" and \"Advanced\" screens as required. Setting it up this way will prevent any crashes from happening on initial launch. And it allows you to also use the Quickstep launcher as the main background. Here's a video tutorial on how to do it properly: Setting up Gapps See this thread from @wrwolf2! Watching Netflix - FOSS & GMS Builds Netflix considers our rooted OS as an \"incompatible\" device, according to their support articles. This version of Netflix seems to work great , as long as you don't update it. If it prompts you, click on \"Cancel\".","title":"Extras"},{"location":"Bliss OS/extras/#extras","text":"","title":"Extras"},{"location":"Bliss OS/extras/#setting-up-taskbar-on-bliss-os-pie","text":"If you would like to use Taskbar as your default launcher, you will need to first go into \"Settings > Blissify > Gestures\", and enable something like Carbon Gestures (we recommend setting up three-finger swipes: Right for Back, Down for Home, & Up for Recents), then you can go to \"Blissify > Buttons\" and switch the navigation mode to SmartBar, then go back and disable the navigation bar from there by switching off \"Allow Navigation Bar on the top\". At this point, you need to switch to your home screen, so swipe up with your gesture, or tap the Windows key (or Windows-Esc). Then launch Taskbar, enable it, set to launch on boot. We recommend disabling hiding. Enable a couple other settings in the \"Freeform\" and \"Advanced\" screens as required. Setting it up this way will prevent any crashes from happening on initial launch. And it allows you to also use the Quickstep launcher as the main background. Here's a video tutorial on how to do it properly:","title":"Setting up Taskbar on Bliss OS (Pie)"},{"location":"Bliss OS/extras/#setting-up-gapps","text":"See this thread from @wrwolf2!","title":"Setting up Gapps"},{"location":"Bliss OS/extras/#watching-netflix-foss-gms-builds","text":"Netflix considers our rooted OS as an \"incompatible\" device, according to their support articles. This version of Netflix seems to work great , as long as you don't update it. If it prompts you, click on \"Cancel\".","title":"Watching Netflix - FOSS &amp; GMS Builds"},{"location":"Bliss OS/installation-guide/","text":"Installation Guide Preface These instructions are based on the Android-x86 project's installation guide. We have not changed the installer, so the procedure of installation is similar. We also thank @bg260 for his contributions - this guide was adapted partially from his work. Warning! Team Bliss does NOT accept any responsibility . Users must read and understand the instructions, as the installation modifies core system files and carries a significant risk. You accept all responsibility , including but not limited to data loss and other malfunctions by continuing beyond this point. Any questions, install issues, bug reports, etc. MUST be accompanied with the following things: Log Device info Build info (file name) Installation method (exact steps used) Any other relevant information REQUIRED to diagnose your issue as NOT user error If the following information is not supplied, your inquiry will be ignored. These instructions have changed quite a bit for Android Pie, so consider this section a work in progress. Thank you for your patience! Bootable installation method - MBR/UEFI/ESP (32/64-bit) This is the current recommended method! Overview of the steps: Download the ISO file Use Rufus or similar to burn to USB drive Disable Secure Boot, Bitlocker, and any other boot security software such as Veracrypt Boot into the USB drive. Run Bliss OS in Live mode to test things out. If all is well, continue to next step Boot into the USB drive, and choose Bliss OS Install Let's get started! Part 1 - Gather Your Tools Please note that this method is not supported on all machines. Download Rufus and the 32-bit .iso or 64-bit .iso / .img file of Bliss OS, depending on the architecture of the machine you are installing Bliss OS on. You will need a decent speed USB drive (4 GB or larger is recommended). Part 2 - Flashing Bliss OS to the USB drive Plug in your USB drive, and load up Rufus. Once loaded, click on the icon next to the ISO Image dropdown menu. Now browse to where you have your Bliss OS (32-bit) .iso , or your Bliss OS (64-bit) .iso / .img file. Once chosen, the dropdown should switch to the correct image type, and fill the rest in for you. Once you are ready, click Start. Part 3 - Testing Bliss OS on your system This is very important! If you, as a user, do NOT test the OS first to make sure it is compatible with your device, please do NOT expect us to help you if you happen to install it blindly and something goes wrong. Reboot your machine, and enter the BIOS. Most motherboards have the default key as \"F2\". Change the boot order so that the USB is the first thing the device will boot to. Once the boot orders are changed, reboot. If everything goes well, you should see a grub boot screen. Select the \"Live CD\" option, and if your machine is compatible, you should then see a little bit of text, and then the Bliss OS boot animation. This will go on for a few minutes, but should eventually boot to Bliss OS. If the system never boots to Bliss OS, this is a bad sign that your system might not be compatible. If it does boot, and you would like to install it, continue to the next step. For those wanting to use root, you will need to install the OS and be running of that install. Root will not function properly in Live Mode. Troubleshooting - Booting from the USB kicks me back to BIOS, or back to my Windows/macOS/Linux installation. Your drive is incompatible or you have formatted it incorrectly. Try flashing the image again to the drive with Rufus. If that does not work, your device does not support booting from USB and you will have to try an alternate method. Part 3 (alternate) - Using Bliss OS from your USB drive If you choose to use Bliss from the USB drive, the data you modify or create on the live install will be in an ephemeral state unless you create a data.img to store the data. You can create a data.img in the root directory of the USB drive (make sure you have a minimum of 4-5 GB free on the drive). We suggest using a tool like RMXtools from XDA to create it (version 1.7 is recommended). Check the tool's thread for detailed usage instructions. You will want to create your data.img inside the root directory of your USB drive, with all the other .img files. From there, just boot into live mode, setup your system the way you want, and the data should be persistant across reboots. Part 4 - Setting up and Installing Bliss OS on your HDD/SSD/SD card Quick warning again, in case you missed it. Team Bliss is NOT responsible , directly or indirectly, for any damages caused by this guide. By continuing, you automatically agree to these terms. This is where things start to get a little tricky, especially with how devices vary. Make sure you have a backup plan in case something goes wrong. Start off by opening your favorite partition management software, such as Disk Management in Windows, and create a new partition, making it the size you want (suggested minimum is 8 GB). Just format it to NTFS for now, because it will be formatted by the installer later into the process anyway. Remember what drive you have created here as it's important later on. For Windows machines, it will typically be sda4 or sda5 . Also create another 300 MB FAT32 partition for the grub bootloader to install to. (This part might require a third-party partition manager as Windows Disk Management might not let it be that small.) Boot up the Bliss OS USB, and select the \"Installation\" option in grub . (It is the second one down, usually.) The installer will load, and you will have an option to choose the partition you created earlier. Pick it, and select ext4 . DO NOT blindly choose the partition, as an incorrect flash can mess up your drive and cause serious data loss. You do NOT want to get this step wrong. If you are unsure, boot back into Windows/macOS/Linux and write it down. When it asks if you want to install system as R/W, select \"YES\" if you want to use root (SuperSU), and \"No\" if you do not need root. When it asks if you want to install grub , select \"Grub for Legacy BIOS boot type\", \"Grub2 for UEFI boot type\", or neither if you are already running a Linux system. If you chose to install grub , the installer will allow you to choose the partition to install grub to. Make sure you select the 300 MB partition you set up earlier for grub . The process will install and create the data directory/image, so be patient. When finished, the installer will then ask if you want to run Android-x86. You can just reboot here. Make sure you remove the USB drive. If we have followed all the directions correctly, you should be presented with a grub boot menu. You can choose your bliss_android_x86 option (or android-x86 ), and it will boot into Bliss OS. If you want to customize your grub boot entry, search the web first. We use the same grub setup that the Android-x86 project uses, so their forums will contain just about all the info you will need. Congratulations! We hope you enjoy using Bliss OS. Windows-based installer - UEFI/ESP (64-bit) This method is no longer supported due to too many people not understanding computer basics and breaking things. Proceed at your own risk. This method might be the easiest currently if you understand what you are doing. For the overall instructions on using this method, please refer to the tool's original thread . The tools have been updated by Team Bliss for easy installation on UEFI/ESP machines. The builds we produce can be found here. And the source for those builds can be found here. This tool should work on Remix OS as well, but this has not been tested yet. Part 1 - Using the Installer The installer has been updated to accept the .iso files for our 8.x/10.x/11.x releases. Just follow the prompts the installer gives. Refer to the original thread for any questions, and please search before asking. If you plan on using root, the process will require you to manually extract the system.img from within the system.sfs file. Then you must delete the system.sfs file after extracting. Warning - for Pie, you will need to add androidboot.hardware=android_x86_64 to the grub entry in order to boot! Part 2 - Switching the UEFI/EFI boot entry Option one is to use the EasyUEFI tool, then switch the UEFI/EFI entry it created to boot first. Close and reboot. Option two is to use your BIOS to select the added UEFI boot entry. Use syslinux EFI to run Bliss OS 7.x/10.x/11.x Thanks to @IcedCube for the original post! This method is NOT recommended as it is fairly bleeding-edge and experimental, but it should help booting on Chinese tablets that do not want to run grub . Use a Linux installation for the following procedure. Part 1 - Grab the required tools Install unsquashfs (part of squashfs-tools ). Part 2 - Get Bliss OS Grab the latest build of Bliss OS 7.x/10.x/11.x. Part 3 - Get the syslinux EFI bootstrap Grab the .zip file from @IcedCube's original post , and extract it to the root of the USB drive. This will bootstrap syslinux EFI onto it. Then, make a folder called android . Now, open up the .iso in an archive program. Extract the following files form the root directory of the .iso image to the USB drive's android folder: initrd.img ramdisk.img kernel Extract system.sfs to a folder somewhere, such as /tmp . Open a terminal and change directory (using cd ) to /tmp . Run ls and confirm that system.sfs is shown in the file list. If there is no output, start over as the file is misplaced. Run the following: unsquashfs ./system.sfs This will make a new directory called squashfs_root . Part 4 - Version specific If you are using Bliss 7.x Change directory to squashfs_root and run ls . There should only be one file - a system.img inside the directory. Copy the file to the USB's android folder. If you are using Bliss 10.x Change directory to squashfs_root . The structure is a complete Android root filesystem. To install Bliss OS, the files will need to be in a system image. The following steps will guide you through creating a 2 GB system.img file, formatting it, mounting it, and copying the contents of squashfs_root into the new disk image. Execute: mkdir /mnt/tempMount truncate /tmp/system.img --size=2G mkfs.ext4 -m0 /tmp/system.img sudo mount -o loop /tmp/system.img /mnt/tempMount sudo cp -prv /tmp/squashfs_root/* /mnt/tempMount/ sync sudo umount /mnt/tempMount The sync command might take some time. Now copy the /tmp/system.img file to your USB's Android folder. Part 5 - Creating the data image First, find where your USB drive is mounted. It is usually in /mnt or /media (ex. /media/USB ). cd into the android folder. We will create a 3 GB data image file. You can attempt to create a 4 GB image but FAT32 maxes out at 4 GB per file. If your system supports exFAT or NTFS, you may try and use it. truncate data.img --size=3G mkfs.ext4 -m0 data.img sync This will be an completely empty ext4 disk image, but will be enough to run Bliss. Finally, check to ensure everything is in structured like so: <ROOT> - syslinux.cfg - android/ -- kernel -- system.img -- data.img -- ramdisk.img -- initrd.img - EFI/ -- BOOT/ --- bootia32.efi --- bootx64.efi --- ldlinux.e32 --- ldlinux.e64 Need to add some kernel parameters? Open syslinux.cfg and add them before the initrd=/android/initrd.img statement. Unmount the USB from your computer. Plug it into your device and use the BIOS to boot from your UEFI USB Drive, partition 1. If all goes well, you will get a black screen with small white text saying \"Booting Android...\" followed by loading files. You should get the Linux kernel text, then see the Bliss boot animation play after a couple minutes depending on your USB drive read/write speed. Custom Install - Bliss OS 8.x/10.x/11.x UEFI/ESP (64-bit) Just as a reminder, Team Bliss is NOT responsible for any damage caused by this guide. By continuing, you automatically agree to these terms. Part 1 - Mounting Your UEFI/ESP Partition You will want to make sure you can view hidden and system files in Explorer options. Once you do that, hit the start menu, and type in cmd . Once \"Command Prompt\" shows up, right click on it and choose \"Open as administrator\". cmd is not showing up, what should I do? Press the Windows key and the R key to bring up the \"Run...\" dialog. Type in cmd , and then press Ctrl-Shift-Enter. Press \"Yes\" on the UAC popup. Run the following: mountvol X: /S Then check to see if it is mounted already. Run \"Task Manager\" by either Pressing Ctrl-Alt-Del and then clicking on \"Task Manager\", or Pressing Ctrl-Shift-Esc Click on \"File\", \"Run new task\", \"Browse\", \"This computer\", and SYSTEM (X or type in X: in the filepath bar. If you cannot access X: , then that could mean one of three things. You have an ESP setup (follow the installation method below) You have a legacy MBR setup Your setup has a custom boot sequence Part 1 (alternate) - ESP setup Windows 10 sometimes has an EFI partition already mounted under drive letter Z: , hidden. A very quick and easy way to access the ESP (EFI System Partition) in Windows 10 without using the command line is to start \"Task Manager\" (check above if you forgot the steps), and then click on \"File\", \"Run new task\", \"Browse\", \"This computer\", and SYSTEM (Z or type in Z: in the filepath bar). Now go to boot/grub/grub.cfg and edit it accordingly with Notepad++ or another text editor. Save the file and your're ready to go! Part 1 (alternate) - Killing the explorer.exe Run cmd as admin and enter the following command: taskkill /im explorer.exe /f This will kill the explorer.exe process - don't be surprised if it shows a warning. This step is sometimes required, because by default explorer.exe is ran by the currently logged in user, and it has to be run by the \"Administrator\" in order to view the mounted system drive. The \"Administrator\" account is not the same as an account with administrative privileges. mountvol X: /s This will mount the system partition that usually consists of UEFI related files. X: is the letter of the drive - you can use whatever letter you want, but it has to be free for assignment. Then type: explorer This will run explorer as \"Administrator\" and will allow you to browse the mounted system partition. The above may not work for all devices, as some handle UEFI differently. Part 2 - UEFI installation Let's start by downloading the required files. Here is a customized UEFI boot for 32/64-bit machines. Please note that if you came from our Nougat builds to our Bliss OS 8.x builds, you will have to edit the grub.cfga . If you are using Bliss OS 8.x/10.x, please use the grub entry below as a guide: menuentry 'Bliss-x86' --class android { search --file --no-floppy --set=root /AndroidOS/system.sfs linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 quiet DATA= initrd /AndroidOS/initrd.img } If you are installing on ext3 / ext4 , due to a bug in the install you will have to use the following grub entry setup: menuentry 'Bliss-x86' --class android { search --file --no-floppy --set=root /AndroidOS/system.sfs linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 quiet DATA= initrd /AndroidOS/initrd.img } Now that we have the partition mounted, we can copy that BOOT directory to your UEFI partition using explorer as the Administrator or by using the \"New Task\" dialog from Task Manager. (See above if you forgot the steps!) Once it is copied, go back to the Administrator cmd prompt and type: mountvol X: /D or if you used Z: , type: mountvol Z: /D This will dismount the UEFI/ESP volume for safe reboot. We then suggest you use EasyUEFI here to create the UEFI boot entry. Open the app, and create a new entry. Select your UEFI partition, and in the \"File\" Path, click \"Browse\" and use the file manager window to browse to your BOOT/grub/grubx64.efi file. Click OK, and then choose the new grub entry and move it to the top. Make sure Secure Boot is turned off or else it likely will just boot back to Windows. Part 4 - The Manual Blissification of Your PC To do a manual \"Wubi like\" install of Bliss OS after you install the UEFI entry, you will need to open the Bliss OS .iso / .img with 7zip, and then drag all the .img & .sfs files to C:/android-x86 or whatever your target drive is (make sure your grub entries match where you are putting these). Then create your data.img . We suggest using a tool like RMXtools (use version 1.7) from XDA to create it. Check the tool's thread for detailed instructions. You will want to create your data.img inside that android-x86 folder. You can now reboot if you have installed the custom UEFI entry right and selected it using EasyUEFI. You should boot right to the Android-x86 grub theme. There, you can use up and down to select, and return to boot that entry. You can also hit e to edit the selected entry. You will want to pay attention to which entry you select, since there will be one for Bliss-x86(32bit) and one or Bliss-x86_64(64bit) . Install Bliss OS on a VM (virtualbox) This method does require some beefy PC specs, so it might not work for all. Thanks to Chih-Wei Huang from Android-x86 Project for the detailed information! This method is currently being worked on. Check back later for more information! Befor we proceed, if things don't work out, check cat /proc/cpuinfo to determine if your CPU is compatible with virtualization. Specific Surface model instructions Reference posts here and here . Many of you have a Surface device and would like to run Android on it. You're in luck, because this project was started with a Surface Pro 3 to test with back in Android Nougat. The device has since been retired and development has continued on a Surface Book, an IPTS device. This means it requires a specific set of firmware for proper functioning. For all other Surface models, the user must upgrade their own firmware, because it is too large of a burden to build for all Surface models without having those devices to test with. To start, you will need to grab the right firmware for your device. Surface Series Devices: Series 5 devices: Surface Book 2 Surface Pro 2017 Series 4 devices Surface Book Surface Pro 4 Surface Laptop Series 3 devices: Surface Pro 3 For the ipts_firmware files (series 4/5 devices only), please select the correct version for your device: v76 for the Surface Book v78 for the Surface Pro 4 v79 for the Surface Laptop v101 for Surface Book 2 15\" v102 for the Surface Pro 2017 v137 for the Surface Book 2 13\" For the i915_firmware files (series 3/4/5 devices), please select the correct version for your device: kbl for series 5 devices skl for series 4 devices bxt for series 3 devices All firmware files can be found here. For Surface Go users, you will have to remove some files and replace with @jakeday's firmware. Please see this thread on Reddit for detailed information. Once you have the right firmware you need, you should copy it to a folder on your Bliss install ( SD_card_root/surface ), making sure to put the right firmware in the right folders: IPTS firmware: SD_card_root/surface/intel/ipts ath10k firmware (some models): SD_card_root/surface/ath10k mrvl firmware (some models): SD_card_root/surface/mrvl mwlwifi firmware (some models): SD_card_root/surface/mwlwifi nvidia firmware for SB2: SD_card_root/surface/nvidia Next, open a terminal (we include one you can enable in \"Developer Options\"). In the terminal, enter the following commands, giving permission to the superuser popup dialog when prompted: su mv -f SD_card_root/surface/* system/lib/firmware/ Then you can restart: reboot It should recognize and load the correct firmware versions for your device upon reboot if you did everything correctly. Conclusion Thanks for following along! If you want to check out the next guide, click here! Having problems with your new installation? Check out Troubleshooting.","title":"Installation Guide"},{"location":"Bliss OS/installation-guide/#installation-guide","text":"","title":"Installation Guide"},{"location":"Bliss OS/installation-guide/#preface","text":"These instructions are based on the Android-x86 project's installation guide. We have not changed the installer, so the procedure of installation is similar. We also thank @bg260 for his contributions - this guide was adapted partially from his work.","title":"Preface"},{"location":"Bliss OS/installation-guide/#warning","text":"Team Bliss does NOT accept any responsibility . Users must read and understand the instructions, as the installation modifies core system files and carries a significant risk. You accept all responsibility , including but not limited to data loss and other malfunctions by continuing beyond this point. Any questions, install issues, bug reports, etc. MUST be accompanied with the following things: Log Device info Build info (file name) Installation method (exact steps used) Any other relevant information REQUIRED to diagnose your issue as NOT user error If the following information is not supplied, your inquiry will be ignored. These instructions have changed quite a bit for Android Pie, so consider this section a work in progress. Thank you for your patience!","title":"Warning!"},{"location":"Bliss OS/installation-guide/#bootable-installation-method-mbruefiesp-3264-bit","text":"This is the current recommended method! Overview of the steps: Download the ISO file Use Rufus or similar to burn to USB drive Disable Secure Boot, Bitlocker, and any other boot security software such as Veracrypt Boot into the USB drive. Run Bliss OS in Live mode to test things out. If all is well, continue to next step Boot into the USB drive, and choose Bliss OS Install Let's get started!","title":"Bootable installation method - MBR/UEFI/ESP (32/64-bit)"},{"location":"Bliss OS/installation-guide/#part-1-gather-your-tools","text":"Please note that this method is not supported on all machines. Download Rufus and the 32-bit .iso or 64-bit .iso / .img file of Bliss OS, depending on the architecture of the machine you are installing Bliss OS on. You will need a decent speed USB drive (4 GB or larger is recommended).","title":"Part 1 - Gather Your Tools"},{"location":"Bliss OS/installation-guide/#part-2-flashing-bliss-os-to-the-usb-drive","text":"Plug in your USB drive, and load up Rufus. Once loaded, click on the icon next to the ISO Image dropdown menu. Now browse to where you have your Bliss OS (32-bit) .iso , or your Bliss OS (64-bit) .iso / .img file. Once chosen, the dropdown should switch to the correct image type, and fill the rest in for you. Once you are ready, click Start.","title":"Part 2 - Flashing Bliss OS to the USB drive"},{"location":"Bliss OS/installation-guide/#part-3-testing-bliss-os-on-your-system","text":"This is very important! If you, as a user, do NOT test the OS first to make sure it is compatible with your device, please do NOT expect us to help you if you happen to install it blindly and something goes wrong. Reboot your machine, and enter the BIOS. Most motherboards have the default key as \"F2\". Change the boot order so that the USB is the first thing the device will boot to. Once the boot orders are changed, reboot. If everything goes well, you should see a grub boot screen. Select the \"Live CD\" option, and if your machine is compatible, you should then see a little bit of text, and then the Bliss OS boot animation. This will go on for a few minutes, but should eventually boot to Bliss OS. If the system never boots to Bliss OS, this is a bad sign that your system might not be compatible. If it does boot, and you would like to install it, continue to the next step. For those wanting to use root, you will need to install the OS and be running of that install. Root will not function properly in Live Mode.","title":"Part 3 - Testing Bliss OS on your system"},{"location":"Bliss OS/installation-guide/#troubleshooting-booting-from-the-usb-kicks-me-back-to-bios-or-back-to-my-windowsmacoslinux-installation","text":"Your drive is incompatible or you have formatted it incorrectly. Try flashing the image again to the drive with Rufus. If that does not work, your device does not support booting from USB and you will have to try an alternate method.","title":"Troubleshooting - Booting from the USB kicks me back to BIOS, or back to my Windows/macOS/Linux installation."},{"location":"Bliss OS/installation-guide/#part-3-alternate-using-bliss-os-from-your-usb-drive","text":"If you choose to use Bliss from the USB drive, the data you modify or create on the live install will be in an ephemeral state unless you create a data.img to store the data. You can create a data.img in the root directory of the USB drive (make sure you have a minimum of 4-5 GB free on the drive). We suggest using a tool like RMXtools from XDA to create it (version 1.7 is recommended). Check the tool's thread for detailed usage instructions. You will want to create your data.img inside the root directory of your USB drive, with all the other .img files. From there, just boot into live mode, setup your system the way you want, and the data should be persistant across reboots.","title":"Part 3 (alternate) - Using Bliss OS from your USB drive"},{"location":"Bliss OS/installation-guide/#part-4-setting-up-and-installing-bliss-os-on-your-hddssdsd-card","text":"Quick warning again, in case you missed it. Team Bliss is NOT responsible , directly or indirectly, for any damages caused by this guide. By continuing, you automatically agree to these terms. This is where things start to get a little tricky, especially with how devices vary. Make sure you have a backup plan in case something goes wrong. Start off by opening your favorite partition management software, such as Disk Management in Windows, and create a new partition, making it the size you want (suggested minimum is 8 GB). Just format it to NTFS for now, because it will be formatted by the installer later into the process anyway. Remember what drive you have created here as it's important later on. For Windows machines, it will typically be sda4 or sda5 . Also create another 300 MB FAT32 partition for the grub bootloader to install to. (This part might require a third-party partition manager as Windows Disk Management might not let it be that small.) Boot up the Bliss OS USB, and select the \"Installation\" option in grub . (It is the second one down, usually.) The installer will load, and you will have an option to choose the partition you created earlier. Pick it, and select ext4 . DO NOT blindly choose the partition, as an incorrect flash can mess up your drive and cause serious data loss. You do NOT want to get this step wrong. If you are unsure, boot back into Windows/macOS/Linux and write it down. When it asks if you want to install system as R/W, select \"YES\" if you want to use root (SuperSU), and \"No\" if you do not need root. When it asks if you want to install grub , select \"Grub for Legacy BIOS boot type\", \"Grub2 for UEFI boot type\", or neither if you are already running a Linux system. If you chose to install grub , the installer will allow you to choose the partition to install grub to. Make sure you select the 300 MB partition you set up earlier for grub . The process will install and create the data directory/image, so be patient. When finished, the installer will then ask if you want to run Android-x86. You can just reboot here. Make sure you remove the USB drive. If we have followed all the directions correctly, you should be presented with a grub boot menu. You can choose your bliss_android_x86 option (or android-x86 ), and it will boot into Bliss OS. If you want to customize your grub boot entry, search the web first. We use the same grub setup that the Android-x86 project uses, so their forums will contain just about all the info you will need. Congratulations! We hope you enjoy using Bliss OS.","title":"Part 4 - Setting up and Installing Bliss OS on your HDD/SSD/SD card"},{"location":"Bliss OS/installation-guide/#windows-based-installer-uefiesp-64-bit","text":"This method is no longer supported due to too many people not understanding computer basics and breaking things. Proceed at your own risk. This method might be the easiest currently if you understand what you are doing. For the overall instructions on using this method, please refer to the tool's original thread . The tools have been updated by Team Bliss for easy installation on UEFI/ESP machines. The builds we produce can be found here. And the source for those builds can be found here. This tool should work on Remix OS as well, but this has not been tested yet.","title":"Windows-based installer - UEFI/ESP (64-bit)"},{"location":"Bliss OS/installation-guide/#part-1-using-the-installer","text":"The installer has been updated to accept the .iso files for our 8.x/10.x/11.x releases. Just follow the prompts the installer gives. Refer to the original thread for any questions, and please search before asking. If you plan on using root, the process will require you to manually extract the system.img from within the system.sfs file. Then you must delete the system.sfs file after extracting. Warning - for Pie, you will need to add androidboot.hardware=android_x86_64 to the grub entry in order to boot!","title":"Part 1 - Using the Installer"},{"location":"Bliss OS/installation-guide/#part-2-switching-the-uefiefi-boot-entry","text":"Option one is to use the EasyUEFI tool, then switch the UEFI/EFI entry it created to boot first. Close and reboot. Option two is to use your BIOS to select the added UEFI boot entry.","title":"Part 2 - Switching the UEFI/EFI boot entry"},{"location":"Bliss OS/installation-guide/#use-syslinux-efi-to-run-bliss-os-7x10x11x","text":"Thanks to @IcedCube for the original post! This method is NOT recommended as it is fairly bleeding-edge and experimental, but it should help booting on Chinese tablets that do not want to run grub . Use a Linux installation for the following procedure.","title":"Use syslinux EFI to run Bliss OS 7.x/10.x/11.x"},{"location":"Bliss OS/installation-guide/#part-1-grab-the-required-tools","text":"Install unsquashfs (part of squashfs-tools ).","title":"Part 1 - Grab the required tools"},{"location":"Bliss OS/installation-guide/#part-2-get-bliss-os","text":"Grab the latest build of Bliss OS 7.x/10.x/11.x.","title":"Part 2 - Get Bliss OS"},{"location":"Bliss OS/installation-guide/#part-3-get-the-syslinux-efi-bootstrap","text":"Grab the .zip file from @IcedCube's original post , and extract it to the root of the USB drive. This will bootstrap syslinux EFI onto it. Then, make a folder called android . Now, open up the .iso in an archive program. Extract the following files form the root directory of the .iso image to the USB drive's android folder: initrd.img ramdisk.img kernel Extract system.sfs to a folder somewhere, such as /tmp . Open a terminal and change directory (using cd ) to /tmp . Run ls and confirm that system.sfs is shown in the file list. If there is no output, start over as the file is misplaced. Run the following: unsquashfs ./system.sfs This will make a new directory called squashfs_root .","title":"Part 3 - Get the syslinux EFI bootstrap"},{"location":"Bliss OS/installation-guide/#part-4-version-specific","text":"","title":"Part 4 - Version specific"},{"location":"Bliss OS/installation-guide/#if-you-are-using-bliss-7x","text":"Change directory to squashfs_root and run ls . There should only be one file - a system.img inside the directory. Copy the file to the USB's android folder.","title":"If you are using Bliss 7.x"},{"location":"Bliss OS/installation-guide/#if-you-are-using-bliss-10x","text":"Change directory to squashfs_root . The structure is a complete Android root filesystem. To install Bliss OS, the files will need to be in a system image. The following steps will guide you through creating a 2 GB system.img file, formatting it, mounting it, and copying the contents of squashfs_root into the new disk image. Execute: mkdir /mnt/tempMount truncate /tmp/system.img --size=2G mkfs.ext4 -m0 /tmp/system.img sudo mount -o loop /tmp/system.img /mnt/tempMount sudo cp -prv /tmp/squashfs_root/* /mnt/tempMount/ sync sudo umount /mnt/tempMount The sync command might take some time. Now copy the /tmp/system.img file to your USB's Android folder.","title":"If you are using Bliss 10.x"},{"location":"Bliss OS/installation-guide/#part-5-creating-the-data-image","text":"First, find where your USB drive is mounted. It is usually in /mnt or /media (ex. /media/USB ). cd into the android folder. We will create a 3 GB data image file. You can attempt to create a 4 GB image but FAT32 maxes out at 4 GB per file. If your system supports exFAT or NTFS, you may try and use it. truncate data.img --size=3G mkfs.ext4 -m0 data.img sync This will be an completely empty ext4 disk image, but will be enough to run Bliss. Finally, check to ensure everything is in structured like so: <ROOT> - syslinux.cfg - android/ -- kernel -- system.img -- data.img -- ramdisk.img -- initrd.img - EFI/ -- BOOT/ --- bootia32.efi --- bootx64.efi --- ldlinux.e32 --- ldlinux.e64 Need to add some kernel parameters? Open syslinux.cfg and add them before the initrd=/android/initrd.img statement. Unmount the USB from your computer. Plug it into your device and use the BIOS to boot from your UEFI USB Drive, partition 1. If all goes well, you will get a black screen with small white text saying \"Booting Android...\" followed by loading files. You should get the Linux kernel text, then see the Bliss boot animation play after a couple minutes depending on your USB drive read/write speed.","title":"Part 5 - Creating the data image"},{"location":"Bliss OS/installation-guide/#custom-install-bliss-os-8x10x11x-uefiesp-64-bit","text":"Just as a reminder, Team Bliss is NOT responsible for any damage caused by this guide. By continuing, you automatically agree to these terms.","title":"Custom Install - Bliss OS 8.x/10.x/11.x UEFI/ESP (64-bit)"},{"location":"Bliss OS/installation-guide/#part-1-mounting-your-uefiesp-partition","text":"You will want to make sure you can view hidden and system files in Explorer options. Once you do that, hit the start menu, and type in cmd . Once \"Command Prompt\" shows up, right click on it and choose \"Open as administrator\".","title":"Part 1 - Mounting Your UEFI/ESP Partition"},{"location":"Bliss OS/installation-guide/#cmd-is-not-showing-up-what-should-i-do","text":"Press the Windows key and the R key to bring up the \"Run...\" dialog. Type in cmd , and then press Ctrl-Shift-Enter. Press \"Yes\" on the UAC popup. Run the following: mountvol X: /S Then check to see if it is mounted already. Run \"Task Manager\" by either Pressing Ctrl-Alt-Del and then clicking on \"Task Manager\", or Pressing Ctrl-Shift-Esc Click on \"File\", \"Run new task\", \"Browse\", \"This computer\", and SYSTEM (X or type in X: in the filepath bar. If you cannot access X: , then that could mean one of three things. You have an ESP setup (follow the installation method below) You have a legacy MBR setup Your setup has a custom boot sequence","title":"cmd is not showing up, what should I do?"},{"location":"Bliss OS/installation-guide/#part-1-alternate-esp-setup","text":"Windows 10 sometimes has an EFI partition already mounted under drive letter Z: , hidden. A very quick and easy way to access the ESP (EFI System Partition) in Windows 10 without using the command line is to start \"Task Manager\" (check above if you forgot the steps), and then click on \"File\", \"Run new task\", \"Browse\", \"This computer\", and SYSTEM (Z or type in Z: in the filepath bar). Now go to boot/grub/grub.cfg and edit it accordingly with Notepad++ or another text editor. Save the file and your're ready to go!","title":"Part 1 (alternate) - ESP setup"},{"location":"Bliss OS/installation-guide/#part-1-alternate-killing-the-explorerexe","text":"Run cmd as admin and enter the following command: taskkill /im explorer.exe /f This will kill the explorer.exe process - don't be surprised if it shows a warning. This step is sometimes required, because by default explorer.exe is ran by the currently logged in user, and it has to be run by the \"Administrator\" in order to view the mounted system drive. The \"Administrator\" account is not the same as an account with administrative privileges. mountvol X: /s This will mount the system partition that usually consists of UEFI related files. X: is the letter of the drive - you can use whatever letter you want, but it has to be free for assignment. Then type: explorer This will run explorer as \"Administrator\" and will allow you to browse the mounted system partition. The above may not work for all devices, as some handle UEFI differently.","title":"Part 1 (alternate) - Killing the explorer.exe"},{"location":"Bliss OS/installation-guide/#part-2-uefi-installation","text":"Let's start by downloading the required files. Here is a customized UEFI boot for 32/64-bit machines. Please note that if you came from our Nougat builds to our Bliss OS 8.x builds, you will have to edit the grub.cfga . If you are using Bliss OS 8.x/10.x, please use the grub entry below as a guide: menuentry 'Bliss-x86' --class android { search --file --no-floppy --set=root /AndroidOS/system.sfs linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 quiet DATA= initrd /AndroidOS/initrd.img } If you are installing on ext3 / ext4 , due to a bug in the install you will have to use the following grub entry setup: menuentry 'Bliss-x86' --class android { search --file --no-floppy --set=root /AndroidOS/system.sfs linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 quiet DATA= initrd /AndroidOS/initrd.img } Now that we have the partition mounted, we can copy that BOOT directory to your UEFI partition using explorer as the Administrator or by using the \"New Task\" dialog from Task Manager. (See above if you forgot the steps!) Once it is copied, go back to the Administrator cmd prompt and type: mountvol X: /D or if you used Z: , type: mountvol Z: /D This will dismount the UEFI/ESP volume for safe reboot. We then suggest you use EasyUEFI here to create the UEFI boot entry. Open the app, and create a new entry. Select your UEFI partition, and in the \"File\" Path, click \"Browse\" and use the file manager window to browse to your BOOT/grub/grubx64.efi file. Click OK, and then choose the new grub entry and move it to the top. Make sure Secure Boot is turned off or else it likely will just boot back to Windows.","title":"Part 2 - UEFI installation"},{"location":"Bliss OS/installation-guide/#part-4-the-manual-blissification-of-your-pc","text":"To do a manual \"Wubi like\" install of Bliss OS after you install the UEFI entry, you will need to open the Bliss OS .iso / .img with 7zip, and then drag all the .img & .sfs files to C:/android-x86 or whatever your target drive is (make sure your grub entries match where you are putting these). Then create your data.img . We suggest using a tool like RMXtools (use version 1.7) from XDA to create it. Check the tool's thread for detailed instructions. You will want to create your data.img inside that android-x86 folder. You can now reboot if you have installed the custom UEFI entry right and selected it using EasyUEFI. You should boot right to the Android-x86 grub theme. There, you can use up and down to select, and return to boot that entry. You can also hit e to edit the selected entry. You will want to pay attention to which entry you select, since there will be one for Bliss-x86(32bit) and one or Bliss-x86_64(64bit) .","title":"Part 4 - The Manual Blissification of Your PC"},{"location":"Bliss OS/installation-guide/#install-bliss-os-on-a-vm-virtualbox","text":"This method does require some beefy PC specs, so it might not work for all. Thanks to Chih-Wei Huang from Android-x86 Project for the detailed information! This method is currently being worked on. Check back later for more information! Befor we proceed, if things don't work out, check cat /proc/cpuinfo to determine if your CPU is compatible with virtualization.","title":"Install Bliss OS on a VM (virtualbox)"},{"location":"Bliss OS/installation-guide/#specific-surface-model-instructions","text":"Reference posts here and here . Many of you have a Surface device and would like to run Android on it. You're in luck, because this project was started with a Surface Pro 3 to test with back in Android Nougat. The device has since been retired and development has continued on a Surface Book, an IPTS device. This means it requires a specific set of firmware for proper functioning. For all other Surface models, the user must upgrade their own firmware, because it is too large of a burden to build for all Surface models without having those devices to test with. To start, you will need to grab the right firmware for your device. Surface Series Devices: Series 5 devices: Surface Book 2 Surface Pro 2017 Series 4 devices Surface Book Surface Pro 4 Surface Laptop Series 3 devices: Surface Pro 3 For the ipts_firmware files (series 4/5 devices only), please select the correct version for your device: v76 for the Surface Book v78 for the Surface Pro 4 v79 for the Surface Laptop v101 for Surface Book 2 15\" v102 for the Surface Pro 2017 v137 for the Surface Book 2 13\" For the i915_firmware files (series 3/4/5 devices), please select the correct version for your device: kbl for series 5 devices skl for series 4 devices bxt for series 3 devices All firmware files can be found here. For Surface Go users, you will have to remove some files and replace with @jakeday's firmware. Please see this thread on Reddit for detailed information. Once you have the right firmware you need, you should copy it to a folder on your Bliss install ( SD_card_root/surface ), making sure to put the right firmware in the right folders: IPTS firmware: SD_card_root/surface/intel/ipts ath10k firmware (some models): SD_card_root/surface/ath10k mrvl firmware (some models): SD_card_root/surface/mrvl mwlwifi firmware (some models): SD_card_root/surface/mwlwifi nvidia firmware for SB2: SD_card_root/surface/nvidia Next, open a terminal (we include one you can enable in \"Developer Options\"). In the terminal, enter the following commands, giving permission to the superuser popup dialog when prompted: su mv -f SD_card_root/surface/* system/lib/firmware/ Then you can restart: reboot It should recognize and load the correct firmware versions for your device upon reboot if you did everything correctly.","title":"Specific Surface model instructions"},{"location":"Bliss OS/installation-guide/#conclusion","text":"Thanks for following along! If you want to check out the next guide, click here! Having problems with your new installation? Check out Troubleshooting.","title":"Conclusion"},{"location":"Bliss OS/troubleshooting/","text":"Troubleshooting 32-bit processors only (Intel Atom and similar) Install Android-x86 32-bit OS from here (doesn't matter which version, as long as it's 32-bit) Update with Bliss OS 32-bit (current version is 11.9). After reboot you should be able to access the grub menu. In grub menu select \"Debug mode\" Run the following commands: mount -o remount, rw /mnt cd /mnt/grub nano menu.lst Add nomodeset before every \"SCR=**\" line. For example, your configuration should look something like this: nomodeset SCR=700 nomodeset SCR=716 nomodeset SCR=795 Press Ctrl+O to save, and then Ctrl+X to close. Type reboot -f You should be finished! If all goes well you will boot into Bliss OS on your 32-bit machine. grub2 kernel parameters and options You will want to pay attention here! With Bliss OS on the PC, we tend to use quite a few command line options to get things working right. We've gathered a few of them here to explain them a little bit. A full list of available kernel parameters can be found here. Brief options overview: parameter : Description root= : Root filesystem. rootflags= : Root filesystem mount options. initrd= : Specify the location of the initial ramdisk. init= : Run specified binary instead of /sbin/init (symlinked to systemd in Arch) as init process. init=/bin/sh : Boot to shell. systemd.unit= : Boot to a specified target. nomodeset : Disable kernel mode setting (useful for fixing video driver panics) This will load mostly everything in software rendering/support mode. No hardware acceleration. Good for debugging. panic= : Time before automatic reboot on kernel panic. debug : Enable kernel debugging (events log level). mem= : Force usage of a specific amount of memory to be used. maxcpus= : Maximum number of processors that an SMP kernel will bring up during bootup. selinux= : Disable or enable SELinux at boot time. netdev= : Network devices parameters. video=<videosetting> : Override framebuffer video defaults. sleep=1 : This will enable the system.prop value for sleep.earlysuspend=1 , and on some machines, it enables the proper sleep state. acpi_sleep=s3_bios,s3_mode : Sometimes needed for older machines to enter sleep mode properly SETUPWIZARD=0 : This command will skip SetupWizard on boot. (Only needs to be run once!) AUTO_LOAD=old : This will load android-x86 variants using the old modprobe method to init devices. We sometimes use this to debug devices not starting. DEBUG=1 & DEBUG=2 : These enable verbose console debugging, giving another command shell after loading kernel modules, but before Android init vga=xxx & video= : These are the common video modes that you can boot into if it doesn't pick the best choice automagically. You can also use video= as resolution parameters: video=LVDS-1:d video=1366x800 . Learn more from our own Henri Koivuneva! HWACCELL=1 : This will disable graphics hardware acceleration, enabling rendering through Swiftshader. (Must use this if running headless) buildvariant=eng, user, userdebug : This is the commandline parameter to run the current build as eng , userdebug , or user DPI=xxx : This will manually set the DPI on init. Use this if things are too big/small for you. fbcon=variablename : This is to configure framebuffer to use various options. Usually used to help fix video settings, etc. Even default rotation on some Atom tablets. Example: video=efifb fbcon=rotate:1 VULKAN=1 : Required for Vulkan-supported chipsets. This enables hwcomposer to work right with screenshots and other things. As an example, here are a few of the boot options used in testing: menuentry 'Bliss-x86 Test-Oreo' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng quiet sleep.earlysuspend=2 DATA= initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo AUTO_LOAD=old' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng quiet DATA= AUTO_LOAD=old initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo - SETUP_WIZARD=0' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive buildvariant=eng SETUPWIZARD=0 quiet DATA= initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo - debug=1' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng SETUPWIZARD=0 quiet DATA= DEBUG=1 initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo - debug=2' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng SETUPWIZARD=0 quiet DATA= DEBUG=2 initrd /AndroidOS/initrd.img }","title":"Troubleshooting"},{"location":"Bliss OS/troubleshooting/#troubleshooting","text":"","title":"Troubleshooting"},{"location":"Bliss OS/troubleshooting/#32-bit-processors-only-intel-atom-and-similar","text":"Install Android-x86 32-bit OS from here (doesn't matter which version, as long as it's 32-bit) Update with Bliss OS 32-bit (current version is 11.9). After reboot you should be able to access the grub menu. In grub menu select \"Debug mode\" Run the following commands: mount -o remount, rw /mnt cd /mnt/grub nano menu.lst Add nomodeset before every \"SCR=**\" line. For example, your configuration should look something like this: nomodeset SCR=700 nomodeset SCR=716 nomodeset SCR=795 Press Ctrl+O to save, and then Ctrl+X to close. Type reboot -f You should be finished! If all goes well you will boot into Bliss OS on your 32-bit machine.","title":"32-bit processors only (Intel Atom and similar)"},{"location":"Bliss OS/troubleshooting/#grub2-kernel-parameters-and-options","text":"You will want to pay attention here! With Bliss OS on the PC, we tend to use quite a few command line options to get things working right. We've gathered a few of them here to explain them a little bit. A full list of available kernel parameters can be found here. Brief options overview: parameter : Description root= : Root filesystem. rootflags= : Root filesystem mount options. initrd= : Specify the location of the initial ramdisk. init= : Run specified binary instead of /sbin/init (symlinked to systemd in Arch) as init process. init=/bin/sh : Boot to shell. systemd.unit= : Boot to a specified target. nomodeset : Disable kernel mode setting (useful for fixing video driver panics) This will load mostly everything in software rendering/support mode. No hardware acceleration. Good for debugging. panic= : Time before automatic reboot on kernel panic. debug : Enable kernel debugging (events log level). mem= : Force usage of a specific amount of memory to be used. maxcpus= : Maximum number of processors that an SMP kernel will bring up during bootup. selinux= : Disable or enable SELinux at boot time. netdev= : Network devices parameters. video=<videosetting> : Override framebuffer video defaults. sleep=1 : This will enable the system.prop value for sleep.earlysuspend=1 , and on some machines, it enables the proper sleep state. acpi_sleep=s3_bios,s3_mode : Sometimes needed for older machines to enter sleep mode properly SETUPWIZARD=0 : This command will skip SetupWizard on boot. (Only needs to be run once!) AUTO_LOAD=old : This will load android-x86 variants using the old modprobe method to init devices. We sometimes use this to debug devices not starting. DEBUG=1 & DEBUG=2 : These enable verbose console debugging, giving another command shell after loading kernel modules, but before Android init vga=xxx & video= : These are the common video modes that you can boot into if it doesn't pick the best choice automagically. You can also use video= as resolution parameters: video=LVDS-1:d video=1366x800 . Learn more from our own Henri Koivuneva! HWACCELL=1 : This will disable graphics hardware acceleration, enabling rendering through Swiftshader. (Must use this if running headless) buildvariant=eng, user, userdebug : This is the commandline parameter to run the current build as eng , userdebug , or user DPI=xxx : This will manually set the DPI on init. Use this if things are too big/small for you. fbcon=variablename : This is to configure framebuffer to use various options. Usually used to help fix video settings, etc. Even default rotation on some Atom tablets. Example: video=efifb fbcon=rotate:1 VULKAN=1 : Required for Vulkan-supported chipsets. This enables hwcomposer to work right with screenshots and other things. As an example, here are a few of the boot options used in testing: menuentry 'Bliss-x86 Test-Oreo' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng quiet sleep.earlysuspend=2 DATA= initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo AUTO_LOAD=old' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng quiet DATA= AUTO_LOAD=old initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo - SETUP_WIZARD=0' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive buildvariant=eng SETUPWIZARD=0 quiet DATA= initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo - debug=1' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng SETUPWIZARD=0 quiet DATA= DEBUG=1 initrd /AndroidOS/initrd.img } menuentry 'Bliss-x86 Test-Oreo - debug=2' --class bliss { search --file --no-floppy --set=root /AndroidOS/android.boot linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive androidboot.hardware=android_x86_64 buildvariant=eng SETUPWIZARD=0 quiet DATA= DEBUG=2 initrd /AndroidOS/initrd.img }","title":"grub2 kernel parameters and options"},{"location":"BlissRoms/","text":"Index New to building? Start here with the Build Guide. Want to build more efficiently? Find out some helpful optimization tips.","title":"Index"},{"location":"BlissRoms/#index","text":"New to building? Start here with the Build Guide. Want to build more efficiently? Find out some helpful optimization tips.","title":"Index"},{"location":"BlissRoms/build-guide/","text":"Build Guide Updated for Pie (p9.0) Introduction This is the official guide to build BlissRoms for your device. In this guide, we will only cover official devices with actual maintainers. We will not delve into porting devices. The golden rule to building is patience. If something breaks, wait for your maintainer to fix it, send a polite message to your maintainer, or better yet, try and fix it yourself. Then you can make a merge request and contribute! Let\u2019s get started. Preparation To get started, you need a computer with Ubuntu 18.04 (LTS), at least 200GB space of HDD, and at least 8GB RAM. A decent CPU (or CPUs if you have a server motherboard) is recommended. Other distros can work but is not officially supported in this guide. Underpowered machines may crash during compilation. If that happens, you may try and restart the build as most crashes are caused by lack of memory. If your storage space has run out, then you will need to build on a different hard drive. Install the JDK Install OpenJDK: sudo apt install openjdk-8-jdk Install build tools To install the required build tools, run the following command: sudo apt install git gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev lib32z1-dev ccache libgl1-mesa-dev libxml2 libxml2-utils xsltproc unzip squashfs-tools python python-mako libssl-dev ninja-build lunzip syslinux syslinux-utils gettext genisoimage bc xorriso liblz4-tool libncurses5-dev libsdl1.2-dev libwxgtk3.0-dev lzop maven pngcrush schedtool lib32readline-dev Install source code tools Now we need to get the source code via a program named repo , made by Google. The primary function of repo is to read a manifest file located in BlissRoms's GitHub organization, and find what repositories you need to actually build Android. Create a ~/bin directory for repo : mkdir -p ~/bin The -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 : curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo Make repo executable: chmod a+x ~/bin/repo And add it to PATH: nano .bashrc Scroll to the end of the file and type these lines: # Export ~/bin export PATH=~/bin:$PATH Ctrl-O and enter to save, then Ctrl-X to exit nano. Now either logout and login again (or reboot), or source the file: source .bashrc Which can be shortened to: . .bashrc What is 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! But why do you need to run it after modifying a file? Well, 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! What if I need repo globally? If you need the 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: curl https://storage.googleapis.com/git-repo-downloads/repo > ~/repo sudo mv ~/repo /usr/bin/ chmod a+x /usr/bin/repo repo will now work anywhere, without any .bashrc modifications. However, these steps aren\u2019t recommended as repo might become a security risk if a vulnerability is found. Now we\u2019re ready to download the source code. Download Create a directory for the source: mkdir -p ~/bliss/p9.0 cd ~/bliss/p9.0 Before we download, we need to tell repo and git who we are. Run the following commands, substituting your information: git config --global user.email \u201crandy.mcrandyface@hotmail.net\u201d git config --global user.name \u201cRandy McRandyface\u201d Now, we\u2019re ready to initialize. We need to tell repo which manifest to read: repo init -u https://github.com/BlissRoms/platform_manifest.git -b p9.0 -b is for the branch, and we\u2019re on p9.0 , Android Pie. It\u2019ll take a couple of seconds. You may need to type y for the color prompt. Then sync the source: repo sync -j24 -c -j is for threads. Typically, your CPU core count is your thread count, unless you\u2019re 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: repo sync -j4 -c -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\u2019t want the entire history to be downloaded. This is used by default unless specified otherwise. I still don't know how much CPU threads I have. How do I check? Run nproc . The output should be something like this: rwaterspf1@test:~$ nproc 24 This means that there are 24 threads in your machine. repo will start downloading all the code. That\u2019s going to be slow, even on a fiber network. Expect downloads to take more than a couple hours. Build Set up the build environment: . build/envsetup.sh This is the initialization file we talked about earlier up top. This \"initializes\" the environment, and imports a bunch of useful build commands required to build your device. Again, you need to remember to source this file every time you log out and log back in, or launch a new bash /Terminal instance. Define what device you\u2019re going to build. For example, the Nexus 5X, has a codename of bullhead . You can check your specific device's codename on GitHub or on Google. Execute: breakfast bullhead What does this do? breakfast searches repositories for your device \"tree\", which contains all the details needed to make the build suitable for your device. CPU, kernel info, device screen size, whether the board has Bluetooth, NFC, what frequencies the build needs for Wi-Fi, and a bunch of other things. breakfast will automatically search in the BlissRoms-Devices GitHub repository, and grab your device tree for you. Okay, so we have the device tree set up. Feel free to browse around the source code to see what changed. You should see folders added to device/ , kernel/ and vendor/ . A shortcut: croot will dump you back in the root of the source code tree. So if you\u2019ve been going through folders and don\u2019t have any idea where you are, you can use the above command. This command, however, requires you to have source d build/envsetup.sh earlier. We're ready to build, but before we teach you the easy command to execute a build, we will first try the manual method. To set up the current terminal environment for building your particular device, execute: lunch bliss_bullhead-userdebug Let's break down the command. 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. bliss_ is the ROM that we are building. As convention, all devices will have this prefix. bullhead is the specific device we are building - in this case, the Nexus 5X. 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. My device isn't booting, and userdebug won't print any adb logcat s. What gives? There is a third build variant called 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! All set? Let's start the building process. Run: mka blissify And the build should start. The build process will take a long time. Prepare to wait a few hours, even on a decent machine. Why mka and not make ? make only runs with 1 thread. mka is properly aliased to use all of your threads by checking nproc . If you want to customize your thread count (maybe you're building with a fan-screaming laptop in a quiet coffee shop), use make -j# , replacing the hash with the number of threads (example of make -j4 ). I get an error about no blissify targets to build against, what's wrong? If you are building other ROMs, it is usually make bacon . For BlissRoms, we chose the build target of blissify . If that doesn't work, sometimes there is a bug, or the ROM developers do not implement a bacon target to build against. In this case, you will need to find what name they use to initialize a full build of the ROM. Conventionally, it is supposed to be bacon , but some ROM developers change this name inadvertently, or actually have a bug that causes the build target to never be found. If you cannot locate the build target, ask the developers of the ROM. Alternatively, you can try poking around in build/make/core/Makefile to see what the build target name is. But this is out of the scope of this article as you're not supposed to be building other ROMs (that's not what this tutorial is for, sorry!) All right, but that's annoying. You had to type three commands to build it all. What about running one command? blissify bullhead But what is blissify ? It is a compact form of these commands: breakfast bullhead lunch bliss_bullhead-userdebug make blissify Sounds great, right? Once you have run the command, jump over to the next section. After building There are two outcomes to a build - either it fails and you get a red error message from 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. If you face the latter, congratulations! You've successfully built BlissRoms for your device. Grab the artifacts for your device: cd out/target/product/bullhead/ In here, you\u2019ll find a .zip that goes along the lines of Bliss-v11.9-Stable-bullhead-UNOFFICIAL-20190531.zip . Install TWRP, flash the build to your device, and enjoy! Troubleshooting If your build failed, there are a couple things you can try. Try a fresh 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. Make sure your dependencies are installed correctly. Error messages help out a lot here! Often it will say shared/linked library not found or something along those lines. Make sure you sourced 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 sync ed do this again. Make sure you\u2019re at the root of the build tree. Again, to quickly jump there, use croot . Make sure you ran breakfast correctly and it did not error out. Missing device files will prevent successful builds. Make sure your computer itself isn\u2019t faulty. HDDs usually die first, followed by RAM. SSDs rarely die but failure is not unheard of. In extremely rare cases, your CPU may have a defect. If you're unsure, run a stress test using a program like Prime95. If something goes wrong and you've tried everything above, first use Google to look up your error! Most of the errors you encounter is due to misconfiguration and wrong commands entered. More often than not, Google will have the answer you are looking for. If you're still stuck and nothing fixes the problem, then ask us via our Telegram Build Support chat. Conclusion Building a ROM is very hard and tedious and the results are very rewarding! If you managed to follow along, congratulations! After you finish building, you can try out the Git Started guide. Make changes, commit, and send them off to our Gerrit for review! Or better yet, download experimental commits not ready for the mainline repositories and review them! Again, ROM building is a fun project you can work with. I hope this guide was a lot of fun to run through! -- Eric Park (ideaman924) Looking for the next tutorial? Check out some tips to optimize your build experience.","title":"Build Guide"},{"location":"BlissRoms/build-guide/#build-guide","text":"","title":"Build Guide"},{"location":"BlissRoms/build-guide/#updated-for-pie-p90","text":"","title":"Updated for Pie (p9.0)"},{"location":"BlissRoms/build-guide/#introduction","text":"This is the official guide to build BlissRoms for your device. In this guide, we will only cover official devices with actual maintainers. We will not delve into porting devices. The golden rule to building is patience. If something breaks, wait for your maintainer to fix it, send a polite message to your maintainer, or better yet, try and fix it yourself. Then you can make a merge request and contribute! Let\u2019s get started.","title":"Introduction"},{"location":"BlissRoms/build-guide/#preparation","text":"To get started, you need a computer with Ubuntu 18.04 (LTS), at least 200GB space of HDD, and at least 8GB RAM. A decent CPU (or CPUs if you have a server motherboard) is recommended. Other distros can work but is not officially supported in this guide. Underpowered machines may crash during compilation. If that happens, you may try and restart the build as most crashes are caused by lack of memory. If your storage space has run out, then you will need to build on a different hard drive.","title":"Preparation"},{"location":"BlissRoms/build-guide/#install-the-jdk","text":"Install OpenJDK: sudo apt install openjdk-8-jdk","title":"Install the JDK"},{"location":"BlissRoms/build-guide/#install-build-tools","text":"To install the required build tools, run the following command: sudo apt install git gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev lib32z1-dev ccache libgl1-mesa-dev libxml2 libxml2-utils xsltproc unzip squashfs-tools python python-mako libssl-dev ninja-build lunzip syslinux syslinux-utils gettext genisoimage bc xorriso liblz4-tool libncurses5-dev libsdl1.2-dev libwxgtk3.0-dev lzop maven pngcrush schedtool lib32readline-dev","title":"Install build tools"},{"location":"BlissRoms/build-guide/#install-source-code-tools","text":"Now we need to get the source code via a program named repo , made by Google. The primary function of repo is to read a manifest file located in BlissRoms's GitHub organization, and find what repositories you need to actually build Android. Create a ~/bin directory for repo : mkdir -p ~/bin The -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 : curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo Make repo executable: chmod a+x ~/bin/repo And add it to PATH: nano .bashrc Scroll to the end of the file and type these lines: # Export ~/bin export PATH=~/bin:$PATH Ctrl-O and enter to save, then Ctrl-X to exit nano. Now either logout and login again (or reboot), or source the file: source .bashrc Which can be shortened to: . .bashrc","title":"Install source code tools"},{"location":"BlissRoms/build-guide/#what-is-source","text":"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! But why do you need to run it after modifying a file? Well, 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!","title":"What is source?"},{"location":"BlissRoms/build-guide/#what-if-i-need-repo-globally","text":"If you need the 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: curl https://storage.googleapis.com/git-repo-downloads/repo > ~/repo sudo mv ~/repo /usr/bin/ chmod a+x /usr/bin/repo repo will now work anywhere, without any .bashrc modifications. However, these steps aren\u2019t recommended as repo might become a security risk if a vulnerability is found. Now we\u2019re ready to download the source code.","title":"What if I need repo globally?"},{"location":"BlissRoms/build-guide/#download","text":"Create a directory for the source: mkdir -p ~/bliss/p9.0 cd ~/bliss/p9.0 Before we download, we need to tell repo and git who we are. Run the following commands, substituting your information: git config --global user.email \u201crandy.mcrandyface@hotmail.net\u201d git config --global user.name \u201cRandy McRandyface\u201d Now, we\u2019re ready to initialize. We need to tell repo which manifest to read: repo init -u https://github.com/BlissRoms/platform_manifest.git -b p9.0 -b is for the branch, and we\u2019re on p9.0 , Android Pie. It\u2019ll take a couple of seconds. You may need to type y for the color prompt. Then sync the source: repo sync -j24 -c -j is for threads. Typically, your CPU core count is your thread count, unless you\u2019re 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: repo sync -j4 -c -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\u2019t want the entire history to be downloaded. This is used by default unless specified otherwise.","title":"Download"},{"location":"BlissRoms/build-guide/#i-still-dont-know-how-much-cpu-threads-i-have-how-do-i-check","text":"Run nproc . The output should be something like this: rwaterspf1@test:~$ nproc 24 This means that there are 24 threads in your machine. repo will start downloading all the code. That\u2019s going to be slow, even on a fiber network. Expect downloads to take more than a couple hours.","title":"I still don't know how much CPU threads I have. How do I check?"},{"location":"BlissRoms/build-guide/#build","text":"Set up the build environment: . build/envsetup.sh This is the initialization file we talked about earlier up top. This \"initializes\" the environment, and imports a bunch of useful build commands required to build your device. Again, you need to remember to source this file every time you log out and log back in, or launch a new bash /Terminal instance. Define what device you\u2019re going to build. For example, the Nexus 5X, has a codename of bullhead . You can check your specific device's codename on GitHub or on Google. Execute: breakfast bullhead What does this do? breakfast searches repositories for your device \"tree\", which contains all the details needed to make the build suitable for your device. CPU, kernel info, device screen size, whether the board has Bluetooth, NFC, what frequencies the build needs for Wi-Fi, and a bunch of other things. breakfast will automatically search in the BlissRoms-Devices GitHub repository, and grab your device tree for you. Okay, so we have the device tree set up. Feel free to browse around the source code to see what changed. You should see folders added to device/ , kernel/ and vendor/ . A shortcut: croot will dump you back in the root of the source code tree. So if you\u2019ve been going through folders and don\u2019t have any idea where you are, you can use the above command. This command, however, requires you to have source d build/envsetup.sh earlier. We're ready to build, but before we teach you the easy command to execute a build, we will first try the manual method. To set up the current terminal environment for building your particular device, execute: lunch bliss_bullhead-userdebug Let's break down the command. 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. bliss_ is the ROM that we are building. As convention, all devices will have this prefix. bullhead is the specific device we are building - in this case, the Nexus 5X. 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.","title":"Build"},{"location":"BlissRoms/build-guide/#my-device-isnt-booting-and-userdebug-wont-print-any-adb-logcats-what-gives","text":"There is a third build variant called 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! All set? Let's start the building process. Run: mka blissify And the build should start. The build process will take a long time. Prepare to wait a few hours, even on a decent machine.","title":"My device isn't booting, and userdebug won't print any adb logcats. What gives?"},{"location":"BlissRoms/build-guide/#why-mka-and-not-make","text":"make only runs with 1 thread. mka is properly aliased to use all of your threads by checking nproc . If you want to customize your thread count (maybe you're building with a fan-screaming laptop in a quiet coffee shop), use make -j# , replacing the hash with the number of threads (example of make -j4 ).","title":"Why mka and not make?"},{"location":"BlissRoms/build-guide/#i-get-an-error-about-no-blissify-targets-to-build-against-whats-wrong","text":"If you are building other ROMs, it is usually make bacon . For BlissRoms, we chose the build target of blissify . If that doesn't work, sometimes there is a bug, or the ROM developers do not implement a bacon target to build against. In this case, you will need to find what name they use to initialize a full build of the ROM. Conventionally, it is supposed to be bacon , but some ROM developers change this name inadvertently, or actually have a bug that causes the build target to never be found. If you cannot locate the build target, ask the developers of the ROM. Alternatively, you can try poking around in build/make/core/Makefile to see what the build target name is. But this is out of the scope of this article as you're not supposed to be building other ROMs (that's not what this tutorial is for, sorry!) All right, but that's annoying. You had to type three commands to build it all. What about running one command? blissify bullhead But what is blissify ? It is a compact form of these commands: breakfast bullhead lunch bliss_bullhead-userdebug make blissify Sounds great, right? Once you have run the command, jump over to the next section.","title":"I get an error about no blissify targets to build against, what's wrong?"},{"location":"BlissRoms/build-guide/#after-building","text":"There are two outcomes to a build - either it fails and you get a red error message from 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. If you face the latter, congratulations! You've successfully built BlissRoms for your device. Grab the artifacts for your device: cd out/target/product/bullhead/ In here, you\u2019ll find a .zip that goes along the lines of Bliss-v11.9-Stable-bullhead-UNOFFICIAL-20190531.zip . Install TWRP, flash the build to your device, and enjoy!","title":"After building"},{"location":"BlissRoms/build-guide/#troubleshooting","text":"If your build failed, there are a couple things you can try. Try a fresh 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. Make sure your dependencies are installed correctly. Error messages help out a lot here! Often it will say shared/linked library not found or something along those lines. Make sure you sourced 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 sync ed do this again. Make sure you\u2019re at the root of the build tree. Again, to quickly jump there, use croot . Make sure you ran breakfast correctly and it did not error out. Missing device files will prevent successful builds. Make sure your computer itself isn\u2019t faulty. HDDs usually die first, followed by RAM. SSDs rarely die but failure is not unheard of. In extremely rare cases, your CPU may have a defect. If you're unsure, run a stress test using a program like Prime95. If something goes wrong and you've tried everything above, first use Google to look up your error! Most of the errors you encounter is due to misconfiguration and wrong commands entered. More often than not, Google will have the answer you are looking for. If you're still stuck and nothing fixes the problem, then ask us via our Telegram Build Support chat.","title":"Troubleshooting"},{"location":"BlissRoms/build-guide/#conclusion","text":"Building a ROM is very hard and tedious and the results are very rewarding! If you managed to follow along, congratulations! After you finish building, you can try out the Git Started guide. Make changes, commit, and send them off to our Gerrit for review! Or better yet, download experimental commits not ready for the mainline repositories and review them! Again, ROM building is a fun project you can work with. I hope this guide was a lot of fun to run through! -- Eric Park (ideaman924)","title":"Conclusion"},{"location":"BlissRoms/build-guide/#looking-for-the-next-tutorial","text":"Check out some tips to optimize your build experience.","title":"Looking for the next tutorial?"},{"location":"BlissRoms/build-tips/","text":"Build Tips Here's a collective list of things you can try to improve your builds. Have fun! repo optimization tips Threads By default, repo only utilizes four threads (or whatever the ROM manifest declares.) If you have a stronger machine with more threads, you can increase this number. So, for example, if you have 24 threads, you would type: repo sync -j24 Current history only This should be set by default in your ROM manifest, but just in case, you can tell repo to only fetch recent changes. This allows for smaller downloads, which makes the sync quicker. Add the flag: repo sync -c Force Warning! Dangerous option. Read before proceeding! Sometimes, your local history may go out of sync with remote repositories. This wouldn't be a problem if repo can handle it gracefully, but it doesn't and gives off a sync error. If you do not commit much, it may be worthwhile to add the force flags. Be warned though, any changes you make to the repositories WILL BE DELETED. Later down the line, if you commit a lot, you may want to remove this flag. To force sync, add the flag: repo sync -f --force-sync Minimal fetch To disable syncing clone bundles and tags, use: repo sync --no-clone-bundle --no-tags More documentation on this required, but for most developers these flags will be OK to use. This makes the sync faster as there is less information to sync over. Putting it all together repo sync -c -f -j24 --force-sync --no-clone-bundle --no-tags That's quite long! How about we add this to our .bashrc as a alias? That way, we only have to type one phrase for bash to automatically type that out for us. Open up ~/.bashrc and add these lines: # Alias to sync alias reposync='repo sync -c -f -j24 --force-sync --no-clone-bundle --no-tags' This way, next time you want to sync, just type reposync and bash will substitute the command for you. Easy! Just don't forget to source ~/.bashrc otherwise bash will not know of this new alias. Reset tree Warning! Very destructive tip. Do not use if you don't know what you are doing! While messing around with device specific folders, you may break something and the build process might not work. Or, you may have multiple devices synced and you want to delete it all and start over. However, you might have limited bandwidth, and might not want to download the source over again. Add this function to your ~/.bashrc : # Script to clean the source function resettree() { rm -rf device kernel vendor out .repo/local_manifests reposync } Let's go over what this does, word by word: rm -rf : Destructive command to erase all of the following: device folder: Holds all device-related files kernel folder: Holds all kernel-related files for devices vendor folder: Holds all vendor-related files for devices AND ROM-specific vendor customizations out folder: Stores artifacts of builds .repo/local_manifests folder: Stores \"manifest\" information of devices to sync. reposync : Executes the repo sync alias we made earlier. The last line is important, because by deleting the vendor folder, we also delete some crucial files for building Bliss. To fix that, we rerun a sync. Note that because we did not delete any other folders, syncing and updating files only take a fraction of a time compared to starting from scratch. To use this, after copying, don't forget to source ~/.bashrc . Then, run resettree at the base folder of the source code. Once you're done, don't forget to initialize a new device using breakfast <devicename> . GitHub cherry-pick Thanks to @blueyes for providing the script! Copy the following into your ~/.bashrc : function gcp() { COMMIT=`echo \"$1\" | cut -d/ -f6` GH=`echo \"$1\" | cut -d/ -f1-3` if [ \"$COMMIT\" != \"commit\" ]; then echo -e \"Please use a commit URL.\" elif [ \"$GH\" != \"https://github.com\" ]; then echo -e \"Please use an https://github.com/ URL.\" else PROJECT=`echo \"$1\" | cut -d/ -f1-5` git fetch $PROJECT CP=`echo \"$1\" | cut -d/ -f7` git cherry-pick $CP fi } To use this, source ~/.bashrc and then run gcp <GitHub commit URL here> . Make and go inside This is a quick way to create and go inside a folder. Once again, copy this to your ~/.bashrc : function mkcdir () { mkdir -p -- \"$1\" && cd -P -- \"$1\" } Don't forget to source , and run mkcdir <directory name> .","title":"Build Tips"},{"location":"BlissRoms/build-tips/#build-tips","text":"Here's a collective list of things you can try to improve your builds. Have fun!","title":"Build Tips"},{"location":"BlissRoms/build-tips/#repo-optimization-tips","text":"","title":"repo optimization tips"},{"location":"BlissRoms/build-tips/#threads","text":"By default, repo only utilizes four threads (or whatever the ROM manifest declares.) If you have a stronger machine with more threads, you can increase this number. So, for example, if you have 24 threads, you would type: repo sync -j24","title":"Threads"},{"location":"BlissRoms/build-tips/#current-history-only","text":"This should be set by default in your ROM manifest, but just in case, you can tell repo to only fetch recent changes. This allows for smaller downloads, which makes the sync quicker. Add the flag: repo sync -c","title":"Current history only"},{"location":"BlissRoms/build-tips/#force","text":"Warning! Dangerous option. Read before proceeding! Sometimes, your local history may go out of sync with remote repositories. This wouldn't be a problem if repo can handle it gracefully, but it doesn't and gives off a sync error. If you do not commit much, it may be worthwhile to add the force flags. Be warned though, any changes you make to the repositories WILL BE DELETED. Later down the line, if you commit a lot, you may want to remove this flag. To force sync, add the flag: repo sync -f --force-sync","title":"Force"},{"location":"BlissRoms/build-tips/#minimal-fetch","text":"To disable syncing clone bundles and tags, use: repo sync --no-clone-bundle --no-tags More documentation on this required, but for most developers these flags will be OK to use. This makes the sync faster as there is less information to sync over.","title":"Minimal fetch"},{"location":"BlissRoms/build-tips/#putting-it-all-together","text":"repo sync -c -f -j24 --force-sync --no-clone-bundle --no-tags That's quite long! How about we add this to our .bashrc as a alias? That way, we only have to type one phrase for bash to automatically type that out for us. Open up ~/.bashrc and add these lines: # Alias to sync alias reposync='repo sync -c -f -j24 --force-sync --no-clone-bundle --no-tags' This way, next time you want to sync, just type reposync and bash will substitute the command for you. Easy! Just don't forget to source ~/.bashrc otherwise bash will not know of this new alias.","title":"Putting it all together"},{"location":"BlissRoms/build-tips/#reset-tree","text":"Warning! Very destructive tip. Do not use if you don't know what you are doing! While messing around with device specific folders, you may break something and the build process might not work. Or, you may have multiple devices synced and you want to delete it all and start over. However, you might have limited bandwidth, and might not want to download the source over again. Add this function to your ~/.bashrc : # Script to clean the source function resettree() { rm -rf device kernel vendor out .repo/local_manifests reposync } Let's go over what this does, word by word: rm -rf : Destructive command to erase all of the following: device folder: Holds all device-related files kernel folder: Holds all kernel-related files for devices vendor folder: Holds all vendor-related files for devices AND ROM-specific vendor customizations out folder: Stores artifacts of builds .repo/local_manifests folder: Stores \"manifest\" information of devices to sync. reposync : Executes the repo sync alias we made earlier. The last line is important, because by deleting the vendor folder, we also delete some crucial files for building Bliss. To fix that, we rerun a sync. Note that because we did not delete any other folders, syncing and updating files only take a fraction of a time compared to starting from scratch. To use this, after copying, don't forget to source ~/.bashrc . Then, run resettree at the base folder of the source code. Once you're done, don't forget to initialize a new device using breakfast <devicename> .","title":"Reset tree"},{"location":"BlissRoms/build-tips/#github-cherry-pick","text":"Thanks to @blueyes for providing the script! Copy the following into your ~/.bashrc : function gcp() { COMMIT=`echo \"$1\" | cut -d/ -f6` GH=`echo \"$1\" | cut -d/ -f1-3` if [ \"$COMMIT\" != \"commit\" ]; then echo -e \"Please use a commit URL.\" elif [ \"$GH\" != \"https://github.com\" ]; then echo -e \"Please use an https://github.com/ URL.\" else PROJECT=`echo \"$1\" | cut -d/ -f1-5` git fetch $PROJECT CP=`echo \"$1\" | cut -d/ -f7` git cherry-pick $CP fi } To use this, source ~/.bashrc and then run gcp <GitHub commit URL here> .","title":"GitHub cherry-pick"},{"location":"BlissRoms/build-tips/#make-and-go-inside","text":"This is a quick way to create and go inside a folder. Once again, copy this to your ~/.bashrc : function mkcdir () { mkdir -p -- \"$1\" && cd -P -- \"$1\" } Don't forget to source , and run mkcdir <directory name> .","title":"Make and go inside"},{"location":"common/","text":"Index Before you start working on open source projects, learn how to maintain proper authorship. New to committing? Start with this Git and Gerrit guide! Learn how to mass-review commits with a child's toy.","title":"Index"},{"location":"common/#index","text":"Before you start working on open source projects, learn how to maintain proper authorship. New to committing? Start with this Git and Gerrit guide! Learn how to mass-review commits with a child's toy.","title":"Index"},{"location":"common/git-started/","text":"Git Started Foreword This guide helps people learn git commands and how to get the features you want into your favorite ROM and make your own builds. This will help new people get started and will be a great refresher for veteran git users and has instructions for Arch Linux users as well. The document will be ever-changing and evolving because even we will be learning new material and will be putting it in here. Installation In order to use git review we need it installed on our local machine. For Ubuntu we use the package manager to install it. sudo apt-get install git-review Or for Arch based installs, use: sudo pacman -S git-review Get the terminal set up First, let's make sure our local git and Gerrit have the same email address associated. cd cat .gitconfig This command should show something along those lines: [user] email = you@youremail.com name = Your Name Edit any incorrect details. Your email and name is used to sign off commits, various changes, etc, so it is important that they are the same ones found on Gerrit and GitHub. Next we will create a SSH key named \u201cgerrit\u201d to communicate with the Gerrit server. ssh-keygen -t rsa -C you@youremail.com -f ~/.ssh/gerrit Again, note the email address must be the same here, your .gitconfig , and on Gerrit. Register at Gerrit Open your favorite browser and go to http://review.blissroms.com . You will see a \u201cSign In\u201d button on the top right - click that and register with GitHub. Please note that you will need to use the same email address that you registered with GitHub for your terminal interactions with Gerrit. Now we need to add our SSH key to Gerrit. Your name will be on the top right of the page. Click your name and you should see \u201cSettings\u201d. Once there click on the link \u201cSSH Public Keys\u201d on the left sidebar. Once it loads, click \"Add Key\" on the right. Let's copy the key from the terminal and paste it into the browser. cat ~/.ssh/gerrit.pub This should show something like: ssh-rsa AAAABBBBBBBBBBCCCCCCCCCCCCCCCCCCDjhl8768usdfsdfuhf/BlahBlahBlah/ThIs+1s/A/fAk3+k3Y/Hdhs+PlCesTvQqfaqHTHwdzGhn2lKVt14WYvQEDKVM9JoE9e8xarNWYa0ZspB1MGn2RVJ3xRp0+Q/pA237uBCl62yTbVGtKQBZB6Q+7A54z795U+G2wCb1rAQnI5yn5q/pQ4NhB0BLml/QRmjn/S8PldEge9Hfdh4Ifdk4r9DKSiicf7IK56jklDHKkJDFkjh/3345L10sTyre3JOeZyvr5SJdyqMtmMv+uSGF28fgZ6/OEO/yBY/eYEI/XVRDaRRat8nGHGae0T4dx me@myemail.com Starting with the line beginning with ssh-rsa and ending with the email, paste that bit into the browser and click \u201cAdd\u201d. Gerrit shows an error about the key! Are you sure you used the correct key? Do not use the \"private\" key. The private key should be kept private as it is the key that allows you to authenticate yourself against servers like Gerrit. When you authenticate using your private key, the servers send out requests encrypted with your \"public\" key that only your \"private\" key can decrypt. This is the basis behind SSH authentication. So keep your private key safe, and try pasting the public key! Most public keys end with the characters .pub . Then, add the new SSH key to your local identity in terminal. eval `ssh-agent` This should print off a bunch of lines. We\u2019re doing this to launch the ssh-agent before adding the key. ssh-add ~/.ssh/gerrit This will result in something along the lines of: Identity added: /home/yourusername/.ssh/gerrit (/home/yourusername/.ssh/gerrit) If you don\u2019t get this, and get this instead: Could not open a connection to your authentication agent. Or this: Error connecting to agent: No such file or directory. This is because in recent versions of Ubuntu, you need to change how you launch ssh-agent . Run the command below, then try adding your SSH key again. eval \u201c$(ssh-agent)\u201d Now we should be ready to use git review . Reviewing Code Just cd to your source code directory and find the package you want to look at from Gerrit. I\u2019ll use frameworks/base as an example. # cd into source code directory cd ~/bliss/p9.0 # Find project to work on cd frameworks/base Let\u2019s setup the remote to Gerrit: git review -s This should create a gerrit remote. If you added a passphrase to your SSH key you will have to enter that. However, if this command outputs something like this: Could not connect to gerrit. Enter your gerrit username: And after you input your username, it shows something like this: Trying again with ssh://username@review.blissroms.com:29418/platform_frameworks_base.git <traceback object at 0x7f7f95ea9e18> We don't know where your gerrit is. Please manually create a remote named \"gerrit\" and try again. Could not connect to gerrit at ssh://username@review.blissroms.com:29418/platform_frameworks_base.git Traceback (most recent call last): File \"/usr/bin/git-review\", line 10, in <module> sys.exit(main()) File \"/usr/lib/python2.7/dist-packages/git_review/cmd.py\", line 1534, in main sys.exit(e.EXIT_CODE) AttributeError: 'GitReviewException' object has no attribute 'EXIT_CODE' Why does this happen? This is because the ssh-agent process got killed after prolonged use of the system, so you need to restart it. As a quick and dirty fix, run this again: eval \u201c$(ssh-agent)\u201d This should fix it. If not, then you need to go back to Chapter 1 and add your existing key. Don\u2019t make a new key, then you\u2019d need to add a new public key to the Bliss Gerrit. Now let\u2019s see if there are any changes we can review. git review -l This outputs: 2433 new-mm6.0 SystemUI: fix double tap power launching custom lockscreen icon 2432 new-mm6.0 SystemUI: remove extraneous debug log Found 2 items for review My output is blank (or different.) Why? This is because right now, there are no changes to be reviewed in frameworks/base (or there are different commits to be reviewed.) This is completely normal and to be expected, as we merge and submit new commits frequently. The guide will probably be out of sync with current changes by the time you are reading this. Now you have a list of commits sorted by change number with a description of what changes were made. We have a few choices of how to pick commits. Cherry-picking commits to current branch git review -x changenumber will cherry-pick that commit to the current branch you are in. A benefit of this is the next time you repo sync \u2013force-sync , it will discard the commits you picked. Cherry-picking commits to new branch git review -d changenumber will cherry-pick to a new branch based on the submitter\u2019s name and change ID. If you choose this route the change will be in its own branch and when you are done you can just delete that branch. Switched to a new branch review/yourusername/changenumber Now you can review the change. Follow these guidelines: Did the ROM build with the change incorporated? Did the added feature or fix work in the new build? Did the new commit break any other aspects of the build? After reviewing these guidelines, log into Gerrit via your web browser, and click on the commit you reviewed. Select the \u2018Reply\u2019 button on the top and choose your score. +1 if it works as intended, -1 if not. Be sure to leave comments on why you gave your score (such as \u201ccommit A does not show in 320 DPI\u201d, etc) Once you're done, return to the base directory ( croot ) to follow along with the next example! Submitting code Go to the directory of the package or app you want to make changes to. We will use frameworks/base as an example. cd frameworks/base Setup the remote to Gerrit if you haven\u2019t already: git review -s Next, make sure you are on the correct branch: git branch -t p9.0 BlissRoms/p9.0 This makes sure that your local branch follows the remote branch. -t stands for tracking. Now we need to checkout , to switch to that new branch we tracked. You usually do not need to do the above command, but it is a nice check to do if something is going south. git checkout p9.0 This should output: Changed to new branch p9.0 tracking upstream BlissRoms/p9.0 Now make your changes, cherry-picks, etc. and commit them. If you need a guide to do that, check out Picking from other sources . When you\u2019re done, come back here! Then all you have to do to send it to gerrit is: git review If you are submitting multiple commits it will ask if you really want to, just type \u201cyes\u201d at the prompt. Picking from other sources So you\u2019ve successfully learned how to commit and send it to Bliss Gerrit. But you need to find something to commit. Thankfully, there are lots of examples you can try out. You can check other teams\u2019 Gerrits and cherry-pick from them. For this demonstration, I\u2019m going to use LineageOS's Gerrit. Find the commit you want, and note down the commit ID. Now, we need to add LOS\u2019s repositories. If you\u2019re pulling over a commit, you must make sure that we track the repository by going to Bliss\u2019s Gerrit and checking in Projects > List. If the repository is not there, it usually means we aren\u2019t tracking it. git remote add los https://github.com/LineageOS/\u2026\u2026(your repo name) git remote fetch los lineage-16.0 We\u2019ve finished adding LOS\u2019s repositories. Now you need to grab the commit ID you copied earlier and paste it on the command underneath. git cherry-pick 9ff831 Replace 9ff831 with your own commit ID. If git complains about duplicate revisions, paste the full SHA1 hash instead of the shorthand git uses. Before pushing and submitting, we need to check if our commit was successfully committed. Type the bottom command: git log --oneline After you check that your commit is there, you can push q to quit. Then you can follow the instructions from Submitting code again. Conclusion Don\u2019t worry if you don\u2019t get it at once. It\u2019s a fairly long process of submitting and reviewing at Gerrit. Read the guide again and again and you\u2019ll start to remember commands without looking at this. I will continue with this as I learn more things, I hope this has helped someone. -- Vaughn (rwaterspf1) -- Eric Park (ideaman924) -- Jon West (electrikjesus)","title":"Git Started"},{"location":"common/git-started/#git-started","text":"","title":"Git Started"},{"location":"common/git-started/#foreword","text":"This guide helps people learn git commands and how to get the features you want into your favorite ROM and make your own builds. This will help new people get started and will be a great refresher for veteran git users and has instructions for Arch Linux users as well. The document will be ever-changing and evolving because even we will be learning new material and will be putting it in here.","title":"Foreword"},{"location":"common/git-started/#installation","text":"In order to use git review we need it installed on our local machine. For Ubuntu we use the package manager to install it. sudo apt-get install git-review Or for Arch based installs, use: sudo pacman -S git-review","title":"Installation"},{"location":"common/git-started/#get-the-terminal-set-up","text":"First, let's make sure our local git and Gerrit have the same email address associated. cd cat .gitconfig This command should show something along those lines: [user] email = you@youremail.com name = Your Name Edit any incorrect details. Your email and name is used to sign off commits, various changes, etc, so it is important that they are the same ones found on Gerrit and GitHub. Next we will create a SSH key named \u201cgerrit\u201d to communicate with the Gerrit server. ssh-keygen -t rsa -C you@youremail.com -f ~/.ssh/gerrit Again, note the email address must be the same here, your .gitconfig , and on Gerrit.","title":"Get the terminal set up"},{"location":"common/git-started/#register-at-gerrit","text":"Open your favorite browser and go to http://review.blissroms.com . You will see a \u201cSign In\u201d button on the top right - click that and register with GitHub. Please note that you will need to use the same email address that you registered with GitHub for your terminal interactions with Gerrit. Now we need to add our SSH key to Gerrit. Your name will be on the top right of the page. Click your name and you should see \u201cSettings\u201d. Once there click on the link \u201cSSH Public Keys\u201d on the left sidebar. Once it loads, click \"Add Key\" on the right. Let's copy the key from the terminal and paste it into the browser. cat ~/.ssh/gerrit.pub This should show something like: ssh-rsa AAAABBBBBBBBBBCCCCCCCCCCCCCCCCCCDjhl8768usdfsdfuhf/BlahBlahBlah/ThIs+1s/A/fAk3+k3Y/Hdhs+PlCesTvQqfaqHTHwdzGhn2lKVt14WYvQEDKVM9JoE9e8xarNWYa0ZspB1MGn2RVJ3xRp0+Q/pA237uBCl62yTbVGtKQBZB6Q+7A54z795U+G2wCb1rAQnI5yn5q/pQ4NhB0BLml/QRmjn/S8PldEge9Hfdh4Ifdk4r9DKSiicf7IK56jklDHKkJDFkjh/3345L10sTyre3JOeZyvr5SJdyqMtmMv+uSGF28fgZ6/OEO/yBY/eYEI/XVRDaRRat8nGHGae0T4dx me@myemail.com Starting with the line beginning with ssh-rsa and ending with the email, paste that bit into the browser and click \u201cAdd\u201d.","title":"Register at Gerrit"},{"location":"common/git-started/#gerrit-shows-an-error-about-the-key","text":"Are you sure you used the correct key? Do not use the \"private\" key. The private key should be kept private as it is the key that allows you to authenticate yourself against servers like Gerrit. When you authenticate using your private key, the servers send out requests encrypted with your \"public\" key that only your \"private\" key can decrypt. This is the basis behind SSH authentication. So keep your private key safe, and try pasting the public key! Most public keys end with the characters .pub . Then, add the new SSH key to your local identity in terminal. eval `ssh-agent` This should print off a bunch of lines. We\u2019re doing this to launch the ssh-agent before adding the key. ssh-add ~/.ssh/gerrit This will result in something along the lines of: Identity added: /home/yourusername/.ssh/gerrit (/home/yourusername/.ssh/gerrit) If you don\u2019t get this, and get this instead: Could not open a connection to your authentication agent. Or this: Error connecting to agent: No such file or directory. This is because in recent versions of Ubuntu, you need to change how you launch ssh-agent . Run the command below, then try adding your SSH key again. eval \u201c$(ssh-agent)\u201d Now we should be ready to use git review .","title":"Gerrit shows an error about the key!"},{"location":"common/git-started/#reviewing-code","text":"Just cd to your source code directory and find the package you want to look at from Gerrit. I\u2019ll use frameworks/base as an example. # cd into source code directory cd ~/bliss/p9.0 # Find project to work on cd frameworks/base Let\u2019s setup the remote to Gerrit: git review -s This should create a gerrit remote. If you added a passphrase to your SSH key you will have to enter that. However, if this command outputs something like this: Could not connect to gerrit. Enter your gerrit username: And after you input your username, it shows something like this: Trying again with ssh://username@review.blissroms.com:29418/platform_frameworks_base.git <traceback object at 0x7f7f95ea9e18> We don't know where your gerrit is. Please manually create a remote named \"gerrit\" and try again. Could not connect to gerrit at ssh://username@review.blissroms.com:29418/platform_frameworks_base.git Traceback (most recent call last): File \"/usr/bin/git-review\", line 10, in <module> sys.exit(main()) File \"/usr/lib/python2.7/dist-packages/git_review/cmd.py\", line 1534, in main sys.exit(e.EXIT_CODE) AttributeError: 'GitReviewException' object has no attribute 'EXIT_CODE' Why does this happen? This is because the ssh-agent process got killed after prolonged use of the system, so you need to restart it. As a quick and dirty fix, run this again: eval \u201c$(ssh-agent)\u201d This should fix it. If not, then you need to go back to Chapter 1 and add your existing key. Don\u2019t make a new key, then you\u2019d need to add a new public key to the Bliss Gerrit. Now let\u2019s see if there are any changes we can review. git review -l This outputs: 2433 new-mm6.0 SystemUI: fix double tap power launching custom lockscreen icon 2432 new-mm6.0 SystemUI: remove extraneous debug log Found 2 items for review","title":"Reviewing Code"},{"location":"common/git-started/#my-output-is-blank-or-different-why","text":"This is because right now, there are no changes to be reviewed in frameworks/base (or there are different commits to be reviewed.) This is completely normal and to be expected, as we merge and submit new commits frequently. The guide will probably be out of sync with current changes by the time you are reading this. Now you have a list of commits sorted by change number with a description of what changes were made. We have a few choices of how to pick commits.","title":"My output is blank (or different.) Why?"},{"location":"common/git-started/#cherry-picking-commits-to-current-branch","text":"git review -x changenumber will cherry-pick that commit to the current branch you are in. A benefit of this is the next time you repo sync \u2013force-sync , it will discard the commits you picked.","title":"Cherry-picking commits to current branch"},{"location":"common/git-started/#cherry-picking-commits-to-new-branch","text":"git review -d changenumber will cherry-pick to a new branch based on the submitter\u2019s name and change ID. If you choose this route the change will be in its own branch and when you are done you can just delete that branch. Switched to a new branch review/yourusername/changenumber Now you can review the change. Follow these guidelines: Did the ROM build with the change incorporated? Did the added feature or fix work in the new build? Did the new commit break any other aspects of the build? After reviewing these guidelines, log into Gerrit via your web browser, and click on the commit you reviewed. Select the \u2018Reply\u2019 button on the top and choose your score. +1 if it works as intended, -1 if not. Be sure to leave comments on why you gave your score (such as \u201ccommit A does not show in 320 DPI\u201d, etc) Once you're done, return to the base directory ( croot ) to follow along with the next example!","title":"Cherry-picking commits to new branch"},{"location":"common/git-started/#submitting-code","text":"Go to the directory of the package or app you want to make changes to. We will use frameworks/base as an example. cd frameworks/base Setup the remote to Gerrit if you haven\u2019t already: git review -s Next, make sure you are on the correct branch: git branch -t p9.0 BlissRoms/p9.0 This makes sure that your local branch follows the remote branch. -t stands for tracking. Now we need to checkout , to switch to that new branch we tracked. You usually do not need to do the above command, but it is a nice check to do if something is going south. git checkout p9.0 This should output: Changed to new branch p9.0 tracking upstream BlissRoms/p9.0 Now make your changes, cherry-picks, etc. and commit them. If you need a guide to do that, check out Picking from other sources . When you\u2019re done, come back here! Then all you have to do to send it to gerrit is: git review If you are submitting multiple commits it will ask if you really want to, just type \u201cyes\u201d at the prompt.","title":"Submitting code"},{"location":"common/git-started/#picking-from-other-sources","text":"So you\u2019ve successfully learned how to commit and send it to Bliss Gerrit. But you need to find something to commit. Thankfully, there are lots of examples you can try out. You can check other teams\u2019 Gerrits and cherry-pick from them. For this demonstration, I\u2019m going to use LineageOS's Gerrit. Find the commit you want, and note down the commit ID. Now, we need to add LOS\u2019s repositories. If you\u2019re pulling over a commit, you must make sure that we track the repository by going to Bliss\u2019s Gerrit and checking in Projects > List. If the repository is not there, it usually means we aren\u2019t tracking it. git remote add los https://github.com/LineageOS/\u2026\u2026(your repo name) git remote fetch los lineage-16.0 We\u2019ve finished adding LOS\u2019s repositories. Now you need to grab the commit ID you copied earlier and paste it on the command underneath. git cherry-pick 9ff831 Replace 9ff831 with your own commit ID. If git complains about duplicate revisions, paste the full SHA1 hash instead of the shorthand git uses. Before pushing and submitting, we need to check if our commit was successfully committed. Type the bottom command: git log --oneline After you check that your commit is there, you can push q to quit. Then you can follow the instructions from Submitting code again.","title":"Picking from other sources"},{"location":"common/git-started/#conclusion","text":"Don\u2019t worry if you don\u2019t get it at once. It\u2019s a fairly long process of submitting and reviewing at Gerrit. Read the guide again and again and you\u2019ll start to remember commands without looking at this. I will continue with this as I learn more things, I hope this has helped someone. -- Vaughn (rwaterspf1) -- Eric Park (ideaman924) -- Jon West (electrikjesus)","title":"Conclusion"},{"location":"common/maintaining-proper-authorship/","text":"One of the most important things you need to keep in mind while working on open-source projects is maintaing correct authorship. In this article, we'll show you why maintaining proper authorship is important, give you a couple examples on correct and incorrect commits, and show you the overall procedure of correctly pulling in commits from others. What is kanging? Kanging is a term used in the Android development community for the action of passing off someone else's code as one's own, intentionally or unintentionally. Why is kanging bad? Kanging is bad because the developers who worked hard on the commits do not get the recognition they deserve. Over time, this may cause the developer to quit releasing public source code or even retire from the Android development community. Kanging examples (what you should NOT) do Example 1: You're trying to cherry-pick some commits from a different repository, but keep running into git merge issues. Out of frustration, you copy the code from the commit, and then just commit it using git commit -a . Satisfied, you push it up to GitHub. Example 2: You bring up a bunch of commits, and squash them before pushing to GitHub. Example 3: You intentionally want to pass off another developer's work as your own. You cherry-pick the commit, and then amend the commit to rewrite the author information. Let's go over why this is wrong. Example 1 is an example of an unintentional kang. You didn't want to resolve the git merge issues, so decided to just copy the code and commit it as your own. This is bad because the author information does not get transferred over with your copy, which you have to specify manually. Example 2 is more of an accident. If you squash multiple commits, all authorship information for the range of commits is lost. In addition, it becomes a real headache for other developers if something in the range of your commits is wrong. Because you cannot individually revert commits in a squash, squashing is very much discouraged and should ONLY be used when you have a lot of commits that you committed yourself and are small in nature. Example 3 is an example of an intentional kang. We won't explain why because it should be fairly obvious. How to maintain proper authorship The process is fairly simple yet important to understand. If you are cherry-picking commits, the authorship information is transferred automatically. Provided that you are running git cherry-pick <commit-id> , the entire commit information, down to when the commit was created, is picked into your repository. You don't have to do anything in this case. If you are committing someone else's code yourself, then you must manually specify who the author is. There are a lot of reasons why you would do this, from merge issues to incompatible code with the existing codebase. To manually specify an author, follow the steps below. Finally, do NOT squash a range of commits that are not your own. This completely wipes authorship information from the range of commits and causes a massive headache for other developers. Manually specifying an author You need to first determine the original author's name and email address. GitHub no longer shows the author information when you mouse over the profile picture, which is quite unfortunate. However, there is an easy workaround. Go to the commit that you want to pick. We'll use my commit as an example. Add the word .patch , with the period, to the end of the URL and press Enter to navigate to the raw patch. In the patch, find the section that contains the author. It should be at the top of the page. Now, it's time to commit with the correct author information. Make the necessary changes, and then commit using this command: git commit --author=\"AUTHOR_INFORMATION_HERE\" Following the example, I would write: git commit --author=\"Eric Park <ideamaneric@gmail.com>\" Once done, push to GitHub or Gerrit.","title":"Maintaining proper authorship"},{"location":"common/maintaining-proper-authorship/#what-is-kanging","text":"Kanging is a term used in the Android development community for the action of passing off someone else's code as one's own, intentionally or unintentionally.","title":"What is kanging?"},{"location":"common/maintaining-proper-authorship/#why-is-kanging-bad","text":"Kanging is bad because the developers who worked hard on the commits do not get the recognition they deserve. Over time, this may cause the developer to quit releasing public source code or even retire from the Android development community.","title":"Why is kanging bad?"},{"location":"common/maintaining-proper-authorship/#kanging-examples-what-you-should-not-do","text":"Example 1: You're trying to cherry-pick some commits from a different repository, but keep running into git merge issues. Out of frustration, you copy the code from the commit, and then just commit it using git commit -a . Satisfied, you push it up to GitHub. Example 2: You bring up a bunch of commits, and squash them before pushing to GitHub. Example 3: You intentionally want to pass off another developer's work as your own. You cherry-pick the commit, and then amend the commit to rewrite the author information. Let's go over why this is wrong. Example 1 is an example of an unintentional kang. You didn't want to resolve the git merge issues, so decided to just copy the code and commit it as your own. This is bad because the author information does not get transferred over with your copy, which you have to specify manually. Example 2 is more of an accident. If you squash multiple commits, all authorship information for the range of commits is lost. In addition, it becomes a real headache for other developers if something in the range of your commits is wrong. Because you cannot individually revert commits in a squash, squashing is very much discouraged and should ONLY be used when you have a lot of commits that you committed yourself and are small in nature. Example 3 is an example of an intentional kang. We won't explain why because it should be fairly obvious.","title":"Kanging examples (what you should NOT) do"},{"location":"common/maintaining-proper-authorship/#how-to-maintain-proper-authorship","text":"The process is fairly simple yet important to understand. If you are cherry-picking commits, the authorship information is transferred automatically. Provided that you are running git cherry-pick <commit-id> , the entire commit information, down to when the commit was created, is picked into your repository. You don't have to do anything in this case. If you are committing someone else's code yourself, then you must manually specify who the author is. There are a lot of reasons why you would do this, from merge issues to incompatible code with the existing codebase. To manually specify an author, follow the steps below. Finally, do NOT squash a range of commits that are not your own. This completely wipes authorship information from the range of commits and causes a massive headache for other developers.","title":"How to maintain proper authorship"},{"location":"common/maintaining-proper-authorship/#manually-specifying-an-author","text":"You need to first determine the original author's name and email address. GitHub no longer shows the author information when you mouse over the profile picture, which is quite unfortunate. However, there is an easy workaround. Go to the commit that you want to pick. We'll use my commit as an example. Add the word .patch , with the period, to the end of the URL and press Enter to navigate to the raw patch. In the patch, find the section that contains the author. It should be at the top of the page. Now, it's time to commit with the correct author information. Make the necessary changes, and then commit using this command: git commit --author=\"AUTHOR_INFORMATION_HERE\" Following the example, I would write: git commit --author=\"Eric Park <ideamaneric@gmail.com>\" Once done, push to GitHub or Gerrit.","title":"Manually specifying an author"},{"location":"common/using-dippy-bird/","text":"Using dippy-bird If you want to review commits quickly on our Gerrit, use the dippy-bird.php script created by the WikiMedia foundation. Thanks to Vaughn Newman (@rwaterspf1) for the original instructions! Installation Make sure you have PHP installed. Download the script and put it in an easily-accessible place. Usage Reviewing commits (code-review only) To review commits, run: php dippy-bird.php --username=ideaman924 --server=review.blissroms.com --port=29418 -q=\"status:open topic:test\" -a=review --review=+1 --verify=0 This will review all commits that match the following criteria: Is open for review (not closed, merged, or abandoned) Has the topic test And will apply +1 code-review and no verify, indicating that you have a successful build with the commits included. Reviewing commits (code-review and verification) To review commits with verification, run: php dippy-bird.php --username=ideaman924 --server=review.blissroms.com --port=29418 -q=\"status:open topic:test\" -a=review --review=+2 --verify=+1 This will review all commits that match the following criteria: Is open for review (not closed, merged, or abandoned) Has the topic test And will apply +2 code-review and +1 verify, indicating that you have tested the commits on an actual device. This means that the commits are now ready for merging.","title":"Using `dippy-bird`"},{"location":"common/using-dippy-bird/#using-dippy-bird","text":"If you want to review commits quickly on our Gerrit, use the dippy-bird.php script created by the WikiMedia foundation. Thanks to Vaughn Newman (@rwaterspf1) for the original instructions!","title":"Using dippy-bird"},{"location":"common/using-dippy-bird/#installation","text":"Make sure you have PHP installed. Download the script and put it in an easily-accessible place.","title":"Installation"},{"location":"common/using-dippy-bird/#usage","text":"","title":"Usage"},{"location":"common/using-dippy-bird/#reviewing-commits-code-review-only","text":"To review commits, run: php dippy-bird.php --username=ideaman924 --server=review.blissroms.com --port=29418 -q=\"status:open topic:test\" -a=review --review=+1 --verify=0 This will review all commits that match the following criteria: Is open for review (not closed, merged, or abandoned) Has the topic test And will apply +1 code-review and no verify, indicating that you have a successful build with the commits included.","title":"Reviewing commits (code-review only)"},{"location":"common/using-dippy-bird/#reviewing-commits-code-review-and-verification","text":"To review commits with verification, run: php dippy-bird.php --username=ideaman924 --server=review.blissroms.com --port=29418 -q=\"status:open topic:test\" -a=review --review=+2 --verify=+1 This will review all commits that match the following criteria: Is open for review (not closed, merged, or abandoned) Has the topic test And will apply +2 code-review and +1 verify, indicating that you have tested the commits on an actual device. This means that the commits are now ready for merging.","title":"Reviewing commits (code-review and verification)"},{"location":"infrastructure/","text":"Index There doesn't seem to be anything here... check back later for more content!","title":"Index"},{"location":"infrastructure/#index","text":"There doesn't seem to be anything here... check back later for more content!","title":"Index"}]}
\ No newline at end of file
diff --git a/sitemap.xml.gz b/sitemap.xml.gz
index 4b7bf22..7a079ed 100644
--- a/sitemap.xml.gz
+++ b/sitemap.xml.gz
Binary files differ