[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.

[pjmlp]

> With Android you have a chance to receive a fix over the network - that's magic in comparison.

Assuming you shelled out money for a Nexus that wasn't canned like the TI one.

All the other OEMs aren't any different from the J2ME days.

All my Android devices got the same amount of updates as the J2ME we used to target, meaning either none or one.

Updated via the desktop software that came with them.

> You're not downloading Samsung SDK

You mean this SDK?

http://developer.samsung.com/sdk-and-tools

Or this one?

https://developer.sony.com/develop/

Or this one?

http://developer.lge.com/resource/mobile/RetrieveOverview.de...

I don't see any difference.

[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?

[pjmlp]

Samsung includes their own modified support library on the classpath, on some of their handsets, before the classes loaded from the APK.

So on those devices you need to load a customised versions to be able to workaround class loading priorities and load the right classes.