A rant about OEM lazieness as it pertains to Proprietary Files

Ever wondered why x device slowed down after an upgrade to the newest android version? Or why y doesn't work on a source built ROM?

A BIG part of the issue is OEM's laziness. The bigger part however, is proprietary binaries.

Quite often, proprietary binaries are not updated for feature inclusion, or improvements, and are only updated for the purpose of making the hardware WORK, not WORK WELL. They often go out of their way to actually update the HAL's/RIL's/Proprietary Blobs.


A great example of this is the RIL. The RIL (Radio Interface Layer) is updated EXTREMELY infrequently.

Android's RIL interface is versioned. The current AOSP revision of it is 11. Now, the ril-daemon (Android component that communicates with the RIL) allegedly supports any RIL revision 6=<.

A great example of these components not being updated is in the Nexus S (crespo). It was upgrade to JellyBean, which natively includes RIL version 7. Instead of updating it to get all the perks, bug-fixes, and patches RIL 7 included, they left the prebuilt RIL 6 and just backported code into ril-daemon to support RIL 6. It is no where near optimized for it, and there is often performance degradation due to this. Though this is an old example, it happens on all modern devices (I've seen it on shamu, hlte, etc.) where the OEM's get lazy.


Another common complaint is GPS lag on updated devices. This is due to the same root problem, just more amplified. GPS blobs are commonly static across multiple major android versions. Run a quick MD5 hash on the pre-update version and post-update version, or look at them in IDA (or really, any dissasembler/decompiler). You'll find it rings true.

Name any piece of hardware (including the CPU), and you'll find a case where some OEM decided to back-port old code to avoid doing hard, time consuming work on older devices. For fun some time, grab any OEM's commit log and grep iot for 'hack'. You will be AMAZED how many times they null out functions, or backport archaic paces of code to avoid actually upgrading (and in the process optimizing) their proprietary blobs for new android versions. I'd also image external vendors have some say in this.  Imagine this, you are a Samsung engineer, you have two options;

- Hack together the current proprietary file set to work for the new android version, and ignore optimization.

or

- Contact every one of the external vendors that has devices onboard the device in question, and pay them all to update the blobs, which could also delay the update indefinitely.

Qualcom/Imagtech/Invensense will only update these binaries if they have to/are paid to.


If you read this, you'll pry realize that this problem isn't easily solved, and, to be honest, the way it is currently done is /probably/ the best way to do it in the current world.

Now, you might say, "Can't the community just update the blobs, cause Android is open source?". That question makes me laugh a little to be honest. Android *itself* is open source, as is the RIL. Though, the AOSP RIL will not work on any devices other than AOSP supported devices (excluding a few lucky cases, like some of 2014/15 Moto phone's due to the Nexus 6 being in AOSP and sharing similar hardware). Due to this, most devices don't have an open source RIL. Many people use AOSP-CAF (Qualcom's 'Code Aurora Forums' version of AOSP), which contains a ton of backports, patches, and additional drivers to support a much wider set of devices. This often allows us to update the RIL aftermarket (similar to what was done to bring the OG Moto G up to Marshmallow), but, these don't contain the initial optimizations that OEM's slaved over pre-release on that device, and will always (in all but a few rare cases) perform at least a tad bit crumbier than the OEM blob on its targeted Android version.


Separately, you also have to realize this:

Smartphone's take more physical damage than almost any other high end electronic (yes, even to those of you who take really good care of them). They ride in our pockets being shaken all about for a large portion of their life. They get dropped occasionally, wet, run through a light rain, etc. So, overtime, your hardware takes a real beating. Having opened up many people's older devices for repair, they are FILLED with random crap (excluding certain brands that manage to keep particles out, namely Samsung, which I dislike, as they are the worst offender of the blobs issue described above). They also get dented, etc. Yet we still expect them to last as long as our PC's, which are often treated much better in comparison. Plus, letting the battery (or really, any device in the phone) get above the recommended temperature even once can permanently effect the device's function, or battery's longevity.

And, in all this, I haven't even began to cover NAND/eMMC/UFS aging which slows down I/O read/write speeds, or the aging of other devices, which is amplified in smartphones due to their MASSIVE amount of uptime compared to most devices.

Tl;DR: Just read it, it contains good info.

Comments

Popular posts from this blog

Breaking Samsung's Security

Guide to Compiling Android on Ubuntu 16.04 (Xenial Xerus) -- OpenJDK7 Installation on 16.04