No problem - you want practical examples, I have literally an endless amount... I will try not to collapse Google servers or something, so I'll post just a few.
By the way - read the original post - I am NOT talking about official fragmentation. Not screen sizes, API levels features and so on. I'm talking about BUGS. All the issues below were tested with a device in front of me, these are not just assumptions. Ok, let's go: 1. On Samsung Galaxy S and most of its variants, when you use this simple and documented intent: http://developer.android.com/guide/topics/media/camera.html#intent-image The camera app behaves completely differently, and will sometimes ignore MediaStore.EXTRA_OUTPUT. If you run the same code that would work on any other device, most likely you'll crash on a NullPointer, unless you workaround for Samsung. Tested with the device in 2. The API AudioManager.setMicrophoneMute (http://developer.android.com/reference/android/media/AudioManager.html#setMicrophoneMute(boolean)) doesn't work at all on some Motorola devices (Milestone variants). It will literally do nothing, not mute the mic and even tell that you DID mute the mic (isMicrophoneMute will return true after that). 3. Using a GLSL shader with 4x3 matrix multiplication containing some 0's on Galaxy S4 will miscalculate the result, and produce artifacts because of that. Every other device does the same calculation fine, except S4. 4. Using camera preview on some Sony Xperia variants (http://developer.android.com/reference/android/hardware/Camera.html#setPreviewCallback(android.hardware.Camera.PreviewCallback)) will give you flipped or even cut preview frames - so it's completely useless for implementing video calling on these devices. 5. Reading from the proximity sensor on Motorola Milestone variants (http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_PROXIMITY) will give you completely unrelated values, different from every other device and ignoring the sensor specification (getMaximumRange() and so on). 6. Running a GLSL shader with 8 varying vectors (the minimum of available varying vectors according to the spec., that should be available on every device), will cause some Galaxy S variants to reboot instantly. 7. Using an Intent to pick an image from the gallery (http://stackoverflow.com/questions/5309190/android-pick-images-from-gallery) on some Galaxy S variants will cause the Gallery app to crash. That's just the ones that came to my mind right now. I'm sure this can turn into a whole book when other people contribute. On Wednesday, July 31, 2013 1:40:14 PM UTC+3, Daniele Segato wrote: > > On 07/26/2013 12:39 AM, Omer Gilad wrote: > > .I am wondering how developers here are dealing with the fact that there > > are 1000's of devices out there, some of them running your applications > > in very broken ways > > .I keep running into these kind of issues again and again for the past 3 > > years, and to be honest, I'm fed up with it > > .I've decided to move to iOS development, and the only way to convince > > me otherwise is to give me a decent, reliable way of dealing with > > fragmentation > > > [snip] > > > > To make it clear, I'm not talking about "official" fragmentation. > > I don't talk about different screen sizes, densities, features, OS > > versions and so on. > > I talk about the "unofficial" fragmentation. The fact that most devices, > > even the popular ones from the big companies like Samsung, HTC, > > Motorola, LG and so on, contain tons of implementation bugs that prevent > > apps from working correctly. > > I'm talking about the fact that you can call a certain simple API, test > > it on a stock Android ROM (like on Nexus 4), and then have your > > application crash on some Samsung, that decided to break the > > implementation because of some customization. > > > > How can people stand that? > > How is it possible to write code, when the machine that executes it is > > completely broken in unexpected ways? > > > [snip] > > I feel a little put off by this. > > Never had issues like the one you describe when doing the things are > they are supposed to be done (following the docs and guide lines). > > When someone talk about fragmentation in Android I laugh. Seriously. > in iOS if you want to support different device you literary has to > develop twice. True, they do not have has many devices. But Android is > designed from the ground to support the fragmentation: > - you can address different API with just an if in your browser or using > -v14 in your resources/layouts/values > - You have fragment and the support library bring backs most of the > features you need for supporting old devices > > Reading your message and the replies you get it seems like everybody is > experiencing bug in how the API is implemented. > > I don't trust you. > What I think is that either I am be always very lucky either you did > something wrong. > > I'm open to change my mind, but I'd like to have some practical example, > you seems to have many since you spend most of the time fixing them. > > Why don't you share what they are? Maybe you'll discover you are doing > something you shouldn't or if you are right it could be a start for > other developers to have a list of gotchas and issues you have to be > aware off making life easier for everyone. > > > Regards, > Daniele Segato > > > -- -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
