Develop Bugs

[ROM] [4.2.2] [AOKP/CM/PA] Maguro Vanilla RootBox [21/05] [v4] [Per-App-DPI] [PIE]

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Description
Vanilla RootBox is built straight from RootBox sources and always carries a very light installation with no extra/useless apps. This means, you can enjoy a pure Android experience combined with AOKP/CM features and some CM cherry-picks. Keep in mind Jelly Bean is only at the beginning stage of development and there will be minor bugs. Every RootBox releases are stable and always up to the challenge for a daily usage. If you're wondering how this ROM differs from any other AOKP roms out there, I only have one thing to say: Try it yourself and choose the one that meets your requirements.
Features
Based on JB 4.2.2- Built from RootBox Sources
AOKP Features
CM Profiles
Per App DPI
Per App Tablet UI
Per App Language
OTA Updates - Goo Manager
Navigation Bar Colour
Camera: Save to external memory
Phone: Advance Phone Settings (Vibrate on Answer, Every 45 Seconds, On Hangup and On Call Waiting)
Phone: Noise Suppression
MMS: Message rate alerts (Modify SMS message limit for alert)
MMS: Fully Customizable MMS Theme
MMS: Soft Keyboard Type (Emoji, Enter to Send, Enter for a New Line)
Option to control cursor in text fields using volume keys
Home button call answer (Accessibility Option)
Variable size pattern lockscreen
RootBox Settings
LockClock (Chronus)
Launch Music app on Headset connection
Pie (Paranoid Android)
Option to disable sound when adjusting volume
Lockscreen Shortcuts (Paranoid)
Lockscreen Targets (CM)
Screen Security Features (Unlock options)
Expanded Desktop
Hardware Keys Remapping
Lockscreen Hardware Keys Remapping
Recommended Installation Steps
Coming from another Custom ROM:
1. Wipe Data/Factory Reset (This does not affect your Internal/External storage)
2. Flash RootBox zip
3. Flash JB GAPPS
4. Wipe Dalvik Cache
5. Reboot
How to upgrade RootBox versions:
1. Download RootBox update
2. Flash RootBox update
3. Flash JB GAPPS
4. Wipe Cache (Optional)
5. Wipe Dalvik Cache (Optional)
6. Reboot
RootBox Sources
www.github.com/Root-Box
Downloads
Official Releases - Nightlies
Official | Google Apps
Quick Tip: To avoid bad flashes and unexpected surprises, make sure you check the md5sum of the downloaded zip file against the one displayed on Goo.
All Private Messages sent to me for support will be ignored. I do not have the time to go through all the PMs I receive on a daily basis.
This is a development thread only. You have been warned.
Changelog
**Due to thread size limit restrictions, only the latest version's changelog will be displayed.
If you wish to have changelogs from previous versions, you can find them at the following link:
RootBox Changelogs
Changelogs are now integrated with the ROM itself:
- At the root of ROM zip file (changelog.txt)
- Goo Manager app (View Changelog section of the zip file)
- Goo.im website (Drag mouse over the zip file and click "view file changelog")
Bugs
*AOKP/CM BUGS
Donations
If you want to donate, feel free to do so but I'm not a big fan of donations. I put this up because I've been getting too many PM asking for my paypal account.
Credits/Thanks To:
* AOKP
* Teamhacksung
* The CyanogenMod Project
* rovo89 - For his excellent work on Xposed Framework
* Paranoid Android
* DaXmax
* Rodries
* Pier
* BigDenn - Logo, bootanimation and wallpapers
ScreenShots/Videos
​

Contribute to RootBox​
Those interested in making wallpapers and bootanimation for RootBox, send an email to [email protected] with the following:
Information
Name
Email
Wallpapers
Attach wallpaper in email
Two sizes are required: HDPI and XHDPI
I'll review them and add the wallpapers in the next release. I will also choose the best one as the default wallpaper for official releases.
Bootanimation
Attach bootanimation or paste download link in the email.
Two sizes are required: HDPI and XHDPI
Wallpaper Resolution
HDPI: 960 x 800
XHDPI: 1440 x 1280
You can also contribute by creating icons for settings. Use proper sizes and always include compatibility for HDPI and XHDPI.
The reason behind this is very simple. I'm always busy and I've neglected the visual aspect of RootBox for a while now. It's time to polish it with new visuals!
How to Build RootBox from Source​
Getting started
I will assume that you have some kind of knowledge with Linux and how to use a terminal. I will also assume that you have already setup all the android building requirements. First, you must create your working folder and initialize a repository with RootBox sources. The following steps will guide you in creating this working folder where you will be able to build RootBox.
You should now open a terminal (By default you should be in your home folder: /home/yourusername/)
Step 1: Let's create a folder in your home directory named RootBox. This will be referred as your working folder.
Code:
~$ mkdir RootBox
Step 2: Let's change our directory to the new RootBox folder we just created.
Code:
~$ cd RootBox
Step 3: Now that we are in our working folder (RootBox), we will initialize our RootBox repository by entering the following command:
Code:
~$ repo init -u git://github.com/Root-Box/platform_manifest.git -b jb-mr1
Step 4: It's now time to sync RootBox sources which could vary from a few minutes to a few hours depending on your internet connection.
Code:
~$ repo sync
Building Vanilla RootBox
Now that you have synced the sources, you're ready to build RootBox.
You can run the following build script:
Code:
~$ . build_rootbox.sh -device- -sync- -thread- -clean-
Device: Choose between the following supported devices: i9100, i9100g, i9300, d2att, d2tmo, d2vzw, mako and grouper.
Sync: Will sync latest RootBox sources before building
Threads: Allows to choose a number of threads for syncing and building operation.
Clean: Will remove the entire out folder and start a clean build. (Use this at your discretion)
Examples:
1) Sync sources and Build RootBox for GT-I9100 with 12 threads
Code:
~$ . build_rootbox.sh i9100 sync 12
2) Don't sync sources, clean out folder and build RootBox for GT-I9300 with 6 threads
Code:
~$ . build_rootbox.sh i9300 nosync 6 clean
3) Don't sync sources, clean out folder and build RootBox for SGH-I747 with 4 threads
Code:
~$ . build_rootbox.sh d2att nosync 4 clean
4) Sync sources, clean out folder and build RootBox for Nexus 4 with 5 threads
Code:
~$ . build_rootbox.sh mako sync 5 clean
This script will make a signed flashable zip file located in out/target/product/-device-/RootBox-JB-(Device)-Nightly-(Date).zip

For me

Future use

Just incase

Re: [ROM][4.2.1][AOKP/CM] Maguro Vanilla RootBox - UNOFFICIAL [21/01][Per-App-DPI]
First blood
Sent from my Galaxy Nexus using xda premium

I remember this tom back in my 'old' days on SGS2 (not even a year ago lol).. it was good stuff.
I'll be watching this thread closely.. Rootbox and G-Nex could be a powerful combo..

great news

AWESOME! Rootbox was my favorite ROM on my SGSII, I remember that bajee11 was the dev and rootbox team made an awesome job with that rom.
I'll be following this ROM closely and this will be, 4 sure, my next rom.
sykomaniac will you release nightlies like on the SGSIII forum or update it when needed?

Re: [ROM][4.2.1][AOKP/CM] Maguro Vanilla RootBox - UNOFFICIAL [21/01][Per-App-DPI]
When needed but often probably 1 or 2 per week. Im also part of team eos primarily but like others really like rootbox
Sent from my Galaxy Nexus

Re: [ROM][4.2.1][AOKP/CM] Maguro Vanilla RootBox - UNOFFICIAL [21/01][Per-App-DPI]
sykomaniac said:
When needed but often probably 1 or 2 per week. Im also part of team eos primarily but like others really like rootbox
Sent from my Galaxy Nexus
Click to expand...
Click to collapse
Another oficial build from aokp is out, can we expect a new build soon?
Another thing, is there any chance to insert the animations in this framework http://db.tt/Cgmm5NTb to this rom?
Those were made to xylon.

sergini said:
Another oficial build from aokp is out, can we expect a new build soon?
Another thing, is there any chance to insert the animations in this framework http://db.tt/Cgmm5NTb to this rom?
Those were made to xylon.
Click to expand...
Click to collapse
Yes there will be an update soon as the overlapping date in tab UI notification area has been fixed - probably tonight.
You can get the animations by using zipthemer and installing: http://db.tt/ei9U3Khc
I don't remember who originally posted this but it work perfect (using it myself now)

New build
Link in OP. Change-log in 2nd post

aokp+cm+per app customizations
im interested, lets see
edit: enabling some tiles makes system ui crash constantly. doesnt stop till reboot. i changed system ui dpi, maybe its related.
also supersu seems outdated. that was the bad part.
good part is i really liked the customizations and per app tweaks. but too many options, im lost in settings

drmxmyt said:
aokp+cm+per app customizations
im interested, lets see
edit: enabling some tiles makes system ui crash constantly. doesnt stop till reboot. i changed system ui dpi, maybe its related.
also supersu seems outdated. that was the bad part.
good part is i really liked the customizations and per app tweaks. but too many options, im lost in settings
Click to expand...
Click to collapse
Can I ask which tiles? Cheers

i went to settings and unticked plane mode, ticked gps and blutooth, pressing ok made my phone crashing.

sykomaniac said:
Can I ask which tiles? Cheers
Click to expand...
Click to collapse
got a friendly tip, when you release a new build if you could change the date on the thread title that would be great, your choice if you want to take the advice or not just trying to help.. btw the rom is great but i am just too in love with PIE to use any other rom lol :good:

k786 said:
got a friendly tip, when you release a new build if you could change the date on the thread title that would be great, your choice if you want to take the advice or not just trying to help.. btw the rom is great but i am just too in love with PIE to use any other rom lol :good:
Click to expand...
Click to collapse
Good point - also for the PIE try LMT.

AW: [ROM][4.2.1][AOKP/CM] Maguro Vanilla RootBox - UNOFFICIAL [22/01][Per-App-DPI]
Build 1 no wifi... Only wifi on Google-registation, after that theres a signal, but no fix.
First go back to old rom, doesnt test build 2... Is there a possibility to cbange dpi?
Greets...
... send with GNx - schlanke Bohne RC1 ...

bvt-1 said:
Build 1 no wifi... Only wifi on Google-registation, after that theres a signal, but no fix.
First go back to old rom, doesnt test build 2... Is there a possibility to cbange dpi?
Greets...
... send with GNx - schlanke Bohne RC1 ...
Click to expand...
Click to collapse
Hmm, I don't know why you didn't have wifi. I'm using the latest build and its working fine for me.
Yes you can change the DPI - it uses the Xposed Framework by rovo89

[GUIDE] How to build ROMs for LB from source

Hi,
since many people asked me how I build my ROMs for locked bootloaders, I have decided to write a short guide.
Getting started
As always, you need to set up a build environment. Since I don’t want to elaborate on this, I suggest you to follow the building instructions on the CyanogenMod wiki. You can also use the AOKP website as a reference.
Initializing the repos
To start, you may want to initialize the repos that you will use later on. Just open a terminal and issue the following command:
Code:
repo init -u git://github.com/aosp-lb-nozomi/manifest.git -b <ROM>
Where <ROM> is the ROM you want to build. You have to choice between aokp, pac, slimbean and mokee.
So, let's say you want to build AOKP - this would be the command you would have to issue:
Code:
repo init -u git://github.com/aosp-lb-nozomi/manifest.git -b aokp
Syncing the code
Now that this is done, you can start syncing (this may take some time):
Code:
repo sync -jX
Replace the X with your core count (eventually +1 or -1). (e.g. If you have a dualcore processor, it can be -j2 or -j3)
Building
Start with:
Code:
. build/envsetup.sh
Now you should be good to go. Lunchtime!
Code:
lunch <ROM>_<device>-userdebug
(e.g. lunch aokp_nozomi-userdebug OR lunch slim_aoba-userdebug)
Finally, you are ready to build.
Code:
make -jX bacon
Patching the ROM to work with LB
If everything went right, you should find an AOKP build in your out folder. But this build is unpatched, so it can be flashed on UB devices only. To patch it, go to your root directory (type "cd"), clone my repo and navigate to it:
Code:
git clone [email protected]:aosp-lb-nozomi/rom_builder.git -b [B]<ROM>[/B] patcher;cd patcher
Again, you have to replace <ROM> by the ROM you want to build. Possible ROMs: aokp, pac, slimbean and mk.
NOTE: If you build for the Sony Xperia Ion (aoba), you have to add that. (e.g. git clone [email protected]:aosp-lb-nozomi/rom_builder.git -b aokp-aoba patcher;cd patcher)
Finally, execute the script (to patch the ROM):
Code:
sh makezip
That’s it! Find your build in the folder “patcher” and flash it.

updating a source tree

For developers: Say I have a CM source tree and I want to start building LineageOS instead. To save bandwidth, time, and disk space I don't want to start from a fresh "repo init". What set of commands can I use to convert my CM source tree to LineageOS?
For bonus points, separate instructions for a repo downloaded via a simple "repo init" vs one using the --reference option.

aaopt said:
For developers: Say I have a CM source tree and I want to start building LineageOS instead. To save bandwidth, time, and disk space I don't want to start from a fresh "repo init". What set of commands can I use to convert my CM source tree to LineageOS?
For bonus points, separate instructions for a repo downloaded via a simple "repo init" vs one using the --reference option.
Click to expand...
Click to collapse
https://gist.github.com/fourkbomb/0d94e286dc6f173eb9053c0d75e84783
The only thing I had to do different was to use the normal repo init command (not using ssh) on step 1, then the rest worked perfectly.
repo init -u git://github.com/LineageOS/android.git -b cm-14.1

[H932] (CAF) Kernel Development Notes

(I'd love to post this in the dev section, but seeing as I've always been an XDA downloader I don't have the post count. )
What I've gathered around the 'net is that there isn't really a good place to get started with development on Android kernels when presented with an OEM source zip drop. This "guide" if you can call it that is nothing more than my musings in stumbling through the kernel dev learning process. My goal is to get both me and maybe you from "ok, I can download source" to doing some basic kernel tasks.
My LG V20 gave up the ghost, but to my surprise my insurance didn't deliver a replacement h918, but instead a T-Mobile LG V30 H932. That messed my restore plans up a good deal. Upon perusing the XDA forums I'm seeing that this model isn't popular with developers. This walkthrough is written with its current latest firmware release in mind, 30d. I won't be updating this guide for newer firmwares as I feel I've documented my process -extremely- thoroughly. If they do miraculously release another update be assured that it'll eventually be in my git's commits.
The first thing I'll note is that this is my first foray into Android kernel development. I've been a Linux sysadmin for 13 years though, so most of my solutions to problems are going to come from that realm rather than Android development. I've been hacking phones using the great releases on XDA since my UTStarcom XV6800 running Windows Mobile 6. It's time to give back.
The second note is that while I tried to keep this guide as generic as possible, that's an impossible task because the process itself is intrinsically tied to what device you're doing this for. I concede 100% that these are the dev notes on my work towards better h932 ROMs w/VoLTE and VoWiFi. If you're working with something else you can follow the same process but change some names around. If your image isn't CAF based, the process is the same except utilizing whatever repository your manufacturer started with.
My last note is that I will not be doing this process on other device kernels unless they're supportable by my base work. The H932 is unloved enough.
------------------------------------------​GETTING STARTED
Start from a Linux host of your choosing. I'll be doing this from Arch Linux. Make sure your basic build tools are installed and you've got lots of disk space (and free time :\ ).
Get the 30d source through your browser: (apparently I can't post links yet- you're gonna have to Google for now)
Inside the file you download from LG will be another compressed tarball named "LGH932SV_Kernel_Pie.tar.gz". This is where the stock kernel source is stored. Keep this file handy as we'll need to extract the stock kernel's contents a few times.
Alright. We have kernel source and the means to build it. Is that all we can do though? Surely LG didn't just magic this whole platform together. They probably started from an upstream base. The most widely used base for starting development on a Snapdragon device would be the Code Aurora (REALLY missing the links) repo. Just by coincidince CAF contains a branch named "msm-4.4", exactly the same as our stock release's kernel folder. It's likely they started here. But where?
CAF uses some extremely hideous tags to mark their releases. I haven't deciphered the full meaning from the CAF tag strings themselves yet but they do correspond to commits in their git repository. That's good enough for us to start guessing at stuff!
(If you're doing this for the H932 30d release, you can skip CAF-dentification and go straight to "Your Kernel Repo". I already have the magic answers for 30d.)
CAF-DENTIFICATION
Modified instructions from:
abhishekan - can't post links yet. To be filled. :\
Click to expand...
Click to collapse
Only necessary if you don't know your base - I already did this for our example.
LG H932 release 30d script results:
Code:
Best match
TAG: LA.UM.7.4.r1-03500-8x98.0
Lines changed: 1174716
That's a LOT of changes! I hope it's not too bad to sort through...
Click to expand...
Click to collapse
Extract your stock kernel sources (located within LGH932SV_Kernel_Pie.tar.gz in the file you download from LG) and go into the msm-4.4 directory via bash terminal.
Code:
cd msm-4.4
Initialize this folder as a git repo
Code:
git init
Add all the stock kernel files into git's tracking and make your initial commit
Code:
git add .
git commit -m "LG V30 30d Stock Open Source Files - (link removed)"
Add the CAF upstream repo for our kernel (msm-4.4)
Code:
git remote add msm https://source.codeaurora.org/quic/la/kernel/msm-4.4
Fetch all their tags (this will take some time/~3.3GB folder size after this command)
Code:
git fetch msm 'refs/tags/*:refs/tags/*'
Download the best-caf-kernel python script to identify which version CAF LG based the image from
Code:
wget https://raw.githubusercontent.com/LineageOS/scripts/master/best-caf-kernel/best-caf-kernel.py
Set it executable
Code:
chmod 755 best-caf-kernel.py
Search through the msm-8998 builds to see which one is most similar
Code:
./best-caf-kernel.py "*-8x98.0"
This command will take a long while to complete because it's checking each release individually and comparing how much of the source code differs. The least changed kernel represents our best chance to merge LG's changes back into a CAF release as a patch.
Again, the secret answer for the H932 30d kernel is: LA.UM.7.4.r1-03500-8x98.0
LG more than likely started from this base for their 30d release and implemented their custom kernel changes atop LA.UM.7.4.r1-03500-8x98.0. Had they released a repository instead of a bespoke zip we wouldn't have to do all this guesswork. We could just review the commit history and see where the two projects match up.
It's never the easy way...
START YOUR KERNEL REPO
Go ahead and delete the msm-4.4 directory you made before (if you did the CAF-dentification step). We'll start fresh here and explain some of the more common git commands as we go. I know some will not be familiar with git so these examples in motion may help.
Go home (or some place with a lot of storage) and make a directory to store your nascent kernel repository.
Code:
cd ~
mkdir -p ./kernel/msm-4.4/
cd ./kernel/msm-4.4/
Initialize this folder as a git repo
Code:
git init
Start by making a master branch we'll use for our "good" code. We have to add a file to start the master branch so just drop a description of what we're coding here.
Code:
echo "# Custom kernel source repo for the LG V30 H932.
" > caffy.readme
git add .
git commit -m "initial commit"
You can see that the master branch was automatically created via the commit:
Code:
git branch -a
Before we move on we should enable a git feature called rerere, short for "Reuse recorded resolution of conflicted merges". This comes in insanely handy in the advanced steps later because it will record how you resolve git conflicts when merging branches. If you merge that code again into a similar branch, git will already know how to automagically fix most of the conflicting issues.
In fact, it's so useful, I recommend enabling it globally. Use branches people!
Code:
git config --global rerere.enabled 1
For now add a staging branch that we'll test our code updates in. This will come into play later.
Code:
git branch staging
Tracking every change we make and the differences between versions is going to play a VERY vital role in maintaining your kernel source. We'll make heavy use of branches to make merging differences easier later.
Add a third branch that will contain the stock LG H932 30d source files.
Code:
git branch LG.H932.30d_stock
Note that you weren't automatically placed in the LG.H932.30d_stock branch. If you do another "git branch -a" you'll see master is still selected. Switch!
Code:
git checkout LG.H932.30d_stock
Extract the file "LGH932SV_Kernel_Pie.tar.gz" from the source you downloaded from LG. Now open that compressed tarball to reveal a ./kernel/ folder. This is your actual kernel source code. Extract their ./kernel/ into your ./kernel/.
Now that the files are in place there are a couple small changes that need to be made to the original source so git can catalog it correctly. Looks like LG missed a few files that changed between software versions behind the scenes (for other devices - just know it may not compile as delivered and you'll have to dig).
Make sure you're back in the msm-4.4 folder before running these commands.
Code:
echo '!vmlinux.scr' >> ./arch/sh/boot/.gitignore
sed -i '/*.pdf/d' ./Documentation/DocBook/.gitignore
rm ./.get_maintainer.ignore
Update our readme breadcrumb with this branch's details. Personal notes will save you eternal frustration down the road when things are much more complicated.
Code:
echo "# This source tree represents the latest LG V30 H932 kernel, version 30d.
#
# Find the original release at:
# (link temporarily removed)
" > caffy.readme
Once all that is in place, add the files into your repo and make a commit for this branch, noting the changes you made from master.
Code:
git add .
git commit -m "Clean version of the LG V30 H932 stock kernel (release 30d)"
You can verify your changes by checking your git logs, which will report your commit history on your selected branch.
Code:
git log
Your two commit messages should be visible in the log.
Switch back to the master branch so we can add s'more kernel branches.
Code:
git checkout master
Note that the directory cleared out again after checking out the master branch. All we have now is our readme file from our initial commit and the .git directory itself (which you should RARELY modify directly).
Now we'll make a new branch to host our stock kernel's closest CAF cousin. Finding out what your CAF tag is can be its own adventure. Normally here is where you have to do the CAF-dentification step (you can refer to that section above). Since this is an example I'll cheat and tell you the closest CAF tag for the H932 30d image: LA.UM.7.4.r1-03500-8x98.0.
Code:
git branch LA.UM.7.4.r1-03500-8x98.0
git checkout LA.UM.7.4.r1-03500-8x98.0
Update our breadcrumb with how we got to this point, just in case someone pulls this code and for some reason and blows the .git dir away.
Code:
echo "# This source tree represents the original "LA.UM.7.4.r1-03500-8x98.0" CAF release.
#
# Find the full original repo at:
# https://source.codeaurora.org/quic/la/kernel/msm-4.4/refs/tags?h=BosSen-msm-44/master
" > caffy.readme
Add the CAF upstream repo for our kernel (msm-4.4 I'm guesing, since the LG kernel is delivered in a folder named that)
Code:
git remote add msm https://source.codeaurora.org/quic/la/kernel/msm-4.4
Grab the most similar version to your CAF as identified by the best-caf-kernel.py script. This is "git fetch" followed by your CAF repo (msm-4.4 here) then the CAF tag.
Code:
git fetch msm LA.UM.7.4.r1-03500-8x98.0
Merge this fetched code into our branch, ignoring that it has no common "history" (commits) with our readme-only-containing branch.
Code:
git merge --allow-unrelated-histories FETCH_HEAD
(Optional sanity check) You can verify that we're using Qualcomm's code now because we have the commit logs available (unlike with the LG releases). The git log will show you looooooots of dev notes.
Code:
git log
Now we have two branches with kernel source code, one of which we suspect is a modified version of the other. Without LG's git history to detail what they changed and where, we're going to have to reconcile the differences ourselves. That sounds easy... right? Wait, did you do the CAF-dentification step? ...remember "Lines changed: 1174716"?
In theory this would be simple and software would note all the changes automagically, sort them, and generate a pretty list. In practice it never works that way.
Here's the basic intro to get you started down the path... Be aware that git merge conflict resolution could be a masters level class depending on what you're starting from and where you're trying to go.
Switch back to your empty staging branch
Code:
git checkout staging
Pull the code from our CAF branch into our staging branch
Code:
git merge LA.UM.7.4.r1-03500-8x98.0
Update your breadcrumb for what's about to come...
Code:
echo "# This source tree represents the "LA.UM.7.4.r1-03500-8x98.0" CAF release,
# with the LG customizations added on top of the standard release code.
#
# Find the full original repos at:
# https://source.codeaurora.org/quic/la/kernel/msm-4.4/refs/tags?h=BosSen-msm-44/master
# (apparently CAF links are fine but LGE opensource links are NOT ok)
" > caffy.readme
Now do basically the same process for the H932 30d kernel files. This will result in A LOT of conflicts because LG added a lot of drivers/fixes.
Code:
git merge LG.H932.30d_stock
Merging these modifications is a process that is kinda outside of the scope of an "introductory" document. My first attempt on this step took almost a full day of verifying file contents and locations. Even after all that I had to go back and find some missed changes between the two versions manually. Kernel modding is not for the faint of heart. I'm still figuring parts of it out!
"git mergetool" is a good place to start your web searches. meld is a graphical tool you can install on Linux hosts to allow merging between LOCAL, BASE, and REMOTE concurrently via GUI.
This step is where the real art comes in, it seems.
Code:
git mergetool -t meld
ANYWAYS, once that whole mess is sorted, you may or may not have a functional stock kernel merged with its closest CAF relative. Preserve your work by adding and committing.
Code:
git add .
git commit -m "CAF release tag: LA.UM.7.4.r1-03500-8x98.0 + LG H932 30d kernel source merged.
LG's kernel release finally gets an upstream commit history. >:D"
Since this was such a huge merge I like to park it in (you guessed it) another branch for posterity. Issue these commands to copy our staging work elsewhere.
Code:
git branch LA.UM.7.4.r1-03500-8x98.0+H932.30d
At this point you've tracked down where LG started with their kernel source, rebuilt the commit history they started with, and created a patch delta between what Qualcomm handed LG and the 30d image that LG eventually shipped. Very nice!
How do we know it works, though? Maybe we fudged one of the merges up and completely disabled a piece of hardware. Maybe there's no sound. The ONLY way to know the final outcome is to compile, flash, and test. If you weren't "an artist" in the previous step this can be a long repetitive slog.
Some notes to help you diagnose stuff: If you know your 30d kernel compiles and works fine on your phone, but your merged CAF tag + 30d release does not, it must be a difference somewhere between the two sets of files. I had missed a few files the first time around which resulted in a ton of build errors in the final stage. I was able to track this down because most of the errors were "net" related, so I started my search for differences in that directory.
Code:
git diff HEAD LG.H932.30d_stock -- ./net/*
git checkout LG.H932.30d_stock -- ./net/Makefile
git checkout LG.H932.30d_stock -- ./net/core/dev.c
git checkout LG.H932.30d_stock -- ./net/core/sock.c
You can go down every directory similarly and VERY SLOWLY verify that you've copied the changes 100%. If you haven't noticed by now this process is a labor of love. Continue until it compiles. Flash. Test. Verify. Progress!

COMPILE KERNEL
If you've followed this guide top to bottom as written, we may be a bit ahead of ourselves. I recommend trying the following steps on the 30d stock files FIRST, and then once you're sure of your methods on the original files you can try your hand at compiling your merged CAF tagged version. This helps isolate issues between your process and your code.
Switch back over to the pristine stock branch.
Code:
git checkout LG.H932.30d_stock
Unless you're doing this from a 64-bit Raspberry Pi (AND 64-bit OS!) or similar platform you'll need to grab the cross-compile toolchain for arm64 (here called aarch64) from Google. There's a slight problem with using the latest release though. Commit fc97ce6abfe822403eb219dcbd1067a53c49e4f1 removed the GCC compiler completely!
Checking back through the git log we can see where they've made changes to GCC, so let's roll back to a version more suitable for our platform. I found the last commit that contains GCC before they started introducing the deprication warnings - 22f053ccdfd0d73aafcceff3419a5fe3c01e878b. We'll leave the msm-4.4 directory first so this toolchain isn't downloaded into our code.
Code:
cd ../..
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9
cd aarch64-linux-android-4.9
git checkout 22f053ccdfd0d73aafcceff3419a5fe3c01e878b
git reset --hard HEAD
You can verify that we have gcc again by checking the ./bin/ directory here.
Code:
ls -lah ./bin | grep gcc
While we're here we need to set some environment variables so the compiler will know to use this location. You'll have to redo this from this directory any time you close your shell (in this case, the terminal probably), if you want to recompile the kernel.
Code:
export CROSS_COMPILE=$(pwd)/bin/aarch64-linux-android-
export ARCH=arm64 && export SUBARCH=arm64
Head back into the msm-4.4 directory for punishment time.
Code:
cd ../kernel/msm-4.4
This next part I'm pretty sure is not the correct way to perform it. I'm not a C developer - just a sysadmin - so I've worked out a way to get it running at least. Yes, this does mean that the code is no longer pristine. Someone let me know how to get the stock code compiling without modification. Click the button below for my steps that are -extremely- specific to the h932 30d image.
In ./Makefile, Remove the gcc-wrapper script from the equation. All it does is stop the build on warnings. Google made a similar change with their commit e7fb62baa7c8b803d7e3b3f3d8bf4e2b916b659d. Change this line:
Code:
REAL_CC = $(CROSS_COMPILE)gcc
to this:
Code:
CC = $(CROSS_COMPILE)gcc
And remove this line:
Code:
CC = $(srctree)/scripts/gcc-wrapper.py $(REAL_CC)
-OR- if you really like stopping on compiler warnings, you need to make the wrapper executable.
Code:
chmod 755 ./scripts/gcc-wrapper.py
Note that this wrapper breaks newer GCC toolchains so it's advised you choose to remove it.
./arch/arm64/kernel/vdso/gen_vdso_offsets.sh has incorrect permissions. It needs to be executable.
Code:
chmod 755 ./arch/arm64/kernel/vdso/gen_vdso_offsets.sh
You're going to need to apply a Linux kernel commit from 4.4.218 (commit ce513359d8507123e63f34b56e67ad558074be22) to prevent compile errors about "multiple definition of `yylloc'". Remove the line "YYLTYPE yylloc;" (or in later versions "extern YYLTYPE yylloc;") from two files:
Code:
# ./scripts/dtc/dtc-lexer.l
# ./scripts/dtc/dtc-lexer.lex.c_shipped
Go into the ./arch/arm64/boot/dts/ directory. Delete the qcom file and make it a link instead. This fixes a missing file error that msm8998-joan_tmo_us_rev-0.dts otherwise runs into.
Code:
cd arch/arm64/boot/dts/
rm qcom
ln -s ../../../../arch/arm/boot/dts/qcom qcom
cd ../../../..
Go into the ./include/uapi/linux/ directory. We're going to delete some files and link them instead. This fixes ambiguous errors like: "../include/uapi/linux/oneshot_sync.h:1:1: error: expected identifier or '(' before '.' token". It's LITERALLY parsing the link in the file. Make it a link instead.
Code:
cd ./include/uapi/linux/
rm oneshot_sync.h
ln -s ../../../drivers/staging/android/uapi/oneshot_sync.h oneshot_sync.h
rm sync.h
ln -s ../../../drivers/staging/android/uapi/sync.h sync.h
cd ../../..
Edit the #include statements in ./arch/arm/boot/dts/qcom/msm8998.dtsi to point to the current file locations. Leave the first #include alone! Change the other three to:
Code:
#include <../../../../../include/dt-bindings/clock/msm-clocks-8998.h>
#include <../../../../../include/dt-bindings/regulator/qcom,rpm-smd-regulator.h>
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
Another #include needs to be fixed in ./include/dt-bindings/interrupt-controller/arm-gic.h
Code:
#include "irq.h"
Two #includes in ./arch/arm/boot/dts/qcom/msm-pmi8998.dtsi
Code:
#include <../../../../../include/dt-bindings/interrupt-controller/irq.h>
#include <../../../../../include/dt-bindings/spmi/spmi.h>
The same thing in reverse on ./arch/arm/boot/dts/qcom/msm-pm8005.dtsi
Code:
#include <../../../../../include/dt-bindings/spmi/spmi.h>
#include <../../../../../include/dt-bindings/interrupt-controller/irq.h>
Some common culprits over in ./arch/arm/boot/dts/qcom/msm8998-regulator.dtsi
Code:
#include <../../../../../include/dt-bindings/clock/msm-clocks-8998.h>
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
ANOTHER set of #includes in ./arch/arm/boot/dts/qcom/msm-pm8998.dtsi
Code:
#include <../../../../../include/dt-bindings/spmi/spmi.h>
#include <../../../../../include/dt-bindings/interrupt-controller/irq.h>
#include <../../../../../include/dt-bindings/msm/power-on.h>
One in the similarly namned ./arch/arm/boot/dts/qcom/msm8998-pm.dtsi
Code:
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
Seeing a pattern yet? The include directory must be defined in something I've missed. Another over in ./arch/arm/boot/dts/qcom/msm-arm-smmu-8998.dtsi
Code:
#include <../../../../../include/dt-bindings/clock/msm-clocks-8998.h>
#include <../../../../../include/dt-bindings/msm/msm-bus-ids.h>
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
Moar. ./arch/arm/boot/dts/qcom/msm8998-vidc.dtsi
Code:
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
#include <../../../../../include/dt-bindings/msm/msm-bus-ids.h>
#include <../../../../../include/dt-bindings/clock/msm-clocks-8998.h>
Moar. ./arch/arm/boot/dts/qcom/msm8998-bus.dtsi
Code:
#include <../../../../../include/dt-bindings/msm/msm-bus-ids.h>
Moar. ./arch/arm/boot/dts/qcom/msm-smb138x.dtsi
Code:
#include <../../../../../include/dt-bindings/interrupt-controller/irq.h>
Moar. ./arch/arm64/boot/dts/lge/msm8998-joan/msm8998-joan_tmo_us/msm8998-joan_tmo_us.dtsi
Only the first #include on this file needs to be changed.
Code:
#include <../../../../include/dt-bindings/interrupt-controller/irq.h>
Locate the devconfig file you'd like to use for your device under the directory ./arch/arm64/configs/.
Code:
ls -lah ./arch/arm64/configs/
The closest in my instance will be the "joan_tmo_us-perf_defconfig" file. Joan is the codename for the LG V30, T-Mobile's my carrier, US is my country, and while using the stock ROM the uname -r command returns "4.4.153-perf+" so I assume they used the perf config. The defconfig will instruct the compiler what options to include in the kernel. We're going with the LG stock options to start with.
Make a few directories for the clean/mrproper scripts. The build process throws some (harmless) errors otherwise.
Code:
mkdir -p out/drivers/staging/qcacld-3.0
mkdir -p out/drivers/staging/qca-wifi-host-cmn
mkdir -p out/arch/arm64/boot/dts
Now run through the make steps. Clean, prepare the environment, prep the make with your devconfig, then run the actual make specifying that it use all the cores your PC has to speed things up. You can change that to a manually specified number like 3 cores if you're using the PC for other stuff with "-j3".
Code:
make O=./out clean
make O=./out mrproper
make O=./out joan_tmo_us-perf_defconfig
make O=./out KERNEL_COMPRESSION_SUFFIX=gz -j$(nproc)
Your kernel should compile successfully and output the file "./out/arch/arm64/boot/Image.gz-dtb". AnyKernel3 will need this so your kernel can be included in the installer.
PACKAGE & FLASH KERNEL
Download the latest AnyKernel3. Make sure you're not in your kernel directory.
Code:
cd ~
wget https://github.com/osm0sis/AnyKernel3/archive/master.zip
Unzip the archive and go into the AnyKernel3 directory.
Code:
unzip master.zip
cd AnyKernel3-master
Place your Image.gz-dtb file into the AnyKernel3-master folder.
Edit the anykernel.sh file, it comes pre-populated with demo values. Copy my example below for the V30 and feel free to change kernel.string (make sure not to use a ' though). If you aren't using a V30 and therefore not making a Joan kernel, change the device.name1 and block lines for your device. You can either pull the values from another kernel for your device, or boot into TWRP or similar, go to the terminal, and try a find /dev/block -name boot to see if you can garnish any clues as to where your real boot is. Some devices just hard specify this under /fstab.${devicecodename} - ours is at /fstab.joan but has no /boot/.
Code:
# AnyKernel3 Ramdisk Mod Script
# osm0sis @ xda-developers
## AnyKernel setup
# begin properties
properties() { '
kernel.string=CAF Test Kernel
do.devicecheck=1
do.modules=0
do.systemless=1
do.cleanup=1
do.cleanuponabort=0
device.name1=joan
'; } # end properties
# shell variables
block=/dev/block/bootdevice/by-name/boot;
is_slot_device=0;
ramdisk_compression=auto;
## AnyKernel methods (DO NOT CHANGE)
# import patching functions/variables - see for reference
. tools/ak3-core.sh;
## AnyKernel install
dump_boot;
write_boot;
## end install
Finally, pack up the entire folder.
Code:
zip -r9 UPDATE-AnyKernel3.zip * -x .git README.md *placeholder
You've created your first kernel release! Most XDA users would know what to do with this file at this point. Remember that if you're using a Pie release like we are that not all versions of TWRP support the newer standard of encryption. I'm using 3.3.1 personally.
That first flash is perilous. You'll swear it's the slowest your phone has ever booted and there's no way this could be working. Patience. If it doesn't work and you have no access to another kernel for your device you'll have to reflash a working image, find out what you did wrong, fix it, and try again.
Once you have a known working kernel the other flashes are much less risky - if it doesn't work, just go back into TWRP and flash the working one.
SWITCHING TOOLCHAINS
Switching between Google Android 4.9 builds
I've pulled some of the commits from the aarch64-linux-android-4.9 git logs which correlate to when they introduced new build versions. Might help someone track down an errant compiler issue or two.
Code:
93092903254cba0b6950c94170332973a85b450f - final gcc build 5790414 + very long delays added to dissuade use
22f053ccdfd0d73aafcceff3419a5fe3c01e878b - build 4983606 - last version before warnings
e7c51da4d09616dcff4a9d0f1190c3403079c462 - build 4682334
ce9d77505072450d2f16a4bf06673f31d8d67ff0 - build 3335333
2d6950d80de80ab7b1252816a2f543d07180deeb - build 2734602
d65210cccc244bf9a92a1ff56953314e9908e0fd - build 2617618
b5845835b5e6a5266c56d554c0c1f282d30f8c3f - build 2492827
8f7279e3d34a45f084fdb23bd434c01d5e598bf4 - they don't mention the builds this early
For anything older checkout this last commit and do: git log --grep 'prebuilts for aarch64'
You can change which gcc build your toolchain is on by going into your aarch64-linux-android-4.9 directory and performing the following commands, making sure to replace the commit with the one reflecting the build you'd like.
git checkout 22f053ccdfd0d73aafcceff3419a5fe3c01e878b
git reset --hard HEAD
Switching to Alternatives
From what I understand reading around XDA, it's best practice to try to compile your kernel with Google's aarch64-linux-android-4.9 toolchain first to make sure that nothing's wrong with it. Relative to the Linux community however, Google has been extremely conservative with its toolchain. If you're looking to bleed every last drop of performance out of your platform you should try a few different toolchains and see which one results in code that's most efficient for your workflow.
There are LOTS of toolchains out there. XDA has entire threads on dedicated to this topic. On Linux your distribution also probably bundles a premade toolchain for aarch64, Arch Linux is currently on GCC 10 (aarch64-linux-gnu-gcc)!
I'm going to focus on a popular performance-focused toolchain here, Linaro. They produce an aarch64 toolchain for most of the GCC release versions with enhancements specific to ARM based targets. Their latest release as of this writing is 7.5.0.
Go back to your home directory and download the aarch64-7.5.0 release of Linaro, then unpack.
Code:
cd ~
wget https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu.tar.xz
tar -xf gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu.tar.xz
Now, whenever you want to compile your kernel following the steps in this guide, you'll go into this directory instead of your previous aarch64-linux-android-4.9 one. Then you'll need to set your CROSS_COMPILE variable a different string which corresponds to Linaro 7.5.0's file structure.
Code:
cd gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu
export CROSS_COMPILE=$(pwd)/bin/aarch64-linux-gnu-
I've tested this on my LA.UM.7.4.r1-03500-8x98.0+H932.30d and it completes albeit with a few warnings. Coding standards and compilers evolve as time moves on and code that isn't maintained can find itself stranded with the ancients - these warnings are to help developers work in the right direction so that doesn't happen to their projects.
To that end, to actually compile a functional kernel using a GCC 7.x+ toolchain there's a flag that needs to be added to your ./Makefile: "-fno-store-merging". I found this tidbit over at https://github.com/nathanchance/angler/commit/406d54a7f006142372157d4fb49d7e76a5564d00
Add the following at line 634 in ./Makefile:
Code:
# Needed to unbreak GCC 7.x and above
KBUILD_CFLAGS += $(call cc-option,-fno-store-merging,)

UPDATE CAF
Repeating history isn't what we came for though. From our CAF base the fun begins. We didn't do all that work to end up with a stock image! The entire reason to figure out what CAF we started with is so we could change it. Now that we have a kernel with the CAF commit history, as we download newer CAF bases, we'll simply reapply the same commits that they did to update our kernel's base.
We're going to download the latest CAF base image for our hardware. Go to the codeaurora.org page for your device's source tags. Search for your chip (here 8x98 referring to the msm8998 aka Snapdragon 835) and find a similar build string to your identified one.
For the H932 this page would be: https://source.codeaurora.org/quic/la/kernel/msm-4.4/refs/tags?h=BosSen-msm-44/master
In this instance, 30d identified closest as "LA.UM.7.4.r1-03500-8x98.0 ", so I'm looking for a "LA.UM.7.4.r1" release for the "8x98.0" architecture.
Just a heads up - I'm not sure if this is right! There are much newer msm8998 releases listed, such as "LA.UM.8.4.r1-05500-8x98.0". I've yet to experiment with these to see if they are of value to us. I went with the "most similar looking" to get my feet wet with the process.
Code:
git fetch https://source.codeaurora.org/quic/la/kernel/msm-4.4.git LA.UM.7.4.r1-06000-8x98.0
Go back to master since it's our only clean branch. Then make a home for our selected CAF release. Then switch to using it.
Code:
git checkout master
git branch LA.UM.7.4.r1-06000-8x98.0
git checkout LA.UM.7.4.r1-06000-8x98.0
Do the same process we did to import the original CAF's code. We already set the LA.UM.7.4.r1-06000-8x98.0 commit as our FETCH_HEAD earlier.
Code:
git merge --allow-unrelated-histories FETCH_HEAD
Head back to staging. It currently has a copy of the LA.UM.7.4.r1-03500-8x98.0+H932.30d branch's code.
Code:
git checkout staging
Now merge the changes from 06000 into our 03500 base.
Code:
git merge LA.UM.7.4.r1-06000-8x98.0
Notice how this produces A TON fewer conflicts than our original go around. Also, rerere has captured how we modified some of the files when we added 30d into the CAF branch so it has a basic concept of what we're trying to achieve, and makes some of these for us automagically. The day is saved!
Break out your git mergetool of choice again and get to work.
Code:
git mergetool -t meld
Then add and commit your changes.
Code:
git add .
git commit -m "LA.UM.7.4.r1-06000-8x98.0 + LG H932 30d kernel source merged"
You also need to update some tertiary CAF drivers like qcalcd-3.0. You may need to check the CAF repo to make sure you've nabbed all that apply. I'm going to assume you can merge a repo at this point.
qcacld:
Code:
git remote add qcacld https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0
git fetch qcacld LA.UM.7.4.r1-06000-8x98.0
fw-api:
Code:
git remote add fw-api https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/fw-api
git fetch fw-api LA.UM.7.4.r1-06000-8x98.0
qca-wifi-host-cmn:
Code:
git remote add qca-wifi-host-cmn https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qca-wifi-host-cmn
git fetch qca-wifi-host-cmn LA.UM.7.4.r1-06000-8x98.0
If your image compiled /before/ adding the CAF drivers but didn't compile /after/, check that your config flags are up to date before changing code around. qcacld-3.0 threw some errors for me in the upgrade from 3500 to 6000 unless I /also/ enabled WLAN_TX_FLOW_CONTROL_V2 in the defconfig, then reverted some of LGE's older custom patches (check OEM patches before modifying CAF code!).
The easiest way to poke around at flags is by doing a menuconfig after you run your "make O=./out joan_tmo_us-perf_defconfig" equivalent.
Code:
make O=./out menuconfig
UPDATE LINUX
Coming soon. Still ascertaining the easiest process. Git merge sounds like an obvious choice.

<reserved>

When you get enough posts we can request a Mod move it to Development section. Thank you for your efforts in developing the V30 more.

ChazzMatt said:
When you get enough posts we can request a Mod move it to Development section. Thank you for your efforts in developing the V30 more.
Click to expand...
Click to collapse
My only other post was apparently waaay back in 2009 about my HTC Touch Pro 2. I'm hoping I can bounce off of questions on this thread and hit 10 posts relatively quickly. And thank you! Without all the work the community had done already I wouldn't be this far along.
I've found the flag to allow the latest GCC 10.1 to compile now. Looks like it became a lot more picky in version 9 and the qcacld-3.0 build fails a buffer paranoia check.

Wow, very impressive write-up. Thanks a lot for sharing it.
I spent quite some time studying parts of the H932 kernel (and other models too) to better understand how the QuadDAC is implemented (es9218p codec). But my background is almost the opposite of yours: I was a prolific assembly language and C programmer back in the days, but have almost zero Unix/Linux experience. I would never be able to build the kernel, not even with your guide, so I couldn't make any changes to the codec, as much as I wanted.
Anyways, great contribution to the community. Thanks again!

TheDannemand said:
I spent quite some time studying parts of the H932 kernel (and other models too) to better understand how the QuadDAC is implemented (es9218p codec). But my background is almost the opposite of yours: I was a prolific assembly language and C programmer back in the days, but have almost zero Unix/Linux experience. I would never be able to build the kernel, not even with your guide, so I couldn't make any changes to the codec, as much as I wanted.
Anyways, great contribution to the community. Thanks again!
Click to expand...
Click to collapse
Collaboration is going to be key moving forward since we're probably not getting any more help from upstream. If you do make some improvements I'd be more than happy to fold it into a kernel release for testing.
I know a few other languages like Java and Python; I never had a reason to get my hands dirty with good ol' C until now. The syntax makes sense to me but I don't always have an underlying knowledge of the big picture. I won't be making my own kernel patches, instead pulling in known working code from newer sources.
CAF tag 6000 is running albeit with some obvious errors in the dmesg log. All the hardware seems to be working fine. I've had one soft reboot in 24 hours so it's getting to a point where I'll be able to release my source code/alpha build. I'm resisting the urge to name it "30e" to avoid confusion with official updates.

Caffination said:
Collaboration is going to be key moving forward since we're probably not getting any more help from upstream. If you do make some improvements I'd be more than happy to fold it into a kernel release for testing.
Click to expand...
Click to collapse
I'm sure you saw these other V30 custom kernel stuff:
https://github.com/zachariasmaladroit/kernel_lge_msm8998
Haumea kernel is the one I hear most about on Telegram group.
Of course compatibility is concern because T-Mobile H932 has different RSA encryption but maybe there's something there to give you ideas.

Caffination said:
Collaboration is going to be key moving forward since we're probably not getting any more help from upstream. If you do make some improvements I'd be more than happy to fold it into a kernel release for testing.
Click to expand...
Click to collapse
Thank you for the offer. It's over a year ago I looked at V30 kernels, and unfortunately that window has since closed for me. For one thing, I no longer have H932 (now on US998). But also, I lost much of my hearing to a nerve disease, so my interest in the QuadDAC is now purely academic.
Once again, I love your project and spirit, and much look forward to your postings around here.

TheDannemand said:
But also, I lost much of my hearing to a nerve disease, so my interest in the QuadDAC is now purely academic.
Click to expand...
Click to collapse
Very sorry to hear that.

ChazzMatt said:
Very sorry to hear that.
Click to expand...
Click to collapse
Thank you, buddy. Yeah it sucks.

Redmi Note 8 Ginkgo Q build question?

When I try to build Redmi Note 8 Q, the build process finished successfully, but I got into black screen after boot splash, where boot animation should appear. After a very long time (~10 mins), phone reboot into recovery.
I have tried LineageOS with trinket-devs trees, and Resurrection Remix with trinket-devs / Arrow OS/ DqrKn3Zz (rr-Official) trees, and I get the same results.
The steps I used to build (using Ubuntu 20.04):
1. repo init
2. add local_manifests includes device/vendor/kernel/proto-clang/miuicamera
3. repo sync
4. RR-ify device tree (only for build resurrection remix rom)
5. . build/envsetup.sh && brunch ginkgo | tee log.txt
Could anyone point out where things go wrong, do I get a wrong building environments, or miss some steps?