The problem is that the abstraction layers do change between Android releases. Sometimes significantly. And, most often, the OEM doesn’t have access to the driver source code, in order to update the exposed abstraction layer code. This means the OEM needs to wait on new, updated blobs from their SoC (system-on-chip) developer. That’s often Qualcomm, or possibly MediaTek or Intel. This company, invariably, wants paid money for these updates (since otherwise they’d be doing the work for “free”). You’d better hope your OEM budgeted for this. I know from experience (although you simply need to trust me on this, as I will not disclose specifics) that this has been the direct cause for a number of specific handsets to not receive further updates – the OEM didn’t have an agreement with their SoC provider for updated board support packages, and they had not budgeted for this. This meant no new board support package of drivers, and therefore no update for that device...
...More to the point, how do custom ROMs bring recent firmwares to devices that didn’t get OEM support? There are three approaches – one is to reverse engineer open source drivers for a device. This is no mean feat, but it leads to a really well-supported device for the future, since the driver’s outward-facing interface can be adjusted when Google tweaks the AOSP HAL. The next approach is to find a similar device using the same hardware, and “repatriate” the drivers from it. This often is done on GPUs, which are very fussy about the versions of their driver blobs. The last approach is to “wrap” the original driver. This is easiest when only a small change has been made to a HAL.
