[charlesdenault]

I believe the fragmentation issue is going to take a lot longer to solve than the author leads on. Android is rooted in its open nature, and it's what caused the proliferation of the OS in the first place. It's going to take much longer for OEMs to stop shipping bloatware on the devices, or Google will effectively fork the OS simply because the OEMs can't keep up. Look how long it's taken Microsoft to get their OEMs to comply (but I do believe Google is a different beast in this regard).

[viraptor]

Depends on the contract really... do we know what terms do the OEMs sign? If Google is free to change the terms on renewal, then they can simply state "must provide updates for X years, up to Y days after upstream, cannot change Z - or you can't call it Android". That would either cause an instant solution or instant full-OEM-forks.

[pjmlp]

Fragmentation is an old beast.

Android is no better than what we had with Symbian, J2ME or proprietary mobile OSes that came before current crop of mobile OSes.

As long as OEM and networks have the last word on firmware, it will always exist´, in name of product differentiation.

[viraptor]

It's way better than J2ME and lightyears ahead of proprietary OSes. If you think that's not the case, I don't think you remember those times very well. With J2ME it was basically close to impossible to create any app apart from the most basic ones without producer-specific APIs. Nokia, Siemens, Samsung, Motorola, etc. - they all had their own special extensions. Even if some game was released for more than one handset, each make had its own version.

(Although it was possible to write a translation layer - I wrote a nokia-to-siemens translating classes which worked in most cases)

Now you may have issues with versions of Android and which features you can support. You may also have issues with different resolutions. But it's nowhere as bad as in 2002.

[pjmlp]

I did develop for J2ME.

> With J2ME it was basically close to impossible to create any app apart from the most basic ones without producer-specific APIs. Nokia, Siemens, Samsung, Motorola, etc. - they all had their own special extensions. Even if some game was released for more than one handset, each make had its own version.

How is this different from the firmware issues that plague Android?

Have you ever tried to make the support library work properly across Samsung devices, or even worse cheap chinese brands?

Or track down native crashes or memory leaks across Android firmware?

Whoever believes that Android is better than J2ME, never had to make their apps work on cheap or network specific Android devices.

[pawadu]

I am sorry, how can J2ME even remotely compare to Android?

With J2ME you couldn't write the simplest application before you ran into the platform specific minefield (example: how to read the D-pad on different phones?). On Android, running into problems is the exception not the rule.

[pjmlp]

The fact is that there are fragmentation issues due to firmware bugs.

And it isn't that exceptional, if you look at the bug database, specially in low spec handsets.

[Oletros]

> How is this different from the firmware issues that plague Android?

What "firmware issues plague Android?

> Whoever believes that Android is better than J2ME, never had to make their apps work on cheap or network specific Android devices.

This must be a joke

[pjmlp]

> What "firmware issues plague Android?

Apparently you lack reading comprehension as I listed two of them.

> This must be a joke

So here are a some more jokes specially just for you:

https://github.com/google/iosched/issues/79

http://www.androidheadlines.com/2014/11/samsung-devices-migh...

http://verybadalloc.com/android/2015/12/19/special-place-for...

https://code.google.com/p/android/issues/list?can=1&q=firmwa...

[viraptor]

So the released devices have bugs - same thing happened on old feature phones. That's always going to happen - that's how consumer software works. This is not even close to what happened for J2ME.

1. If there was a J2ME bug on a phone, you were stuck with it forever. Only a handful of phones received upgrades and you had to find a specific cable to flash them, so most people never did. With Android you have a chance to receive a fix over the network - that's magic in comparison.

2. You're still using Android libs to write the apps. You're not downloading Samsung SDK which won't work on Asus, or LG SDK which won't work on something else. You're publishing one package, and not one package per phone producer, or even model. Again, magic in comparison.

[Gracana]

I'm experiencing a great low-level bug right now. Last week Google released an update that breaks SSL in chrome, google now, and the search bar. Apparently this phone has a buggy neon unit and their latest update broke the check that would detect the problem and disable the offending instructions. Even for a company with experience and talent like Google, and even having seen this bug before, they still released this code that breaks most things on my phone, and there has not been a fix for six days now. I can't imagine being a small developer trying to handle quirks like this in the vast array of phones on the market.

[pawadu]

I looked into your first link, the linked google issues says:

java.lang.NoClassDefFoundError: android.support.v7.internal.view.menu.MenuBuilder at android.support.v7.widget.ActionMenuView.getMenu(SourceFile:620) at android.support.v7.widget.Toolbar.ensureMenu(SourceFile:823) ...

Is this really a "firmware issue"? I thought the inclusion of support libraries was the responsibility of the developers? Am I misreading this?