Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

I don't like this argument, because Android is not developed openly and the kernel itself is a fork which lags behind the mainstream Linux development until Google implements the changes, which users see when they throw away their phone because Samsung/HTC/Xiaomi/Ulefone/Whatever doesn't want to update the phone or Verizon/ATT/Telenor/T-Mobile, etc., doesn't want to push the update because they branded the phone so that means its theirs but not their responsibility.


sort by: page size:

I fail to see the relevance of Samsung not updating their phones to Google not wanting Android to be forked. If Samsung had forked Android, they still wouldn't update old phones.

I consider google with android to be a similar position to the linux kernel on my servers. I don't expect any of the kernel team to produce a patch for my 2.6.18 kernel I am running on a RHEL 5 system, I expect Red Hat to do that.

Why doesn't Samsung / LG / HTC manage Long Term support for Android versions, back port the patches and roll them out? Alternatively why don't they all pool together and manage an LTS version for customers.

It seems crazy that the company that has a relationship with the customer doesn't have to support the customer, and everyone instead blames google who wrote the code. The android vendors could back port, create alternative patches or simply make the device able to be updated to a more recent version.


Google has shown it's willing to force the issue on other parts of Androids -- particularly shipping Google Play with default apps. You can make an argument that's anti-competitive, or against the spirit of Open Source, but regardless, Google is willing to do it.

Custom kernels definitely aren't the only reason why the Android update situation is bad, but they're also definitely a nontrivial part of it. A hardline policy that kernel patches had to be pushed upstream if you wanted to brand as Android with Google Play would probably go a long way towards improving that situation for everyone.

Qualcomm would either say yes or all of their proprietary chips would become nonviable for the smartphone market.

Linux itself can't force that issue because they don't have an attractive brand and suite of basically mandatory proprietary services to take away from smartphone designers who say no. The only thing Linux can do is make life more hellish for people maintaining userland drivers, which companies don't care about because they're not interested in maintaining their stuff to begin with.


Why are you blaming Google, and not Samsung, HTC, LG? Aren't they the ones who produce software updates for their phones?

I really don't see how Google is stopping them from updating their handsets.


Google doesn't control Android after they release it. It's open software (which is why Samsung gets to "skin" it the way they do) and Samsung could add anything they want or even rip bits out. It's not Google's decision.

Edit: this is a lot of downvotes for no comments. What's wrong with my comment?


Blaming Google for not updating your non-Nexus Android phone is like blaming Linus Torvalds for not updating your cisco router from your ISP just because it uses linux.

Android is based on AOSP, which Google does not control because of the license, not sure why especially on HN, people do not seem to understand or want to understand how open source licensing work.


I'm fairly technical, I do a reasonable amount of programming and I've been using various flavours of Linux for well over a decade, but installing vanilla Android on a phone where the manufacturer doesn't support it is just ridiculous. There was a time when I'd be fine to issue endless arcane commands during an install process, or I wouldn't mind manually partitioning my drive and setting mount points, or getting stuck into some X config file to try out some new window manger etc., but now I just want things to work. And that's if you are supported by CyanogenMod, if you aren't it's just a recipe involving random .exe files from "HaKerD00dz" with animated gif avatars from some PHP forum that you have to trust. It's a total mess.

The android OS ecosystem is totally broken on this level by the carriers who have every interest in making the higher cost phones more attractive by not updating the Android version on lower cost phones and not updating the version for existing customers. This issue is exactly why Linus' rant resonated with people and Engadget's position attracted so much fire. Nobody should be on an old version of Android. I've got my phone up to Android 4.0 after a stupid custom process from the manufacturer (which only ran on Windows) but I am fairly certain it's the last official update I will see for it even though it's more than capable of running newer versions. However, unless I can get a source more reliable than some php forum for updating it myself I am unlikely to update outside of this manufacturer version.

I really hope Google's Nexus intervention clears up this issue and finally turns the telcos into dumb pipes, but I am afraid it will only make the carriers offer an up-to-date Android on sale, which then won't be updated later. This is why the ecosystem for installing vanilla Android needs to be seriously improved and Google needs to step up to their responsibilities to provide automatic updating to carriers or a really properly supported community for mods.


One of the annoyances I've had with Android, from a new consumer's point of view, is that it's presented as this monolithic OS that's the same across every phone. But once you do the research, you find that it's really not. Except for the Nexus line, there really isn't a "Google Android" experience. When you buy an Android device, you're really buying HTC's, Samsung's, Amazon's or Motorola's Android. Every device has different capabilities. Some ship with different Google services out of the box, others ship with their own internal apps. Google's Android strategy is that every manufacturer can make their own Android shell, without placing any requirements on the vendors as to what version of Android they're using.

It's a great thing that there's all this choice for the devices. It's a great thing that Android allows this kind of freedom. But it's led to a lot of issues for Google and for developers.

The problem that Google has is that they've effectively lost control of Android. They can't force manufacturers to use the latest version of Android. So they're left with situations like this, where the vast majority of Android devices are running an old version of the OS, and will never be updated to the newest version, because the manufacturers just don't want to[1]. So the result is that they have to support around 4 different codelines at the same time(ICS, HC, Gingerbread, and Froyo).

It's a problem for developers because your display code might not look right on a new device with a weird screen resolution. Or you might need API calls that are only in 4.0, which would lock you out of 90% of the devices right now.

No, the alternative is for Google to exert control over the device manufacturers and state that if they're going to be using the Android OS, they need to support and update their devices to the latest version for at least 2 years after the phones are released.

[1] There is a good economic argument that patching phones that are 18 months old with 24 month contracts about to be up just doesn't make sense, but honestly, it comes down to that the manufacturers just aren't willing to do it.


It's not like manufacturers don't want the strong brand recognition of being well supported and giving their owners the latest stuff. That helps them sell future phones as well, by gaining market share.

The problem that Google apologists/Android fanboys forget... is that deploying an Android update is a HUGE cost to manufacturers for customization, testing, and deployment.

Google ships endless new versions without any respect to this, and leaves most of the work, and the cost, on manufacturers, who already had thin margins to begin with. Especially on entry level phones, hardware costs have been a race to the bottom.

These people are afraid to point out that Google has created an OS that's hard to update universally, requires a custom deployment for each and every hardware model, and is shipped without working hardware support for most of the hardware using it or even a modicum of stability even on their own reference platforms.


Google is interested in building Android as a platform. Having 80% of your install base stuck 4 versions behind[1] is a crappy way of doing it. Even after they've moved more and more of the platform into the Play frameworks you're still leaving users without a bunch of improvements to the core platform, not to mention security fixes. iOS is miles ahead on this front exactly because it controls the hardware. That Google doesn't do the same now that it also controls the hardware seems short-sighted.

Building a 150$ great phone would allow them to set a feature/quality floor for the market. If they forced their suppliers so the hardware in these phones is properly supported upstream, targeting new versions of Android should be pretty easy. When Ubuntu launches a new version it doesn't need to go and retrofit it to the thousand different types of laptop out there. The state of Android though is that the GPU/Camera/whatever drivers are binary blobs locked in to a specific kernel version.

[1] https://developer.android.com/about/dashboards/index.html


The biggest problem I see is (and there may be other biggies, but this is the one that has bitten me), is that device support in Android kernels never gets upstreamed to Linux. Not necessarily due to GPL violations, but because even though the device source tree is published, there's no one willing to shepherd the changes upstream (and many vendor changes are low quality, so it would be a lot of work). Typically even a Nexus device is stuck on the specific kernel version that it was released with.

Google is a little better on the kernel side, but in other ways, AOSP is even worse. There's lots of good stuff done in Cyanogen and OmniROM, for example, but there's no way to get stuff into upstream AOSP. Google just pitches something over the wall once a year and ROM developers have to rebase or re-implement their ROM features.


The real problem with it is Linux. Here's a few facts:

The Kernel has no stable ABI for drivers.

Manufacturers only ever develop a driver for their chips once, and then send that to the OEM. They never update.

The Linux Kernel LTS gets 2 years of updates, Google's fork about 4.

From the day a Kernel is released, to the day it ships in a phone, usually 2 years are spent integrating the blobs and code drops from the chip manufacturers.

On every kernel upgrade that breaks the ABI, those 2 years would have to be redone from scratch.

Linux can't mainline support for every exotic piece of hardware that ever shows up in a device.

Manufacturers can't keep maintaining several developers to update every single chip they release.

Google can't keep Android on 6 year old kernels forever.

Now combine these facts, and you'll see the issue.


Android OEMs love it when people keep blaming Google for phones not being updated and as long as this happens this issue will never be addressed.

Do you know how open source works? Google has no control over OEM phones or the carrier approval process. Period!

The only reason OEM Windows phones can be upgraded is that OEMs agree to that level of control by Microsoft. Have you ever noticed their are few Windows phone OEMs? LOL Google could try to assert this kind of control on OEMs but Samsung would bail as soon as possible for sure. They would fork AOSP or move to their own OS.


Google never forbid updating phones... They forbid forking Android.

I keep wondering why nobody just supersets Android. Even just having an Android phone which is designed to be repairable and have drivers in the kernel tree so it isn't tied to a specific kernel version, people would pay for that.

And then on top of it you can add all of your Google-alternative libraries and services, which need not be perfect immediately to get people to use it because they can start off running Android apps and buying it for the open hardware. But as you get more users, the software improves too.


Somewhat related, but in other thread two weeks ago people complain Google has too much power over Android ecosystem: https://news.ycombinator.com/item?id=24917918

Now, here people are suggesting Google should somehow update the old Androids.

Be damned one way or the other.


> Android device vendors don't care because either way they will stop updating their kernels after a number of years

This one seems like a big problem to me. Maybe the handset manufacturer doesn’t care because they already made their profit, but this pushes the support burden onto app developers (including Google itself) who have to maintain support for these old Android devices that the manufacturers don’t care about.

This seems like a real issue to me, is there something I’m missing?


It's even worse than that. The device manufacturers often can't update the kernel on their own; they need cooperation from their peripheral vendors. I see a lot of Android customers criticizing device vendors for fragmentation and failing to release OS updates. But Google really created the problem by failing to build in stable APIs for a hardware abstraction layer and loadable device drivers. Unfortunately the only ways they could really fix the problem would be by forking Linux or building a new kernel from scratch and those would be huge efforts.

That's what this article neglected to target: The dozens of proprietary versions of Android that are dribbled out by each carrier for each phone.

I'd like to know how this failure happened. Did Google fail to create a proper hardware abstraction layer and driver model that would allow people to update the OS immediately upon release, as long as the driver model didn't change? Even with the crapware installed by telcos, why can't people update the OS? There's plenty of shit installed on PCs by vendors, but it doesn't all just break if you install a new version of Windows.

next

Legal | privacy