Bringing the Android kernel back to the mainline
lwn.net
lwn.net
You say this like it is unique to android, iOS 12 was basically the same. And I can say from friends experiences, its not always true for all android phones.
At any rate, the big issue I tend to hear about Android phones getting updates is "my Android phone isn't getting updates." My iPhone 6 shipped in 2014, and iOS 12 actually ran on 2013's iPhone 5s. How many Android phones that shipped before 2016 are getting Android P? Are there Android phones that shipped in 2016 that aren't?
It's not universally true. It's mostly true, with a couple of outliers (namely iOS 9 and iOS 11). Most of time, major iOS upgrades slow down older hardware.
I wouldn't necessarily have a problem with this, if not for the fact that iOS downgrades are literally impossible (outside a small window of time). Install an update and discover your phone is too slow? Either learn to live with it or buy a new phone.
Or you could just restore from a backup, possible at any time.
https://medium.com/metodixtech/ios-how-to-downgrade-and-save...
> You can downgrade (If you don’t have Shsh blobs saved) only until Apple is still signing the old software.
Saving SHSH blobs needs to be done in advance, while the iOS version you want to install is still being signed by Apple. With blobs, you used to be able to use a replay attack to force a restore. This doesn't work anymore due to the addition of NONCE, except in very limited and not particularly useful circumstances (you can move to an unsigned iOS version IF you're already Jailbroken AND if SEP is compatible).
If you know a way around this system, please do share. The Jailbreak community will love you for it. :)
Apple does everything in their power to make downgrading iOS impossible outside of a narrow window. I suspect this is also why we haven't seen any actual, definitive speed tests between different iOS versions. The discussion always devolves into "this feels slower" or "I remember my phone used to be like this," because no one can actually install an older version to test with.
As to your original point, though -- yes. I'd certainly prefer it if Apple didn't make downgrading so difficult, even if it's just on general principle. I've rarely been tempted to downgrade, but iOS 11 could be pretty clunky on my iPhone 6 compared to its predecessor. (I think 11.4 finally smoothed all that out, but that came out literally a week before iOS 12 was announced!)
Yes, it is, just not this time because of all the backlash Apple has received over the past few years over this issue. Let's see how iOS13 and 14 do, but my guess is they will be slower still.
So please don't imply iOS updates brings iDevices "ever closer to unusably slow" because that's very non-factual.
Except those who Apple was "helping" "preserve battery life" by purposefully slowing the clock speeds on updates without telling them? I've often wondered how many people went out and actually purchased an entirely new phone due to this unannounced "help" vs slapping a (relatively cheap) new battery in it?
What Apple did is to prefer to have people's devices run slower compared to breaking them.
What they did wrong was keeping quiet about it. I ain't ever disputing that, it was a really bad decision to hide it.
The reasoning to do it however has solid foundations in physical reality. Even I that I know nothing of electronics went out of my way to read about it and asked several electronical engineer acquaintances of mine and they all said Apple did the right thing by slowing down the devices.
> So please don't imply iOS updates brings iDevices "ever closer to unusably slow" because that's very non-factual.
Because THAT was non-factual. They have done it, and for some it was "unusably slow." Whether the reasons were electrically sound wasn't in dispute.
IMO the original statement implied some ill will from Apple -- a myth that has been debunked pretty quickly. That's what I was arguing against.
Say what you want about Apple pricing and some bad decisions along the way, but their approach to security, hardware build quality and overall experience of using their device over longer periods of time is very good and certainly beats Android devices.
I wish there were good alternatives with open platform but there are none currently and I don't think there will be any in the next few years.
P.S. I switched to iPhone about a year ago and I don't really miss Android.
On the other hand when I buy a laptop or an access point I just do minimal checking of supported hardware in case there's something that's very exotic and then I get to install whatever software I want for however long I want to keep the hardware in service. For the HN crowd this should be worrying. Mobile is the #1 hardware platform by unit volume and there's no way we can actually target these devices sensibly.
Bringing in strictly theoretical supposition which is directly at odds with what's historically been a very solid track record from Apple isn't doing your argument any favours. Unless I misunderstood you.
Apple laptops are also in a pretty bad shape. Eventually, they may be usable as laptops for other (free) OSes with sufficient reverse engineering, but currently they can't. That they can be used at all is quite accidental due to things outside of Apple's control and other historical factors.
It's not about if I can buy a cheap FreeNAS rig -- an i5 CPU and 10-year old motherboard with 16-32GB of DDR2/DDR3 RAM -- and gradually add WD Gold hard drives to it. It's not about if I can use Syncthing and a command-line password manager. It's not about if I can use PostmarketOS or LineageOS and thus only buy Android-enabled devices (yay Linux freedom?).
I can do all that. But it requires more manual management. And I just don't have the time and energy for it.
It's strange to me to imply that the HN crowd are some sort of world-changers that never have financial struggles and live in beach houses a la Iron Man style with 3x independent gigabit fiber links and 500 sq.m. of home labs that rival Mythbusters' space -- and are constantly busy disrupting an area.
Truth is, even though in principle you are correct -- and even though I really would like to only use free [as in freedom and not a free beer] hardware and software -- the reality is that we all have jobs to do. And most of us actually love the people we live with and would want to spend a chunk of our free time with them. We all would love to get a normal amount of sleep and invest in the knowledge necessary to get proper nutrition because we're literally a hugely complex chemical compound and we better put the right chemicals inside of us...
...etc. etc to infinity., I can go on all day and night but I am pretty certain you got the point.
The HN crowd is certainly much more aware than many other crowds. Doesn't automatically imply they have the means to change a lot of things. Trust me, I'd like to live like Tony Stark and invent a ton of stuff that can change the world -- that includes his house and a lab -- but I am gradually coming to terms with the fact that I'll very likely stop at having 7-10 profitable consultancies and/or lifestyle businesses that will give me a peace of mind even after retirement.
Life is short and many of us don't want to work 24/7. More power to the people who can maintain a good living AND be inventors and disrupters. I have big respect for them.
My point is that if the world's #1 computing platform only has that choice then we lose the ability to get some kinds of innovation driven by the few percent that care and have the time to tinker. And HN has a much larger proportion of the kinds of people that will want to do that innovation or at least value that it's possible. We wouldn't have gotten Linux if Linus couldn't develop on his hardware.
But maybe we've just been spoiled with mass-market general-purpose hardware up to now and this is the new normal. I shudder to think that but maybe it's true. At this point I don't think I'd much care for a smartphone if I didn't need it for work. And it's the stuff of nightmares for me particularly if that was also the case on the PC/laptop side of things.
I agree that it's rather horrifying what we settled for these days. The world to me is a lot darker compared to my student years back in 1997 to 2001 when I played Quake3 for days on end, without sleep, with only WC and food breaks -- and when I was coding my heart and brains out on things I believed could shape the future world.
These are the times I'll dearly remember until the end of my life. And nowadays almost nobody seems to be wanting to make things better. It's saddening and extremely discouraging. I get it and I agree with your overall premise.
What I was mostly saying is that those of us who had wide-eyed naive optimism for the future and were there when the internet started gaining steam are now anywhere between 30 to 50 and we can only dream of the ages past when we could do the things you described without any other worries.
In the end, I am just pointing out that these past life phases are long gone and aren't likely coming back for the most of us. And I'll say it again: I have a big respect for those who still manage to truly innovate and disrupt.
I agree and identify with this. The reason I point these things out here is that the kinds of people actually doing the leg work on these platforms are on the site. And in some cases if they did a few things differently (e.g., upstream the drivers much earlier in the SoC bringup) then maybe we could actually fix this. I'm not nearly as pessimistic about the situation as you :)
https://www.computerbase.de/preisvergleich/?cat=umtsover&xf=...
Any Apple device is a specific combination of hardware and software that Apple chooses when to stop supporting, and you have very little recourse. Apple has generally been better at providing support to older devices than Android (on average), but in the end the situation is fundamentally the same.
Outside of that I am in full agreement with you. The mobile ecosystem is basically a dystopia where we have zero recourse as you said.
Released 2008. If I get an x86 laptop from 2008, I can install a modern Ubuntu on it with approximately 0 effort. If anything, it'll usually be better than cutting-edge hardware because the drivers have already been developed and released in a stable Linux version. iOS still loses this comparison.
Its frankly shocking that the Allwinner A10/A20/A64 (which can run Win10!) /H3/H5/H6 has nearly complete mainline kernel support, whereas nearly any of the smartphones made since 2008 can't boot mainline Linux and drive their cameras, screen, GPS, etc. Its a huge failing of the industry.
With regard to supporting tablets, most of the older Allwinner based tablets have feature parity between the mainline kernel and the vendor BSP kernel: https://linux-sunxi.org/Linux_mainlining_effort
Edit: actually, when I say 'latest' I mean 'latest available for the moto g'. I'm not 100% sure that's the very latest version that exists.
It's not. You're stuck with an Android that's 2 versions behind current and are still using the original kernel version that shipped with the device.
Take a copy of a standard 2008 version of Ubuntu desktop and try and install it on a 1998 laptop. I doubt it’d run at all, not without ditching the default desktop.
That's something for the users to decide. Imposing artificial restrictions to software, including forced obsolescence, is never a good thing.
Meanwhile I have a 5 year old 5S that I use while traveling which runs iOS 12.1 swimmingly, and keeping older devices running longer was a major topic discussed by Lisa Jackson at the last Apple keynote. I fully expect that this old phone will run iOS 13 as well, and I expect that current iOS devices will have increasingly longer usable lifespans than 5-6 years. There isn’t anything close in terms of manufacturer support on the Android side of things.
In terms of keeping phone hardware useful through an alternative OS, you may also want to keep an eye on PostmarketOS [2].
iPhone 4 is 8 years old so not sure I see your point.
This thread started with a comment about mobile phones in general being locked down to a specific kernel/os/software-combo, and that the upgrade paths is at the mercy of the vendor (unlike PCs).
Both Apple and Android phones are locked down. Who does it in the most convenient way is irellevant to the argument made.
The OP's comment was that any mobile devices these days, both Android and iOS are locked down black boxes. It wasn't specifically criticizing just Apple.
Are you new here?
But it's easier to flag people as fanboys. <shrugs>
Since you are having trouble with getting what I said: I am saying that Apple in my eyes is the lesser evil of only two options. It's a very practical and time-saving decision to use Apple tech. But call it fanboyism if you like.
Windows CE 6.0 was supported for twelve years.
It was not always the case and for various reasons (mostly the much heavier integration constraints of different components) it is harder to make on a phone.
It may sound strange, but I think that redemption will come from efforts similar to the PiPhone [1] that allow to create devices from different manufacturers that were not specifically designed to work in a tightly integrated way.
[1] https://learn.adafruit.com/piphone-a-raspberry-pi-based-cell...
Buy a Pixel or any other phone that supports AOSP (Sony does too, with some caveats) and install plain AOSP.
It's not perfect as you need a bit of infrastructure to compile it yourself and keep OTA updates. But it's the most practical secure and privacy-respecting option, I think.
In older times, kernel patches for exotic hardware often tied the user to a specific version - of course a very stale one... Let's not go there again !
My friends seem to get a year or so before the SoC desolders from the motherboard, causing the device to bootloop, or the battery fails, or one of a million other things. Among us, there are a few dozen Pixels that are unusable due to their hardware defects.
Meanwhile, both of my old Galaxy S4's is going strong, and ditto for all but one of my LGs (one had its charge controller start smoking, LG repaired it).
I've avoided Samsung devices (including Galaxy Nexus/Nexus S) because the girlfriend has had the last 4 Samsung devices fail or become completely usable right at the end of the warranty (+/- 2mo) running completely stock. For those that became completely unusable it was usually pitiful battery life, the others became too slow to function on stock roms that I suspect they failed due to internal storage wear. Not even custom roms could save them.
I keep my devices a long time, and frequently repurpose them after they are no longer my primary device. Non-Samsung "Pixus" problems are overblown, except Nexus 6 AMOLED burn-in which is annoying but didn't present itself until it was used daily as a HUD.
Your choice in devices of the Nexus/Pixel series is very lucky, you avoided the defective models nearly entirely. I have no faith that I will be similarly lucky.
However, it still has the problem that it cannot realistically update beyond Android 7.
A smaller surface area with a stable HAL would separate the proprietary / often bad board support code from the kernel itself and allow core changes to progress without requiring software-adverse hardware manufacturers to keep up.
Whether or not this is a good thing is certainly debatable, but I'm not convinced the Linux "get to mainline or get wrecked" approach has stood the test of time well.
"Your WiFi only supports Android Kernel API 3.9. You need 7.0 to run this version of Google play".
The Linux kernel already has a stable user space ABI. If your hypothesis was valid, you would be able to upgrade the Android userspace on an old kernel with no problem. But you can't -- and that's with just one well specified ABI with a standardized, portable subset to worry about.
There are builds like this working on many devices right now: https://forum.xda-developers.com/project-treble/trebleenable...
It's a huge improvement (a lot of bugs are in platform layer, including the media/stagefright stuff), but not yet perfect.
By separating out the driver interface using Treble, you can update the kernel and android versions from upstream without worrying about driver integration/updates.
Google is finally facing the issue that regular consumers aren't caring to update anymore, specially now that devices are quite usable for several years.
So if they want to bring new OS versions into the market they really have to force OEMs to do it.
Hence the new GSI concept, finally adding update clauses to the Play Store usage agreement, and now upstreaming kernel changes.
In the end, you will never be successful doing so, be sure 99%. But whether they understood the bigger picture of things or not, technical needs need to supersede business needs, or that tech business will not work.
There's an upwards trend of people DISABLING updates because they tend to break tools they use in daily lives.
That's true, but regular distros are also faced with the same dilemma, and you see both cases. RH will patch a kernel to death ship of Theseus style for a decade, whereas Canonical offers newer stable kernel releases (although they also maintain the original kernel that the distro shipped with). Canonical leans more towards updating to a newer kernel version though.
>There's an upwards trend of people DISABLING updates because they tend to break tools they use in daily lives.
The general public is affected more by questionable updates higher up in the stack. I doubt if they interact directly with the kernel.
Things like bluetooth, OpenGL drivers and Wifi drivers are usually the pain points which love to break (or more accurately: break in a different way) when upgrading them. This causes those endless "I've updated my iPhone/Android phone and now it doesn't work with my car anymore!" posts. It's usually preferrable to keep the things working as they are, since we humans accept that more easily.
Newer Sony devices got a major version bump from 4.4 to 4.9 with their Pie releases:
https://developer.sony.com/develop/open-devices/latest-updat...
I wonder if the major version update for Sony's 9.0/Pie was due to a Qualcomm BSP change, or if it was solely their initiative? I think the reason for typically not doing major kernel updates may be down to sticking with reference stuff from BSPs. (I don't think they're offering any big updates, not kernel or Android major versions, for their Mediatek stuff. I think that might be typical though.)
Kind of cool, anyway, to move from one LTS kernel release to the next. I wonder have any other OEMs made the same move?
[1] https://github.com/WebBluetoothCG/web-bluetooth/blob/master/...
Google should go one step further and require upstreaming hardware drivers.
Unfortunately this problem will still exist with the proposal in the article, manufacturers will still be allowed to ship out of tree code. Being able to boot a mainline kernel on your device is practically useless if the code necessary for display, input, audio, etc are out of tree and thrown over the wall by the manufacturer with no intention of keeping it up to date.
I don't think anyone is thinking of a GNU/Linux desktop environment when they think "Android runs Linux!", they are quite literally thinking "Android uses the Linux kernel." They are not wrong.
I'm curious about what is there to celebrate in some huge corp using some free software in a completely cornered use that gives little to no freedom to its users.
I'm sorry if my points are not clear. As it has been evidenced english is not my first language.
Huge amount of money poured into development of said opensource software - including the patches in the article you're commenting on.
Major opensource projects are (and have for years) receiving most contributions from developers in Microsoft, Google, Intel, RedHat, Pivotal, and many others.
> As it has been evidenced english is not my first language.
No problem, I'd say that your English seems great, better than some native English speakers I know. English is my first language and it's easy for me to be unclear :D
ChromeOS is also "Linux" in this sense, because of Crouton.
Official NDK APIs are ISO C and C++ standard libraries, a couple of portable libraries like zlib and Android specific APIs.
As of Android 7, any application that tries to link to on-device libraries or do calls that aren't whitelisted just gets killed.
Yes one might successfully do Linux specific calls, but given they aren't part of the stable Android NDK API, any OEM is free to bork those attemps.
In practice, being based on Linux doesn't mean anything for app developers.
Only for those doing system space development, which are Google and the OEMs, noone else.