lets talk about the phasing out of haluim
-
basically as the title suggest i think it would be a ton of work ....but i for one am sick of needing to "downgrade" android versions on install ....maybe its just because of my device ...but either way my brain will brain
-
@developerbayman That's already possible on mainline devices but it's not trivial on devices without mainline which is most of the devices. And even if they do, many things don't work.
Not sure what your realistic expectation on this
-
@kugiigi well if its already being addressed ....but no i was inspired by the mesa project and was thinking why not a four year plan like wise? ....the information surrounding this whole project is quite vast and very hard to keep up with lol
-
but the expectation is to totally eliminate halium for all future devices ...but yeah just random inspiration
-
@developerbayman You can check the postmarketOS project to see how realistic it would be for UT to ditch halium.
-
@developerbayman You may be interested in my recent post on the matter. Tldr there are projects who already ditched hallium years ago, basically ALL other mobile linux projects. For ubtouch flavored mobile distro, you may be more interested in lomiry on debian.
-
@grenudi originally i was mobian for example ....but it was in the same state as UT in lots of ways also many projects dont support my device ...also i see ubuntu touch as a garden ....its just needs watering ...and actually i find clickable development daunting ....but regardless something about "here" rubs me right ubuntu touch can be very great with l;ots of care and love ..and some convention tweaks ...also in some ways UT is more mature than some of those other projects IMO ...little things
-
@developerbayman I hear you
-
@developerbayman I'm not that competent to estimate for sure if your plan is actually possible. but still, it seems very promising, if I understood it correctly - a sequential stripping off of HALium layers and replacing them with direct kernel elements, than shifting to mainline kernel when no HALium layers have left. And more over, if it works, it should work vise-versa, giving a temporary foot hold for all those postmarketos devices that already run mainline kernel but lack camera, gps, etc, bringing those players back to HALium contribution. You basically proposed a solution to a situation that ubtouch ended up in, that I've described in my report. Needless to say that I like it, and admire your dedication
-
@grenudi thanks man! ...and cool yeah i was sitting there and im like ? i wonder?? ...so cool i dont mind being late to the party lol
-
grenudi said:
And more over, if it works, it should work vise-versa, giving a temporary foot hold for all those postmarketos devices that already run mainline kernel but lack camera, gps, etc, bringing those players back to HALium contribution
joining back with upstream communities on this would be amazing
but again, all pure speculation on my part, though very worth investigating further, in my opinion. -
grenudi said:
joining back with upstream communities on this would be amazing
but again, all pure speculation on my part, though very worth investigating further, in my opinion.A bucket of cold water from AI
:Is the "Sequential Stripping" or "Reverse Hybrid" Possible?
In a word: No. The transition between Halium and Mainline Linux is not a gentle slope; it is a steep cliff.
Here is the technical reasoning why you cannot easily mix the two:
The Kernel Version Mismatch: Halium relies on a tool called libhybris. This tool allows a standard Linux operating system to talk to the phone's proprietary Android hardware drivers (known as "blobs"). The fatal flaw is that these closed-source blobs were compiled by the manufacturer for a very specific, older Android kernel (e.g., Linux 3.18 or 4.14). Mainline Linux projects (like postmarketOS) use modern kernels (e.g., Linux 6.x).
API/ABI Breakage: If you try the "reverse" approach—putting Halium on a mainline kernel just to make the camera work—the proprietary camera blob will crash. It expects to talk to old Android-specific kernel interfaces (like ashmem or older versions of the Binder IPC) that either do not exist or have been drastically changed in the mainline Linux kernel. Because the blob is closed-source, you cannot recompile it to understand the new kernel.
It's All or Nothing: You cannot "sequentially strip" Halium while running the old Android kernel, because the end goal is to replace the kernel itself. As soon as you swap the old Android kernel for a mainline kernel, every single proprietary Halium driver breaks simultaneously.
To get off Halium, developers must painstakingly reverse-engineer the hardware and write brand new, open-source drivers directly into the mainline kernel. There is no shortcut.
-
@grenudi totally what im proposing total rewrite from the ground up ....ill need to hit the books
-
@developerbayman I got spoiled with those AI's
Yes, hitting those books would be much more productive than me consulting LLMS over shoulder
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login