STRIX Kernel Revived 20241202

"When the FS is SUS!"

Changelog:
(from 20241125-STAGING) [MIUI] Fix display glitch issue that occurs randomly or when switching refresh rates
Fixed soft bootloops when charging
Fixed disconnect and reconnect while charging issue
Added BORE Scheduler 5.1.0
Picked fixes and changes from unmoved's STRIX-inline fork
—————————————————————
rsuntk's KSU fork 12002 (required manager apk!) + SUSFS 1.5.2 (module)

The difference between [KSU] and [KSU-NEXT] is that the NEXT build has lineage map hiding which should help hide custom ROM detections if using the recommended linked susfs module, however, not all ROMs like it and can cause bootloops on those ROMs, in that case, please switch to the [KSU] build
[KSU-NEXT] build supports OSS only!! DO NOT INSTALL ON MIUI!!! Use [KSU] build if MIUI instead

Kernel Source (a15-ksu branch for ksu changes, a15-ksu-next for ksu-next changes)
🤓 diffs since last release
⚠️ Disclaimer
Credits:

@itsshashanksp for the eBPF A15 commits
@aryannn999 for scripts and fixes from vantom that are very useful
@unmoved21 for fixes and changes from own STRIX-inline fork
@xfirstnamelastname and @sidex15 for BORE Scheduler
@RooGhz720 for the 90Hz refresh rate
@fiqri_ardyansyah for the kernel everyone loves ❤️

@RissuDesu for their KSU fork
@changhuapeng for the SUSFS 1.5.2 commits
@xfirstnamelastname for the lineage maphide and ksu commits
@simonpunk for SUSFS

vbantom Kernel 20241202

"When the FS is SUS!"

Changelog:
None, same as 20241129. Thus, NO-SU build has been skipped (it has only been 3 days dawg 😭)
———————————————————————
rsuntk's KSU fork 12002 (required manager apk!) + SUSFS 1.5.2 (module)

The difference between [KSU] and [KSU-NEXT] is that the NEXT build has lineage map hiding which should help hide custom ROM detections if using the recommended linked susfs module, however, not all ROMs like it and can cause bootloops on those ROMs, in that case, please switch to the [KSU] build

Kernel Source (and rebased-15-ksu for KSU changes, 15-ksu-susfs-next for KSU-NEXT changes)
⚠️ Disclaimer
Credits:

@itsshashanksp, @RooGhz720, @fiqri_ardyansyah and @xfirstnamelastname for tweaks and features from sleepy, aghisna, strix and westcoast respectively
@aryannn999 and @Vantom for bes kernel

@RissuDesu for their KSU fork
@changhuapeng for the SUSFS 1.5.2 commits
@xfirstnamelastname for the lineage maphide and ksu commits
@simonpunk for SUSFS

Before anyone asks, no, the known issues are still NOT fixed

Google has announced that it's hardening Play Integrity API verdicts so they're less spoofable but also faster and more privacy-friendly.

- Improved device integrity verdicts on Android 13+ will require the use of hardware-backed security signals using Android Platform Key Attestation, making them much harder to bypass. Google will adjust verdicts when it detects "security threats across Android SDK versions, such as when there is evidence of excessive activity or key compromise."

- The Play Integrity API will now have the "same level of reliability and support across all Android form factors."

- Because these new verdicts reduce the number of device signals that need to be collected and evaluated, Google says verdict latency can improve by up to 80%.

Developers can opt in to use these new verdicts today or wait until May 2025 which is when all API integrations will automatically transition.

In addition:

- The "meets-strong-integrity" response is being updated to require a security patch level within the last year on devices running Android 13+.

- A new device attributes field lets apps adjust their behavior based on the user's Android SDK version.

- All optional verdict signals are being standardized across apps, games, SDKs, and more.

For in the case of sweet, this may mean that it won't pass strong integrity even if TEE is not dead+Stock ROM+Locked BL, only device
Because
Current strong verdict will become the new device verdict (I.e you'll need a unrevoked keybox to pass device, not strong soon)
New strong verdict will depend on RKP, a hardware backed functionality that is only available in devices released with A13 or later (fucking planned obsolescence 😔)

If that turned out to be true when it happens (May 2025), I might just go ahead and install PostMarketOS on me sweet and have a secondary phone (Android or iPhone 🤔)

A lot of people didn't realise how nice Google was to us with free device integrity through beta fingerprints.

A15 DerpFest booted lessgooo
Installed via fastbootd (use lineage recovery)
Used TRM's Hyper NEXT as vendor base + me vbantom kernel to boot

Bugs:
Vibration is dead
Wired and BT headphones is dead
Refresh Rate is locked on 60hz (regardless of what you switch it to, maybe switchable via cli) + backlight control dead so weird colors+very bright (workaround: Livedisplay works, so set colors from there but lower them to below 50)

Btw it is very bland, no derp custiomizer tab and all tweaks are everywhere else

But ME Moto dolby atmos! I likey

Anyhow, for those who are here from vbaloboto days, you can see how happy I am that I finally booted a GSI 😁
Main takeaways that I've learned
1. OSS vendor won't boot anything BUT the AOSP ROM it compiled with, so use MIUI vendor to boot GSIs (preferred from MIUI/HyperOS ports)
2. Do not try too gorey GSIs that obviously wont boot like Pixel OEM, NothingOS, etc.. (HyperOS 2.0 however is an exception)