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.
Related
Conflicts of interest with Android supporters helped kill Google's Nexus One project, but that is not stopping the search giant embarking on another bid to keep Apple-style control of the Android platform. Google is reported to be planning a unified user interface that will be imposed across Android products, ending the fragmentation that dogs the system, but also restricting partners' development of their own user experiences.
Full story HERE
if the UI makeover is any good then I wont mind but I do hope they dont make it harder on HTC to make sense for gingerbread as I quite like Sense UI.
I'm not that fussed on sense to be honest. I could take it or leave it.
I just hope that Google don't start to push people away by trying to monopolise everything. I can't imagine that HTC would be happy if they were having their lives made difficult by Google.
HTC have made an excellent phone in the desire, and if things like this make them think again about a new release using Android then it can only be bad for all of us.
True.
Android is open source so Google cant ban anyone from making thier own UIs so in that sense should be fine. if they do start to monopolise then yeah I will get worried as thats going the apple way.
This depends on the implementation if we (at least I) should take it as good or bad.
Good: google unifies the UI but also allows others (developers) to make their own UI and doesn't make hard the implementation of personal UI. In the end, after Froyo, google needs a nice and unified UI. Froyo brings many things which are needed, now the only thing lacking is nice and unified UI.
Bad: google unifies the UI and doesn't allow nobody to make their own UI. Then they will become like apple and I will personally refuse to purchase anything that has to do with them. To speak the truth, I chose the Android (Desire) device only because of Android openness. If someone takes that away from me, I will take my 500 euro from them. Simple as that. That is the least I can do.
I know this sounds terrible but to be honest I have no problems with Google semi 'monopolising' Android. Unity is so important for a mobile OS IMO. Look how far Apple has got with theirs.
Unlike Apple however, I trust Google not to go too far with it all...
If the UI is good, I dont mind.
I hate everytime Google released a new version of Android and I have to WAIT to get it.
Kill that fragmentation ... please ... please Google?
Whether we like it or not, it seems this is the direction that all OS's (i.e. Microsoft WP7) seem to be going in although Google has under gone more radical changes with it's new versions due to being so new and having developed so fast. Despite what that article above said Microsoft with WP7 are stopping (having stopped development of WM 6.5) OEM's from adding custom UI's so that they can roll out OS updates without OEM's getting in the way or delaying them. This means they can have uniformed releases of OS updates across the whole platform and them not be device dependant.
It's not a bad idea as long as they do not completely lock it down and still allow 3rd party enhancements to be added to the core OS with custom launchers and widgets IMO, as we don't all want or need to have our devices all looking exactly the same. But if it means new OS updates reach users faster as long as the hardware is capable that has to be good for both us the users and Android or any of these OS's.
Also remember Google has said after Gingerbread their will be a slow down of core changes to the OS as it just won't be so necessary as it starts to mature and should only require minor tweaks or fixes from then on. That's not saying development will cease just that it won't need to be so rapid and if by then there are a minimum spec being used with less custom UI's any new features should be easier and faster to apply to all the devices.
-------------------------------------
Sent via the XDA Tapatalk App
i think that what should be done is a unified UI by google which many users like but it will be awsome if their way of customizing is on top of the main core files and can be customized bu 3rd parties too. so there will be faster updates and the possibility of customizing it. something like a folder with the customizations that will be used instead of the system defaults......
Yes....What should I say????......
If(google==apple)
cout<<"**** THEM BOTH";
else
cout<<"Long live google!!";
That has to do it!(c++ style comment)
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.
I'm on the final Pie version PQ3A.190801.002 rooted with Magisk.
Reasons that others have decided to stay with Pie for now:
1) No TWRP
2) Battery life worse on 10 (for some)
3) Reported issues with colors
I reviewed the security bulletins but there are multiple severe and critical issues patched with every release, so it's hard to tell which are significant threats.
I read the thread that clarifies that it is not possible to apply security patches without installing Android 10.
I'm happy with Pie, and lean toward "if it aint broke don't fix it" unless there are significant security issues.
Can anyone comment on other data points that should be considered while deferring the update to Android 10?
I mean, there is not anything that is game changing about it. My battery is a little better actually. Lack of TWRP is something, but it does force you to figure out how to do things in a new way, which might be the only way in the future. After going from DU on Pie to stock on 10 I simply set my phone up exactly the same, so I really see little difference. I learned a bit about making Magisk modules in order to systemlessly change some things, guess that was a personal benefit (I have to modify vendor partition to get VoLTE and such to work properly).
I would tend to agree though, if it ain't broke don't fix it. I see no substantial changes in the phone's functionality.
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.
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.crDroidLineageOS-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.