Flaming is not the purpose of this discussion - the purpose is to: 1. Share and find some practical solutions, if there are any. 2. Bring the seriousness and span of this issue to Google's attention - as there seems to be complete ignorance and self-delusion regarding it. So far I haven't seen any official Google source admit that this issue even exists, or provide any practical way of dealing with it.
Of course, there's an inevitable element of being completely pissed-off about it. Regarding an issue database - that's a partial solution that can certainly cut off the amount of work that developers spend on device bugs. If I could look up issues related to a specific device or API and prepare myself before publishing to users using already made workarounds, maybe my job would be easier. It will also bring the issue to Google's attention, because at some point they'll have to confront a constantly growing device issue database. But it's only partial - I'm trying to point out the the problem is more in the attitude, than in specific device vendors. Bugs will always happen in any product, and Google can't put surveillance in Samsung's factories and tell them what to do. However, Google can be very strict about regulations, and demand high standards from anyone who wishes to use the Android brand and use the Google Play service. Some practical steps that Google can take to eliminate the problem that developers face when distributing apps: 1. Automatically monitor app ratings in Google Play, and identify spikes where a certain device gives a considerably low rating for an app than the other devices. Chances are that there's a device specific bug. Actively inquire the situation ( that will usually apply to lots of apps using the same API), and when Google verifies there's indeed a bug in the device - demand an on-the-air update from the vendor in 2 weeks. If the vendor won't fix the bug on all of its device that can access Google Play, ban the device from the store until they fix it. 2. Set up a special contact email for developer reports, so you can get reports about specific device issues that developers encounter. Do the same procedure like in #1 - ask the vendor to fix it. If they don't fix it, remove their Google Play certification until they do. All that is being asked from Google is to be assertive and strict about who they give Google Play certification to. I don't expect Google to fix vendor bugs, that's impossible - but I expect Google to demand high quality without compromise. On Wednesday, July 31, 2013 3:32:41 PM UTC+3, Daniele Segato wrote: > > On 07/31/2013 01:47 PM, 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. > > Thanks for that. > > > > > 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. > > I got it. > I'm just saying I never hit one. > I wrote that message with the specific intent of moving this discussion > on facts in opposition to "my opinion VS your opinion" > > I never said the API are flawless (as Piren pointed out in the other > response to my message). It's their implementation that may be buggy. > > I said my perceiving of the issue is not so bad as you pictured it. > Maybe 20% of the time for a project may go for fragmentation (both bugs > and handling API changes, screen sizes etc.). > I do not often write with native code, Graphics, Bluetooth, Sensors etc. > Sure, my user bay may not be so big too, sure. > > But you know what? I think it's more constructive to list issues and > try, together as a community, to route them out instead of just wining > about fragmentation. > Complaining with Google doesn't help either, because they can't do > anything about a bug created by someone else. > > The only thing you, and all the other hitting this kind of issues can do > is find a way to list them out. If you really care about the issue you > should discuss that and put facts (as this list) in front of claims > (fragmentation sucks). > > > > 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. > > Thank you for this list. > > I ask you to avoid the flame and start a constructive discussion instead > about what we can do, as a community, to help other developers discover > this kind of issues. > > A issue database is what we need. > > I don't have the resources to put one up. Probably none of you, alone, > has them. > > my 2 cent > Cheers, > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
