Traditional Linux kernel drivers are not considered legacy and upstream drivers can be used when available. Treble does not imply anything about the kernel driv

Traditional Linux kernel drivers are not considered legacy and upstream drivers can be used when available. Treble does not imply anything about the kernel driver design. The whole Treble vendor HAL layer including all the userspace code and kernel modules is an implementation detail of the device. It's a stable API/ABI for the system image to make it easier to update to new major Android versions without overhauling the device support code. It was also used as an opportunity to heavily sandbox most of the HALs as part of splitting them out of running in system_server, media processes, Bluetooth processes, etc. It did not result in significant changes to kernel drivers. GKI (Generic Kernel Image) support did result in significant kernel driver changes by requiring them to use a far smaller subset of the kernel API and work with a GKI image for testing. Certified devices don't need to use a GKI in production and mostly don't but do need to work with it for testing. That's supposed to make it possible to much more easily update the kernel in a similar way as Treble did for the OS. This has forced writing drivers in a way that's much easier to port to new kernel versions which encourages updating the kernel to new LTS branches. It has the downside of making Android itself upgrading the AOSP kernel trees to new LTS revisions within a branch much harder since there's supposed to be a stable ABI. It would be much more purely beneficial if they dropped the stable ABI while keeping the restriction on the subset of the ABI usable by modules. Implementing drivers largely in userspace is entirely a choice for the companies writing the drivers. It's much better for security and robustness to have most of the code in sandboxed userspace processes than the kernel. There's no requirement from Android or Google certification to do this. It's simply regarded as a good engineering practice by most. The reason the Linux kernel puts so much into the kernel is because it doesn't control the userspace. They're largely putting code into highly privileged kernel space for organizational reasons. If they had a way to write large portions of the drivers in userspace, then many upstream Linux drivers would likely be written that way. It's a huge problem that there isn't a standard and accepted way to do that rather than a good thing. Many out-of-tree drivers for Android devices largely being in isolated userspace processes is a major security benefit which shouldn't exist because upstream drivers should be able to be written as sandboxed processes too. The APEX modules used as part of the device independent base OS are open source parts of the Android Open Source Project. Google Play mainline updates are Play Store shipped builds of the code for those for Google Mobile Services devices. It didn't result in anything being removed from AOSP.