Fix partial incompatibility with LineageOS

[Anderhar]

Please check before submitting an issue

• I have searched the issues and haven't found anything relevant
• I will upload bugreport file in KernelSU Manager - Settings - Report log
• I know how to reproduce the issue which may not be specific to my device

Describe the bug

Currently, in certain scenarios, KernelSU relies on automatic detection of the KMI version. But LineageOS developers follow an atypical kernel naming scheme that doesn't include AndroidRelease and KmiGeneration parts.
Here's an example:
Compatible: 5.15.176-android13-8-g878bb89d69a4
LineageOS: 5.15.176-g878bb89d69a4

This leads to partial incompatibility of KernelSU with LineageOS and its derivatives (/e/OS, iodéOS, etc) and has some unwanted effects.
One of the most annoying and a bit dangerous among these effects is the need to manually select KMI on each OTA in LKM mode, which is not only inconvenient, but also involves the possibility of bootloop in case of an accidental wrong selection.

There's already at least one issue here caused by this exactly aspect of LineageOS. Unfortunately, its developers stay away from anything related to root and they are unlikely to help with this.

So here are two suggested solutions:
A. Look for another way to get the missing data for automatic KMI detection.
B. Add a persistent KMI selector to the KernelSU manager's settings to allow the user to manually set KMI once for all cases.

To Reproduce

No response

Expected behavior

No response

Screenshots

Logs

07-17 01:13:00.823 2292 3733 D CoreBackPreview: Window{5172cdb u0 com.rifsxd.ksunext/com.rifsxd.ksunext.ui.MainActivity}: Setting back callback OnBackInvokedCallbackInfo{mCallback=android.window.IOnBackInvokedCallback$Stub$Proxy@31c2a8d, mPriority=-1, mIsAnimationCallback=false, mOverrideBehavior=0}
07-17 01:13:00.823 2292 3733 D CoreBackPreview: Window{5172cdb u0 com.rifsxd.ksunext/com.rifsxd.ksunext.ui.MainActivity}: Setting back callback OnBackInvokedCallbackInfo{mCallback=android.window.IOnBackInvokedCallback$Stub$Proxy@e034442, mPriority=0, mIsAnimationCallback=true, mOverrideBehavior=0}
07-17 01:13:00.866 6727 6727 I KernelSU Next: ksud::cli: command: BootInfo { command: SupportedKmi }
07-17 01:13:00.880 2292 2863 I ImeTracker: com.rifsxd.ksunext:e8571d96: onRequestHide at ORIGIN_SERVER reason HIDE_UNSPECIFIED_WINDOW fromUser false
07-17 01:13:00.881 6490 6490 D InsetsController: hide(ime(), fromIme=false)
07-17 01:13:00.881 6490 6490 I ImeTracker: com.rifsxd.ksunext:e8571d96: onCancelled at PHASE_CLIENT_ALREADY_HIDDEN
07-17 01:13:01.665 2292 2838 D ActivityManager: freezing 3626 com.android.permissioncontroller
07-17 01:13:01.673 2292 2904 D InetDiagMessage: Destroyed 0 sockets, proto=IPPROTO_TCP, family=AF_INET, states=14
07-17 01:13:01.675 2292 2904 D InetDiagMessage: Destroyed 0 sockets, proto=IPPROTO_TCP, family=AF_INET6, states=14
07-17 01:13:01.675 2292 2904 D InetDiagMessage: Destroyed live tcp sockets for uids={10192} in 5ms

Device info

• Device: Motorola X40 (rtwo)
• OS Version: LineageOS 21/22 (official)
• KernelSU Version: 1.0.5
• Kernel Version: 5.15.176-g878bb89d69a4

Additional context

No response

[rifsxd]

I've already said what's the problem they don't follow standards of GKI kernel building it's more of a lineage issue KernelSU-Next/KernelSU-Next#671 (comment)

[Anderhar]

I've already said what's the problem they don't follow standards of GKI kernel building it's more of a lineage issue

So what? Does this mean that the problem should not be responded and should stay forever, bothering more and more new users? Or maybe you know a way to get LineageOS devs to abandon their biases against the root solutions supporting?

And by the way, you didn't say that. You only said that my kernel by LineageOS doesn't have necessary parts to detect them, but nothing more.
I am very grateful to you for your help in finding the cause of this long-standing problem, really. But I find your position counterproductive. Please, let's not expand our previous dispute to this place too.

[rifsxd]

I've already said what's the problem they don't follow standards of GKI kernel building it's more of a lineage issue

So what? Does this mean that the problem should not be responded and should stay forever, bothering more and more new users? Or maybe you know a way to get LineageOS devs to abandon their biases against the root solutions supporting?

And by the way, you didn't say that. You only said that my kernel by LineageOS doesn't have necessary parts to detect them, but nothing more. I am very grateful to you for your help in finding the cause of this long-standing problem, really. But I find your position counterproductive. Please, let's not expand our previous dispute to this place too.

There is absolutely no other way to detect what kernel it is without the correct uname, you have to choose manually.

I don't understand why this is even an issue

[rifsxd]

I've already said what's the problem they don't follow standards of GKI kernel building it's more of a lineage issue

So what? Does this mean that the problem should not be responded and should stay forever, bothering more and more new users? Or maybe you know a way to get LineageOS devs to abandon their biases against the root solutions supporting?
And by the way, you didn't say that. You only said that my kernel by LineageOS doesn't have necessary parts to detect them, but nothing more. I am very grateful to you for your help in finding the cause of this long-standing problem, really. But I find your position counterproductive. Please, let's not expand our previous dispute to this place too.

There is absolutely no other way to detect what kernel it is without the correct uname, you have to choose manually.

I don't understand why this is even an issue

I've already said what's the problem they don't follow standards of GKI kernel building it's more of a lineage issue

So what? Does this mean that the problem should not be responded and should stay forever, bothering more and more new users? Or maybe you know a way to get LineageOS devs to abandon their biases against the root solutions supporting?

And by the way, you didn't say that. You only said that my kernel by LineageOS doesn't have necessary parts to detect them, but nothing more. I am very grateful to you for your help in finding the cause of this long-standing problem, really. But I find your position counterproductive. Please, let's not expand our previous dispute to this place too.

It's not even a problem, it's falling back to manual selection if the uname doesn't have the uname requirements

[Anderhar]

It's not even a problem, it's falling back to manual selection if the uname doesn't have the uname requirements

I don't understand why this is even an issue

Then you have a good enough memory and sufficiently accurate motor skills to remember your device's KMI for sure and not miss it once in years of monthly OTAs.
Or you don't have multiple different devices with KernelSU installed so that you never confuse their KMIs with each other accidentally.
Or you don't have less tech-savvy relatives or friends who have asked you to root their phone for some purpose and now you have to explain to them how to maintain it.
Looks like you're a happy person!

But please, let's just stop this flaming.

[rifsxd]

It's not even a problem, it's falling back to manual selection if the uname doesn't have the uname requirements

I don't understand why this is even an issue

Then you have a good enough memory and sufficiently accurate motor skills to remember your device's KMI for sure and not miss it once in years of monthly OTAs. Or you don't have multiple different devices with KernelSU installed so that you never confuse their KMIs with each other accidentally. Or you don't have less tech-savvy relatives or friends who have asked you to root their phone for some purpose and now you have to explain to them how to maintain it. Looks like you're a happy person!

But please, let's just stop this flaming.

It's not even a problem, it's falling back to manual selection if the uname doesn't have the uname requirements

I don't understand why this is even an issue

Then you have a good enough memory and sufficiently accurate motor skills to remember your device's KMI for sure and not miss it once in years of monthly OTAs. Or you don't have multiple different devices with KernelSU installed so that you never confuse their KMIs with each other accidentally. Or you don't have less tech-savvy relatives or friends who have asked you to root their phone for some purpose and now you have to explain to them how to maintain it. Looks like you're a happy person!

But please, let's just stop this flaming.

I have 4 test devices with each different variations, it's seems a skill issue, do tell how are we supposed to know what kernel variant is the kernel in question other than uname cuz me and others don't have a clue, if this is such a huge issue then I would suggest sticking to APatch or Magisk to be honest

[tiann]

Please send the bugreport and let me know your actual KMI; I need to check something.

[Anderhar]

Please send the bugreport and let me know your actual KMI; I need to check something.

Thanks for your kind attention!
The actual KMI of my device is android13-5.15
KernelSU's bugreport archive looks a bit comprehensive to share publicly, so I'll send a link to twsxtd#gmail.com.
Hope it's okay.

[tiann]

For the vast majority of Android devices (except for Pixel), the AndroidVersion in KMI is equivalent to the Android system version that was launched; therefore, the value of ro.product.first_api_level can be displayed in the KMI selection interface to assist users in making a judgment.

[Anderhar]

For the vast majority of Android devices (except for Pixel), the AndroidVersion in KMI is equivalent to the Android system version that was launched; therefore, the value of ro.product.first_api_level can be displayed in the KMI selection interface to assist users in making a judgment.

By using getprop ro.product.first_api_level, I checked this statement on five different LineageOS devices from various years starting from 2015`— it's very true! The only possible exception might be Banana Pi M5 single-board computer, because I just don't know where the developers got the base kernel from. But that's even more unusual beast than Pixels that doesn't support KernelSU anyway.

Thus, if the KMI selection screen is preceded by a question like "Did your device originally shipped with Android 13? (Yes/No)", then in case of a positive answer, the manual selector can be completely skipped! This would make things much easier and safer in most cases, while still leaving an option for Pixel owners.

Feasible?

Update: Alternatively, if ro.product.first_api_level on Pixels remains constant and only the actual KMI changes (just don't have any Pixel to answer myself), then perhaps the KMI selector screen could be left as is, but the expected option made already checked so the user of non-Pixel device only needs to tap "OK" without changing this pre-defined choice.

[tiann]

I prefer to only present information rather than make choices for the user—once the phone is unlocked, you are its owner, and you need to take responsibility for all choices.

[Anderhar]

I prefer to only present information rather than make choices for the user—once the phone is unlocked, you are its owner, and you need to take responsibility for all choices.

Your creation – your rules! But at least, please make the hint visually clear to minimize the risk of misclick during quick interaction (relying on graphics instead of pure text is always preferable in such situations).
In any case, I am glad that my concerns have finally reached the right person. Thanks!