When building AOSP (Android Open Source Project) or LineageOS, there is a tool named breakfast. It downloads proprietary blobs and integrates them to the source tree.
I have read this article, does it mean all of the blobs are under /system/vendor/ directory?
Do those binary files also exist in Android filesystem? And where are they?
Answer
Yes, binary blobs are part of Android filesystem. Android can't boot without them as they are kind of hardware drivers for the device. Most of those are found under /vendor/lib(64), some also under /system, /etc and /bin. Before Android Treble, /vendor wasn't necessarily a partition but a symlink to /system/vendor directory. Starting with Oreo, /vendor is a partition, containing all content related to OEM and SoC vendor. Most of the blobs are executable files or libraries, run as independent services on boot. See this sample proprietary-files list.
In addition to that, the first partition (usually labeled modem) on eMMC contains Radio/RIL related firmware. Another partition dsp contains Qualcomm's Digital Signal Processor related binaries. They aren't built with ROM but are part of Android filesystem tree, mounted at (/vendor)/firmware and (/vendor)/dsp. Their execution is isolated from the rest of the device.
Many partition related to bootloaders are in themselves complete binaries, such as aboot, sbl, rpm, tz, cmnlib, devcfg, keymaster, lksecapp on Qualcomm devices. Those aren't mountable filesystem, but directly executed by bootloaders during boot process. All of them are proprietary binary blobs; the closed-source part of Android devices.
PS: Android (a superset of AOSP) isn't a generic OS which can be installed on any hardware like we do on PCs. Support for the hardware is locked down to proprietary binaries (HALs) by the OEM and/or silicon vendors. So the binary blobs are critical, and the open-source AOSP (including modified Linux kernel source provided by Google) is of no use without hardware drivers. And the manufacturers rarely document the working of their hardware so that developers like Replicant can implement an open source driver. There is very small set of hardware components on Android devices that you can expect to be handled directly by making syscalls to kernel as is the case on PCs. The only notable addition by SoC vendors / OEMs to generic kernel source already modified by Google (1, 2) is the handling of non-discoverable devices (defining device nodes). Rest of the hardware related stuffed is handled in userspace through binary blobs.
Further reading:
No comments:
Post a Comment