[UNOFFICIAL][PORT](11)HavocOS for us996 - LG V20 ROMs, Kernels, Recoveries, & Other Developm

i have used the LineageOS 18 device files and kernel available here:
GitHub - LineageOS/android_device_lge_msm8996-common
Contribute to LineageOS/android_device_lge_msm8996-common development by creating an account on GitHub.
github.com
GitHub - LineageOS/android_device_lge_us996
Contribute to LineageOS/android_device_lge_us996 development by creating an account on GitHub.
github.com
GitHub - LineageOS/android_kernel_lge_msm8996
Contribute to LineageOS/android_kernel_lge_msm8996 development by creating an account on GitHub.
github.com
i simply changed some references to lineage to instead reference havoc, and stuffed the necessary files into Havoc's build tree to create this haphazard port.
Havoc's source code i used: https://github.com/Havoc-OS/android_manifest
i cannot test other variants of V20, but it works on my us996.
UPDATE 2022-JAN-23: enabled SELinux, added LineageOS' ExactCalculator app. fingerprint is now non-functional, should come back by simply disabling SELinux with adb.
UPDATE 2022-JAN-25: fixed fingerprint and SELinux, added LineageOS' Eleven app. DeOdexed to reduce download size, expect long first-boot.
UPDATE 2022-JAN-27: fixed some SELinux conflicts, should solve some crashes.
UPDATE 2022-JAN-28: added LineageOS' "Jelly" browser.
i am not at all affiliated with either LineageOS or Havoc, i will honor any request by them to remove/edit this post. I am just a college student sharing the results of a weekend project.

Noice, it should run fine on other devices, just add their sources to the vendor and device tree. Also pro tip, Us996, vs995, h915 and h910 are cross compatible, if you find that running builds for each of them are hard, just make one for all (Vs995 preferably as it has the dirty santa patch). Also, look for denials though adb when booting to fix selinux.

Make sure it's permissive^ not disabled. IF disabled it will not show the denials, it needs to be permissive.

i got SELinux working, but i cant seem to get it to function alongside the fingerprint sensor. i am at a complete loss as to how to fix this.
audit2allow seems useless here. im pretty certain this is the culprit. any help is appreciated.
init: Control message: Could not ctl.interface_start for '[email protected]::IBiometricsFingerprint/default' from pid: 464 (/system/bin/hwservicemanager): File /vendor/bin/hw/[email protected] (labeled "u:object_r:vendor_file:s0") has incorrect label or no domain transition from u:r:init:s0 to another SELinux domain defined. Have you configured your service correctly? https://source.android.com/security/selinux/device-policy#label_new_services_and_address_denials

i have fixed the fingerprint and SELinux issue.

mathew2214 said:
i have fixed the fingerprint and SELinux issue.
Click to expand...
Click to collapse
Mind if I ask how? I'm working on a very different device, but similar issue; trying to add an executable somewhere and make init kick it off during boot.

Terminator.J said:
Mind if I ask how? I'm working on a very different device, but similar issue; trying to add an executable somewhere and make init kick it off during boot.
Click to expand...
Click to collapse
i just used autid2allow and patched the rules files.

Related

[REFERENCE] [3.10.105] Stock kernel with upstream Linux patches - May 9th

Introduction
Hello all, I am bringing you this thread as a jumping off point to compiling kernels and working with upstream Linux. I will include a guide, some links, and some terms that will help you get started with modifying kernel source. This is also a good reference point for existing developers as I have consolidated all upstream patches into one repo. Let's get down into it!
What in the world is upstream Linux?
When an OEM sets up a device, they will pick a stable longterm branch from the Linux kernel to base their modifications around (drivers and such). In the case of Shamu, they picked 3.10.40. Currently, the Linux kernel's 3.10 is updated to 3.10.105, as you can see on kernel.org. This means that Google is "missing" versions 3.10.41 to 3.10.105. Now, why does this matter? Well, the way that the Linux kernel runs its stable branches, the only things that get merged into there are bug fixes and security updates. That's it, there are no wonky features or unstable patches. The only way you get a patch into a stable branch is by having it be in the mainline branch first. Some developers have an aversion to adding upstream because they claim it is excessive and not necessary and they are partially right since not all the patches that come in are relevant to our architecture (arm). However, upstream Linux is not unstable and by adding each version one at a time, you can verify this. Being up to date is good since you keep yourself protected from bugs and security issues that crop up. Google has been better about doing this lately with their monthly security updates but it never hurts to take matters into your own hands.
I suggest watching one of these talks given by Greg Kroah-Hartman, it is really interesting to see how the process goes:
https://www.youtube.com/watch?v=SPY0LyTU53w | https://www.youtube.com/watch?v=L2SED6sewRw
What did you do?
All I did was fetch the latest kernel.org patches from here and cherry pick them on top of the latest kernel source from Google.
I merge these patches by cherry-picking each version individually (3.10.40 to 3.10.41, 3.10.41 to 3.10.42, etc), that way I can verify that the kernel compiles fine and that there are no merge conflicts. Google will sometimes pick certain commits from upstream that are of a higher importance than others which can result in conflicts if you try to pick it again. Additionally, upstream might fix a bug one way and Google has done it another (which is not really good, Google should be pushing their fixes back to upstream so everything stays in sync).
What do I do with this?
I have created two repos below: one with the latest N security update branch with the latest upstream patches picked up on top of it (the shamu-upstream branch) and another one with a plain AnyKernel source for you to modify (shamu-stock is the most basic, shamu-decrypt contains an fstab file that will disable both forced encryption and dm-verity). You are free to fork these or base other branches on them, that's the whole point of this post. I have verified that all the patches contain no major detectable issues. I would like some credit if you do use it but it's not required since the kernel is licensed under GPL Another reason I offer this is I have seen a lot of developers picking in upstream in patch sets, so you get one single commit for an upstream version. This is detrimental as you start to add your own patches as you cannot fully tell what was modified and for what reason without the individual commits. It might look cleaner but you don't get full history which hurts you in the long run.
Links
Kernel source: https://github.com/nathanchance/shamu/tree/upstream-7.1.1
AnyKernel source: https://github.com/nathanchance/AnyKernel2/tree/shamu-stock-decrypt
Toolchain source: https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8/
How to compile
This will be a quick, step by step guide on how to compile this kernel from source. By using this process, you can start to make modifications to the kernel source and make a flashable zip.
Clone the kernel source, the AnyKernel source, and toolchain source
Code:
cd ~
mkdir Kernel && cd Kernel
git clone https://github.com/nathanchance/shamu.git source
git clone https://github.com/nathanchance/AnyKernel2.git anykernel
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8 AOSP-4.8
Explanation:
First command: make sure you are in your home directory (or whatever directory you want to hold the kernel folder we are about to make.
Second command: make a Kernel folder and move into it
Third command: clone the kernel source from my repo into a folder named source
Fourth command: clone the AnyKernel source from my repo into a folder named anykernel
Fifth command: clone the Google 4.8 toolchain into a folder named AOSP-4.8
AnyKernel is the name of the zip we are going to make which allows the kernel to be flashed over any ROM.
A toolchain is a set of compiler tools that allow us to compile the kernel on any computer architecture.
Make sure you are on the correct branches
Code:
cd source && git checkout upstream-7.1.1
cd ../anykernel && git checkout shamu-stock-decrypt
Explanation:
First command: move into the source directory and checkout the branch "upstream-7.1.1", which is the necessary branch for this device.
Second command: move into the AnyKernel directory and checkout the branch "shamu-decrypt". If you don't want to disable forced encryption, use the "shamu-stock" branch.
Tell the compiler what you are are compiling
Code:
export CROSS_COMPILE=${HOME}/Kernel/AOSP-4.8/bin/arm-eabi-
export ARCH=arm && export SUBARCH=arm
make clean && make mrproper
make shamu_defconfig
Explanation:
First command: point the compiler to the location of your toolchain. If you have done anything different with the folder locations, you will need to modify the "${HOME}/Kernel/AOSP-4.8" part.
Second command: tell the compiler which architecture we are compiling for. In this case, our device is an arm device.
Third command: clean out any compiled files and remove our previous defconfig.
Fourth command: tell the compiler which options we want in the kernel using the shamu_defconfig.
A defconfig is a file that will tell the compiler which features we want in the kernel. No computer ever uses all of the options in the kernel since there are different drivers for various devices.
Make the kernel!
Code:
make -j$(nproc --all)
Explanation:
make tells the compiler to make the kernel (duh) and the -j$(nproc --all) tells the compiler to use the maximum number of cores your computer has available
Make the AnyKernel zip
Code:
cp -v arch/arm/boot/zImage-dtb ../anykernel
cd ../anykernel
zip -r9 stock-upstream.zip * -x README stock-upstream.zip
Explanation:
First command: copies the completed kernel (zImage-dtb) into the AnyKernel folder
Second command: moves us into the AnyKernel folder
Third command: makes the zip file (named stock-upstream.zip) in the AnyKernel folder.
If you ever want to do this again, run these commands and go straight to step 3:
Code:
cd source && git clean -fxd && git pull
cd anykernel && git clean -fxd && git pull
NOTE: This thread is aimed to be a breeding ground for kernel development, a place to jump off if you will. I am happy to answer how to questions about building kernels or flashing the one I have provided but this is not supposed to be a general Q&A thread. Please use another thread or create your own in Q&A if you need assistance.
Nice write up.
One suggestion though. Instead of using the current version as the branch name, you may want to just name them for the device, like "Shamu-Upstream" then tag the versions once you've gotten to the version commit. This will prevent you from having to update the thread for this command anytime that you pull in more upstream changes. It also makes it alot cleaner/easier if someone for whatever reason wanted to checkout a specific patch version as they could just checkout the tag rather than resetting back to the commit.
For lack of a better explanation, tags are sort of like sub-branches within a branch.
Very new to kernel building and AOSP in general. Followed the guide but I'm getting stuck when make mrproper is ran. Build stops and i get the error : unknown target 'mrproper' then the build fails. Any help?
The Flash said:
Another reason I offer this is I have seen a lot of developers picking in upstream in patch sets, so you get one single commit for an upstream version. This is detrimental as you start to add your own patches as you cannot fully tell what was modified and for what reason without the individual commits. It might look cleaner but you don't get full history which hurts you in the long run.
Click to expand...
Click to collapse
That's true. Some devs are lazy to commit each patch and bring up from 3.10.40 to 3.10.103 which comprises nearly 3000 patches.
neobuddy89 said:
That's true. Some devs are lazy to commit each patch and bring up from 3.10.40 to 3.10.103 which comprises nearly 3000 patches.
Click to expand...
Click to collapse
Exactly lol. It's also annoying for people looking at your source because if you had to fix anything, it is going to be lumped in with that enormous patch.
Root Wizard said:
Very new to kernel building and AOSP in general. Followed the guide but I'm getting stuck when make mrproper is ran. Build stops and i get the error : unknown target 'mrproper' then the build fails. Any help?
Click to expand...
Click to collapse
can I see a full terminal window/log showing you entering all the commands?
The Flash said:
can I see a full terminal window/log showing you entering all the commands?
Click to expand...
Click to collapse
Just logged off for the night. Will give a full report back tomorrow with pictures. Basically all the commands go good up to 'make mrproper' . 'make clean' runs fine but the 'make mrproper' goes through incuding all the aosp files for build, then ninja enters build directory, then the error 'unknown target 'mrproper' ' comes up, and the build fails.
Root Wizard said:
Just logged off for the night. Will give a full report back tomorrow with pictures. Basically all the commands go good up to 'make mrproper' . 'make clean' runs fine but the 'make mrproper' goes through incuding all the aosp files for build, then ninja enters build directory, then the error 'unknown target 'mrproper' ' comes up, and the build fails.
Click to expand...
Click to collapse
Oh you're building this into a ROM? Alright, that might make things different but yeah show me pictures tomorrow and I'll try to get you up and running.
The Flash said:
Oh you're building this into a ROM? Alright, that might make things different but yeah show me pictures tomorrow and I'll try to get you up and running.
Click to expand...
Click to collapse
Ah I guess I should have metioned that I was building an aosp rom. Thanks for your quick assistance. Will get back tomorrow.
If you're building into a rom, you just need to change the existing kernel source to this one in the xml for this device.
Yoinx said:
If you're building into a rom, you just need to change the existing kernel source to this one in the xml for this device.
Click to expand...
Click to collapse
Can you explain how to do this? First time building with aosp, not very familiar which xml file or what to change to apply the upstream patch.
Root Wizard said:
Can you explain how to do this? First time building with aosp, not very familiar which xml file or what to change to apply the upstream patch.
Click to expand...
Click to collapse
For shamu in aosp, the kernel is pulled with the main aosp source by that manifest. https://github.com/android/platform_manifest/blob/master/default.xml#L65
You world need to substitute this repo with the new one, and delete your existing kernel source. Then next time you sync the repo tool will pull it down.
On other roms it gets pulled in during the breakfast/brunch process. I can't remember exactly where that comes from, but I think that is in the vendor directory for the device, maybe.
How to modify rom manifests and such though is a little outside of this thread's topic. If you need more info I'd recommend opening a thread in the Q&A forum unless this is something that The flash wants to cover in this thread.
There are a few other caveats with doing it in the rom as well. The defconfig name would need to match what the rom build expects and you would need to go in and checkout the correct branch.
Yoinx said:
For shamu in aosp, the kernel is pulled with the main aosp source by that manifest. https://github.com/android/platform_manifest/blob/master/default.xml#L65
You world need to substitute this repo with the new one, and delete your existing kernel source. Then next time you sync the repo tool will pull it down.
On other roms it gets pulled in during the breakfast/brunch process. I can't remember exactly where that comes from, but I think that is in the vendor directory for the device, maybe.
How to modify rom manifests and such though is a little outside of this thread's topic. If you need more info I'd recommend opening a thread in the Q&A forum unless this is something that The flash wants to cover in this thread.
There are a few other caveats with doing it in the rom as well. The defconfig name would need to match what the rom build expects and you would need to go in and checkout the correct branch.
Click to expand...
Click to collapse
Ok, thanks for your help.
For those of you who have forked my kernel, you will need to revert this patch: https://github.com/nathanchance/and...mmit/0b17006c16bba286ecc9d7bacd75a3902a26835e
It causes issues with Wi-Fi and Chrome.
The Flash said:
For those of you who have forked my kernel, you will need to revert this patch: https://github.com/nathanchance/and...mmit/0b17006c16bba286ecc9d7bacd75a3902a26835e
It causes issues with Wi-Fi and Chrome.
Click to expand...
Click to collapse
It does? I have been using Chrome Beta (on wifi) since last night fine with that patch. Maybe its just a matter of time before things start failing. Thanks anyway, will keep a heads up.
Root Wizard said:
It does? I have been using Chrome Beta (on wifi) since last night fine with that patch. Maybe its just a matter of time before things start failing. Thanks anyway, will keep a heads up.
Click to expand...
Click to collapse
If you toggle Wi-Fi, start flipping through pages in Chrome, and toggle Wi-Fi again, it will reboot. Oddest issue I have ever dealt with.
Sent from my Nexus 6P using XDA Labs
The Flash said:
If you toggle Wi-Fi, start flipping through pages in Chrome, and toggle Wi-Fi again, it will reboot. Oddest issue I have ever dealt with.
Click to expand...
Click to collapse
Interesting, will look into this. I also have been getting reboots from searching forums in xda labs app. Logcat says a ton of "PowerHAL_touch_boost failed to send: Connection refused" before reboots. Is this what is happening to you?
Root Wizard said:
Interesting, will look into this. I also have been getting reboots from searching forums in xda labs app. Logcat says a ton of "PowerHAL_touch_boost failed to send: Connection refused" before reboots. Is this what is happening to you?
Click to expand...
Click to collapse
No I haven't had that happen but that error shouldn't cause reboots.
The Flash said:
No I haven't had that happen but that error shouldn't cause reboots.
Click to expand...
Click to collapse
Huh, odd
Github and the kernel in the OP are updated to 3.10.104.

[APP][XPOSED][UNOFFICIAL][6.0+] XPrivacyLua Mod - Android privacy manager

XPrivacyLua Unofficial Build
This is an unofficial build of XprivacyLua with the scope to prevent privacy violations and tracking. Contrary to the official XprivacyLua release, this build provides the ability to block device specific IDs (Sensordata, IMEI, SIM-Serial number, SubscriberID, phonenumber, etc.) for limiting the possibility of tracking by too curious apps. As this, as well as the original version, is still in an early stage of development, not all personal or device specific data are covered at present. It will probably take some time until userdefined lua scripts get into the official version. In the meantime, this application will close the gap that resulted from the decision of the main developer not to prevent tracking based on the reading device IDs.
I would like to point out that I haven't written any code myself yet. Only the restrictions deactivated by M66B were reactivated in the source code (hooks.json).
I will try to keep this app synchronized to the latest official builds. In future I planning to extend the protection against tracking and more. However, it will take some time to add own code, because I have just started learning Java programming. Forgive me if my first coding attempts may not be as accurate and neatly written as M66B is.
ATTENTION: DO NOT DISCUSS THIS FORK IN THE OFFICIAL THREAD!
M66B said:
... Anyway you have my permission, but I reserve the right to revoke that permission if people are going to discuss here about your fork.
Click to expand...
Click to collapse
XDA thanks! I dont want any donations!
If you want to support the project, please send donations to the official contributor.
Standard Restrictions (official build)
Get applications
Get calendars
Get call log
Get contacts (including blocked numbers)
Get location
Get messages (MMS, SMS, SIM, voicemail)
Read account name (mostly e-mail address)
Read clipboard
Record audio
Record video
Use camera (take pictures)
Reenabled Restricions (unofficial build)
Sensor Data
Phone Data (IMEI, SubscriberID, SIM-Serial, ...)
XDAevDB Information
XPrivacyLua, Xposed for all devices (see above for details)
Contributors:
M66B (Developer of the official XPrivacyLua)
Participated:
EinsteinXXL
Installation:
Download, install and activate the Xposed framework (skip this step if already installed)
Download, install and activate the mod edit - link removed
Source Code: mod edit - link removed
App Download: mod edit - link removed
Xposed Package Name: eu.faircode.xlua
Version Information
Status: Beta
More information about XPrivacyLua, please visit the official thread!
Current Version: 0.20
Last Update: 2018-01-14
EinsteinXXL said:
...
Contributors:
M66B (Main Developer of the official build)
EinsteinXXL
Click to expand...
Click to collapse
I wouldn't call this a contribution, since it is just enabling something that was already developed:
https://github.com/EinsteinXXL/XPrivacyLua/commit/c7a46e28831b60323d26f2c086fe8ec343f3b7fd
thread closed as per OP request

[GUIDE]Working with Android Kernel from Scratch

Introduction
I am writing this guide as I was unable to find a well-documented thread over XDA (there are just a lot of them). In case there is anything that concerns this guide, feel free to ask in this thread. I expect you to know the basics of Linux, GIT, Android. Please look over some guides in the forum in case you are not familiar with them. In case you want to contribute to this, feel free to do so. I welcome everyone's contribution to be it fixing my derp, pointing a mistake or adding a new section.
Links to some nice documentations:
Git Documentation
Linux Kernel Newbies
How to take logs in Android
How to get an Android kernel up to date with linux-stable
Checking Current CAF Tag of the Kernel
We will be using best_kernel for this purpose, whose aim is to compare your current kernel source code with different CAF tags and select the best possible match using git diff.
Clone/Download your kernel repo and commit your changes(if not already committed) as best_kernel depends upon git diff to compare changes.
Depending upon your kernel version, add required CAF kernel repo as remote and fetch it. best_kernel will use this fetched data to compare changes.
After fetch is done, run best_kernel. It should run automatically if you have placed dotfiles in the $BIN directory and have the necessary dependencies installed.
best_kernel will compare changes and will provide results based on that. However, depending on the number of tags, it will take time. A lot of time, so go and grab a cup of coffee till then.
A Dummy Example:
Downloading stock kernel source code from OEM’s website
Code:
wget http://nokiaphones-opensource.azureedge.net/download/phones/Nokia6.1_V2.22J.tar.bz2 && tar xvjf Nokia6.1_V2.22J.tar.bz2 && cd kernel
Adding and committing all files due to lack of a .git dir.
Code:
git init && git add --all && git commit -m "Initial Commit"
As the kernel source code version is 4.4, I will add 4.4 remotes from CAF and fetch it.
Code:
git remote add caf https://source.codeaurora.org/quic/la/kernel/msm-4.4/ && git fetch caf
After fetch, I will check for the current CAF tag using best_kernel. As my device platform is sdm660 and CAF has been releasing sdm660 tags as sdm660.0, I will be using it as an argument in best_kernel. This will ensure that best_kernel doesn’t waste time checking CAF Tags of other platforms and will speed up the process considerably.
Code:
best_kernel "*sdm660.0"
RESULT will be something like this:
Code:
Best match TAG: LA.UM.6.2.r1-06900-sdm660.0 Lines changed: 177924
What is CAF/Code Aurora | CodeAurora Android Releases Page | CAF Kernel Sources​
Creating/Importing GIT History for Kernel Source
A lot of OEMs release kernel sources in a compressed format excluding the .git dir which results in no git history. Creating or it's better to say to import one is simple and easy.
Download and check the current CAF tag of your Android kernel source.
Note: If your chipset is not Qualcomm, you should visit Linux Kernel Source or AOSP's Kernel Common and use that as a base while checking out to the specific version of your kernel source you are going to copy-paste. Qualcomm devices can also use that as a ref but I will recommend them to use CAF source.
Based on that CAF tag, download the respective kernel repository from CAF and checkout for that specific tag.
Copy and paste your downloaded kernel source (with no history) over the CAF one (which has the history of that CAF tag).
Commit the changes.
You have accomplished creating/importing history.
A Dummy Example:
My current CAF tag is LA.UM.6.2.r1-06900-sdm660.0.
Therefore, cloning kernel source from CAF and checking out for this tag while creating a new branch named rebase.
Code:
git clone https://source.codeaurora.org/quic/la/kernel/msm-4.4/
cd msm-4.4/
git checkout tags/LA.UM.6.2.r1-06900-sdm660.0 -b rebase
Now, I will copy-paste the kernel source that I downloaded from OEM's website over the CAF one. Assuming the downloaded kernel is in ~/Downloads/kernel and CAF kernel source is in ~/msm-4.4 directories.
Code:
#Renaming the dir so, that it will get merged while copying due to similar names
mv kernel/ msm-4.4/
cp -avr msm-4.4/ ~/msm-4.4
cd ~/msm-4.4
git status
git commit -m "Import Nokia Kernel Source"
Keep in mind that a .gitignore is generated which can and will ignore files during commit which were not getting ignored earlier due to its absence. In case during compilation you encounter any error stating about missing file, add it forcefully and commit again.
Remember, its always good to split that one big commit into small parts. It's helpful when you start rebasing your kernel usually when new CAF Tag for new android versions come out. Solving a few conflicts ina lot of commit is much better than solving a load of them in one. It also gives you a chance to easily diff on websites like GitHub so that you can figure what's a particular line is doing.
Doing that is also easy. Just reset head for a particular folder like driver/touchscreen and commit them separately. Check git rebase documentation which will help you with this.
Upstreaming your Kernel
Merging upstream versions is a really good thing. It brings in security patches, stability, new features and much more. The usual and best way is to visit Linux Kernel Source and check if there are upstream updates available. If yes, start merging them in your kernel source one by one.
Note: If your chipset is not Qualcomm, you should visit Linux Kernel Source or AOSP's Kernel Common and use that as a base. Qualcomm devices can also use that as a ref but I will recommend them to use CAF source.
A Dummy Example:
Assuming my current kernel version is v4.4.205, I will fetch v4.4.206 from Linux Kernel Source and merge that. I can also fetch and merge different branches from CAF Source which are usually upstreamed with Linux-stable (for example, aosp/upstream-linux-4.4.y branch)
Code:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git v4.4.206
git merge FETCH_HEAD
Fix conflicts if you get some. What to keep and what not is a question that depends upon the device to device. Usually, you should compare local changes and upstream and try to figure out what could be the best way to fix it. I will advise to check the history of that file in upstream and see which commit caused that conflict and why. You can also check similar merges by other same kernel versions to see if they had the same conflict and how they fixed it.
I will also advise merging AOSP's kernel/common and new CAF upstream tags (Only QCOM devices should merge new CAF tags) regularly when available. The reason is pretty simple. There are commits that get merged in AOSP like which improves performance or other stuff which doesn't get merged in Linux Kernel Source. This way you can get the benefit from all sources. This, however, is not pretty easy and might result in a huge number of conflicts considering if OEM has modified the source a lot from upstream.
CAF also hosts f2fs and other file system changes on their servers. Merge it if you want and use it.
Compiling Standalone Kernel
Compiling a kernel standalone requires you to have a compatible toolchain like GCC or Clang. The best way to figure out which one suits your need is testing and debugging. The standard AOSP GCC toolchains are recommended for devices with old kernels, to begin with, while newer ones can use clang with backports or upstream merges. In case you want to compile with clang, checking out android-kernel-clang is a good way, to begin with.
Compiling standalone kernels can give a lot of missing headers errors/warnings. This is due to not compiling it in a ROM environment. This can be easily fixed either by correcting paths of those header files being included or creating an out dir manually and using it as output. You can also use this commit to do that automatically.
Clone your kernel source and desired toolchain(s). Export arch and cross compiler arguments. Choose the desired defconfig to make and compile.
A Dummy Example:
I will clone the kernel source and toolchain in the same dir and export the following arguments in kernel source root dir.
Code:
export ARCH=arm64
export CROSS_COMPILE=/media/hdd/aayush/kernel/aarch64-elf-gcc/bin/aarch64-elf-
make nokia_defconfig
make -j$(nproc --all)
Kernel conflicts might occur. You can search on GitHub to check if someone has fixed that already, otherwise fix the issues yourself. Comparing code with upstream repositories is also a way to figure out the differences. Choosing defconfig can be a bit tricky if you are doing bringups. I recommend pulling the current defconfig from your device itself. Its usually by the name of config.gz in /proc/ of your device.
Links to some cross compiler
GNU Toolchain by ARM
DragonTC
GNU and Linaro
Working with TWRP from Scratch
This post is supposed to help you with building TWRP from scratch for the first time if you are a newbie. There are some good resources already available for that over the web, specially XDA. I am linking some good ones below that you can read for more info on it.
How to compile TWRP Touch Recovery
The aim of a device tree is to contain the device-specific code for the build you are doing. In this case, as we are building TWRP which is a custom recovery, only flags relating to building TWRP and a normal recovery are enough to build it. Adding system specific codes like partition sizes for the system, vendor, boot and other doesn't contribute anything. An example tree can be begonia's tree hosted on TeamWin's org maintained by me.
Now coming to the device you want to build TWRP for, you will the following :
- A working kernel
- Device-specific binaries/libraries etc required for features like encryption which heavily differs on OEM implementation
AB devices need an extra commit in their kernel to make 'fastboot boot' command work: init: initramfs: disable do_skip_initramfs . Additionally if your device ships a separate DTBO image you will also need the following flag and the DTBO image: begonia: Build DTBO image into recovery
Newer devices are nowadays coming with 'fastboot boot' command disabled. Nokia 8.1 is an example of it. To make it work again, you might need to tweak bootloader which can prove to be risky.
Now coming to creating a device tree for TWRP. The very first step is to look out if someone else has booted TWRP on a similar SOC, OEM or same device. It can be used as a reference to fix similar/OEM related bugs and hacks quickly. In case, one doesn't exist, just pick a latest one from Teamwin's Github org for the android version you are compiling for.
Reserved (2)
Wew many thanks,
Thanks
Have just started exploring xda chef central.
I cam across this guide, really ahlepful Hope you complete it soon.
Updated the thread. Fixed formatting, links and added a new section.
How To Unofficially Unlock Bootloader For LG G8
We all know LG G8 is a android device. It's open source. But I recently bought a LG G8 only but it's locked to sprint sim . No any sim work. I can't unlock bootloader. I can't root. I can't flag firmware or install custom recovery. Anyone know here , how to totally remove firmware and but another firmware ? Why we can't build a method to do that?
TheImpulson said:
Updated the thread. Fixed formatting, links and added a new section.
Click to expand...
Click to collapse
Can you create a guide for, "How to Rebase an Android Kernel". Like from Android 9 to Android 10?
thanks for this guide bro
While using best caf kernel, Prefix of the caf tag should start with a -
For example, "*- sdm660.0"
@theimpulson
Hey there,
Am getting this error del.dog/megupebinu.txt
While trying execute best_kernel script
This is helpful, thanks mate
@theimpulson I had a question: (Before reading this guide) I had already downloaded stock Samsung sources and git init push the thing to my Github. So will anything bad happen if I did it this way or do I have to rebase it with CAF?
Also what are the benefits of these so-called CAF based kernels everywhere? Improved performance? Cuz I really wanted to compile my own kernel specifically for performance with WSL-2 (shameless plug)
Thanks in advance and sorry if the @ bothered you,
Ishaq
NullCode said:
@theimpulson I had a question: (Before reading this guide) I had already downloaded stock Samsung sources and git init push the thing to my Github. So will anything bad happen if I did it this way or do I have to rebase it with CAF?
Also what are the benefits of these so-called CAF based kernels everywhere? Improved performance? Cuz I really wanted to compile my own kernel specifically for performance with WSL-2 (shameless plug)
Thanks in advance and sorry if the @ bothered you,
Ishaq
Click to expand...
Click to collapse
The existing sources are fine, no issues if you are fine without any git history.
SOC specific optimizations, bug fixes etc. Nothing more. So, yeah, if you want SOC specific optimizations, performance improvements, you will want to merge latest CAF tags for your kernel.
theimpulson said:
The existing sources are fine, no issues if you are fine without any git history.
SOC specific optimizations, bug fixes etc. Nothing more. So, yeah, if you want SOC specific optimizations, performance improvements, you will want to merge latest CAF tags for your kernel.
Click to expand...
Click to collapse
thanks a lot for the reply! Another thing, because of your suggestion I tried to Import the git history (and i succeeded). Then I wanted to upload these sources to my own Github, which I can't figure out how to do. It only gives Github repo for the place where it came from (msm-3.18). Help me please
Edit: The guides which I found for merging CAF tags say that my base also has to be CAF (which it isn't) and this guide here basically does not work

[Discontinued] LineageOS 17.1 for SM-T580 (gtaxlwifi)

This is LineageOS 17.1, which is based on Android 10, for the WiFi-only variant of the Samsung Galaxy Tab A 10.1" (2016), codenamed gtaxlwifi. LineageOS doesn't need much of an introduction - It's a well-known custom firmware/Android distribution.
I started these builds because the LineageOS builds from @Valera1978 had 2 particular significant bugs in them that were always being mentioned in posts in that thread: display backlight brightness not changeable from full brightness and the touchscreen appearing to not respond after putting the tablet to sleep. Those bugs had existed for quite a long time. @followmsi has some changes in his 17.1 device tree that fixed those 2 bugs.
These builds really became a continuation of Valera's builds after he unfortunately discontinued work on this device due to an (understandable) lack of interest, with many improvements and additional features.
I've now discontinued these 17.1 builds.
I've long ago moved onto LineageOS 18.1 and 19.1.
Very important note for those upgrading from the releases from 20210523 and 20210413 in this post: https://forum.xda-developers.com/t/lineageos-17-1-for-sm-t580-gtaxlwifi.4059571/post-85106105
Note: I've never had any builds for the LTE variant. However, builds for the WiFi-only variant boot and work on the LTE variant, only without mobile networking (of course), GPS and vibration, so since I've allowed installation on the LTE variant in the last several builds, you can try to use my builds on it if you can go without any of that functionality.
Downloads:
Latest build from 20211116 (with security patch level 20211105):
https://drive.google.com/file/d/14ZCYYcT5b6E9zWiFNgwUP3Kxlvf-dyVn
Folder for these builds (which includes text files with MD5 and SHA256 checksums for the final build, and another folder within it containing some previous builds): https://drive.google.com/open?id=1UiUlSbfj3agDvt-4f_YLIS0Xyuz5RtFC
Changelog:
Final release for 20211116:
Latest updates from LineageOS, including the 20211105 Android security updates.
The WiFi driver has been switched from being a kernel module to being built into the kernel. This may improve reliability for enabling and disabling WiFi and the WiFi hotspot very slightly.
The rewrite of the sepolicy containing all of the SELinux rules that I did for 18.1 has been ported over to 17.1, and so it's now of much better quality.
The audio outputted from the audio jack while playing media will now be noticeably louder, as the headset "DAC1 playback volume" for media has been increased to the maximum of 175 from 162.
An issue where there was additional extremely quiet high-pitched noise from the right speaker has been fixed.
The ZRAM size has been increased to 768MiB.
The BSP sources have been redone to closely match what has been done with the new exynos7880-specific part of Lineage's BSP sources, and with that, there are now more exynos7870-specific changes to the open source gralloc that is in use.
Some miscellaneous cleanups have been done.
The qcom_cfg.ini configuration file for WiFi has been imported from Samsung's A720SKSU5CTL2 firmware - A change within it appears to have made WiFi more reliable.
The system image size has been increased from 3072000000 bytes to 3145728000 bytes, which is the size of the system partition on Korean and Chinese variant T580s and T585s, and the smallest system partition size out of all T580s and T585s.
Some proprietary blobs have been updated as follows:
WiFi and Bluetooth firmwares from Samsung's T390XXS9CUG1 firmware
libexynoscamera3.so library from Samsung's P580ZSS1CTI1 stock firmware - This improves the situation with the issues with stretched/squashed camera previews for images and stretching/squashing in videos at some resolutions
MFC (Multi-Format Codec) firmware from Samsung's A305FDDU6CUI3 firmware
sensors.universal7870.so library from Samsung's P580ZSS1CTI1 stock firmware
As the oldest proprietary blobs are now as in Samsung's P580ZSS1CTI1 stock firmware (with a few exceptions), the vendor security patch level has been increased to 2020-09-01, which is the security patch level that firmware has.
The 32-bit wcnss_filter binary, used for Bluetooth, that was used previously has been replaced with the 64-bit wcnss_filter binary from Samsung's A520FZTU4BRB1 firmware.
Configuration files for media codecs and profiles have been updated from Samsung's T580XXS5CTK1 stock firmware.
There are many (final) updates from the (unfortunately now deprecated so no longer updated) 3.18 Android common kernel, many updates from Linux 4.4, and some updates from a few of Samsung's newer kernel sources to the kernel, and also some other various changes.
A few changes have been imported to the MMC block device driver in the kernel from Samsung's M105GDXS6CUD4 kernel sources that specifically fix extremely rare kernel panics that occurred when there was an error with a MMC device (mainly with SD cards).
Some unnecessary drivers have been disabled in the kernel.
The sdfat driver in the kernel, which is used for exFAT filesystem support, has been updated to version 2.4.5.
The fix for an issue where the duration of videos that are taken is lengthened by the time spent in deep sleep/suspended that was previously used has been replaced with a better fix in the Exynos fimc-is2 driver in the kernel.
Previous releases:
Release for 20210530:
Latest updates from LineageOS.
File-based encryption has been disabled after I left it enabled by mistake after testing FBE before moving onto LineageOS 18.1.
Release for 20210523:
Latest updates from LineageOS, including the 20210505 Android security updates.
Some changes have been imported to libbt-vendor from https://github.com/LineageOS/android_hardware_qcom_bt on branch lineage-18.1-caf (same as branch lineage-17.1-caf).
The rampatch_tlv_tf_1.1.tlv firmware for Bluetooth has been updated from Samsung's stock T585XXS6CTJ7 firmware.
There are some updates from the 3.18 Android common kernel and Linux 4.4 to the kernel.
A workaround that was used to get USB tethering and Bluetooth tethering to work is no longer used, and has been replaced with a proper fix (enabling CONFIG_NETFILTER_XT_TARGET_CT in the kernel).
Release for 20210413:
Latest updates from LineageOS, including the 20210405 Android security updates.
There are some updates from the 3.18 Android common kernel and Linux 4.4 to the kernel.
Release for 20210313:
Latest updates from LineageOS, including the 20210305 Android security updates.
There are some updates from the 3.18 Android common kernel and Linux 4.4 to the kernel, many changes to the rcu, locking and btrfs code from 4.4, and a few changes from Samsung's M105GDXU6CUA1 kernel to the kernel.
The exynos part of the BSP has a few changes from Lineage's 18.1 branch for HWC and memtrack.
Release for 20210207:
Latest updates from LineageOS, including the 20210205 Android security updates.
SELinux denials that caused the torch feature to not work have been addressed.
The issue where videos that are recorded have a duration that is lengthened by the time spent in deep sleep has been worked around - It looks like Samsung did something wrong in the camera HALs for Exynos 7870 devices.
There are some more updates from the 3.18 Android common kernel and Linux 4.4 to the kernel, and a few changes from Samsung's M105GDXU6CTL3 kernel.
Release for 20210116:
Latest updates from LineageOS, including the 20210105 Android security updates.
The custom camera provider HAL has been removed, and the camera provider HAL has been binderized - this fixes camera glitches when there is motion.
Quota support has been enabled on userdata, so that storage usage statistics can be gotten more quickly.
The Widevine DRM blobs from the Pixel 3 XL's last Android 10 firmware are now used.
The MFC (Multi Format Codec) firmware has been updated from Samsung's M105FDDU3CTK3 firmware, and the camera.vendor.universal7870.so library has been updated from Samsung's latest stock firmware (version T580XXS5CTK1).
There are some more updates from Linux v4.4 and the 3.18 Android common kernel to the kernel.
Release for 20201223:
Latest updates from LineageOS.
Address hal_graphics_composer_default SELinux denials on video_device - fixes issues with video playback with SELinux set to enforcing. (Thanks to @Kostareka for providing logs with the SELinux denials)
Release for 20201221:
Latest updates from LineageOS, including the 20201205 Android security updates.
I've prepared new BSP sources, based on Lineage's SLSI BSP sources, and the BSP libraries are now built from those sources. (Thanks to @Valera1978 for providing his old BSP sources! Without them, this wouldn't have been possible.)
Samsung's proprietary audio libraries, adapted by @Valera1978, are now used, to workaround an issue where audio will be outputted to both the 3.5mm audio jack and the speakers quietly when something is connected to the audio jack.
The build fingerprint has been changed to an older Android 8.1 fingerprint for the Google Pixel C. (For information on why we can't use the fingerprint from the stock firmware, see: https://github.com/TALUAtGitHub/android_device_samsung_gtaxlwifi/issues/1 )
Installation on the LTE variant (SM-T585, codenamed gtaxllte) is now allowed - apparently, builds for the WiFi-only variant boot and work on the LTE variant, only with no mobile networking (of course) and GPS.
There are a few minor cleanups.
Version 2 of the AOSP bluetooth audio HAL has been enabled.
FIFO UI scheduling has been enabled.
The camera libraries have been updated from Samsung's latest stock firmware, version T580XXS5CTK1.
There are a few other miscellaneous improvements.
There are some updates to the kernel from the Android 3.18 common kernel and Linux v4.4, and there are updates to some of the drivers from Samsung's M105GDXU5CTI3 kernel.
Release for 20201121:
Latest updates from LineageOS, including the 20201105 Android security updates.
The sepolicy has been improved - many unnecessary SELinux rules have been removed and a few SELinux denials have been addressed.
The init.power.rc script is now actually used to set some parameters for the interactive CPU governor to make it less aggressive.
The GNSS and sensors HAL are now compiled from source in the device tree with necessary modifications. (Thanks to @followmsi for some very useful information regarding this!)
As many vendor blobs as possible have been updated from Samsung's T580XXS5CTD1 and A520FXXUGCTI9 stock firmwares, the gpsd shim has been removed as it's no longer necessary after updating gpsd from T580XXS5CTD1 and a few unused vendor blobs have also been removed.
cbd/cpboot-daemon has been removed, because it, along with the modem_v1 driver in the kernel, no longer works with the latest bootloader and spams the kernel log with error messages, I have very little idea of what it does for the WiFi-only variant and it's unnecessary.
Made a few other miscellaneous improvements.
Many more updates to the kernel from Linux v4.4 and the 3.18 Android common kernel, some miscellaneous improvements and many changes to the f2fs filesystem driver from newer Android common kernels and mainline Linux.
The kernel is now compiled using the clang compiler after having applied the many necessary changes to it to do so.
Release for 20201022:
Latest updates from LineageOS, including the 20201005 Android security updates.
Enable config_setColorTransformAccelerated - LiveDisplay colour calibration and reading mode is now available. (Thanks to @followmsi for finding this fix.)
Add FlipFlap for flip covers. (Note that FlipFlap only works if the timeouts in Settings -> Connected devices -> Connection preferences -> Smart cover are set to 'immediately')
Fix a typo in the power profile.
More updates to the kernel from Linux v4.4 and the 3.18 Android common kernel.
Apply/backport some changes to zram and the lz4 compression algorithm from mainline Linux for faster compression and decompression, and add a backport of the zstd compression algorithm from the 4.9 Android common kernel which can be used as the compression algorithm for zram (lz4 is still the default compression algorithm).
Release for 20200915:
Latest updates from LineageOS, including the 20200905 Android security updates.
Increase microphone gains.
Many more updates from Linux v4.4 and android-3.18 and a few improvements to the kernel.
Release for 20200821:
Latest updates from LineageOS.
A few more updates from Linux v4.4 and android-3.18 and improvements to the kernel.
Revert 2 changes to the kernel related to hotplugging - should fix an issue where the device doesn't wake up after a while of deep sleeping in certain cases, and a hard reset is needed.
Release for 20200814:
Latest updates from LineageOS, including the 20200805 Android security updates.
Update the Mali graphics blob to r28p0 from r22p0.
Make a few changes for GPS that fix Assisted GPS, and switch to different XTRA servers with HTTPS.
Fix OpenCL.
Symlink libGLES_mali.so to libOpenCL.so, libOpenCL.so.1 and libOpenCL.so.1.1 instead of copying - saves a significant amount of space in /system and makes the installation zip slightly smaller.
Change media volume control to be in 25 steps rather than 15 steps.
More updates from Linux v4.4 and android-3.18 to the kernel and some improvements.
Release for 20200711:
Latest updates from LineageOS.
Android security updates from 20200705, manually applied to skip the wait for them to be merged. ('repopick -t android-10.0.0_r40')
Disable window rounded corner animations.
Reduce ZRAM size to 512MB.
Enable debug.sf.disable_backpressure.
A few more updates to the kernel from Linux v4.4 and android-3.18.
Port over/import zsmalloc, zram, zswap, zbud and zpool from Linux v4.4.
Fix the issues with hanging/freezing that were present in the previous release.
Release for 20200703:
Latest updates from LineageOS.
Enable support for using USB for MIDI.
Fix/workaround issues with USB tethering.
Remove sswap and use ZRAM.
Latest update from @Valera1978 - "update audio_policy_configuration.xml from SM-A600FN q stock"
Many more updates to the kernel from v4.4, android-3.18 and a few from v3.16.
Disable the Exynos hotplug governor again. (in the kernel)
Release for 20200608:
Latest updates from LineageOS including the 20200605 Android security updates.
Use userspace lmkd.
Enable Always On Display. (Thanks to @followmsi)
Address a few more SELinux denials.
power_profile: change names as per pie naming changes.
Switch to [email protected]g. (Thanks to @followmsi)
Fix freeform window moving/resizing doesn't work (In my new fork of LineageOS' android_frameworks_base repository).
Add back support for Miracast using the changes from https://review.lineageos.org/q/topic:%22ten-aosp-wfd%22 (In my new fork of LineageOS' android_frameworks_av repository).
More updates to the kernel, including many updates from Linux v4.4 and v3.16 and general updates. There are also improvements to downstream drivers.
Release for 20200512:
Latest updates from LineageOS including the 20200505 Android security updates.
Address more SELinux denials.
Remove the ro.enable_boot_charger_mode property and revert "gtaxl: workaround for offline charging".
Remove some useless services for non-existent binaries in init files.
Hide sRGB toggle in developer options.
More updates to the kernel, including many updates from Linux 4.4 and to the kernel-based wireguard implementation.
Release for 20200411:
Latest updates from LineageOS including the 20200405 Android security updates.
Update the cpu.speeds array in the power profile for 1.69GHz, 449MHz and 343MHz frequencies.
Make the power profile aware of the big.LITTLE cluster.
Address more SELinux denials and remove duplicate rules.
Use an up-to-date Samsung hardware repository based on LineageOS' repository, and make changes to the device tree for it. ((Thanks to @followmsi for changing the sepolicy to accommodate for modem/macloader having been moved to /vendor and mentioning that the Exynos hidl power HAL has to be used after the old power HAL was removed)
Enable secure ADB and set persist.sys.usb.config to none.
Use pool.ntp.org for the NTP servers.
ramdisk: cleanup the init files and fstab for readability.
ramdisk: init.samsungexynos7870.rc: only start gpsd after booting - fixes GPS when encrypted.
More updates to the kernel, including many updates from Linux 4.4, general updates (such as updates to the wireguard kernel module) and fixes.
Use sdfat for exFAT support.
Add toggle for disabling newly added USB devices.
Release for 20200309:
Latest updates including 20200305 security patches
Upgrade android.hardware.keymaster to 4.0.
lineage-gtaxlwifi_defconfig: disable CRYPTO_FIPS to get encryption partially working.
sdfat: update to version 2.3.0.
Update the BFQ IO scheduler to v8r12 using a port.
Release for 20200303:
wireless: add back Samsung's 'temporary' workaround due to qcacld-2.0 page allocation errors. Looks like this is actually necessary. Works around issues with WiFi not being possible to be enabled after some time again due to page allocation failures that still exist.
Revert duplicate "signal/ptrace: Don't leak unitialized kernel memory with PTRACE_PEEK_SIGINFO". We already had this commit as in Linux v3.18, the content of this reverted commit are useless.
Release for 20200301:
Fix a few SELinux denials. (including app_zygote denials, sepolicy in post 5 no longer needed for this build at all and also shouldn't be used anymore as more denials beyond just the app_zygote denials have been fixed)
Release for 20200229:
Initial release.
Known issues and workarounds (if any):
Issue 1: adoptable storage is reported to not work correctly.
Somewhat of a workaround to issue 1: format and use your micro SD card with the exFAT filesystem.
Issue 2: Camera previews for images to be taken at resolutions with aspect ratios other than 16:9 using the rear camera are squashed from 16:9 (while final saved images at any resolution are unaffected by any squashing), and videos taken at some resolutions are affected by similar issues with squashing in previews, and, in a smaller set of resolutions, also in final saved video files. (Note that these issues don't affect the front-facing camera)
Somewhat of a workaround to issue 2: Use resolutions at which there are no issues with squashing from 16:9.
Issue 3: the on-screen navigation bar feature that can be enabled with the option at Settings -> System -> Buttons -> "Enable on-screen nav bar" doesn't work properly.
To report issues, get a log from logcat and dmesg. If you are unsure of how to get both, there is good documentation out there for how to do so.
Sources:
A manifest containing all of the necessary repositories to make a build is in this repository on branch lineage-17.1: https://github.com/TALUAtGitHub/gtaxlwifi-manifests
Thanks to:
@Valera1978 - for all of the previous work for these devices, and for providing his old BSP sources without which the previously used open BSP sources wouldn't have been possible.
@followmsi - for fixes to various issues and other improvements, for useful information, and for working with me on much of this stuff.
LineageOS - for the Android distribution itself.
...and everyone else who's worked on anything that is in use.
No build for sm-t585?
Echo_2000 said:
No build for sm-t585?
Click to expand...
Click to collapse
Unfortunately not, as I mentioned in the original post.
Sorry.
Edit on 2020/12/22: for anyone who is reading this post and has missed my new note in the original post, installation is now allowed on the LTE variant in my latest build, so you can try my build on it.
TALUAtXDA said:
Unfortunately not. As I mentioned in the original post:
Sorry.
Click to expand...
Click to collapse
Too bad, bad no problem.
I installed this, mostly seemed to work OK, but although I could install Chrome from Play Store it would simply disappear (no error) every time I opened it. Tried Chrome Beta instead and same issue.
I don't know if Gapps related. I used Bit gapps for what it's worth.
Gone back to old build.
Thanks anyway.
Glenn2 said:
I installed this, mostly seemed to work OK, but although I could install Chrome from Play Store it would simply disappear (no error) every time I opened it. Tried Chrome Beta instead and same issue.
I don't know if Gapps related. I used Bit gapps for what it's worth.
Gone back to old build.
Thanks anyway.
Click to expand...
Click to collapse
Hi,
The issue was caused by SELinux denials. I've fixed these denials in this commit: https://github.com/TALUAtGitHub/and...mmit/0ec43a448795230a3d2d8576cd93c5b156468e21
I was able to get the SELinux denials you were experiencing as you told me how you encountered them. Attached is a zip archive named 'sepolicy_and_precompiled_sepolicy.zip' containing 2 files: 'sepolicy' and 'precompiled_sepolicy'. This is a new sepolicy containing the rules to fix the denials. If you decide to use my builds again, extract the zip archive and copy the 'sepolicy' file to /system/ and 'precompiled_sepolicy' file to /system/system/vendor/etc/selinux/ in TWRP with system mounted. You may want to run SELinux as permissive for now, though keep in mind that this will ignore denials. To set SELinux to permissive, run:
Code:
setenforce 0
I never caught these denials as I don't use Chrome, and use Bromite web browser which doesn't seem to trigger these denials. I'll probably upload a new build tomorrow containing a sepolicy with the new rules. Also, I've put this in the original post for reporting SELinux denials:
TALUAtXDA said:
There maybe more issues due to SELinux denials. If something doesn't work, test it with SELinux set to permissive:
Code:
setenforce 0
If the issue is no longer reproducible, it's due to SELinux denials. Get logs by running:
Code:
dmesg | grep "avc: denied" > dmesg_selinux_denials
logcat | grep "avc: denied" > logcat_selinux_denials
while SELinux is permissive after doing whatever triggered the denials in a shell and upload the files 'dmesg_selinux_denials' and 'logcat_selinux_denials'. It would also be preferable to report what triggered the denials. In some rare cases, SELinux has to be set to enforcing to get certain denials, which would unfortunately mean that every denied action isn't logged and it takes multiple tries to get every denied action causing issues. Don't report any random denials that don't cause any issues. I won't fix some denials (such as proc_version denials, which should be denied and it causes no real issues) and I'll only fix denials that cause unintended issues.
Click to expand...
Click to collapse
Thanks I will try it again soon.
Did as suggested, seems ok now! Thanks.
Good evening,
God bless you and thank you very much for fixing this beautiful rom.
I have a request and a question.
Request: I am using sm-t580. When I was using stock rom, I was able to cast my screen to my Samsung TV. I am aware that LOS and Pixel have removed this ability. Would you consider please to re-enable "smart cast". I would love to enjoy your ROM on my sm-t580 and be able to cast to Samsung TV.
Question: I am unable to edit build.prop or other system files. I tried to re-mount root but probably doing something wrong. Not very good with this. Could you walk me through how to remount and what do I need to use (what terminal inside your rom). I have root access with Magisk and in twrp used shell terminal with your command "mount -o rw,remount /" without success. Then I downloaded some some terminal app and tried. No use... I get "/dev/block/platform/13540000.dmmmc0/by-name/system" not user moutable in fstab. Thank you.
Thanks for building a rom with selinux enforced. I used encryption on 14.1 but it doesn't seem to work here. Some more denials to add, or maybe I need a newer recovery to format data with first?
Jet T said:
Good evening,
God bless you and thank you very much for fixing this beautiful rom.
I have a request and a question.
Request: I am using sm-t580. When I was using stock rom, I was able to cast my screen to my Samsung TV. I am aware that LOS and Pixel have removed this ability. Would you consider please to re-enable "smart cast". I would love to enjoy your ROM on my sm-t580 and be able to cast to Samsung TV.
Question: I am unable to edit build.prop or other system files. I tried to re-mount root but probably doing something wrong. Not very good with this. Could you walk me through how to remount and what do I need to use (what terminal inside your rom). I have root access with Magisk and in twrp used shell terminal with your command "mount -o rw,remount /" without success. Then I downloaded some some terminal app and tried. No use... I get "/dev/block/platform/13540000.dmmmc0/by-name/system" not user moutable in fstab. Thank you.
Click to expand...
Click to collapse
Hi,
You're welcome, though kudos to followmsi of course.
Smart cast seems to be a Samsung specific, proprietary feature. But we do have the generic casting feature available in Settings -> Connected devices -> Connection preferences -> Cast. Casting to wireless displays can be enabled through the 3 dot menu and then the "Enable wireless display" option and your TV should be detected. However, this doesn't work. A TV either doesn't connect or there's a soft reboot. I also have a Samsung smart TV with which I could test it with. The TV gets detected as "[TV] Samsung", and selecting it makes it say that it's connecting but it either stops trying to connect or it soft reboots and the TV displays an "loading" message that's infinite.
I found this while searching for "MediaPlayerService: listenForRemoteDisplay is no longer supported!" (this seems to be the main error): https://pastebin.com/s4utSi6c It seems like this issue has been reported before and existed at least a few months (though most certainly more) before my builds. I'll try finding a way to fix this, but my knowledge is unfortunately quite limited at this moment.
To do a mount command like that, you need to be root. To get a root shell, run "su", grant your terminal app root access and then run any commands needed to be run as root in that shell, such as that mount command.
EDIT: found this: https://forum.xda-developers.com/galaxy-tab-a/development/rom-t4006261/post81782081#post81782081 The replies say that you need to go back to Android 8 to use Miracast. I'm not sure if that's true but that's apparently how it is. There's probably nothing that can be done. Since smart cast is proprietary and Samsung specific, you'd only find it in Samsung ROMs. Also found this: https://forum.xda-developers.com/showpost.php?p=81369313&postcount=143 saying that support for Miracast is no longer available in Android 9 and 10.
I had another device where encryption didn't work. Turned out to be twrp writing incorrect (encryption?) footer when formatting data partition. But here encryption on 14.1 worked. Maybe encryption changed 14.1 to 17.1 with different footer, or maybe encryption on the los 17.1 base is broken on all devices. Difficult.
TALUAtXDA said:
Hi,
You're welcome, though kudos to followmsi of course.
Smart cast seems to be a Samsung specific, proprietary feature. But we do have the generic casting feature available in Settings -> Connected devices -> Connection preferences -> Cast. Casting to wireless displays can be enabled through the 3 dot menu and then the "Enable wireless display" option and your TV should be detected. However, this doesn't work. A TV either doesn't connect or there's a soft reboot. I also have a Samsung smart TV with which I could test it with. The TV gets detected as "[TV] Samsung", and selecting it makes it say that it's connecting but it either stops trying to connect or it soft reboots and the TV displays an "loading" message that's infinite. I captured a logcat at a time when it soft rebooted:
I found this while searching for "MediaPlayerService: listenForRemoteDisplay is no longer supported!" (this seems to be the main error): https://pastebin.com/s4utSi6c It seems like this issue has been reported before and existed at least a few months (though most certainly more) before my builds. I'll try finding a way to fix this, but my knowledge is unfortunately quite limited at this moment.
To do a mount command like that, you need to be root. To get a root shell, run "su", grant your terminal app root access and then run any commands needed to be run as root in that shell, such as that mount command.
EDIT: found this: https://forum.xda-developers.com/galaxy-tab-a/development/rom-t4006261/post81782081#post81782081 The replies say that you need to go back to Android 8 to use Miracast. I'm not sure if that's true but that's apparently how it is. There's probably nothing that can be done. Since smart cast is proprietary and Samsung specific, you'd only find it in Samsung ROMs. Also found this: https://forum.xda-developers.com/showpost.php?p=81369313&postcount=143 saying that support for Miracast is no longer available in Android 9 and 10.
Click to expand...
Click to collapse
I appreciate your answer!
I have now installed EX Kernel Manager as I had previously purchased it anyway when I (briefly) used the ElementalX kernel on my Pixel 3a.
I can see that we lose half the CPU permanently after the device goes to sleep, as you described, by looking at the dashboard.
Under Tools/User Settings I added a setting for /sys/devices/system/cpu/cpuhotplug/enable with a value of 0 as you suggested (to apply on boot) and this has cured the issue. It explains why I sometimes had smooth and sometimes not so smooth performance on the old rom! Now it's just always smooth.
Interestingly, I could not write to this value once the problem had occurred and the CPU was half disabled. The '0' value would not save, it stayed at '1'. It was not writable - is that a clue to the cause? I had to reboot and put the setting in EXKM before the device had been to sleep. Now it is fine even after reboot.
Thanks.
Thanks for your work and contributions to this device.
Many thanks for your work. Your ROM is working perfectly. No screen freeze.
Thank you for the rom!
I flashed it because it should have signature spoofing, but actually microG self-check doesn't tick signature spoofing permission and correct signature for play services and play store. Can anyone help me?
Jamess27 said:
Thank you for the rom!
I flashed it because it should have signature spoofing, but actually microG self-check doesn't tick signature spoofing permission and correct signature for play services and play store. Can anyone help me?
Click to expand...
Click to collapse
Hi,
It should be possible to select the "System grants signature spoofing permission" option in the MicroG self-check menu to get a dialog asking if you'd like to allow signature spoofing. Otherwise, you can grant the signature spoofing permission using a root shell or ADB with these pm commands:
Code:
pm grant com.google.android.gms android.permission.FAKE_PACKAGE_SIGNATURE
pm grant com.android.vending android.permission.FAKE_PACKAGE_SIGNATURE
TALUAtXDA said:
Hi,
It should be possible to select the "System grants signature spoofing permission" option in the MicroG self-check menu to get a dialog asking if you'd like to allow signature spoofing. Otherwise, you can grant the signature spoofing permission using a root shell or ADB with these pm commands:
Code:
pm grant com.google.android.gms android.permission.FAKE_PACKAGE_SIGNATURE
pm grant com.android.vending android.permission.FAKE_PACKAGE_SIGNATURE
Click to expand...
Click to collapse
Thanks for the fast response! I got the permission with the dialog in MicroG, but apps still don't find google play services
Jamess27 said:
Thanks for the fast response! I got the permission with the dialog in MicroG, but apps still don't find google play services
Click to expand...
Click to collapse
You're welcome. Now, the signature spoofing permission is granted to microG, but from what you describe, it's likely that play store (or fake store) doesn't have the signature spoofing permission. You can check if this is the case by opening the MicroG self-check menu and checking if the "Play Store (Phonesky) has correct signature" item is checked. If play store doesn't have the signature spoofing permission granted, you need to run this one pm command in a root shell or using ADB:
Code:
pm grant com.android.vending android.permission.FAKE_PACKAGE_SIGNATURE

Development [Kernel][01.06.2023][Android 13] Kirisakura 2.0.24_T for Asus Zenfone 9 aka "DaVinci"

Kirisakura-Kernel for the Asus Zenfone 9
Hello everyone,
To keep it short: Here is Kirisakura - Kernel for the Asus Zenfone 9 aka DaVinci. The Zenfone line-up internal codenames were traditionally derived from alcoholic drinks. Two years ago the Zenfone 6 bore the title "Kirin". The Zenfone 7 was codenamed "Tequila", while the Zenfone 8 bore the title "Sake".
This year seems to make a change however. The Zenfone 9´s internal codename is "DaVinci".
I would appreciate if everybody that flashes the kernel, reads at least once through this opening post and the following ones.
As far as we, @tbalden and me, are aware and as far as we know this project, alongside CleanSlate kernel for the Zenfone 9, marks the first release of a source compiled custom QGKI 2.0 kernel as a standalone flashable zip and project here on XDA.
The introduction of GKI and QCOMs adaptation QGKI means unfortunately that building a monolithic kernel becomes harder and harder. This results in the "kernel" itself no longer just sitting in one partition or the zImage, but it´s spread across different partitions (no longer being monolithic) now. Since there´s no requirment to keep monolithic builds working as in the past, it´s no longer possible to compile the source as is (without applying major rewrites, tricks or hacks) in the monolithic fashion on 5.10 kernels. The same was true for the Pixel 6/Pro.
That means the "kernel" project you´re seeing here needs to be compiled in a build environment to achieve the GKI/QGKI way. Since only Google releases the full build environment alongside the kernel sources itself in a proper fashion with git history, it became very complicated and seemingly impossible to do this on the Zenfone 9 at first glance. A big thanks at this place to Asus. From all the sources of SD8 Gen 1 QGKI devices published, the Asus Source is the most complete. A big thanks to Asus for publishing the sources on time and complete! Also for listening to us if the source is not complete and something is missing.
With excellent teamwork and a lot of hardwork, @tbalden and me managed to compile the Zenfone 9 kernel in QGKI 2.0 fashion after a lot of failed attempts and misery. It´s been a pleasure to work with him over the years here on XDA.
Kirisakura - Kernel is designed to bring a handful of beneficial features to the device, while ensuring excellent performance and smoothness to get you safely through the day!
If you expect a custom kernel to magically improve your devices battery life manifold and this is your only priority then this might not be the right place for you.
However the kernel is built to keep battery life close to the same as you would experience the on stock kernel while being tuned to perform better in various UI related benchmarks. The same benches are used by google to verify and ensure UI smoothness on the Pixel devices. The scheduler is tuned to yield lower jitter and reduce jank frames.
If that got your curious, I welcome you to continue reading if you´re still interested!
This project aims to keep most of the subsystems updated, way ahead of the stock kernel, thereby improving security and performance, while keeping stability as the foucs during testing! This includes Linux-Stable, CAF-Upstream and kernel/common.
A very positive development. Google pushed for CFI and SCS to be enabled by default in the android-common kernel. Starting with 5.4 kernel ( SD 888 ) CFI and SCS were enabled by default. It was a lot of work to get these features working nicely on the kernel I did the years back. So it´s nice to see this is now there by default in everybody can profit from it.
I put the explanations and links in hide tags here.
Spoiler: Documentation Control-Flow-Integrity (CFI) / Shadow Call Stacj (SCS)
Kernel Control Flow Integrity (Kernel-CFI), which is achieved by linking the kernel with LLD and Link Time Optimization (LTO), more precisely ThinLTO, are quite unique security features.
The recently released Kirisakura-Kernel for the OnePlus 8 Pro was featured on the XDA-Portal due to the inclusion of CFI. The featured article explains CFI in great details, is easy to understand and definitely worth to read.
If possible the latest Kirisakura-Kernel releases for various devices aim to include CFI in enforcing mode so users can benefit from this security features.
Another security feature is Shadow Call Stack (SCS).
SCS is another security patchset that is aimed at preventing attacks via return oriented programming (ROP).
ROP is a technique where the attacker gains control of the kernel stack to overwrite function return addresses and redirect execution to carefully selected parts of existing kernel code.
If you´re interested here are a few good links:
Google Security Blog explaining SCS.
LLVM doc about SCS
Android DOCs documenting SCS
If reading about upstream in the paragraph above got you curious, have a read about Linux-Stable and why it is important here. The stable-process is not the same for every subsystem, but the general idea, rule of thumb and benefits are applicable for other subsystems as well.
Read more about the Release-Model following this link.
This conversation on the LKML mailing list also shows the power of Linux-Stable and why it´s very beneficial to not just say it´s not worth and a potentiol source for bugs:
Starting with the Initial Message , the following reply and a good summarizing statement.
Quick explanation of QCOM-Upstream. CLO-git is the place where development from Qualcomm for their SoCs happens. This includes the Snapdragon 8+ Gen1 that´s built into the different SKUs of the Zenfone 9.
The kernel-bases available on QCOMs git, are basically the foundations OEMs use, to build their own kernel additions on top for devices featuring Qualcomm SoCs.
The Qualcomm developers push regular updates to the bases of the different SoCs, a bit similar to how Linux-Upstream works. OEMs usually stop updating the initial base after the phone is released.
This kernel focuses amongst the other features to provide the latest CAF-Updates merged in a regular manner, to provide updates, improvements and enhancements for SoC specific drivers and subsystems! This might take a while, because a lot of device specific testing is done on my end to ensure stability.
The kernel includes a lot of improvements and contributions from other developers as well. Without this kernel would not exist.
A big part of improvements originate from @arter97´s, @kdrag0n´s and @Sultanxda´s work. Many others contributed in some way or another to this kernel.
A big thanks to all of them at this place!
Now lets continue with a list of features in the next paragraph!
Main Features:
- Based on latest kernel sources from Asus for Android 13 and intended to be used on the latest Asus Stock-Firmware
- compiled with Clang 16.0.2 and built with -O3 speed optimizations
- Linux-Stable-Upstream included to 5.10.181
- upstreamed QCOM base for the Snapdragon SD8+ Gen1 (qcoms internal codename "cape")
- Lazy RCU which should result in power-savings while the device is lightly-loaded or idling, more information here
- include important fixes/improvements from kernel/common
- SSG IO scheduler for reduced overhead and less CPU cycles (more lightweight and android optimized)
- implement ramoops for easier logs in case of kernel panics
- implement LRNG (see arter kernel OP for more info )
- Flashing the kernel will keep root!
- Flashable via EXKM, FKM or Kernel Flasher (free open source solution, get it here)
- Anykernel zip is based on the Anykernel3 release from @osm0sis
EAS related features:
- Implement dynamic WALT-Window size depending on current FPS, collecting information about CPU-Load to provide more precise information for the scheduler
- EAS implementation patched up to latest CAF state
- updates from kernel/common
CPU related features:
- Power saving workingqueues enabled by default
- Change various drivers (WLAN, MM, audio, charger, power, thermal, glink etc) to use power efficient workingqueues. This compliments EAS in general
- vdso32 patches as found on Google Pixel devices (brief documentation here) (CAF 5.10 default, keep for documentation)
- improve suspend/resume from audio driver (caf-upstream for audio-kernel)
- enable suspend_skip_sync to save power during suspend/resume
- speed up face unlock
- reduce camera launch time
GPU related features:
- GPU driver updated to latest CAF-State
File System related features:
- f2fs improvements
UI/UX/Usability related features from CleanSlate:
- CleanSlate features made by @tbalden
- Disclaimer: All CleanSlate features can be controlled via the free companion and config app found on CleanSlate thread here on the Zenfone 9 Forums on XDA. Please consider buying the premium versions if you enjoy using the CleanSlate features, to give a little something back to @tbalden.
- add option to force 240hz touch sample rate
Network related features:
- Wireguard Support (Details)
- advanced TCP algorithms enabled
- use bbr as default TCP congestion algorithm (fasted algo according to this excellent research from @kdrag0n found here )
- includes new bbr
- Enable support for TTL spoofing
Memory related features:
- Speculative Page Faults left enabled (1. 2) (CAF 5.4 default, keep for documentation)
Security related features:
- Control-Flow-Integration (CFI) and Link-Time-Optimization (LTO) (CAF 5.4 default, keep for documentation)
- Use ThinLTO which was first used in the Pixel 4 XL Android R-Kernel instead of full LTO (CAF 5.4 default, keep for documentation)
- Shadow Call Stack (SCS) Security-Feature ( 5.4 default, keep for documentation)
- enable init_on_alloc for even more security, more information can be found in the commit message (CAF 5.4 default, keep for documentation)
Other features:
- clean up asus drivers and fix a few warnings in kernel log
- enlarge dmesg size to ease debugging
Flashing Guide, Download and Changelog
Requirements:
- unlocked Bootloader (this will void warranty and kill future OTA updates on all asus phones at the moment)
- USB-Debugging in developer options enabled
- latest adb and fastboot binaries
- working adb and fastboot environment
- magisk root
- a backup of stock boot.img, vendor_boot.img, vendor_dlkm.img and dtbo.img so you can go back to stock conditions (simplest way is TWRP or to extract from stock firmware via payload extractor)
How to flash the Kernel:
1. Download the latest kernel.zip and make sure you have properly updated to the latest matching Asus Stock-Firmware. When the Zenfone 9 receives an OTA update it takes Asus a while to release the source code for the new OS and me a while to build a new kernel. If you don´t want to face any issues, wait until I either release an updated kernel or give green light because there were no kernel changes.
Always make sure to run the firmware the kernel is built for!
If you feel adventurous and try in advance, make sure you have a backup ready!
2. Flash the kernel.zip in your favorite kernel app (I personally use Kernel Flasher by @capntrips as it´s free OSS) or TWRP once available.
3. Reboot and profit.
DOWNLOAD:
Download is located always in this folder:
AFH is currently down. Please check release posts for attached files.
https://www.androidfilehost.com/?w=files&flid=335947
Important: Read after Download
Please take a look at the second post after flashing the kernel!
Changelog:
Android 12
1.0.0 Initial Release
1.1.0 https://forum.xda-developers.com/t/...s-zenfone-9-aka-davinci.4489055/post-87544785
1.1.0 https://forum.xda-developers.com/t/...s-zenfone-9-aka-davinci.4489055/post-87641829
1.1.3 https://forum.xda-developers.com/t/...s-zenfone-9-aka-davinci.4489055/post-87761015
Android 13
2.0.0
[Kernel][09.12.2022][Android 13] Kirisakura 2.0.0_T for Asus Zenfone 9 aka "DaVinci"
Kirisakura-Kernel for the Asus Zenfone 9 Hello everyone, To keep it short: Here is Kirisakura - Kernel for the Asus Zenfone 9 aka DaVinci. The Zenfone line-up internal codenames were traditionally derived from alcoholic drinks. Two years ago...
forum.xda-developers.com
2.0.6 https://forum.xda-developers.com/t/...s-zenfone-9-aka-davinci.4489055/post-87945357
2.0.12 https://forum.xda-developers.com/t/...s-zenfone-9-aka-davinci.4489055/post-88194923
2.0.18 https://forum.xda-developers.com/t/...s-zenfone-9-aka-davinci.4489055/post-88332217
2.0.19 https://forum.xda-developers.com/t/...s-zenfone-9-aka-davinci.4489055/post-88360955
2.0.21 https://forum.xda-developers.com/t/...s-zenfone-9-aka-davinci.4489055/post-88384057
2.0.24 https://forum.xda-developers.com/t/...s-zenfone-9-aka-davinci.4489055/post-88600875
Donations:
Donations are not mandatory but very welcome if you want to support development or just buy me a coffee/tea
If you like my work: http://paypal.me/freak07
Credits:
Asus for the development device, giving me the opportunity to create this project! This device is absolutely stunning!
@osm0sis for all his work, including the ak3 installer!
@capntrips for his relentless work on several projects, including kernel flasher!
@tbalden for being the best HTC, Pixel, OnePlus and now Asus wingman!
@LeeDroid and @mwilky for their awesome roms and work I used on multiple devices!
@Captain_Throwback for all the mentoring and guidance!
@Eliminater74 for bringing me into the game and the Inspiration
@nathanchance for his upstream guidance and assistance
@RenderBroken for helping me out
@flar2 for all his work
@joshuous for all the help he provided to me in the past!
@arter97 for giving me advice
@kdrag0n for his help and advices!
@topjohnwu for magisk!
Source Code: https://github.com/freak07/Kirisakura_DaVinci_AI2202/
For necessary changes to other repos, besides the main kernel tree please check tbaldens github, we did the bringup together:
tbalden - Repositories
engineer. Started github with kernel for HTCDoubleshot, migrating version in 2011. kernel follows kernel, patching intuitive new features into CleanSlate line. - tbalden
github.com
F.A.Q:
Question: How do I return back to stock?
Answer: Extract boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img from the matching factory image provided on googles download page.
If you want to stay rooted make sure to flash a boot.img that has been patched with magisk.
Flash those images via fastboot/fastbootd and you will be back on stock kernel.
boot.img, dtbo.img and vendor_boot.img are to be flashed in regular fastboot.
vendor_dlkm.img is to be flashed in fastbootd (you can get to this with "fastboot reboot fastboot" when you´re in regular fastboot)
Question: How to report bugs properly?
Answer: Have a look at post #3 in the linked thread. The linked guide is a pretty good starting point.
Before reporting any bug make sure you´re running on a stock configuration. That´s means you´re not using any mods, tweaks in kernel managers or other root tweaks , magisk modules, scripts or other modifications that alter various functions like sound mods, data traffic, sleeping behaviour, scheduler, magical battery tweaks etc.
Try to describe the issue as detailed as possible! Give your exact setup, like rom, magisk version, kernel version.
Is the issue reproducible? Does it happen frequently?
Please make sure to meet the points described above, provide logs as detailed in the link above, otherwise debugging is a lot more time consuming and harder. If these requirements aren´t met and I don´t find time to either reproduce the issue myself or I´m not able to reproduce the issue myself reports might just be ignored. If you can already reproduce the issue and provide logs it greatly limits the amount of time I have to spent until I figure out how to reproduce it.
Question: What about unlocking, rooting, passing safetynet, apps detecting root/modifications and other topics that are vaguely related, but not really subject of this thread?
Answer: If you want to modify your phone via root/magisk in any way you need to unlock the bootloader. Unlocking will result in safetynet not passing. This has nothing to do with the kernel. At the moment of writing this, safetynet not passing can be worked around with a magisk module called "Universal SafetyNet Fix".
Not passing safetynet is unrelated to the kernel since hardware attestation is enforced on nearly all newly released devices now.
If you´re not passing safetynet banking apps might for example be detecting root. There are various tricks to hide root/modifications to the phone from banking apps or others but that´s not really subject of this thread.
taken from pixel 6 soon to be adjusted
AOSP Build Environment and Standalone Kernel builds (monolithic builds)
I´m sure some of you followed the movement towards the Generic Kernel Image (GKI) and Qcoms adaption to it called QGKI.
You can find more information about GKI following this link.
What does that mean for custom kernels and this custom kernel?
The last few years the kernel on android devices was more or less compiled as a monolith. That means the kernel is in the zImage with all (most) drivers compiled inline.
However with GKI this changed. There´s the base kernel image while vendor/device specific drivers are compiled as dynamically loadable kernel modules.
On last years devices like the Pixel 5 (using a 4.19 kernel) and this years devices with SD888 on a 5.4 kernel base, there was the possibility to change the QGKI kernel back into a monolithic kernel image. (building the drivers that are on stock kernel external modules back into the zImage to end with a monolithic kernel)
On the Pixel 6 I wasn´t able to achieve this yet. But during my tries I also wondered if maybe finally the time has come to follow suit, instead of trying to enforce old ways, when there´s a new way going forward.
What does that mean. This means that at this point the kernel is shipped as images that are to be flashed via fastboot. At a later stage I´m sure we can modify anykernel3 to allow flashing zips again, but at this early stage fastboot flashable images will be provided.
Those images can be flashed the same way the device is rooted, therefore I think everybody should be able to flash it easily since the device can´t be rooted any other way.
The kernel was compiled using the aosp kernel build environment. Information about it can be found on the documentation page from google.
this one too
and this one as well
Woohoo! Rock'n'roll! ^__^
Update to 1.1.0
Hey guys and girls,
Here´s the next update. It includes quite a few changes.
It also includes the few kernel changes from the latest firmware 32.2040.2040.23.
The link to the latest firmware can be found following this link.
More changes in the changelog below:
Changelog:
- Linux-Stable upstream bumped to 5.10.146
- merge latest CAF-Upstream
- bump clang to prebuilt 14.0.7 from google
- fixed clang warnings in the process
- other improvements and tweaks please check github
Download:
AFH is currently not working properly. Please check this post for the download. Kernel.zip is attached.
https://www.androidfilehost.com/?w=files&flid=335947
Instructions can be found in the OP!
But look at this post too
Have fun, enjoy the kernel and your phone.
Donations are not mandatory but very welcome.
If you like my work and want to buy me a coffee/green tea to keep development going: http://paypal.me/freak07
Freak07 said:
Update to 1.1.0
Hey guys and girls,
Here´s the next update. It includes quite a few changes.
It also includes the few kernel changes from the latest firmware 32.2040.2040.23.
The link to the latest firmware can be found following this link.
More changes in the changelog below:
Changelog:
- Linux-Stable upstream bumped to 5.10.146
- merge latest CAF-Upstream
- bump clang to prebuilt 14.0.7 from google
- fixed clang warnings in the process
- other improvements and tweaks please check github
Download:
AFH is currently not working properly. Please check this post for the download. Kernel.zip is attached.
https://www.androidfilehost.com/?w=files&flid=335947
Instructions can be found in the OP!
But look at this post too
Have fun, enjoy the kernel and your phone.
Donations are not mandatory but very welcome.
If you like my work and want to buy me a coffee/green tea to keep development going: http://paypal.me/freak07
Click to expand...
Click to collapse
Hello sir,
How do you compile the original Kernel? Is any of vendor_boot or vendor_dlkm images the same as original stock or both are different? What about DTBO? I'm trying to build kernel for ROG Phone 6 but I thought kernal was still a monolithic file, so I flashed one only and failed to boot. ROG Phone 6 includes a script that apparently compiles everything but I don't which one is DTBO, vendor boot and vendor dlkm. Where and how you compile this kernel and where does the output go? For example I see kernel-platform/msm-kernel as the one you modified? That one is the vendor_boot?
Thank you for your help
And by the way, any plan for Kirisakura for ROG Phone 6?
Update to 1.1.1
Hey guys and girls,
Here´s the next update. It includes quite a few changes.
It also includes the few kernel changes from the latest firmware 32.2050.2050.29.
The link to the latest firmware can be found following this link.
More changes in the changelog below:
Changelog:
- included few changes from firmware 32.2050.2050.29
- other improvements and tweaks please check github
Download:
https://www.androidfilehost.com/?w=files&flid=335947
Instructions can be found in the OP!
But look at this post too
Have fun, enjoy the kernel and your phone.
Donations are not mandatory but very welcome.
If you like my work and want to buy me a coffee/green tea to keep development going: http://paypal.me/freak07
Lossani said:
Hello sir,
How do you compile the original Kernel? Is any of vendor_boot or vendor_dlkm images the same as original stock or both are different? What about DTBO? I'm trying to build kernel for ROG Phone 6 but I thought kernal was still a monolithic file, so I flashed one only and failed to boot. ROG Phone 6 includes a script that apparently compiles everything but I don't which one is DTBO, vendor boot and vendor dlkm. Where and how you compile this kernel and where does the output go? For example I see kernel-platform/msm-kernel as the one you modified? That one is the vendor_boot?
Thank you for your help
And by the way, any plan for Kirisakura for ROG Phone 6?
Click to expand...
Click to collapse
boot.img contains the zImage, vendor_boot contains first stage kernel modules, vendor_dlkm contains second stage kernel modules.
Kernel is no longer monolithic by default. I´m using the build environment to get the relevant images for GKI.
Freak07 said:
boot.img contains the zImage, vendor_boot contains first stage kernel modules, vendor_dlkm contains second stage kernel modules.
Kernel is no longer monolithic by default. I´m using the build environment to get the relevant images for GKI.
Click to expand...
Click to collapse
Do you have any kind of tutorial to follow to pack the kernel like you do in AnyKernel zip?
Thank you
Lossani said:
Do you have any kind of tutorial to follow to pack the kernel like you do in AnyKernel zip?
Thank you
Click to expand...
Click to collapse
I´m sorry but a step by step tutorial I don´t have the time to type that all down.
Please check tbaldens github for ZF9. We did the "bringup" of the ZF9 GKI environment together.
That here contains the scripts/methods we basically use both.
GitHub - tbalden/android_kernel_asus_zf9_build_env
Contribute to tbalden/android_kernel_asus_zf9_build_env development by creating an account on GitHub.
github.com
Check all the other zf9 repos as well.
We took basically the asus build script inside the ROG 6 source, readjusted it for the ZF9 source, as the build environment for the ROG 6 was more complete than ZF9.
You either need to remove avb from fstab (that lands in vendor_boot) or disable vbmeta flags for verity/verfication before you can flash any modified vendor_dlkm.
Be aware, disabling the flags triggers an inevitable wipe.
Otherwise check the scripts and work yourself through all the repos.
Unfortunately with GKI kernels you need to adjust the ABI. Now it gets complicated. The gki kernel, the zImage is usually compiled, from the common repo, while the qcom specific drivers are built in the msm repo. Since I don´t care about preserving googles abi for the GKI kernel, I compile the zImage from the updated msm repo, as well as the qcom modules.
That means in my build environment common repo is a symlink of msm repo, while I compile with the same script found in ROG 6 source. I think once you start working through the build environment you´ll understand. Tbalden doesn´t need to do that, as his kernel is close to stock with only a few mild changes, so easier to keep abi in check.
Unfortunately at the moment there´s no easy way to compile it.
Freak07 said:
I´m sorry but a step by step tutorial I don´t have the time to type that all down.
Please check tbaldens github for ZF9. We did the "bringup" of the ZF9 GKI environment together.
That here contains the scripts we basically use both.
GitHub - tbalden/android_kernel_asus_zf9_build_env
Contribute to tbalden/android_kernel_asus_zf9_build_env development by creating an account on GitHub.
github.com
Check all the other zf9 repos as well.
We took basically the asus build script inside the ROG 6 source, readjusted it for the ZF9 source, as the build environment for the ROG 6 was more complete than ZF9.
You either need to remove avb from fstab (that lands in vendor_boot) or disable vbmeta flags for verity/verfication before you can modify vendor_dlkm.
Otherwise check the scripts and work yourself through all the repos.
Unfortunately with GKI kernels you need to adjust the ABI. Now it gets complicated. The gki kernel, the zImage is usually compiled, from the common repo, while the qcom specific drivers are built in the msm repo. Since I don´t care about preserving googles abi for the GKI kernel, I compile the zImage from the updated msm repo, as well as the qcom modules.
That means in my build environment common repo is a symlink of msm repo, while I compile with the same script found in ROG 6 source. I think once you start working through the build environment you´ll understand. Tbalden doesn´t need to do that, as his kernel is close to stock with only a few mild changes, so easier to keep abi in check.
Unfortunately at the moment there´s no easy way to compile it.
Click to expand...
Click to collapse
Thank you for your reply. I succeded to compile using ROG 6 script but I end up with a vendor_dlkm.img in out/target/platform/taro and in gki folder "dist" outputs Image, vendor_boot.img and another vendor_dlkm.img + dtbo.img but doesn't seem to be the correct size, I guess there's another step missing to compile or I don't know which one of the dlkm is the correct one or if I need another step to make the Image file and vendor_boot.img.
Thank you anyways
Lossani said:
Thank you for your reply. I succeded to compile using ROG 6 script but I end up with a vendor_dlkm.img in out/target/platform/taro and in gki folder "dist" outputs Image, vendor_boot.img and another vendor_dlkm.img + dtbo.img but doesn't seem to be the correct size, I guess there's another step missing to compile or I don't know which one of the dlkm is the correct one or if I need another step to make the Image file and vendor_boot.img.
Thank you anyways
Click to expand...
Click to collapse
check the scripts I just sent you. the vendor_dlkm and vendor_boot from the environment don´t work on the device.
The thing is, asus just uses the kernel environment to precompile zImage,all the modules, dtb and dtbo, then transfer those to their complete build environment and those get includes into the images that end up in the firmware. The zImage they´re using on the device is actually not the one compiled in the build environment, but the GKI kernel uploaded by google. That´s why abi is so important. You´re not supposed to flash the ones produced by the build environment.
Check the scripts how repacking both of those works. If everything is right, that will get you to boot.
the zImage you can get from ASUS_AI2202-32.2030.2030.26-kernel-src/kernel_platform/out/msm-waipio-waipio-gki/dist
Update to 1.1.3
Hey guys and girls,
Here´s the next update. Linux-Stable up to 5.10.149, which also fixed the CVEs discussed here and here.
The link to the latest firmware can be found following this link.
More changes in the changelog below:
Changelog:
- included few changes from firmware 32.2050.2050.34
- merge latest kernel/common
- linux-stable to 5.10.149
- includes a few fixed CVEs
- other improvements and tweaks please check github
Download:
Attached to release post, AFH is currently broken
https://www.androidfilehost.com/?w=files&flid=335947
Instructions can be found in the OP!
But look at this post too
Have fun, enjoy the kernel and your phone.
Donations are not mandatory but very welcome.
If you like my work and want to buy me a coffee/green tea to keep development going: http://paypal.me/freak07
Update to 2.0.0
Hey guys and girls,
Here´s the next update with source for A13 stable merged. (not much changes, hence the fast release)
Update to A13 stable before flashing this.
The link to the latest firmware can be found following this link.
More changes in the changelog below:
Changelog:
- included few changes from firmware 33.0804.2060.65
- merge latest kernel/common
- linux-stable to 5.10.157
- other improvements and tweaks please check github
Download:
Attached to release post, AFH is currently broken
https://www.androidfilehost.com/?w=files&flid=335947
Instructions can be found in the OP!
But look at this post too
Have fun, enjoy the kernel and your phone.
Donations are not mandatory but very welcome.
If you like my work and want to buy me a coffee/green tea to keep development going: http://paypal.me/freak07
Update to 2.0.6
Hey guys and girls,
Here´s the next update. That´s a bigger one. I´ll explain a few things below in more detail.
The link to the latest firmware can be found following this link.
Monolithic kernel build
Thanks to @arter97 it´s now possible to build the 5.10 qcom kernel now as a monolithic kernel, not needing to build as a GKI style kernel.
To explain it simple: The problem is QCOM/Google are no longer required to test if drivers are loading in the correct order and or test compilation of a monolithic kernel at all.
The gki style kernel has 100s of drivers build as external kernel modules, instead of directly into the zImage.
Having a monolithic build eases development a bit, but won´t directly make an impact to the user.
If you´re interested check my github, it contains the commits. and be sure to drop @arter97 a few thanks somewhere!
Introduction of Lazy RCU
Usually I´m not stating remarks about a change improving battery life notably. But this is one of the few kernel changes that really does make a noticeable difference.
This kernel has the entire(!) RCU subsystem updated to latest linux 6.0 kernel state. This also allowed for Lazy RCU to be merged into the kernel, which should result in power-savings while the device is lightly-loaded or idling (which is basically the case all the time a smartphone isn´t being interacted with (nothing touching the screen and no other workload such as video editing is done).
If you´re interested in details check the slides, which are also linked in the article mentioned/linked above.
A very simplified explanation: RCU functionality can be called 1000s of times a second, batching RCU calls can save power by not calling as often.
Please keep in mind, those are kernel changes and battery life will not be improved magically by huge amounts, but there´s definitely an improvments.
Sony Scheduler Improvements
Import some scheduler changes around Walt from Sony Xperia 1 IV. This improves jitter by a significant amount.
More changes in the changelog below:
Changelog:
- merge latest kernel/common lts branch
- linux-stable to 5.10.160
- merge latest qcom upstream to main branch
- bump clang to latest prebuilt from google 16.0.2
- lazy rcu backported
- scheduler improvements from Sony Xperia 1 IV
- remove wlan rx wakelock as it´s unnecssary
- other improvements and tweaks please check github
Download:
Attached to release post, AFH is currently broken
https://www.androidfilehost.com/?w=files&flid=335947
Instructions can be found in the OP!
But look at this post too
Have fun, enjoy the kernel and your phone.
Donations are not mandatory but very welcome.
If you like my work and want to buy me a coffee/green tea to keep development going: http://paypal.me/freak07
is there any possibility you could try to make such a kernel for rog 6 ? if you had a tester
luki2411 said:
is there any possibility you could try to make such a kernel for rog 6 ? if you had a tester
Click to expand...
Click to collapse
hi everybody. this is a very voluminous work, but still, if you decide, I am ready to take an active part in testing.
Hi Freak Will you port this kernel to ROG Phone 6 ?

Categories

Resources