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

[viraptor]

All of those provide extra functionality. Extra, as in beyond what you would normally need for an app. There are sensors, themes, accessories, etc. They're not available in (for example) non-Samsung devices, so they don't really apply there.

In J2ME you pretty much needed to use custom SDK to play a sound. Or draw a screen fast enough to do scrolling. Or just activate colours at all. I'm talking about things like http://www.j2megame.org/j2meapi/Nokia_UI_API_1_1/ which provided sound and ui canvas.

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