I’ve worked with Qualcomm SoCs a long time ago and, from my experience, the binary blobs ARE the biggest hurdle to the true Foss phone. Google is the most to blame, IMO, but also the rest of traditional OEMS of SoCs. They basically found the way to circumvent the OSS nature of Linux, which is why even though android is based on linux, the actual product and ecosystem looks nothing like regular Linux. What Google allowed with Android architecture, particularly with their HAL subsystem is force a layer in between native Linux device interface and Android system, so OEMs use that to implement whatever proprietary peripheral (device, sensor, etc) purely in userspace, rather that just as a kernel module. The kernel module is then just a userspace/kernelspace adapter, and everything is handled in the user space. This then means you dont have to have an open source driver, as it is not a part of kernel, and you just lock your driver into a binary blob. And in case of Qualcomm and I assume other oems, everything is just a binary blob. All sensors, microphone, GPS, modem, EVERYTHING. Yes, you can boot a basic Linux kernel, but no other functionality will work. If you had access to the blob source, you’d be able to fix, update and use a newer kernel versions eventually. HAL is technically not the cause of the problem, but it’s certainly an inspiration and almost a blueprint for how to lock down your hardware.



Not trying to defend temu, they are definitely careless enough to breach way bigger restrictions than this. However, don’t just ignore the rest of the context here.
It’s unreasonable of you to only direct blame to Temu (which are know to be negligent and aggressive at testing the limits of what they can get away with) in this particular, unusual case.