At the moment, phones include all sorts of custom drivers for very specific versions of the hardware. The OEMs ought to send these upstream, but don't want to. You can't build your own kernel and upgrade without breaking all the binary-only drivers.
Android falls between two stools. Google own the userland but the OEMs are responsible for updates and the SOC manufacturers (mostly Qualcomm and Mediatek) are responsible for closed-source drivers. Arguably the cleanest and least achievable way out of this is trying to have an OS-only phone.
RedHat Enterprise Linux actually solved this with their kABI. This allows vendors to ship binary driver RPMs for kernels in the same RHEL major version (eg, RHEL 4, RHEL 5, etc). However, this entails a major effort on the part of RHEL, as it forces them to carefully backport improvements from upstream in a slow and careful way, so as to avoid breaking binary compatibility.
The RHEL kABI model was quite nice to deal with as a 3rd party NIC vendor (and you had to do it, even if you upstreamed your drivers, as they were frequently not backported to RHEL/Centos at a rapid clip, so RHEL customers would be using ancient buggy drivers unless you put together a driver RPM for them).
However, the source changes to support all the backports were something else entirely (which you needed if you wanted support for newly backported features). For a 10GbE driver that was roughly 2000 lines of C, I had a roughly 1000 line hand-made configure script, roughly 1/2 which was checks made necessary due to RHEL's backports. Checks that could have been a simple check to see what the linux kernel version was were complex spaghetti, trying to detect how many arguments some function took. This is because EVERY kernel was 2.6.18 for RHEL5, even if it had backports from 10 or more versions higher.
I'm guessing that Google felt that it was better to invest in building an OS they could control from the ground up, rather than hiring a building full of people to backport upstream patches in a binary compatible way.
Obviously, you can't just take .28, apply a fix, and call it .29... But you have to do something.. ideally something that indicates binary ABI compat with upstream .28, (so software vendors can just decide, your .28, you get .28 features.
Maybe something like SemVer needs a model for versioning of forks? (I'm not a SemVer fan or hater, it's just the best known effort in this area..)
And you're right, if you always build on the base version, then you have greater compat. However, you also loose out on the backported features, many of which were important for performance.
This is just an excuse. The reality is the manufacturers still have the mentality that once something is sold their responsibility ends. We see the exact same results on certain OS's that do have stable ABI's. You've probably made a transaction recently on a device that uses an old and unpatched version of windows CE.
I'm still shipping software for WinCE4.2 devices. They're supposed to be on their own little LAN segment, not bridged to the internet, with a border PC managing them. The upgrade path would almost certainly both an expensive nightmare and possibly infeasible - they have exactly enough Flash for the OS they shipped with.
It's really a cost-benefit tradeoff; all these software updates cost money. Who pays for that, under what circumstances, and why?
Not my experience. I have three hardware devices that worked on Windows, Linux and FreeBSD 5-10 years ago, and now only work on Windows and FreeBSD. (Amusingly enough one of them is a windows CE device)
Thus, with what you describe, the argument can be made that the Linux driver model doesn't appropriately take into consideration the incentives and needs of hardware manufacturers.
Isn't this a rampant GPL violation? Why do we put up with this?
We are about to lose the war for general purpose computing due to insufficient GPL enforcement.
Isn't this a rampant GPL violation?
For example, an OEM can bash out low quality code which is hard to maintain, secure in the knowledge that they'll only have to maintain it for the year or two that phone is getting updates, and it won't have to survive any big kernel updates or be compatible with anything that isn't on the phone.
Upstream, on the other hand, wants to maintain device support forever so they want good quality code that they can get through kernel updates with a minimum of fuss, and they can't accept anything that breaks existing code.
So upstream won't accept the OEM's shitty patch, and the OEM won't pay for the engineering time to make patches that upstream will accept.
(Of course, some OEMs absolutely do violate the GPL, and then there's also the issue of binary drivers and blobs that violate the spirit but not the letter.)
Interesting, wonder where this puts Android's Dalvik VM (is the VM called this too? I don't remember). Edit: Not sure what the JVM Dalvik is based on is licensed as though.
They do not want to piss of their corporate masters..
Who is "we"? As in, who will pay the lawyers?
"a post-API programming model"
looks like it came directly from the source repo.
https://fuchsia.googlesource.com/modular/+/master
/----------------- Modular
Modular is the application platform of Fuchsia.
It provides a post-API programming model that allows applications to cooperate in a shared context without the need to call each other's APIs directly.
/-----------------
The thing is, this only works on countries similar to US where most people are on contracts.
In the rest of the world, where people are on pre-paid, we use our phones until they either die or get stolen, which is way more than just 1-2 years.
Between that and fragility of smartphones (mechanical damage, water damage), most people are bound to replace theirs every few years anyway.
My S3 is 4 years old now, and it is works perfectly fine.
When it dies, I will most likely adopt one of my Lumia devices as main one, or will buy a 2nd hand Android device, instead of giving money to support bad OEMs
Just spent it a new battery very easily for 7 € for the years coming.
However do be aware that your perception of what is slow changes as you use newer devices which perform better, making older ones feel slower than they did before - much like a shiny new work PC makes your home PC feel slow (or vice-versa) - so that may partly explain it.
Finally, I've just breathed new life into my ageing Nexus 7 (2013) tablet by installing the custom ROM "AICP" on it, which has made a huge difference to its performance & battery life. I recommend giving it a whirl on your SO's S3 - download from http://dwnld.aicp-rom.com/?device=i9300 (though you'll need to read up elsewhere about installing custom ROMs if you've never done it before)
Point is, I won't change my S3 until it crumbles to dust, if I can help it. I don't understand the obsession with buying the latest mobile every 1-2 years.
Also, the GC on older Android devices is a mess. It does not take many apps hanging out in the background before things slow to a crawl.
Is it still getting security patches? If not then it's not running perfectly fine.
2 years update + 1 security for mobiles that cost more than a computer is not something I am willing to pay a premium for.
Do you have an study available that I can refer to?
My smartphone's getting on for 9 years old; I don't think I'm a key demographic ;)
If so, then there might be greater pressure from phone rental agencies on the manufacturers to stabilise and fix bugs so that they can extract maximum value from the hardware.
To be honest, subjected to a "mildly aggressive & negligent" usage pattern, like mine, even an iphone will barely last more than 3 years and it will be in "far from good" condition after 1 year of usage!
Modern smartphones are simply not built to last unless you take exceptional good care of them. Or maybe it's just that me and the people I know tend to be "exceedingly violent" with our smartphones, dunno...
I think most people are more like me, but there are indeed a non-negligible segment of the population like you (and my sister) who just destroy their phones. Based on everything I've seen, it's definitely more of a you thing than a modern phone thing.
We are very far away from phones that you could use without screen protection and not see damages after 1-2 years. For a device that is supposed to be carried around all the time, modern phones show little resistance against scratches. But maybe that's just not possible to archive.
--
[0] - Unless you want to take a risk and get someone to replace you just the broken glass, a process which involves some manual fumbling with heatguns and UV-hardened glues. Or, unless you live in Shenzhen, where they'll replace you the whole phone front (with electronics and all) for cheap, if you give them your phone front (which they presumably fix up later and resell to the next person).
I dropped my Xperia Z1 Compact a bunch of times from that height, the screen is still fine...
> You accidentally sit on it, and you may have a screen to replace.
Solution: Don't ever put your phone in your back pocket.
I used the occasion to ask for a front for S3. She sold me one for somewhere around $50 - because I didn't have the broken one for exchange - which I later used to fix my SO's phone myself. It's not that hard after you've seen how the Chinese do it, though a little stressful - I had to use a needle to punch through a speaker canal, which for some reason wasn't hollowed out properly :).
I guess the reason it works in Shenzhen is because that's the place where the phones are made and recycled - they have tons and tons of parts for every model imaginable, both from factories and from broken phones. Given how many different phone models are out there, I doubt any city except a major metropolis could sustain this type of market.
That's a direct quote from the linked page. Unless you are suggesting that the authors of fuchsia have "insufficient tech chops".
If someone important enough says "decouple" and "monolith are bad" often enough, those arguments will be used to support more or less all changes as they already got leverage in the organisation.
The actual reasons could be something else, possibly as simple as they would like to control the OS, and possibly also that it's cool to write OSes.
Right, but they will never get my money if they don't deliver timely OS updates for the old model.
You're right of course that this issue has absolutely zero to do with Linux.
Which is why I would absolutely love to see a hardware vendor adopt paid updates, with a mission statement along these lines:
"we cannot believably promise a reliable progression of software updates, because too many before is have tried and failed. What we can do, however, is rewrite the rules so that we will have a much stronger incentive to follow through than or predecessors".
No matter how updates happen, if they do the effort will be paid for with money coming from the customer, one way or the other. Any payment scheme other than pay on delivery requires trust and that specific form of trust has evaporated a long time ago.
I believe he's talking about having a driver API. Fuchsia also runs its drivers in userspace, which is the proper design in a post-Liedtke world. (principle of minimality)
The update problem on Android is indeed a policy issue, not a technical one.
The fact you need Android device OEM's support is precisely the problem here, and that's mostly (mostly - admittedly not entirely) to blame on the way that manufacturers need to update their Linux kernels. Linux' monolithic nature makes this a major pain, especially since component manufacturers (for the SoC, touchscreen, fingerprint reader, camera sensor) implicitly require maintaining some non-mainline Linux. The manufacturer now serves as the central hub coordinating this 'mess' to update their devices. Mostly (again, not entirely) due to Linux, Android updates are dependant on manufacturers compiling update packages which are essentially full system upgrades. Each time they make an upgrade for a phone, they need to make an entire new device image.
The manufacturers have clearly shown to be incapable of handling this responsibility, both in terms of their abilities as well as their motivations. A more modular OS would go a long way in taking away these responsibilities, since it will be technical means by which responsibilities can be given to a better motivated third party. Clearly we should be looking towards a model more akin to Microsoft Windows, where there's a more stable driver API/ABI for drivers, that allows the OS' original manufacturer to update critical components and introduce new features without depending on an incapable/unwilling manufacturer. Make system updates not full system upgrades, but make the system able to update some components with reasonable confidence that things will keep on working. With such a system Google or the "Open Handset Alliance" - or depending on the openness of this new Andromium, others like the LineageOS community - can take care of updating phones instead of the device OEM.
In such a scenario you might still be stuck on graphics drivers from several years ago with serious rendering bugs, but at least security issues like Stagefright [1] and Dirty COW [2] can be effectively dealt with in a matter of days. That's a huge improvement over the current situation, where the majority of Android devices are still affected by both issues, years or months after their publication.
Imagine how unlucky we should be to be fully dependant on Asus or LG for software support on our laptops. But that's exactly the situation on our phones.
[1]: https://en.wikipedia.org/wiki/Stagefright_(bug) [2]: https://en.wikipedia.org/wiki/Dirty_COW
This is what we need with phones.
This is it; unless crucial apps (or some other necessity) only work with a newer Android version (which could push OEM's to update) they never will. Much better for OEM's to hope that you'll "update Android" through the purchase of a new phone.
So either Google fully controls Andromeda, as it does with Chrome OS, so it can update it (Google could probably still release an open source "Andromedium" version later on, like it does with Chromium OS), or it somehow forces all OEMs to update on time right from the beginning.
But the later sounds like a real pain from Google's perspective, as it would probably have to one day completely retract Samsung's license for instance, or sue it, if Samsung doesn't comply, and this could create all sorts of PR problems for the Google. Or Google would have to compromise and allow the OEMs to delay updates from say 1 month to 3 months or more. And then we'd be right back to square one.
I don't think there's a real practical solution to the update problem other than Google fully controlling the codebase.
> The joke of course being that linux is monolithic and googles new OS is a microkernel ergo more modular.
If you're suggesting that because the microkernel is modular that means "it should solve the update problem", I disagree. I don't think it would be much better than what we have now. Sure, it may be easier for Google, or say Samsung, to update their modules faster. But what about the other modules in the market? Will they be updated just as fast by noname OEMs? Probably not.
"a post-API programming model"
But pressing on how somehow manages to blame the lack of updates to android phones on the modularity of the Linux kernel. The joke of course being that linux is monolithic and googles new OS is a microkernel ergo more modular.
The quote is "...however. I also have to imagine the Android update problem (a symptom of Linux’s modularity) will at last be solved by Andromeda"
Its hilarious that he can somehow defying all sanity ascribe androids update issue to an imagined defect in Linux. Android phones don't get updated because for the manufacturers ensuring their pile of hacks works with a newer version of android would represent a non trivial amount of work for the oem whom already has your money. The only way they can get more of your money is to sell you a new phone which they hope to do between 1-2 years from now.
In short offering an update for your current hardware would simultaneously annoy some users who fear change, add little to those who plan to upgrade to a new model anyway, decrease the chance that a minority would upgrade, and cost them money to implement.
Its not merely not a flaw in the underlying linux kernel its not a technical issue at all.