Develop Bugs

android on samsung s5600 preston?

i'm new into this, so i was wondering if anyone knows if there is any way i can port android on a samsung preston. it's native ui is awful and there's little to no customization.

if no-one is planning on doing an android port for this phone, can anyone point me in the direction of a good guide to doing it myself?
My daughter has this phone it it could really do with a decent OS

Yeah...I would really like to have android on my samsung GT-S5600...I HATE the samsung OS...I like the phone's design,but I'm thinking of buying a new one,just because of the crappy OS...If someone could make android for it,I would be grateful...

dexter9374 said:
Yeah...I would really like to have android on my samsung GT-S5600...I HATE the samsung OS...I like the phone's design,but I'm thinking of buying a new one,just because of the crappy OS...If someone could make android for it,I would be grateful...
Click to expand...
Click to collapse
I have the same "problem" if anyone find the solution will be very apriciated.
Thanks
Bissius

Well, I think our only way out would be getting a dev interested... Or we could always buy another phone

I don't see this as being very likely. There are a number of problems that will need to be overcome. First and foremost is the processor type. We have no idea what the speed is. Let alone the architecture. Android requires an ARM based architecture to run with a minimum of 200MHz or so which pretty much guarantees global system lag. You'll probably have smoother performance on the proprietary OS. Not that I've used the device or anything but that's what would be expected. After all, the prop. OS's have been slimmed down to the extent that only the incorporated functions run and nothing else. Next is ram. We again are told nothing on how much memory this thing has. Barebones 'droid requires 128mb minimum to run. Storage… Here's a list of 'droid's requirements.
http://www.netmite.com/android/mydroid/development/pdk/docs/system_requirements.html
Recommended is 256MB of minimum internal storage. It says it will run on less but its not recommended. Let's push the boundaries a little. Lets say that the preston has 96mb of internal memory, which realistically should be about right. Maybe 128mb TOPS. Thats 37.5-50% of the original requirement. Even if you did get it running, where are your personal files going to be stored if you can't get the sd card slot working? In addition to that, more lag will be faced as it is a proven fact that all machines slow down if more than half the internal storage has been used.
Assuming that we got passed all of this (it'll be a miracle if we did), there are other matters that are sure to lay down a roadblock. First of all, drivers. The internal hardware of the device will need drivers written for it. That means everything like radio, bluetooth, camera, keypad, touchscreen, audio, display etc. etc. All current devices that run Android can run it because the hardware in the device already exists in an equivalent Android device. If none of the hardware in the 5600 exists in any other droid phone, drivers will need to be reverse engineered. The kernel is essential for the system to boot. It is the underlying structure on which the OS is built. If the CPU in the device is not ARM based, there is a fat chance that a working kernel will ever be built for it. And the final and probably most important reason why this will probably never work is the boot loader. Even Windows Mobile devices which currently run Android won't work without a third party loader. Hence the reason it must boot into WinMo first to load droid. The reason being is that all phone manufacturers lock the phone's boot loader to prevent it from running anything but the shipped OS. Lets say we got past this by creating a loader similar to haret that ran inside the prop. OS. You would be able to TECHNICALLY bypass the problems we would have with the stock boot loader and internal storage (that is, considering that we have established a way to enter the linux kernel). But you would still be faced with CPU compatibility issues, driver support and sufficient ram to barely run an OS as packed as Android. I will gladly give a medal and bow down to the gentleman/woman who manages the task but as I previously said, it does not seem possible.

ayilm1 said:
I don't see this as being very likely. There are a number of problems that will need to be overcome. First and foremost is the processor type. We have no idea what the speed is. Let alone the architecture. Android requires an ARM based architecture to run with a minimum of 200MHz or so which pretty much guarantees global system lag. You'll probably have smoother performance on the proprietary OS. Not that I've used the device or anything but that's what would be expected. After all, the prop. OS's have been slimmed down to the extent that only the incorporated functions run and nothing else. Next is ram. We again are told nothing on how much memory this thing has. Barebones 'droid requires 128mb minimum to run. Storage… Here's a list of 'droid's requirements.
http://www.netmite.com/android/mydroid/development/pdk/docs/system_requirements.html
Recommended is 256MB of minimum internal storage. It says it will run on less but its not recommended. Let's push the boundaries a little. Lets say that the preston has 96mb of internal memory, which realistically should be about right. Maybe 128mb TOPS. Thats 37.5-50% of the original requirement. Even if you did get it running, where are your personal files going to be stored if you can't get the sd card slot working? In addition to that, more lag will be faced as it is a proven fact that all machines slow down if more than half the internal storage has been used.
Assuming that we got passed all of this (it'll be a miracle if we did), there are other matters that are sure to lay down a roadblock. First of all, drivers. The internal hardware of the device will need drivers written for it. That means everything like radio, bluetooth, camera, keypad, touchscreen, audio, display etc. etc. All current devices that run Android can run it because the hardware in the device already exists in an equivalent Android device. If none of the hardware in the 5600 exists in any other droid phone, drivers will need to be reverse engineered. The kernel is essential for the system to boot. It is the underlying structure on which the OS is built. If the CPU in the device is not ARM based, there is a fat chance that a working kernel will ever be built for it. And the final and probably most important reason why this will probably never work is the boot loader. Even Windows Mobile devices which currently run Android won't work without a third party loader. Hence the reason it must boot into WinMo first to load droid. The reason being is that all phone manufacturers lock the phone's boot loader to prevent it from running anything but the shipped OS. Lets say we got past this by creating a loader similar to haret that ran inside the prop. OS. You would be able to TECHNICALLY bypass the problems we would have with the stock boot loader and internal storage (that is, considering that we have established a way to enter the linux kernel). But you would still be faced with CPU compatibility issues, driver support and sufficient ram to barely run an OS as packed as Android. I will gladly give a medal and bow down to the gentleman/woman who manages the task but as I previously said, it does not seem possible.
Click to expand...
Click to collapse
thanks for the info, looks quite feasible what you're telling; it makes me a little sad though

[Q] How Does the Android OS Work?

Disclaimer: I am only a flasher. I do, however, contribute to the forums, donate to devs and also use the paid version of good apps.
My question is: How does Android work on our phones?
You have hardware (HTC Incredible); you have a carrier (Verizon, in my case); you have an OS (Android, obviously); you have a radio; you have a ROM; you have a kernel; you have themes, you have skins and you have apps. How do all these pieces interact? Just curious.

This is a really good question that should be answered in laymen's terms. I'm surprised it hasn't been answered yet.

I also thought it would have been answered by now. However, I think the developers (who would be the best folks to answer this question) are busy working with the Gingerbread source code to build new ROMs for us.
This is what I have figured out so far but I'm not sure if my analysis is correct:
After selecting your hardware and carrier, the OS is the most important element. Most of us are currently on Froyo (2.2). I have seen some screen shots showing the OS version to be "2.2.1" but I am not sure why. Google (I think) has released the source code for Gingerbread (2.3) and the developers ("devs") are hard at work producing new ROMs as I post this.
I gather that it is best to stay away from trying out different radios ("basebands"). Most of us are using 2.15.00.07.28.
I think the ROM takes the OS and re-works the user interface by adding, removing and changing the various screens and "features" of the OS. For example: the ROM can be written to take out the stock music player and substitute a music player that the ROM developer prefers. I think this is called "baking in an app". I believe the ROM developer can also create an overall "look and feel" that can be quite different from the stock OS. For instance, the ROM can be "colored" in black and red (rather than the stock green) and the stock font can be changed to something the developer prefers. In other words, the ROM is what you see and use on a daily basis.
Now this is where things get a little fuzzy: the kernel. I think this is kind of a behind the scenes element that governs the performance of a ROM. It greatly affects things like battery life, time to charge the battery and the "speed" of the phone. The kernel is where the phone can be "over-clocked" and "under-volted" should you want to do those things. I gather that once you select a ROM, you can try different kernels without changing what the various screens look like on the phone. I believe this is the way most people do it (pick a ROM and try different kernels with it). I don't think the other way really works (pick a kernel and try different ROMs with the kernel).
Next comes themes and skins which really only affect what you see on the various screens without do anything about battery life or the speed of the phone. I haven't played with these much.
Finally, I forgot to put WALLPAPER on the list in the original post. I believe this only appears as a background image on the home screens.
If any reader sees errors in my layman's analysis, please, by all means jump in and correct me. Per my disclaimer in Post #1, I am just an ordinary user and this analysis could be flawed or incorrect in whole or in part.

Everytime I try to answer a question like this, I get too complex about it and leave more questions than answers. Then someone comes along and says "It's like Windows or Linux or MacOS on a PC", and that's that. Well they're right. Those OS's tell the PC's that they are PC's and essentially all OS's do the same things.
Here's my simplified new list:
1) Hardware on phone :: meaningless without OS
-- (android OS - or any other OS)
2) Linux kernel understands hardware like touchscreen, radios, I/O (drivers/modules). Of course it also understands how to schedule processes and all those "kernel tasks".
3) Libraries provide APIs (Application programming interface) to userspace code (like APPS).
4) Userspace (apps, scripts, libraries) provide user control over the phone.
--
Together they work in harmony (we hope) to make the phone realize it is a phone and allow us to use it as such. (well, a smartphone, so many things other than a phone).
Here's a simple example: You touch the phone icon which is in userspace, and it brings up the userspace phone app. As soon (or before) as you touch some buttons, dial a number, it is using the API to the driver in the kernel that actually understands the phone hardware/radio. Also userspace controls GUI which is also requiring API to some form of OPENGL API that is requiring device drivers that get the touchscreen/LCD display. and so on.
--- Hashi
PS: I realize there are a thousand things wrong with this representation, but hey, it's a start. Feel free to fix it up if you're inclined.

Project treble?

Is this project treble?

No

halleyrokz said:
Is this project treble?
Click to expand...
Click to collapse
That is the security patch level of android. You can get more info about project treble here.

For everyone getting excited over Treble should keep this in mind
"Project Treble doesn’t necessarily mean that all handsets will see updates instantaneously, as Google is not handling them directly. OEMs are still free to tweak and skin the OS, as well as embed their own software into the Android OS release. So there’s still going to be some time taken for OEMs to build and test their own particular take on Android."

zelendel said:
For everyone getting excited over Treble should keep this in mind
"Project Treble doesn’t necessarily mean that all handsets will see updates instantaneously, as Google is not handling them directly. OEMs are still free to tweak and skin the OS, as well as embed their own software into the Android OS release. So there’s still going to be some time taken for OEMs to build and test their own particular take on Android."
Click to expand...
Click to collapse
Spot on. Treble just eliminates the need for new drivers, so OEMs don't need to wait for part manufacturers (like Qualcomm). But OEMs (Samsung, LG,...) are still the main culprit when it comes to wait times or not getting updates at all.
If community can make a custom ROM for a 5+ year old device, so can an OEM. Drivers are obviously there, they're just not interested in updating anything for more than 2 years (even less in case of low and mid range devices). Treble can't change that.
The only real solution would be "one size fits all" system, that gets pushed directly by Google to ALL devices - like desktop systems. But that would probably be way to big for available storage on phones ...
Sent from my OnePlus 3 using Tapatalk

Explorer23 said:
The only real solution would be "one size fits all" system, that gets pushed directly by Google to ALL devices - like desktop systems. But that would probably be way to big for available storage on phones ...
Click to expand...
Click to collapse
We're going very offtopic here, but the topic interests me so, eh.
If we're talking about size here, we can follow a method that has been used in Linux live systems for a while now: a tarred (.tar) or squashed (squashfs) images. These provide a small yet ”fast enough” images that can be smaller than their uncompressed counterpart. Size is not of the constraint nowadays with these at developers disposal.
Alternatively, you can have a system that Treble tries to achieve: a base image (AOSP), OEM-specific changes and drivers, and abstraction for said drivers and changes. This system still relies on OEMs (and SoC manufacturers to an extent) to actively update their changes to the base system (and we know how lazy some OEMs can be with their updates).
But this is very offtopic, so let me offset the talk a little.
------------
To OP: No, that is not Treble. Treble isn't something you can quite see in user space (i.e Settings app). What you're pointing out is the security patch level, that is, how "updated" your current system are to the security patches Google are providing.
The level is laid out in date, so "November 1 2017" would be a fairly recent update. These patches get updated monthly, and seeing that you're using OxygenOS, means that you'll have to wait for OnePlus to push the security update after Google pushes them.

F4uzan said:
We're going very offtopic here, but the topic interests me so, eh.
If we're talking about size here, we can follow a method that has been used in Linux live systems for a while now: a tarred (.tar) or squashed (squashfs) images. These provide a small yet ”fast enough” images that can be smaller than their uncompressed counterpart. Size is not of the constraint nowadays with these at developers disposal.
Alternatively, you can have a system that Treble tries to achieve: a base image (AOSP), OEM-specific changes and drivers, and abstraction for said drivers and changes. This system still relies on OEMs (and SoC manufacturers to an extent) to actively update their changes to the base system (and we know how lazy some OEMs can be with their updates).
But this is very offtopic, so let me offset the talk a little.
------------
To OP: No, that is not Treble. Treble isn't something you can quite see in user space (i.e Settings app). What you're pointing out is the security patch level, that is, how "updated" your current system are to the security patches Google are providing.
The level is laid out in date, so "November 1 2017" would be a fairly recent update. These patches get updated monthly, and seeing that you're using OxygenOS, means that you'll have to wait for OnePlus to push the security update after Google pushes them.
Click to expand...
Click to collapse
There never can be a one size fits all OS. Even Linux can't really pull that off for every device.
See this is another thing that will never happen. Oems will never upload their code changes to aosp as Google intends. Most of the time due to the fact that they don't write the code for the different parts like BT, Wifi chips etc. This code comes others which is closed sourced and paid for.
Treble will most likely never become much. Already too many people misunderstand what it does. That i can't blame people for. Things like the xda portal that are giving out bad info is gonna cause a huge amount of drama over it.

[SCRIPT] Build LineageOS EASY

If you are interested in building LineageOS for Bonito or Sargo you can use my script on Github to compile for either device. The script I link in this post will build my daily driver ROM. To consider running this script you will need the following:
- A PC running Ubuntu 18.04 or a distro based off Ubuntu 18.04 (I use ZorinOS)
- This PC needs at least 8gb RAM, a quad core processor and 300GB of available space on a drive (preferably SSD)
- Patience
* These are the instructions for running the script:
Open a terminal and run the following commands
git clone https://github.com/stevn4127/scripts
(This clones my scripts to a directory called scripts)
cd scripts
(This navigates you to the scripts directory)
bash lineage.sh
(This runs the script)
You will need to enter your root password to update the OS and install build tools. You may also need to run the following command with your Github credentials following the text:
git config --global user.email
git config --global user.name
Here is a direct link to my scripts repository on Github:
https://github.com/stevn4127/scripts
Join my Telegram chat for help: NugTowers HQ
Test builds and a ton of OT. We are mainly Pixel/Pixel 3a users but everyone is welcome! Just don't be a POS Please... No nudity. DONT be a pervert. (Mod Edit: Certain descriptions removed)
https://t.me/nugtowers
Good Luck!

Since I cloned your scripts, I have added Lineage to my "skinny build box" project; primarily due to the VoLTE and VoWifi support it shares with Bliss 12.x. Yes; I know that T-Mobile is kicking phones that don't support VoLTE and VoWifi off their network; however, that won't apply to any phone that runs AOSP - as VoLTE is par for the course for any phone that runs a recent AOSP firmware (Pie or later in practically all cases; in the case of Lineage, as far back as Oreo). I changed tower providers because T-Mobile doesn't care what firmware you run on your phone. (Since then, it turns out that my infusion center (and my current cardiologist - which is in the same building) are in a hole in the UnCarrier's tower network - which makes hotspot support - and therefore VoLTE and VoWifi support - all the MORE critical.)

PGHammer said:
Since I cloned your scripts, I have added Lineage to my "skinny build box" project; primarily due to the VoLTE and VoWifi support it shares with Bliss 12.x. Yes; I know that T-Mobile is kicking phones that don't support VoLTE and VoWifi off their network; however, that won't apply to any phone that runs AOSP - as VoLTE is par for the course for any phone that runs a recent AOSP firmware (Pie or later in practically all cases; in the case of Lineage, as far back as Oreo). I changed tower providers because T-Mobile doesn't care what firmware you run on your phone. (Since then, it turns out that my infusion center (and my current cardiologist - which is in the same building) are in a hole in the UnCarrier's tower network - which makes hotspot support - and therefore VoLTE and VoWifi support - all the MORE critical.)
Click to expand...
Click to collapse
Google may be trying to kill custom development, but we have developers like you to thank for continuing to help advance this field. Keep at it!

blksith0 said:
Google may be trying to kill custom development, but we have developers like you to thank for continuing to help advance this field. Keep at it!
Click to expand...
Click to collapse
I am not a developer. This is just my hobby. Lol. Thank you though. I'll be doing this stuff for as long as it's still possible. Long live the custom community!

PGHammer said:
Since I cloned your scripts, I have added Lineage to my "skinny build box" project;
Click to expand...
Click to collapse
Is this skinny build box project available?

tvoneicken said:
Is this skinny build box project available?
Click to expand...
Click to collapse
The skinny build-box project is designed to be as low a specification that can build a standard-spec AOSP-based ROM.
My target is a two-core PC with 8 GB of ROM and 250 GB of storage space used - as either a virtual machine OR a WSL2-bsed spec.
The very reasons FOR the skinniness is so the PC used for it can be doing other things while build operations are going on - which is also why I am concentrating heavily on WSL2-based specs - because it has such operating in mind.
As opposed to most build-boxes - which have lots of both storage and cores - I'm going the other way - with as few cores and storage as can be gotten away with - to keep costs for builders down (hence "skinny") - not every builder is rich.
Once I get things ironed out, I will, naturally, publish exactly HOW "skinny" the final spec is - and I'll do so publicly ALA Nathan Chancellor.

A followup
PGHammer said:
The skinny build-box project is designed to be as low a specification that can build a standard-spec AOSP-based ROM.
My target is a two-core PC with 8 GB of ROM and 250 GB of storage space used - as either a virtual machine OR a WSL2-bsed spec.
The very reasons FOR the skinniness is so the PC used for it can be doing other things while build operations are going on - which is also why I am concentrating heavily on WSL2-based specs - because it has such operating in mind.
As opposed to most build-boxes - which have lots of both storage and cores - I'm going the other way - with as few cores and storage as can be gotten away with - to keep costs for builders down (hence "skinny") - not every builder is rich.
Once I get things ironed out, I will, naturally, publish exactly HOW "skinny" the final spec is - and I'll do so publicly ALA Nathan Chancellor.
Click to expand...
Click to collapse
I'm still shooting for the two-core target; however, as a backup, I'm doing a slightly-beefier four-core version based on the stebomurkn scripts - for the honest reason that I find them personally extremely useful.
CPU - Intel Core i5 (Socket 1151 or later)
Motherboard - any H or Z chipset that can take the same
RAM - 16 GB
HDD - 4 TB or larger
SSD - optional
GPU - optional
I'm doing a rebuild of my current system based on this spec. While my current system is G3258-based, I actually have a bigger budget than I did when I built "Baby Beastie" - my current '58 PC. The GPU will be the same GTX 1050Ti that drives "Baby Beastie" currently, as I have no need to upgrade it based on my gaming drivers. The HDD will be larger, because pricing for such has dropped dramatically. The PSU - like the GPU - is carryover (Corsair CX550M) - why replace what isn't broke? Same with the case - a full-size ATX. An SSD is an option - as my gaming needs don't require one. (My motherboard choices support both traditional SSDs and the M.2 sorts.) I'm still trying to stay under $1000USD - and I'll be purchasing everything via Amazon.com - which I did with "Baby Beastie".

ADDENDUM - Can you use both stebomurkn's scripts AND the scripts referenced in Nathan Chancellor's AOSP build guide? Absolutely - you simply need two script directories - ~/scripts and ~/scripts2; they can be in either order. (The reason why you need two directories is that you can't simply add them to the existing ~/scripts directory because it's not empty - hence you need a new place to put them - ~/scripts2.)

ADDENDUM - the core of the "skinny box" has been acquired - and it's the platter drive.
First off - why a platter drive? Platter drives are not pricey, and have gobs of capacity; further, thanks to onboard cache, they need not be snails. In my case, I went with the midrange Seagate 4 TB Barracuda Compute - which has been on sale at Amazon (AKA "Smiley's") for a mere $80USD (Prime). The Compute series is in three ranges - 2.5-inch for portables - 3.5-inch for desktops - and Compute Pro for workstations. The Compute I chose - for that $80USD - is from the 3.5-inch formfactor desktop range - which makes it physically no larger than the 1 TB previous-generation Barracuda it replaced, despite the four times larger storage capacity AND fifty percent faster (according to Windows 10) I/O performance - so much for making snap judgements! You don't need speed from a build box storage medium; what you DO need, though, is capaciousness - and 4 TB is plenty.
With the new core acquired, next came moving the data from the old drive to the new. Normally, I would use old-friend Acronis True Image; however, it has grown unwieldy in its age - so I wound up replacing it with Macrium Reflect 7. It has all the features that the older version of Acronis did - operates natively in Windows - and costs nothing.
Once you have the old data moved to the new home, re-sync your repos - remember, you have a LOT more space than you used to! (If you had a 1 TB (or smaller) platter drive, you may find yourself KICKING yourself, thinking "I was that silly in terms of lack of storage space?" Not exactly fun. Don't overeat - but don't skimp, either.)

Due to issues starting a new thread with a new post, I am making this one here; could someone with the proper access move it where it should go once I am finished? The subject involves running GSI (Generic System Image) ROMs on the Pixel 3a.
Why would anyone do so? The reasons are - unfortunately - twofold; it is getting harder and harder to find - or build, in fact - ROMs based on Android 10 and later for THE utility-infielder phone for Android 10 - the Pixel 3a. The second I have uncovered in my own running of Android 10-based GSI Havoc OS 3.8 for the past week - it is, in fact, better than the purpose-built Havoc ROM for the same hardware based on the same code - which makes not a lick of sense, but there it is.
There are two differences - Pixel Launcher is missing; instead, it uses Havoc's Shady Launcher - also, it cannot use Google Camera. Still, that is, in fact, all.
Now comes the $0.64 USD (sixty-four cents in US dollars) question - how does it run, and especially compared to purpose-built? Here's the scary part - for the most part, it actually runs BETTER than purpose-built based on the same code. The display is better. The performance is also better for the most part. As I said earlier, it makes not a lick of sense for "generic" to be better than "name-brand" - even when it comes to ROMs - yet here it is.
I have run it for the last week, and am STILL running it; either tomorrow or Monday, I will replace it with Havoc OS v. 4.1 (also GSI) for additional thrashing.

My BlissROM script is up to date if anyone is interested in building for this device still. I will be updating my Lineage script in the following days to make this thread relevant.

stebomurkn420 said:
My BlissROM script is up to date if anyone is interested in building for this device still. I will be updating my Lineage script in the following days to make this thread relevant.
Click to expand...
Click to collapse
Hi, I've tried to build Bliss using your script, and it failed at Building Kernel Image (Image.lz4) :-(
Most likely I'm the problem - I have no clue how android and Linux works nor any clue what scripts do and how they work, but since everything seemed to be working fine for a couple of hours, I hope it wasn't me (=fixable) this time. I can provide you with the log, just let me know where can I find it... Thank You!

ADDENDUM/FOLLOWUP - Can this be used with Windows 11? Yes - and with no changes whatever.

Why are you running a custom rom?

I wanted to GTFO Google and (ONE) single ROM has been developed for this phone on XDA without Gapps and it's not even maintained any more. I tried out Lineage with Micro G and I was pretty happy. I asked if anyone here would be interested in GrapheneOS and got no reply. I built it for myself and was happier with the spoofing in Lineage so I went back. But that brings me to the OP question...​​I guess I just don't understand why anyone would build a custom ROM that allows Google to spy on you completely unchecked. I thought I must have been insane since literally nobody here seemed to agree. Then I found this write up......I immediately decided to post it. Not because I want to piss people off. Not because I'm unappreciative. But because WTF ARE WE DOING??​​Why are we even running custom ROMS? Xposed came out and Google screwed us with SafetyNet. Then you had Substratum that got checked from Google but it's being "allowed" right now even though they tried to patch it out. Then Magisk comes and Google buys him out. This has always been a "cat vs mouse" game until recently. Now it's just a "cat vs customizable cat" game. Did we lose? Or is it that people would rather trade their privacy for convenience? The direction we are headed as a community is allowing Google to slowly close off and become Apple pt2 and nobody seems to mind much. But this is XDA! How will it exist without people caring about this?​​Here is part of the write up that applies specifically to the OnePlus7T. Hopefully I'm not alone. Hopefully we can get this train back off the tracks where it belongs. Barreling through the unknown in defiance of these huge entities trying to control you. Link is at the bottom of the write up.​​crDroid​LineageOS-based custom ROM designed to increase performance and reliability over stock Android for your device while also attempting to bring many of the best features existing today, according to their intro & how I think its grammar should be.
Personal remarks: A very good heavyweight ROM (and the best Limbo ROM at the moment), burdened with a soydev website (at least there's no BlockAdBlock unlike Arrow) & lack of Vanilla/GApps enforcement in a way similar to Bootleggers - no Vanilla/GApps branding
Advantages:
Per-app data restriction (Pie, A10, A11)
Signature spoofing (A10 & A11: no toggle)
Inbuilt App Lock
Disadvantages:
No signature spoofing (Pie-only; forgiven & redacted starting with A10, 12/4/2020 build)
If you look at the official site, there's a screenshot that shows this feature, on a toggle. Should have been available at Settings > crDroid Settings > Miscellaneous; but it's not there.
Tested the 12/4/2020 build & found out that microG support is enabled without toggle. This anti-feature is redacted.
Poco X3(N) only (confirmed on 23/3/2021 build) - USB debugging enables itself on boot (redacted per 22/4/2021 7.5 build)
28/4/2021 Update : With inbuilt vendor on 22/4/2021 7.5 X3N build, USB debugging no longer self-enables on boot (it's enabled at 1st boot, but can be disabled without enabling itself on subsequent boots). Welp, guess it's like the F1's Pie era all over again, where most builds (especially userdebug ones) enable USB debugging on boot until developers starts to include vendor partition in their builds.
Poco F1 (A11) : No force encryption
No Vanilla/GApps enforcement, in addition to lack of Vanilla/GApps labeling
List of GApps-infested builds :
OnePlus 7T & 7T "Pro"
Not having an active TWRP development for a device does not excuse the maintainers for releasing GApps-only releases, unless they also make a Vanilla variant. And, since there is an active TWRP development, there shouldn't be any more reason to tolerate a lack of Vanilla build (other than the maintainer being too lazy / unwilling to develop a Vanilla build, in which case per should be replaced).
Poco F3 (switched to Vanilla builds as of 9/7/2021 builds, but still listed for reference)
Redmi K20 / Mi 9T (davinci) (Vanilla build available on GDrive, FWIW.)
OnePlus 9 "Pro"
When its non-"Pro" (the vanilla OnePlus 9) variant gets a Vanilla build (despite a lack of functional TWRP for either) there is no excuse to be lazy & provide GApps-only builds
Custom ROM List

Definitely. Yaap microG by John Galt is very good also. Omni microG is also good

I read through your entire post and while most of the things you have said could be attributed to a subjective basis depending on person to person basis but the overall idea has a couple of inconveniences that I would like to add some insight of my own and would like to explain without sounding too brash
This is just my own personal impression that I have witnessed being part of the greater Android ecosystem in general starting from the early days to where we are now
In my opinion, the lack of interest by developers that originally gave their time and effort into working hard and fixing things has generally not kept up with the pace of Google's development efforts to curb these "hacks". The cat and mouse game what the post you quoted said is nearly at an end. I think Google is winning with everything in broader terms and despite the conveniences offered by microG and custom roms using that implementation, it doesn't come close to what Google offers.
The hassle of finding workarounds to make even the basic of functionality to work on Android requires time and effort which as I have already said earlier, it's something no one can commit to these days. The "enthusiast" aspect of custom rom development has really taken a dive over the past few years as manufacturers generally offer good enough functionality (at least for my use case as I am heavily reliant on my phone for work and general personal use) and Android has come a long way since the early days.
All of what I said boils down to the cost of convenience vs concern for issues that are really issues for a specialist segment of users within the entire community. People de-google their phones to focus on privacy and prevent data mining from these data hungry corporations and I for one for wish I could have something that would decrease my overreliance on Google's services but it is just not possible as the majority of people just use their phones and expect things to work just like that. So, the long lived idea of if it ain't broke, don't fix it plays very well into this. The trouble is generally not worth the inconveniences that come with it. Lack of interest of users therefore means lack of options and thus a lack of development.
Here's my 2 cents

I think for devs or hobby-coders who do this for free, time is more valuable than the luxury of "privacy" (which doesn't really exist if you're using any form of social media, like XDA).
Things changed. Android is more polished now than the Nexus days.