"And also, please check your stock boot.img's format, you should use the right format, such as lz4、gz."

How do I find out my boot.img format? I have a "Google Pixel 6a"

pixel is lz4_legacy

how did you arrive at this conclusion, so future readers can find the format of their own boot images?

Why, just use lineageOS.

Sorry I didn't see this reply... I'm on 18.1 at the moment, but I'm pretty sure I had su installed at one point.

I reflashed my phone a few months ago because my nand/SD are starting to go... Time to ditch the S5 and buy a S23 :)

This has nothing to do with LineageOS.

You're right, it doesn't. But why go through the hassle of hacking the kernel when you can replace the whole OS with something better?

Because, last I checked, LineageOS doesn't expose root privileges to the user.

The install goes something like this...

- install new recovery and reboot

- install new OS image

- install google apps

- install su package

- reboot and wait half an hour because androids first boot always takes forever :)

Installing su is often skipped because its not recommended.

The latest officially avaiable su package is for 16.0. My phone's on 18.1 and the latest version is 20. If you want SU on a supported LineageOS, you have to use Magisk or potentially this project.

KernelSU is pretty interesting in certain circumstances compared to say, Magisk, which is a systemless root. KernelSU cannot be prevented by SELinux—the kernel can even disable SELinux if it wants to.

It's quite useful for gaining root on "weird" and or/old android devices such as lesser-known smartwatches, often that have no support for Magisk at all.

In terms of bypassing SafetyNet, both KernelSU and Magisk have their own strengths and limitations. For those utilizing an Android smartphone in a conventional manner, Magisk may be the preferred choice due to its extensive module support and strong community support.

KernelSU need to be integrated to kernel source and compile kernel, for "wired" and/or old android devices, maybe it is difficult to do that.

Nice, but using root generally is very insecure. The whole concept of superuser is broken and bad. Such privileges shouldn't be given to any user.

Bypassing "security" when you as the owner of the device want to is the whole point of root.

This project allows root by default, like it's part of the user experience, which is bad for security.

It does not grant root by default, quote: "Whitelist access control Only App that is granted root permission can access `su`, other apps cannot perceive su."

In this context I meant that it allows root where Android never allows.

But that's the whole point? That you can user your own device as a general-purpose computing device, not only as a media-consumption device limited by arbitrary restrictions the vendor of the device can pose on you?

This kernel is for day to day use. Using insecure features such as root, can potentially cause harm. Do whatever you want, just pointed a fact.

What attack do you see this allowing that wouldn't work without it? Considering that the user has to intentionally add it, and the user has to explicitly give apps root access, the only problem I can see is if a user gives root to an untrustworthy app, but that seems like a good trade.

Incidentally, do you also think that users shouldn't have admin power on, say, laptops, or are phones special?

Those are apps that are granted root can be exploited by other apps.

And yes also on other devices (depends which one, such laptops).

GPLv3 licensed, despite almost certainly being a derivative work of Linux, which is GPLv2 licensed (with no "or later" provision).

Now, I ain't no lawyer or nothin', but I reckon that's a legal paddlin'.

> Kernel devs are tame even with closed-source device and software vendors pirating the Linux kernel.

It's more complicated than that: https://lwn.net/Articles/698452/

> I doubt any kernel copyright holder will bat an eye over GPLv3 vs. GPLv2.

Probably not, but why risk it? The only meaningful difference between the two is the anti-TiVoization clause, and considering how thoroughly Android is already TiVoized, that seems pretty pointless anyway.

> Not to mention the very relevant question of "is it really a derivative work?", which very much depends on the depth and complexity of integration, provided interfaces, GPLONLY symbols and other minutiae.

It's a kernel module, the build process for which entailing pulling the KernelSU code into a cloned Linux repo. It's pretty unambiguously a derivative work.