Over 3 years ago, Google announced Project Treble, a major rearchitecting of Android designed to speed up software updates. While the architecture introduced by Project Treble has helped OEMs to speed up the delivery of major Android OS updates and monthly security patches, it has had an adverse effect on SoC providers like Qualcomm. In fact, Treble has actually increased the complexity, and thus the engineering costs, associated with providing Android OS update support for any given chipset. That has limited the length of support that Qualcomm can provide for its SoCs, but that will soon change. All Snapdragon SoCs launching with Android 11 or later—starting with the Snapdragon 888, Qualcomm will support 4 Android OS version updates as well as 4 years of security updates. That’s an additional year than they previously provided for their flagship 800-series chipsets.
Since virtually all popular Android devices use Qualcomm chipsets, this is a big boon for Android users.
Which is what we all suspected: The entity that actually decides if you will get the upgrade is the SoC vendor. No drivers, no upgrade, it’s that simple. Someone tell those kids blaming the OEMs that the OEMs do not have the ultimate say. Even LG (the king of delayed upgrades) got an initial bad reputation due to Nvidia Tegra.
It’s a problem in layers.
Both parties have a vested interest in selling more product and investing as little as possible in future support.
Reading through this very carefully “Project Treble” effectively outsourced the problem to vendors. The Android HAL is basically a wrapper for the hardware. The GSI is only good for two versions. In the PC world this would be equivalent to ever vendor being responsible for all the drivers and the OS interface not gauranteeing to be stable for more than three versions. As you read through the problems get worse and worse.
I find there’s a lot about Windows I like. One of them is the way the HAL and drivers and WDK were organised. Because of standardisation a lot of devices could run on generic drivers or drivers compiled with skeleton or sample code in the WDK. In the early days Microsoft wrote many of the drivers themselves to achieve support critical mass. This enabled Windows to support a huge amount of hardware and software changes to the point where Microsoft had to artificially cripple older versions to get people to shift to new versions.
New software continues to work on Android in part because parts of the OS were closed then shifted into Google Play Services. While phones work this leaves pretty much every phone pre Qualcomm Snapdragon 888 without even minor support or even security updates. Eg: There a couple of minor bugs in Android 4.3 and a few security nightmares. Android 4.4 has a nasty memory leak. There is nothing in this which needs a major OS update yet they remain unsupported due to an artificial two year marketing window which may not, strictly speaking, be compliant with consumer protection laws in all jurisidctions.
Has anyone done an environmental impact assessment of Googles latest wheeze? Costs? Monopoly issues? I include the SoC vendors in this criticism.
Many of us felt that “Treble” was a bad solution to the problem because it failed to acknowledge the realities that vendors were (and still are) part of the problem. What we really needed, but did not get, was independent OS updates. When I buy a Dell computer for example, they’ll provide a few years of official support, but even once that’s over the OS continues to be updated by others for much longer.
A four year commitment is better than nothing of course, but four years of security updates is not great. I for one am very disappointed that they’re not breaking this dependency cycle altogether. Until they do it will continue to be a recurring problem for consumers 🙁
Come to the vendor’s side for a while. Linux doesn’t care about ABI stability, neither Android cares about the stability of its driver interface (the Android API is remarkably stable with shims for old API Levels and such, but not the Android driver interface). As a result, vendors face a backlog of old chips they have to provide new drivers for, and these new drivers require major code changes. Compare and contrast with Windows, where you will find drivers from 2009 in Windows Update working just fine. Because Windows keeps driver compatibility in the same major Windows NT version. This means you can make a Windows 10 driver by recompiling the Windows Vista driver. Even if they are minor edge cases (from moronic devs abusing the interface), they will be a minor defect fix, not an epic (to put in Silicon Valley speak). No full re-writes.
That is indeed true. It’s been a very very long time since discussing driver models so my memory is very hazy. Within limits you could use windows 9x drivers on Windows 2000 and later (I cannot remember if this was true of NT4 or not). There was also some tolerance of older NT driver models on later versions of NT which required new driver models. As you say a simple recompile would solve some problems. Okay, so Microsoft is now playing funny for various reasons with Windows 10 and drivers for legacy software because of artifically imposed WDK and signing reasons but this is by the by.
I know the movers and shakers with Linux (and Android) have their reasons (as do Microsoft and Apple) but this is causing real problems for end users as well as uptake of new systems or even just shifting platform of choice.
I think this is one of those issues when it is worth going back to the long forgotten design choices of the people who created these systems in the first place and ask why.
For the record, there was a major breakage of driver compatibility during the x64 transition (which fortunately coincided with the Windows NT 6.x transition introducing some breakage of its own, so most users perceived it as one big breakage when they bought a new Core 2 Duo machine with Vista). Basically, Windows x64 refuses to load x86 drivers at all. This allowed Microsoft to get rid of lots of bug-for-bug compatibility in x64, such as the ability for drivers to patch the kernel. Which is why x64 versions of Windows are so rock-solid.
In Windows-land, there is a clear separation between “XP drivers” (NT5.x and older, x86-only usually) and “Vista and higher drivers” (NT6.x, with x86 and x64 drivers included). But the breakage happened once, in a well-studied manner, because quite honestly Microsoft couldn’t get away with the old driver model anymore. Instead, Android and its kernel (Linux) break compatibility for fun.
BTW I actually like the enforcement of driver signing in Windows. If the vendor can’t be bothered to have their driver signed and put it in Windows Update, they have no business releasing a driver intended at casual users. Most vendors do, in fact, sign their drivers. I have come across a product (an IrDA adapter) with no vendor name (the vendor name in the executable files was “Company”). The driver literally existed only on the included CD (and it was an XP driver because XP doesn’t complain about signatures, duh). This shtick should have been ended by Microsoft years ago. Advanced users can install unsigned drivers (for example new versions of GPU drivers on old gaming laptops with vendor-locked drivers, I have done it).
Yeah. Thanks for the clarifying. I kind of stopped wanting to remember any of this past a certain point so it’s all hazy now.
I may have come across the same or similar USB IrDA adapter for a Windows remote control. lol. (It was probably a straight compile of a WDK sample.) I no longer have to bother installing it as Windows 10 happily installs a driver and the remote works fine.
I have a few issues with Linux (and Android) articulated very well by others who have the expertise and influence to do so (and from time on OSNews) and know they have been banging their head against the wall. My main current interests on none technology but similar problems arise for irritatingly similar reasons.
The Linux team freely breaks kernel API/ABI. Userland API/ABI doesn’t get broken, for good and bad.
The SoC vendors make money selling professional services to companies using their chips, so they are suspect here.
That’s the old “Linux will change how things are done once it’s popular” excuse we ‘ve been hearing since forever. Guess what, Linux (the kernel) is now popular thanks to Android, and nothing has changed.
I think the culprit really is Linux and Android breaking driver compatibility for fun. Because they are creating costs and demanding others to pick those costs up (negatives externalities, I think they are called). Guess what, nobody likes picking up someone else’s negative externalities, so the costs translate into problems.
You can witness a lot of this kind of behaviour with some organisations, departments, or even individuals. Dogmatism, old farts nearing retirement, lack of training or accountability, young bucks wanting to make a rep for themselves, or sometimes just plain idiocy pushes costs from pillar to post until when they think nobody is looking they are dumped externally.
I’ve noticed some people don’t like change even when the original reason for the dogma/policy/viewpoint expired years ago.
kurkosdr,
Sure I agree linux has a kernel driver stability problem. I’ve criticized the lack of driver ABI stability before on osnews, The kernel devs don’t want to budge on stability and the hardware manufacturers don’t want to budge on pushing open source drivers to mainline. Given the lack of compromise from all sides, we the consumers remain remain stuck on unsupported operating systems with no updates, which sucks.
Also, it’s not really the case that updates need to be full re-writes. The breakages prevent us from re-using existing binary drivers, but if you’ve got access to the source code (which we the public don’t) most of the changes are relatively trivial in nature. I’ve dealt with this for years in my own distro, the breakages are annoying but by no means particularly difficult for a kernel dev to resolve. Most of the hardware manufactures could commit to longer updates without too much work. But impediment here is mostly down to corporate justification: why would they want to release new binary drivers for old products when EOLing those products increases sales? Seriously it’s against their own financial interests to provide updates. Does anyone think they’re going to prioritize last gen owners over wallstreet? This is why the situation did not get better with treble, and why it’s not likely to ever get better so long as we’re dependent on hardware vendors for software updates. I’m not saying this to deflect from linux’s ABI stability problems, but just to be pragmatically realistic.
This is where I feel frustrated. These things are ultimately a government issue or an issue for the courts. There are existing regulatory frameworks on competition, legislation on consumer rights, and law on environmental issues too. One big mistake is to assume any of these players are in any way rational. Where none of the players act because of intransigence or finger pointing sometimes they have to be compelled to. If nobody does anything we will still be here in another ten years saying the same things.
This is just how I feel about it.
And why should Qualcomm open-source their driver, considering they foot the bill for its development? Get real. Especially considering their rivals (MediaTek) have craptastic GPU drivers and Qualcomm has a competitive advantage because of their better drivers. Sure, MediaTek chips claim to support OpenGLES this and OpenGL that, but in practice they are buggy. Google had to insert as much usage of OpenGL ES and OpenGL calls in the Android UI and default Android apps as possible, in order to provide a safe subset of API calls guaranteed to work.
Also, keep in mind some of Qualcomm’s wifi and cellular radio code is in the drivers, and wifi and cellular radio technology is another major advantage of Qualcomm. Again, why give that away to competitors?
PS: which distro is yours?
There’s the issue of regulatory and market and legal failures. This isn’t about the notional competitive advantage of one single company.
On the topic of OpenGL (and OpenGL ES) there have always been issues with conformity. Strictly speaking a driver could not call itself an OpenGL driver (the name is trademarked) unless it passed the conformancy tests. Where there were problems there was an obligation on the vendor to rectify this. This and the fastpath/slowpath issue and whether a vendor has or has not been willing to provide a driver or even a quality driver has been an issue since whenever hence the OpenGL trademark and conformancy tests. (See also company complaints procedures and trading standards and irritated customers demanding refunds.)
A lot of radios (almost all to some degree or another) are software defined radios. The vast majority of their function is now defined in firmware or in the driver or in a software application. Some lock down their functionality while others leave the SDR function fully exposed. This is not a mystery.
There’s nothing to stop Qualcomm designing good abstraction layers and releasing an SDK, and some of this being open source and the rest being closed. The fact they don’t nor using their influence to address regulatory and market and legal failures hints just a little bit of Qualcomm taking advantage.
People are fully within their rights to question. We do live in a democracy after all (or most of us do.) Putting aside that “distro” is a Linux term this has nothing whatsover to do with who or who does or does not produce what if any “distro” although they too can be equally concerned. This is their choice. In any case just because someone produces a “distro” is entitled, in some peoples mind, to Catholic levels of worship and fawning, it does not mean they are interested nor competent nor even capable of addressing these issues. The skills and knowledge and expertise to produce a “distro” are not the same as consumer rights and other directly and indirectly related issues. However, there are people who are more expert in these and who have the capability to act on this.
kurkosdr,
I didn’t say anything about them having a reason to do it. The point was merely that because they don’t do it, we suffer. Trust me I’m well aware that consumer interests often take a back seat to corporate interests. For better or worse, if you’re a corporate executive, you work for the shareholders and consumers are just a means to an end.
My understanding is that the radio stuff is technically running on a separate baseband processor, which is out of reach to the main operating system. The OS (android as it were) is only interfacing to the radio as a high level packet driver. But in any case, it’s no secret to the FOSS community that Qualcomm isn’t willing to cooperate, and it’s part of the reason things aren’t improving 🙁
GMLinux2. It’s completely headless. It doesn’t even have a link though, I use it to run my client infrastructure and fix things I don’t like about other distros, haha.
kurkosdr,
This could all be obsolete now, but I found this interesting link about accessing Qualcomm’s rf processor. While I have no firsthand experience with this kind of hardware, I’ve heard that from the host many of these radios are actually using a kind of AT command set reminiscent of the good ol’ hayes modems. If you’re old enough you’ll recall the way we would often interact with these protocols by hand! Haha.
https://blogs.gnome.org/dcbw/2010/04/15/mobile-broadband-and-qualcomm-proprietary-protocols/
I think this is doing some productive tasks using reverse engineered radio interfaces.
https://github.com/P1sec/QCSuper
@Alfman
I think AT commands are mandated somewhere in the GSM specfication which may explain why CDMA phones may not expose this even if it is theoretically available in the underlying hardware.
I’ve been told a lot of telcos with the complicity of IHVs obscured this feature deliberately. My memory is hazy but I think it’s something to do with trying to peddle data services. The fact that Qualcomm is hiding behind a wall of flummery and gobbledegook to protect their “intellectual property” and market position is no real surprise. Both Qualcomm and Broadcom have been singed by regulators over their behaviour and they were equally full of it when trying to head off investigation. I doubt it would be a big shock if Qualcomms open source and driver release policy is based on a stack of lies and self-interest with zero technical or competition merit.
Android Police has a different take on the matter. It’s not so much Google doing good as much as Google’s marketing department digging up publicity during the holiday buying spree.
https://www.androidpolice.com/2020/12/16/google-and-qualcomms-big-update-announcement-isnt-what-it-seems-heres-what-you-need-to-know/
https://www.androidpolice.com/2020/12/16/google-and-qualcomm-just-announced-huge-news-for-android-os-updates/
I caught this too after people queried Googles puffery on Slashdot and wondered how anyone missed it.