• 0 Posts
  • 6 Comments
Joined 2 years ago
cake
Cake day: June 11th, 2023

help-circle

  • If google restricts access to its os, like they have already started, all you’ll have is pixel up to 10/11 still supported 10 years from now. They’ve already started by no longer providing device trees in aosp for their phones, so graphene has to work harder to obtain them now. Whereas if you work on lineage, you potentially have a greater number of vendors and potentially new ones ready to open up to draw in new userbase.



  • 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.