Hacker News new | past | comments | ask | show | jobs | submit login

> If ITV wanted to avoid fragmentation it would have chosen to make its app compatible with only pure versions of Android

That isn't what causes Android's fragmentation issues. Even between virgin android devices there is a LOT of fragmentation, these devices just happen to be popular with developers so most people aren't impacted by it.

Different screen sizes/resolutions, driver issues, graphics acceleration, aftermarket distro's, all cause a LOT of issues and these things all exist on virgin Android just as much as Samsung's strange re-imagining of the ecosystem.

Nvidia Tegra in particular has broken a LOT of stuff.




I am an android developer.

Are you suggesting that screen sizes and resolutions are uniform among Samsung devices? Drivers are the same? That is nonsense.

Aftermarket distros include no warranty warnings, it's up to the packagers to solve bugs in their builds.

Here is the reality: if they had opted to use the MediaPlayer classes with whatever streaming service they use on devices 2.3+, they would have likely had to deal with a few corner cases. If they didn't, they have made a poor decision. If they did, they are restricting allowed devices for reasons that are non-technical.

> Even between virgin android devices there is a LOT of fragmentation, these devices just happen to be popular with developers so most people aren't impacted by it.

I use the emulator for almost all of my testing and then test on a Galaxy Nexus. I beta test across a large net. The number of corner cases that are not related to pre-gingerbread versions of android is tiny. [EDIT: In the streaming media field, as of now. This was a much bigger problem several years ago. Obviously, the differences are more of an issue with games, which we are not talking about here.]


> Are you suggesting that screen sizes and resolutions are uniform among Samsung devices? Drivers are the same? That is nonsense.

...No? In fact my post said exactly the opposite of that:

> all cause a LOT of issues and these things all exist on virgin Android just as much as Samsung's strange re-imagining of the ecosystem.

I am saying there is fragmentation between two "virgin Android" devices. Therefore making his point that virgin Android somehow "solves" fragmentation wrong.

Samsung has a lot of fragmentation. So do "virgin Android" devices. Android has fragmentation because there is too much incompatible hardware and for some things the abstraction is more weakly enforced than for others (e.g. hardware acceleration).


The argument that the post was making was that there is zero weight to the claim that this decision was made for technical reasons.

Further, the post makes the point that choosing an open-source baseline as the first system you support means that there's a clear and relatively straightforward path to compatibility. Setting that target at a proprietary fork of that system does nothing to improve the situation.


I too am an Android developer and I test similarly to how you do (even have a Galaxy Nexus [as well as a Nexus 7]). Really have not had anything drastic in fragmentation either if only supporting 2.2 and above (2.2 lacking the download manager, but I don't really need that too much).

Even the gripes other are claiming about graphic incompatibilities are generally untrue, since 2.2 and above supports OpenGL ES 2.0. As someone else mentioned, audio still leaves something to desired. Graphics are not anywhere close to that being an issue from my experiences, but I suppose that all has to do with how far one goes down the rabbit hole for optimizations and tuning to a specific GPU. I don't doubt that OEMs screw around with things, but I'm not a GPU development guru by any means so I cannot say it won't be in every use case.

The only real compatibility issue I've had to deal with was working around in the radio interface layer for Android in a small open source app I maintain[1][2] as a personal side project for reading/analyzing some of the hidden network readings that Android does not normally expose to the user. Biggest issue with that is that some OEMs (Samsung being one) do whatever they feel like with the data here (sometimes tying some areas into the radio firmware and other times not [as well as sometimes deviating from what the functionality says it should do in the Android API]).

Since Android 4.0, it's been pretty sane across the board in the radio interface layer, but I still get an occasional 2.3 or 2.2 device that sends me a stacktrace after crashing for some silly reason. If it's not too much trouble, I'll try to work around it, but otherwise (short of a user going out their way to help me pin down the issue personally) I just let it go. I've mostly abstracted out any of the issues to make the old readings compatible with Android 4.0 now so it's not too much of a big deal for me anymore.

[1] https://github.com/yareally/SignalInfo

[2] https://play.google.com/store/apps/details?id=com.cc.signali...


Add audio APIs to that list. If you want to do anything with noise control, echo cancellers or gain control it's a whole world of pain - in my experience HTC phones are particularly bad in this area - your experience may differ, depending on what type of app you develop.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: