[X Style (Pure) Android Development] ResistanceIsFutile:
Excuse me that I read alot, most of the time absorbing just a little.

Could you not pull something from a Moto shipped with Oreo or one getting the O update?

Moto X4 , Moto Z2 Play, Moto Z Play.

Starting this fall Motorola's getting O - moto z, moto z Droid, moto z Force Droid, moto z Play Droid,

moto z2 Force Edition, moto g5, moto g5 Plus, moto g5S, moto g5S Plus.

Didn't OREO address this physical vendor partition with Project Treble?

Possibly of decompiling a LOS 16 download for another Motorola device for it - ideals - resources?

https://www.cyanogenmods.org/lineageos-16-supported-devices-list-and-downloads-android-pie-9-0/#Motorola_Lineage_OS_16_Android_90_Pie_Download_list

I ran across this and other passages in an artical on the web:

It’s important to reiterate that Android uses the Linux kernel under the hood. A kernel is the part of an operating system which handles input/output and computer instructions from the application layer, essentially allowing the application software to communicate with the hardware. To make changes to the way Android handles this communication is to make some notable changes to the way the Linux kernel operates.

To solve the hardware abstraction layer issue, Android 8.0 Oreo and later version like Android 9.0 Pie formalize the division between hardware subsystems like audio or camera, and their clients on the software side. These new formal divisions specify the interface between a HAL and its users. There are now around 60 formal interfaces for various hardware components, known as HIDLs.

The goal of a HIDL is to allow the framework to be replaced without having to rebuild HALs. HALs will be built by vendors or SoC makers and put in a /vendor partition on the device, enabling the framework, in its own partition, to be replaced with an over-the-air update (OTA) without recompiling the HALs. To update devices running earlier versions of Android to Android O, developers can wrap both conventional and legacy HALs in a new HIDL interface too.

(Down further reads)

As of Android 8.0, the new vendor interface is validated by a Vendor Test Suite (VTS), to ensure that the updated OS is compatible with the existing hardware setup.

(Down a little further reads)

XDA community members are already excited about the prospects. Developer OldDroid went as far as to call this a breakthrough, after booting Oreo on the Mate 9, which hadn’t even seen a single custom Nougat ROM. Other developers have also already shown off a single system image capable of booting on different devices with different processors."

"Project Treble has some interesting implications for the revival of the custom ROM scene too, as there’s likely to be less work required to get software and hardware playing nicely. It could take just days, rather than weeks or months, to port AOSP to a device that supports Treble."

"The prospect is that we may be edging closer to a time where Android software can be easily ported across a range of devices, much like how Windows can run on a huge range of hardware configurations with minimal effort."

"only handsets with Android 8.0 Oreo and 9.0 Pie installed out of the box must support Project Treble. Phones that upgrade to Oreo from Nougat don’t have to fully support Treble, though OEMs can choose to if they wish. We’ll have to pay close attention to which manufacturers say what as they roll out their Oreo upgrades. It’s also unlikely that custom ROMs will be able to introduce Treble to many older devices, as lower level hardware access isn’t open source."

Source:https://www.androidauthority.com/project-treble-818225/

(This was interesting in the comments)

Windows doesn't have to be recompiled because Microsoft have made a stable ABI (application BINARY interface) for drivers, Linux deliberately doesn't do this to discourage hardware manufacturers from creating closed source binary drivers that can't be ported to new kernel versions without the blessing of the hardware vendors.

Linux has a stable API (application PROGRAMMING interface) for driver development so that the source code will compile in later versions of the kernel, or on different hardware without changes, but you need to include the module stubs for those drivers or they won't be able to load.

The differences between how Windows and Linux drivers work is imposed by their respective developers and not due to any technical aspect of kernel design.

Please forgive if already known or being no help to you.

Wishing only to help you in my limited capacity.