Linked by Radio on Mon 2nd Jul 2012 19:15 UTC
Google It was time somebody cleared that up: the oft-decried skins put by OEM and operators on Android are not responsible for the lateness or lack of updates. The truth is that skins are easy, hardware drivers are hard. That is not to say skins do not have other problems, or that the problem is unsolvable, but asking for "stock" Android OS is not going to help on the update front.
Order by: Score:
GPL to the rescue!
by tidux on Mon 2nd Jul 2012 19:46 UTC
tidux
Member since:
2011-08-13

Ever notice that it's only the proprietary hardware drivers that have this problem? If your code is included in AOSP, it'll ship day and date with a new release.

Reply Score: 3

RE: GPL to the rescue!
by _txf_ on Mon 2nd Jul 2012 22:13 UTC in reply to "GPL to the rescue!"
_txf_ Member since:
2008-03-17

Ever notice that it's only the proprietary hardware drivers that have this problem? If your code is included in AOSP, it'll ship day and date with a new release.


If there was ever an argument for in kernel tree drivers this is it.

The hardware oems have the power to tell their suppliers to work with the kernel devs. Any porting efforts between versions are somewhat shared.

Unfortunately there is also the problem that the linux kernel arm tree complete mess ( I assume aosp shares the same problem) . With massive amounts of duplicated functionality and code...

Reply Score: 4

RE[2]: GPL to the rescue!
by Radio on Tue 3rd Jul 2012 07:39 UTC in reply to "RE: GPL to the rescue!"
Radio Member since:
2009-06-20

Unfortunately there is also the problem that the linux kernel arm tree complete mess ( I assume aosp shares the same problem) . With massive amounts of duplicated functionality and code...
Which shows that the problem is not "open vs close" drivers. The real root of the "problem" is hardware diversity. (It is more of a trade-off though; I do like the diversity and fast progress we see.)

Hardware changes are generally wide; getting open drivers would not help much, you can seldom iterate code from one CPU (or GPU, or the camera chip, or any other chip) to its next version or variant.

Reply Score: 3

RE: GPL to the rescue!
by 0brad0 on Mon 2nd Jul 2012 22:29 UTC in reply to "GPL to the rescue!"
0brad0 Member since:
2007-05-05

Ever notice that it's only the proprietary hardware drivers that have this problem? If your code is included in AOSP, it'll ship day and date with a new release.


The license itself is irrelevant for the situation. The drivers simply need to not be binary blobs but open and included upstream.

Reply Score: 4

RE[2]: GPL to the rescue!
by tidux on Tue 3rd Jul 2012 12:40 UTC in reply to "RE: GPL to the rescue!"
tidux Member since:
2011-08-13

It's not irrelevant, since only GPLv2 drivers can be included into the Linux kernel tree.

Reply Score: 2

Blaming the drivers!???
by sc3252 on Mon 2nd Jul 2012 19:48 UTC
sc3252
Member since:
2005-09-06

Not surprised one bit, that's why there is only one kernel release a year and half the stuff doesn't work...

Reply Score: 2

Good to get that cleared up
by No it isnt on Mon 2nd Jul 2012 19:53 UTC
No it isnt
Member since:
2005-11-14

Now, if we could just convince the manufacturers to use stock Android anyway.

Reply Score: 6

Drivers?
by viton on Mon 2nd Jul 2012 19:54 UTC
viton
Member since:
2005-08-09

Take a Sony for example. They have zillion of configurations of the same model (Sales Item as they call it). HW and drivers shared across several models.

http://talk.sonymobile.com/thread/42096?utm_source=Product%2Bbl...

My Phone SI is different in 7th digit so custom firmware is my only choice.
They just don't bother to build a version for me (so far)

Edited 2012-07-02 20:00 UTC

Reply Score: 2

Comment by Nelson
by Nelson on Mon 2nd Jul 2012 23:07 UTC
Nelson
Member since:
2005-11-29

I still think it contributes to the problem. Maybe not for point releases, but certainly for anything that breaks whatever hooks into the OS they call into to achieve custom skinning.

I just can't imagine that skins from say 2.3 work as-is with 4.0, things just undoubtedly have changed and it contributes (albeit maybe not the main contributing cause) to update delays.

Besides that, there is still the major implication that in my opinion I've yet to find a skin which in its totality does something good for Android that stock doesn't do. Small things that HTC and Samsung do are helpful, but as a whole, hell no.

In my opinion they just make things slower and are a net loss in UX for the consumer.

Reply Score: 3

Obvious fix
by Nelson on Mon 2nd Jul 2012 23:11 UTC
Nelson
Member since:
2005-11-29

The obvious fix to this is to strive to use as little binary blobs as possible. This means lobbying HW/chipset vendors to affect a change.

This is a systemic problem with implications beyond Android.

Reply Score: 3

RE: Obvious fix
by Radio on Tue 3rd Jul 2012 07:44 UTC in reply to "Obvious fix"
Radio Member since:
2009-06-20

Not gonna help. Hardware is too diverse, and code cannot be iterated between different variants or versions of chips.

Reply Score: 2

RE[2]: Obvious fix
by Nelson on Tue 3rd Jul 2012 07:55 UTC in reply to "RE: Obvious fix"
Nelson Member since:
2005-11-29

Merging drivers into the kernel tree will go a long way towards alleviating the problem.

Reply Score: 2

RE[3]: Obvious fix
by Radio on Tue 3rd Jul 2012 08:27 UTC in reply to "RE[2]: Obvious fix"
Radio Member since:
2009-06-20

No, you are just moving the problem.

Reply Score: 2

RE[4]: Obvious fix
by Nelson on Tue 3rd Jul 2012 09:45 UTC in reply to "RE[3]: Obvious fix"
Nelson Member since:
2005-11-29

Instead of a handful of eyes looking at it, a potentially large number of eyes can look at it and maintain it.

I guarantee you that Samsung's SoC drivers have a lot more interest than just Android engineers if they're opened up. You can get a groundswell of maintainers this way.

I never really understood the tying of the drivers to Android. Seems like a pointless dependency.

This way Android is free from driver cruft, and a Linux kernel version comes with an implicit guarantee of hardware support.

You can take 4.1, back port it to a Kernel revision with your drivers, and get functionality.

Of course, I'm just conjecturing here so if I'm mistaken I'd welcome the insight.

Reply Score: 2

No duh!
by cmost on Tue 3rd Jul 2012 02:26 UTC
cmost
Member since:
2006-07-16

Why upgrade an existing phone so that it will be useful longer when a carrier can simply flaunt an expensive new model with the latest software? My advice is to only buy Google phones such as the Galaxy Nexus...oh wait... Apple has made sure that can't happen anymore in the U.S. I hate Apple!

Reply Score: 1

Bill Shooter of Bul
Member since:
2006-07-14

I switched from Samsung's froyo to cyanogenmod's froyo. Samsung's version was slower and more error prone.

My good friend had a Motorola cliq. Moto froyo was terrible, cyanogenmod froyo decent.

So why does the manufacture's software suck so badly when it comes to raw performance? Drivers never really explained that, so of course we latch on to what we can see.

Reply Score: 3

WorknMan Member since:
2005-11-13

So why does the manufacture's software suck so badly when it comes to raw performance?.


Because they have to do stupid shit like make the widgets sing and dance, and make the screen have swirly effects when you drag your finger across it, in order to appease all of the mouth breathers out there who care more about how the UI looks vs how it actually functions.

Reply Score: 3

Comment by kaiwai
by kaiwai on Tue 3rd Jul 2012 05:37 UTC
kaiwai
Member since:
2005-07-06

I know, this whole thing could be avoided had the OEM's merged the driver code and kernel modifications into the main tree and thus it would therefore be possible to pull on the latest Linux source code, compile it along with Android dependencies and voila everything works. IMHO I'd love to believe that it is because hardware drivers are hard to write but I'm more cynical in that what I see are hardware companies who simply don't value software. Samsung being the best example of that - throw the hardware out to the market, put next to no effort when it comes to the software then hope that by hyping up the hardware specifications it can make up for the half-assed effort when it comes to updates and upgrades.

IMHO like most things, the anger regarding the crap Android support (upgrades and updates) will start in the geek world and eventually roll out to main street with Windows Phone 8 being the most likely winner. Sure, I'm an Apple fanboy but I'm realistic given that I can see Windows Phone 8 threatening Android based on the ability for multiple vendors to offer different products at different pricing levels. Add to that the Windows NT core, a stable ABI and API which pretty much means drivers can be left untouched between upgrades and updates I could see OEM's ditching the development clusterf-ck that is Android's development model.

Edited 2012-07-03 05:39 UTC

Reply Score: 2

RE: Comment by kaiwai
by WorknMan on Tue 3rd Jul 2012 05:59 UTC in reply to "Comment by kaiwai"
WorknMan Member since:
2005-11-13

know, this whole thing could be avoided had the OEM's merged the driver code and kernel modifications into the main tree and thus it would therefore be possible to pull on the latest Linux source code


I dunno if this is possible, since the hardware vendors are probably using some proprietary code in their drivers, such as HTC's beats audio stuff. And I think I read somewhere that some of the tweaks they do to the stock camera used some licensed code as well.

IMHO like most things, the anger regarding the crap Android support (upgrades and updates) will start in the geek world and eventually roll out to main street with Windows Phone 8 being the most likely winner.


Why would you say that, since Microsoft has already said that Windows Phone 7 users will not be getting the Windows Phone 8 upgrade? Seems the WP7 crowd is in an even worse spot than the Android crowd.

Reply Score: 2

RE[2]: Comment by kaiwai
by kaiwai on Tue 3rd Jul 2012 07:38 UTC in reply to "RE: Comment by kaiwai"
kaiwai Member since:
2005-07-06

I dunno if this is possible, since the hardware vendors are probably using some proprietary code in their drivers, such as HTC's beats audio stuff. And I think I read somewhere that some of the tweaks they do to the stock camera used some licensed code as well.


Then end users will have to accept that 6 months after they buy their phone they might as well smash it into small little pieces given that'll be entirely useless after that point. Like I said, here we are in 2012 and as an iPhone I'm still receiving updates - but it seems that end users with an anti-Apple friend are more concerned with 'sticking it to the man' than getting the best value for money when they purchase a $1000 phone - yes, a HTC One X will set you back NZ$999 to buy the phone outright:

http://store.telecom.co.nz/mobile/pay-monthly/htc-one-x

Why would you say that, since Microsoft has already said that Windows Phone 7 users will not be getting the Windows Phone 8 upgrade? Seems the WP7 crowd is in an even worse spot than the Android crowd.


Windows Phone 7 devices were never promised to be able to receive an upgrade from Windows Phone 8. Windows Phone 7 is a platform, then Windows Phone 8 is a new platform - the hardware specifications and requirements are different hence you don't receive an upgrade. With that being said you'll receive Windows Phone 7.8 which is a damn sight better than Android vendors that can't even be bothered providing an upgrade form 4.0.0 to 4.0.3. Heck, here in New Zealand we're still waiting for Android updates to the latest minor revision.

Edited 2012-07-03 07:40 UTC

Reply Score: 2

RE[3]: Comment by kaiwai
by WorknMan on Tue 3rd Jul 2012 17:56 UTC in reply to "RE[2]: Comment by kaiwai"
WorknMan Member since:
2005-11-13

Like I said, here we are in 2012 and as an iPhone I'm still receiving updates - but it seems that end users with an anti-Apple friend are more concerned with 'sticking it to the man' than getting the best value for money when they purchase a $1000 phone


LOL, well you're getting semi-updates anyway. If you're on an iPhone4 for example, no Siri or turn-by-turn nav for you.

And anyway, most of the features introduced in iOS6 are things Android users have had since 2009-ish, and you want to talk about value? As it seems that iOS is generally 2-3 years behind on features, even if Android phones don't get any updates from this point on, they'll be light years ahead of iOS even two years from now, so have fun with your toy iPhone and your gimped updates ;)

Reply Score: 2

RE[4]: Comment by kaiwai
by kaiwai on Wed 4th Jul 2012 08:24 UTC in reply to "RE[3]: Comment by kaiwai"
kaiwai Member since:
2005-07-06

LOL, well you're getting semi-updates anyway. If you're on an iPhone4 for example, no Siri or turn-by-turn nav for you.


Which are hardware limitations (lack of proper noise cancelation makes siri virtually unusable on phones prior to iPhone 4s) rather than vendors deciding that pushing a hardware upgrade will help their bottom line. For me I'm happy if the vendor says, "ok, we'll provide you an upgrade but here is a list of things that you won't get because of hardware limitations" because for me the more important part is have a safe, stable and secure operating systems first and foremost before any of the bells and whistles.

And anyway, most of the features introduced in iOS6 are things Android users have had since 2009-ish, and you want to talk about value? As it seems that iOS is generally 2-3 years behind on features, even if Android phones don't get any updates from this point on, they'll be light years ahead of iOS even two years from now, so have fun with your toy iPhone and your gimped updates ;)


What features of great importance as missing? maybe Android vendors can provide music management software for Mac that doesn't suck, maybe proper synchronisation software for Mac users so that we're treated like first class customers (heck, if Microsoft can provide 'Windows Phone 7 Connector' I'm sure Samsung/HTC can do the same).

Again, the issue isn't about features but about having a safe, secure and stable operating systems - heck, I'm happy to forego any features due to hardware limitations as long as I know that the phone I am running is secure and stable. You keep ignoring EVERY single post I've made in the past and make an assumption about me based on ONE. Great, thanks for letting me know what OSNews.com is really about - lazy people who can't be bothered doing their homework.

Edited 2012-07-04 08:34 UTC

Reply Score: 2

OEMS Do alot more than skin Android
by TheKurrgan on Tue 3rd Jul 2012 06:13 UTC
TheKurrgan
Member since:
2010-07-28

Skinning isnt an accurate term. Take Samsung...They modify most of the front end stuff the users interact with and see... from the dialer down to the camera..the only thing that remains the same is the underlying base linux platform..
As to drivers, there is no way you are going to convince me it takes 7 months to get this stuff working and tested when the boys over on xda are already pulling it off without the benefit of source code.
Not to mention the sheer bloat they add to the device.. Motorola being the most obvious of the bunch.. Still no ICS on any GSM device they have yet..

Reply Score: 1

Radio Member since:
2009-06-20

The guys at XDA can't do much without the code dumps by vendors. And, as the article righfully points out, hardware support is always the sore point. The whole interface works at the first alpha, but no wifi, no camera, no hardware acceleration, etc.

Reply Score: 2

Nelson Member since:
2005-11-29

I've seen XDA guys do a lot to be honest. The only thing that usually holds them back is kernel source releases, but you can retrofit ICS on older kernel sources for the most part.

They're not to be underestimated. I really sincerely doubt that OEMs have any legitimate excuse for these delays (or sometimes lack of updates altogether).

How anyone can defend an OEM, especially one as blatantly negligent as Samsung is beyond me.

Reply Score: 2

Comment by Trebus
by Trebus on Tue 3rd Jul 2012 11:03 UTC
Trebus
Member since:
2012-04-11

I don't understand why there are so many changes in android releases regarding drivers.
Changes between 2.3 and 4.0 were big, but minor releases like 4.1 should be easier to implement. I'm not expert on Android kernel but rewriting drivers for each release sounds strange to me.

Reply Score: 1