The Galaxy S (especially the i9000) is one of the shittiest devices i've worked on, without a doubt.
On Wednesday, July 31, 2013 2:47:38 PM UTC+3, Omer Gilad wrote: > > 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.
