The i9000 - oh yeah! The file system freezes alone were a killer, and then when they implemented a "fix", it was preventing apps from saving their own shared preferences.
Today's top of the line Samsung devices seem to be much better (haven't run into anything on my Galaxy Note 2, myself, but then I don't develop games), but their middle- and low- end devices are still really weird. Just had an issue reported for one of them, which I am able to reproduce only on my 2.3 devices - and this Samsung runs 4.0/4.1. Did they screw up the merge / rebase? -- K On Wednesday, July 31, 2013 4:02:38 PM UTC+4, Piren wrote: > > 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.
