Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
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 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
Either you intentionally ignored the message of his post or you're playing dumb. No one is complaining about fragmentation (which sucks, but that's besides the point). We're talking about APIs not performing as they should.If you claim that this never happened to you, you're either lying, inexperienced, without a user base, targeted a single device or haven't used any of the APIs beyond doing an app with a single clickable button. How about you trying writing some code that deals with Bluetooth, Sound, Graphics and Sensors (especially the camera) ... run that code on 20 different devices, then tell us that the APIs are flawless. 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 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
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
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
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
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
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
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
You're wrong about calling it fragmentation: fragmentation means there are n versions of Android, and you have to consider that. What Omer is saying is that there are actually x n versions of Android, when you take into account all of the vendor ROMs, with their long list of bugs. So it's not about fragmentation, except for in the latter sense. I also disagree that starting an issue database will help anyone. Telling developers to worry about 900 bugs their app may need to worry about when they can't test on the individual devices isn't really a solution. Kris On Wed, Jul 31, 2013 at 8:32 AM, Daniele Segato daniele.seg...@gmail.com 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
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
On 07/31/2013 02:40 PM, Kristopher Micinski wrote: You're wrong about calling it fragmentation: fragmentation means there are n versions of Android, and you have to consider that. What Omer is saying is that there are actually x n versions of Android, when you take into account all of the vendor ROMs, with their long list of bugs. I know, I just used the term Fragmentation because that's the term Omer used (unofficial fragmentation) in the first message. So it's not about fragmentation, except for in the latter sense. I also disagree that starting an issue database will help anyone. Telling developers to worry about 900 bugs their app may need to worry about when they can't test on the individual devices isn't really a solution. Ok, then what you suggest? -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
Daniele, I think Omer has been constructive. He asked clearly: how do you deal with this situation? It's obvious there's no bullet proof solution to this problem, he has told us what he did until now and asked the community what are they doing to deal with it. El miércoles, 31 de julio de 2013 09:32:41 UTC-3, Daniele Segato escribió: On 07/31/2013 01:47 PM, Omer Gilad wrote: 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. -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
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
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
I think various people outlined possible solutions if you'd read the previous messages. One possible solution is stricter certification requirements. Kris On Jul 31, 2013 8:49 AM, Daniele Segato daniele.seg...@gmail.com wrote: On 07/31/2013 02:40 PM, Kristopher Micinski wrote: You're wrong about calling it fragmentation: fragmentation means there are n versions of Android, and you have to consider that. What Omer is saying is that there are actually x n versions of Android, when you take into account all of the vendor ROMs, with their long list of bugs. I know, I just used the term Fragmentation because that's the term Omer used (unofficial fragmentation) in the first message. So it's not about fragmentation, except for in the latter sense. I also disagree that starting an issue database will help anyone. Telling developers to worry about 900 bugs their app may need to worry about when they can't test on the individual devices isn't really a solution. Ok, then what you suggest? -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
On 07/31/2013 03:10 PM, Kristopher Micinski wrote: I think various people outlined possible solutions if you'd read the previous messages. One possible solution is stricter certification requirements. That's something Google can do, and is probably doing. I asked what WE can do. If we don't talk about this this whole discussion can be trashed, will not be of any help to anyone. -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
On 07/31/2013 03:05 PM, Omer Gilad wrote: Flaming is not the purpose of this discussion - the purpose is to: 1. Share and find some practical solutions, if there are any. That's the primary reason I bothered to reply in the first place. I saw you wasn't try to flame. But, since you were pissed off, you missed to actually bring facts to the discussion, which you did later replying to me. Accomplishing that I tough of moving it one step further: from other discussion is pretty clear that among who read your question there's no one who have a solution. Every single developer is solo in handling this issue, which is part of the reason this is so costly. If we (all the Android developers) want to achieve this second point: 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. we should keep to the facts, like the list you gave, and start doing something. And I think this discussion is perfect to do some brainstorming of what we can do to help everyone. It may also help bringing the fact in front of Google to make them acknowledge it and help. Of course, there's an inevitable element of being completely pissed-off about it. :) Know the feeling 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. Yes, better then nothing I think. And there are plenty of free bug trackers that can be used too. 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. Thanks for pointing that out, that's not a small point in building up an 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. Agree, and I think they are moving in that direction, but that's my guess. Still, it will take time. And more importantly, we can't do anything about it now. We may in the future if we build that database we were talking about (visibility helps). 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 That would be a good idea. And maybe they already do so. - 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. That's probably harder to do. But as developer we may do something similar... for example by stopping supporting very buggy device. This is very similar to the InternetExplorer issue web developer have. If only Web developer stopped supporting the browser every user would just change it. If you buy a device for which there are no app you (as an User) say the device sucks, not the app. But if you don't know which devices are more buggy you don't know which device to remove the support from -- back to the bugs database. 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. email wouldn't probably be the most useful thing, a dedicated bug tracker may be better. But that's what Google can do, doesn't help us now. 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. I also expect that. But you can't change the behavior of someone else. You can only change your own and hope this will also change the others. That's some idea: - choose and start to use a bug tracker to grow a bug database about android personalizations from different vendors - create a Google+ Community dedicated to this to have a
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
I really dont get any of your points Daniele! Every developer that till now sent an email in this discussion has already stated his/her opinion in order to answer at Omer's first question... We can bring Google's attetntion at this problem but we should be focused on it! If you don't create any workarounds for the buggy devices and just ban them from your app, imagine what could happen for those devices..They would only be able to download 4-5 apps (just saying...)... On Wed, Jul 31, 2013 at 4:12 PM, Daniele Segato daniele.seg...@gmail.comwrote: On 07/31/2013 03:10 PM, Kristopher Micinski wrote: I think various people outlined possible solutions if you'd read the previous messages. One possible solution is stricter certification requirements. That's something Google can do, and is probably doing. I asked what WE can do. If we don't talk about this this whole discussion can be trashed, will not be of any help to anyone. -- -- 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.comandroid-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+**unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/**group/android-developers?hl=enhttp://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.comandroid-developers%2bunsubscr...@googlegroups.com . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- *Παύλος-Πέτρος Τουρνάρης* *Android Software Developer* - *http://goo.gl/TsJ8u* - *http://acschedule.org* -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
On 07/31/2013 03:36 PM, Παύλος-Πέτρος Τουρνάρης wrote: I really dont get any of your points Daniele! I can see that ;) Every developer that till now sent an email in this discussion has already stated his/her opinion in order to answer at Omer's first question... I'm asking you all to think and propose what can be done BY US (not Google) to ease up the issue. That's it. And I made a proposal. We can bring Google's attetntion at this problem but we should be focused on it! If you don't create any workarounds for the buggy devices and just ban them from your app, imagine what could happen for those devices..They would only be able to download 4-5 apps (just saying...)... That would be absolutely perfect. What do you think an user able to download 4-5 apps of that device? -- This device sucks What will the reviews say about it? -- don't buy it What will the vendor producing that device do with next devices? -- be more complain to the standards. But hey, that's was just a suggestion on what one can do knowing the devices causing more issues. The main proposal was to put up a bug database for this kind of issues. -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
1. Share and find some practical solutions, if there are any. There isn't any, for some specific use cases (games) best solution is to use higher level API (game engine). 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. And you are saying that because of what exactly? 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. There is no practical way of dealing with it (except of on device basis which, according to you, isn't practical), if you search this group and stackoverflow you will find several examples where Android team engineers talk about device bugs so I really have no idea why you think they aren't aware of that, moreover anyone who has ever work with J2ME is more than aware that avoiding this is impossible (and J2ME was few orders of magnitude worse due to differences in underlying OSes, drivers, CPU architectures etc). -- Bart -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
I am missing the point of this post. Are you saying that there is no solution? If so, what do you suggest? Just stop developing for Android? When I say not aware of that, I mean that it doesn't show up as a practical solution from the eyes of developers. Maybe they're aware of that and do internal meetings and discussions about it, but it's not something that I know of. On Wednesday, July 31, 2013 5:43:42 PM UTC+3, a1 wrote: 1. Share and find some practical solutions, if there are any. There isn't any, for some specific use cases (games) best solution is to use higher level API (game engine). 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. And you are saying that because of what exactly? 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. There is no practical way of dealing with it (except of on device basis which, according to you, isn't practical), if you search this group and stackoverflow you will find several examples where Android team engineers talk about device bugs so I really have no idea why you think they aren't aware of that, moreover anyone who has ever work with J2ME is more than aware that avoiding this is impossible (and J2ME was few orders of magnitude worse due to differences in underlying OSes, drivers, CPU architectures etc). -- Bart -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
I would certainly support by adding known issues if there was such a system. I'm not familiar with any free website that can easily create such a database - anyone? On Wednesday, July 31, 2013 4:59:19 PM UTC+3, Daniele Segato wrote: On 07/31/2013 03:36 PM, οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½-οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ wrote: I really dont get any of your points Daniele! I can see that ;) Every developer that till now sent an email in this discussion has already stated his/her opinion in order to answer at Omer's first question... I'm asking you all to think and propose what can be done BY US (not Google) to ease up the issue. That's it. And I made a proposal. We can bring Google's attetntion at this problem but we should be focused on it! If you don't create any workarounds for the buggy devices and just ban them from your app, imagine what could happen for those devices..They would only be able to download 4-5 apps (just saying...)... That would be absolutely perfect. What do you think an user able to download 4-5 apps of that device? -- This device sucks What will the reviews say about it? -- don't buy it What will the vendor producing that device do with next devices? -- be more complain to the standards. But hey, that's was just a suggestion on what one can do knowing the devices causing more issues. The main proposal was to put up a bug database for this kind of issues. -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
I think a central website for collecting known issues and workarounds would be a great idea. There are free wiki hosting services that could be used for that: https://en.wikipedia.org/wiki/Comparison_of_wiki_hosting_services On Wednesday, July 31, 2013 10:14:40 AM UTC-5, Omer Gilad wrote: I would certainly support by adding known issues if there was such a system. I'm not familiar with any free website that can easily create such a database - anyone? On Wednesday, July 31, 2013 4:59:19 PM UTC+3, Daniele Segato wrote: On 07/31/2013 03:36 PM, οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½-οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ wrote: I really dont get any of your points Daniele! I can see that ;) Every developer that till now sent an email in this discussion has already stated his/her opinion in order to answer at Omer's first question... I'm asking you all to think and propose what can be done BY US (not Google) to ease up the issue. That's it. And I made a proposal. We can bring Google's attetntion at this problem but we should be focused on it! If you don't create any workarounds for the buggy devices and just ban them from your app, imagine what could happen for those devices..They would only be able to download 4-5 apps (just saying...)... That would be absolutely perfect. What do you think an user able to download 4-5 apps of that device? -- This device sucks What will the reviews say about it? -- don't buy it What will the vendor producing that device do with next devices? -- be more complain to the standards. But hey, that's was just a suggestion on what one can do knowing the devices causing more issues. The main proposal was to put up a bug database for this kind of issues. -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
On 07/31/2013 05:58 PM, Nobu Games wrote: I think a central website for collecting known issues and workarounds would be a great idea. There are free wiki hosting services that could be used for that: https://en.wikipedia.org/wiki/Comparison_of_wiki_hosting_services I think a wiki is not a good idea for something like this. More like this: http://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems I think we need a bug tracker that allow tagging by vendor, devices, device variant, android version and let the user combine those when searching. It would also be good to have some statistics on those tags/categories. Jira would be perfect, but it's not free. I can list some, but do not know them well enough to compare or to know if they fit: - Google Code: https://code.google.com/ - GitHub - the repository can just be a readme - https://github.com/ - SourceForge - http://sourceforge.net/ I'm sure there are others. -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
Oops, I sent my reply just to you, so here again for all to see: on the one hand that's a good idea. On the other hand we would need someone who is willing to host and maintain that bug tracker. Setting up products, versions etc. is a lot of work in a bug tracking system. That's why I think that a wiki has more chances to take off with the majority of Android developers as users. There are 10.000-something different Android devices out there. It's not much of a problem to introduce new devices in a wiki. But it takes a whole deal of dedication for doing that in a bug tracking system On Wednesday, July 31, 2013 11:17:48 AM UTC-5, Daniele Segato wrote: On 07/31/2013 05:58 PM, Nobu Games wrote: I think a central website for collecting known issues and workarounds would be a great idea. There are free wiki hosting services that could be used for that: https://en.wikipedia.org/wiki/Comparison_of_wiki_hosting_services I think a wiki is not a good idea for something like this. More like this: http://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems I think we need a bug tracker that allow tagging by vendor, devices, device variant, android version and let the user combine those when searching. It would also be good to have some statistics on those tags/categories. Jira would be perfect, but it's not free. I can list some, but do not know them well enough to compare or to know if they fit: - Google Code: https://code.google.com/ - GitHub - the repository can just be a readme - https://github.com/ - SourceForge - http://sourceforge.net/ I'm sure there are others. -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
Hi Thomas, The bug trackers I proposed are all free to use and cloud bug trackers (meaning no one has to maintain a server or something). What's needed are admins for that bug tracker. Categories can be created when needed. If there are enough maintainers I think it can be done, the community is big and if people really care about this issue I don't think it should be a problem to find some. If they don't really care so much then we will see no one stepping in, that's for sure. regards, Daniele Segato On 07/31/2013 06:30 PM, Nobu Games wrote: Oops, I sent my reply just to you, so here again for all to see: on the one hand that's a good idea. On the other hand we would need someone who is willing to host and maintain that bug tracker. Setting up products, versions etc. is a lot of work in a bug tracking system. That's why I think that a wiki has more chances to take off with the majority of Android developers as users. There are 10.000-something different Android devices out there. It's not much of a problem to introduce new devices in a wiki. But it takes a whole deal of dedication for doing that in a bug tracking system On Wednesday, July 31, 2013 11:17:48 AM UTC-5, Daniele Segato wrote: On 07/31/2013 05:58 PM, Nobu Games wrote: I think a central website for collecting known issues and workarounds would be a great idea. There are free wiki hosting services that could be used for that: https://en.wikipedia.org/wiki/Comparison_of_wiki_hosting_services https://en.wikipedia.org/wiki/Comparison_of_wiki_hosting_services I think a wiki is not a good idea for something like this. More like this: http://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems http://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems I think we need a bug tracker that allow tagging by vendor, devices, device variant, android version and let the user combine those when searching. It would also be good to have some statistics on those tags/categories. Jira would be perfect, but it's not free. I can list some, but do not know them well enough to compare or to know if they fit: - Google Code: https://code.google.com/ - GitHub - the repository can just be a readme - https://github.com/ - SourceForge - http://sourceforge.net/ I'm sure there are others. -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
I guess I'm trying to ascertain: is there a concrete question you have, or just a bunch of bad points about how the Android ecosystem sucks right now? If it's the second, everyone agrees it sucks, there's not a good solution. I suppose one thing that Android could have done better from the start was to offer UI modes that would be guaranteed to homogenous across all certified devices. I don't think that I said statistics were a solution to the issue (though apologies if I gave that impression): I meant to merely give the idea that because of Android's fragmentation a good way to get a handle on what you're facing would be to use device install statistics. I never meant to imply that it was in any way a solution. But everyone agrees that fragmentation sucks. Everyone has agreed it sucks since the beginning (even Android 2.0), and people knew it would get *worse*. You have to worry about API levels, screen configurations, hardware configurations, etc... I know of a few groups developing open source test services, that could presumably end up making a co op or something: that would definitely give more leeway than traditional expensive test services. (If people would be interested, this would be possible to do in the community right now: just buy a server, write some code to distribute the APKs with a feedback / review system, etc..) Kris On Thu, Jul 25, 2013 at 10:01 PM, Omer Gilad omer.gi...@gmail.com wrote: I agree that it's better than nothing. But, since it's a paid service that has nothing to do with the official SDK, it doesn't come in the SDK's favor at all. The problem appears in much more obvious parts of the SDK than the one I presented. I can give countless examples on demand and I'm sure others can too. Also, I never even bothered to fix custom ROMs and such - this is really beyond my scope. I'm having constant issues with stock, popular devices from Samsung, HTC, etc. - the ones that get shipped in the millions and dominate the Google Play statistics. As you said, statistics are also a temporary solution to the issue - just focus on workarounds for the most popular buggy devices - mainly the Samsung Galaxy series and its endless variations. On Friday, July 26, 2013 4:33:52 AM UTC+3, Kristopher Micinski wrote: Your last paragraph is *exactly* what the CTS is all about, but obviously if you don't work for google you can't mandate what goes in and what does not :-). I'm not recommending that these services are the solution to everyone's problems: but I do contend they get you farther than you would be otherwise. Games are particularly hard to test, since GPUs vary more widely across devices and aren't part of the most common pieces of the SDK. The fact of the matter is, there are always going to be hacked up ROMs running on the market: that's the design decision made by Android. The CTS helps get you farther to a holistic / cohesive platform, but in the end it's a numbers game: knowing which devices, API levels, user bases, countries, etc.. to care about is something the experienced developer has to have a handle on. Kris On Thu, Jul 25, 2013 at 9:05 PM, Omer Gilad omer@gmail.com wrote: Yes, I've encountered those services. This is still not a solution. It requires substantial money investment, and in a lot of cases it doesn't give you the ability to debug on those devices. Personal example - I'm developing a game, and we've found (after a friend checked it) that it has major display artifacts on Samsung Galaxy S4. No logs or attempts to remotely resolve the issue helped - so we had to get our hands on the device for a day. It turned out that the device's GPU is buggy, and miscalculates some common shader operations (like matrix multiplication). There's no remote testing platform in the world that can assist you in resolving issues like that. The issue is at the core, and must be solved at a design and attitude level - devices like that SHOULD NOT be allowed to run Google Play apps (and of course, they should be deprived of their certification), until the vendor fixes those issues. On Friday, July 26, 2013 3:27:49 AM UTC+3, Kristopher Micinski wrote: There are potential solutions, but in practice it's a constant battle. Certainly there are people that provide internet based test services that test your app on huge numbers of devices for a subscription based fee. Kris On Thu, Jul 25, 2013 at 8:12 PM, Omer Gilad omer@gmail.com wrote: I've found that even the biggest app developers like Skype, Gameloft, etc. have device issues, and they don't look in such a good shape. Just scan the reviews of any super-popular Android app, and you can see the same disease... This app doesn't even work, it sucks, and I PAID FOR IT! (from some crappy device). Obviously, those bigger developers have the budget and capacity to own 100's or
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
The point of the original post (the concrete question) was beyond just rant and rave - the question asked is How to deal with it. To put in other words - What do you suggest as a practical solution to the problem, beyond just dumping Android and developing for iOS. To filter out some possible answers: 1. Buying 50+ devices and doing QA on each one of them is NOT an option. It shouldn't ever be. 2. Paying constantly to remote testing services just to know what bugs we have (without even the ability to debug and resolve them) is NOT an option. 3. Chasing after devices (borrowing from friends, getting debug logs from users, etc.) and writing ugly code for workarounds time after time is what I've been doing for some time, but that is NOT an option. 3. Filtering many devices on Google Play console is our current solution, which is far from ideal as you can imagine. Currently, I don't have an effective way to deal with it, to the point that I've decided to move to another platform - the current state is impossible to cope with. I'm an independent developer, working in cooperation with some people, and we fail to address the fragmentation issue. All our efforts invested in creating a quality product are in vain when it's being run on countless broken devices that we can't keep track of. Just to back myself up - I've been developing for Android for more than 3 years, and have been constantly chasing after devices since the beginning. I experienced that in multiple types of projects (apps and games), as a hired or freelance developer and as an entrepreneur. It applies to every aspect of developing for Android, so this issue can't be evaded. To me, this is far more important than answering the questions on API usage, etc. On Friday, July 26, 2013 2:03:28 PM UTC+3, Kristopher Micinski wrote: I guess I'm trying to ascertain: is there a concrete question you have, or just a bunch of bad points about how the Android ecosystem sucks right now? If it's the second, everyone agrees it sucks, there's not a good solution. I suppose one thing that Android could have done better from the start was to offer UI modes that would be guaranteed to homogenous across all certified devices. I don't think that I said statistics were a solution to the issue (though apologies if I gave that impression): I meant to merely give the idea that because of Android's fragmentation a good way to get a handle on what you're facing would be to use device install statistics. I never meant to imply that it was in any way a solution. But everyone agrees that fragmentation sucks. Everyone has agreed it sucks since the beginning (even Android 2.0), and people knew it would get *worse*. You have to worry about API levels, screen configurations, hardware configurations, etc... I know of a few groups developing open source test services, that could presumably end up making a co op or something: that would definitely give more leeway than traditional expensive test services. (If people would be interested, this would be possible to do in the community right now: just buy a server, write some code to distribute the APKs with a feedback / review system, etc..) Kris On Thu, Jul 25, 2013 at 10:01 PM, Omer Gilad omer@gmail.comjavascript: wrote: I agree that it's better than nothing. But, since it's a paid service that has nothing to do with the official SDK, it doesn't come in the SDK's favor at all. The problem appears in much more obvious parts of the SDK than the one I presented. I can give countless examples on demand and I'm sure others can too. Also, I never even bothered to fix custom ROMs and such - this is really beyond my scope. I'm having constant issues with stock, popular devices from Samsung, HTC, etc. - the ones that get shipped in the millions and dominate the Google Play statistics. As you said, statistics are also a temporary solution to the issue - just focus on workarounds for the most popular buggy devices - mainly the Samsung Galaxy series and its endless variations. On Friday, July 26, 2013 4:33:52 AM UTC+3, Kristopher Micinski wrote: Your last paragraph is *exactly* what the CTS is all about, but obviously if you don't work for google you can't mandate what goes in and what does not :-). I'm not recommending that these services are the solution to everyone's problems: but I do contend they get you farther than you would be otherwise. Games are particularly hard to test, since GPUs vary more widely across devices and aren't part of the most common pieces of the SDK. The fact of the matter is, there are always going to be hacked up ROMs running on the market: that's the design decision made by Android. The CTS helps get you farther to a holistic / cohesive platform, but in the end it's a numbers game: knowing which devices, API levels, user
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
The conversation so far, and app testing services, assume that there are certain broken device models / firmwares and they are broken in a deterministic way. This implies that those bad devices can be discovered and excluded or workarounds implemented, again, in a deterministic way. From my experience, it's worse than that. I can get a user bug report that makes my jaw drop to the floor, and have a an exact or similar device on my desk that does not exhibit the issue. Basic things get broken: the app not being able to connect to well known servers, a toast notification getting stuck on the screen, the system ActionBar overflow button not showing on a device without a Menu button, etc. Reinstaling or clearing the Dalvik cache (or some other magic) often resolves these. That itself is a bad sign -- meaning that system level things can randomly break and randomly heal themselves, in a non-deterministic way. Here is a video I made of Galaxy Nexus with 4.0.2 rebooting when trying to start Google Maps, happened every time out of 10 or so I tried: http://www.youtube.com/watch?v=mC4EegjeWZA I fixed it by resetting the device back to factory settings and reinstalling Google Maps, but the question remains: why did this help? Did Google Maps get corrupted during installation? Can it happen to other apps too? I'm not even asking why a modern, preemptively multitasking operating system can enter a reboot triggered by application code. I don't have an answer for this situation either. It's just something I have to deal with every day, costing me a lot of wasted time and a depressed mood. The irony is, users always assume it's the app which must be doing something weird, unlike Windows, where they're quick to blame MS and Bill Gates personally. Must be some kind of Google magic. -- K 2013/7/26 Omer Gilad omer.gi...@gmail.com The point of the original post (the concrete question) was beyond just rant and rave - the question asked is How to deal with it. To put in other words - What do you suggest as a practical solution to the problem, beyond just dumping Android and developing for iOS. To filter out some possible answers: 1. Buying 50+ devices and doing QA on each one of them is NOT an option. It shouldn't ever be. 2. Paying constantly to remote testing services just to know what bugs we have (without even the ability to debug and resolve them) is NOT an option. 3. Chasing after devices (borrowing from friends, getting debug logs from users, etc.) and writing ugly code for workarounds time after time is what I've been doing for some time, but that is NOT an option. 3. Filtering many devices on Google Play console is our current solution, which is far from ideal as you can imagine. Currently, I don't have an effective way to deal with it, to the point that I've decided to move to another platform - the current state is impossible to cope with. I'm an independent developer, working in cooperation with some people, and we fail to address the fragmentation issue. All our efforts invested in creating a quality product are in vain when it's being run on countless broken devices that we can't keep track of. Just to back myself up - I've been developing for Android for more than 3 years, and have been constantly chasing after devices since the beginning. I experienced that in multiple types of projects (apps and games), as a hired or freelance developer and as an entrepreneur. It applies to every aspect of developing for Android, so this issue can't be evaded. To me, this is far more important than answering the questions on API usage, etc. On Friday, July 26, 2013 2:03:28 PM UTC+3, Kristopher Micinski wrote: I guess I'm trying to ascertain: is there a concrete question you have, or just a bunch of bad points about how the Android ecosystem sucks right now? If it's the second, everyone agrees it sucks, there's not a good solution. I suppose one thing that Android could have done better from the start was to offer UI modes that would be guaranteed to homogenous across all certified devices. I don't think that I said statistics were a solution to the issue (though apologies if I gave that impression): I meant to merely give the idea that because of Android's fragmentation a good way to get a handle on what you're facing would be to use device install statistics. I never meant to imply that it was in any way a solution. But everyone agrees that fragmentation sucks. Everyone has agreed it sucks since the beginning (even Android 2.0), and people knew it would get *worse*. You have to worry about API levels, screen configurations, hardware configurations, etc... I know of a few groups developing open source test services, that could presumably end up making a co op or something: that would definitely give more leeway than traditional expensive test services. (If people would be interested, this would be possible to do in the community right now: just buy
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
Can't agree more with everything that has already been said here, but let me remind you something guys: WE chose the Android way, they didn't force us! Android is an Open Source Project and therefore it was more than 100% sure that problems like the ones mentioned above, would appear by the time. There is nothing we can do when almost every brand (Samsung, LG, Sony) uses it's own custom ROM. This should have been handled at the beggining of Android's carreer! It's kind of difficult to deal with it at this moment with this huge penetration of Android on numerous devices! On Fri, Jul 26, 2013 at 3:19 PM, Kostya Vasilyev kmans...@gmail.com wrote: The conversation so far, and app testing services, assume that there are certain broken device models / firmwares and they are broken in a deterministic way. This implies that those bad devices can be discovered and excluded or workarounds implemented, again, in a deterministic way. From my experience, it's worse than that. I can get a user bug report that makes my jaw drop to the floor, and have a an exact or similar device on my desk that does not exhibit the issue. Basic things get broken: the app not being able to connect to well known servers, a toast notification getting stuck on the screen, the system ActionBar overflow button not showing on a device without a Menu button, etc. Reinstaling or clearing the Dalvik cache (or some other magic) often resolves these. That itself is a bad sign -- meaning that system level things can randomly break and randomly heal themselves, in a non-deterministic way. Here is a video I made of Galaxy Nexus with 4.0.2 rebooting when trying to start Google Maps, happened every time out of 10 or so I tried: http://www.youtube.com/watch?v=mC4EegjeWZA I fixed it by resetting the device back to factory settings and reinstalling Google Maps, but the question remains: why did this help? Did Google Maps get corrupted during installation? Can it happen to other apps too? I'm not even asking why a modern, preemptively multitasking operating system can enter a reboot triggered by application code. I don't have an answer for this situation either. It's just something I have to deal with every day, costing me a lot of wasted time and a depressed mood. The irony is, users always assume it's the app which must be doing something weird, unlike Windows, where they're quick to blame MS and Bill Gates personally. Must be some kind of Google magic. -- K 2013/7/26 Omer Gilad omer.gi...@gmail.com The point of the original post (the concrete question) was beyond just rant and rave - the question asked is How to deal with it. To put in other words - What do you suggest as a practical solution to the problem, beyond just dumping Android and developing for iOS. To filter out some possible answers: 1. Buying 50+ devices and doing QA on each one of them is NOT an option. It shouldn't ever be. 2. Paying constantly to remote testing services just to know what bugs we have (without even the ability to debug and resolve them) is NOT an option. 3. Chasing after devices (borrowing from friends, getting debug logs from users, etc.) and writing ugly code for workarounds time after time is what I've been doing for some time, but that is NOT an option. 3. Filtering many devices on Google Play console is our current solution, which is far from ideal as you can imagine. Currently, I don't have an effective way to deal with it, to the point that I've decided to move to another platform - the current state is impossible to cope with. I'm an independent developer, working in cooperation with some people, and we fail to address the fragmentation issue. All our efforts invested in creating a quality product are in vain when it's being run on countless broken devices that we can't keep track of. Just to back myself up - I've been developing for Android for more than 3 years, and have been constantly chasing after devices since the beginning. I experienced that in multiple types of projects (apps and games), as a hired or freelance developer and as an entrepreneur. It applies to every aspect of developing for Android, so this issue can't be evaded. To me, this is far more important than answering the questions on API usage, etc. On Friday, July 26, 2013 2:03:28 PM UTC+3, Kristopher Micinski wrote: I guess I'm trying to ascertain: is there a concrete question you have, or just a bunch of bad points about how the Android ecosystem sucks right now? If it's the second, everyone agrees it sucks, there's not a good solution. I suppose one thing that Android could have done better from the start was to offer UI modes that would be guaranteed to homogenous across all certified devices. I don't think that I said statistics were a solution to the issue (though apologies if I gave that impression): I meant to merely give the idea that because of Android's fragmentation a good way to get a
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
I had no idea it was this broken when I started developing for Android in early 2010. The only technology I can recall that was comparably broken was the early releases of Direct 3D, back in 96-98 or so... MS moved very quickly to improve it, though, and got hardware vendors to fix their drivers too. There are 58 thousand issues reported in the Android bug tracker. Dividing by three years, and accounting for installed base growth, that's, let's say, a hundred issues reported a day. Will they all be looked at, fixed, verified? I seriously doubt it. -- K 2013/7/26 Παύλος-Πέτρος Τουρνάρης p.tourna...@gmail.com: Can't agree more with everything that has already been said here, but let me remind you something guys: WE chose the Android way, they didn't force us! Android is an Open Source Project and therefore it was more than 100% sure that problems like the ones mentioned above, would appear by the time. There is nothing we can do when almost every brand (Samsung, LG, Sony) uses it's own custom ROM. This should have been handled at the beggining of Android's carreer! It's kind of difficult to deal with it at this moment with this huge penetration of Android on numerous devices! On Fri, Jul 26, 2013 at 3:19 PM, Kostya Vasilyev kmans...@gmail.com wrote: The conversation so far, and app testing services, assume that there are certain broken device models / firmwares and they are broken in a deterministic way. This implies that those bad devices can be discovered and excluded or workarounds implemented, again, in a deterministic way. From my experience, it's worse than that. I can get a user bug report that makes my jaw drop to the floor, and have a an exact or similar device on my desk that does not exhibit the issue. Basic things get broken: the app not being able to connect to well known servers, a toast notification getting stuck on the screen, the system ActionBar overflow button not showing on a device without a Menu button, etc. Reinstaling or clearing the Dalvik cache (or some other magic) often resolves these. That itself is a bad sign -- meaning that system level things can randomly break and randomly heal themselves, in a non-deterministic way. Here is a video I made of Galaxy Nexus with 4.0.2 rebooting when trying to start Google Maps, happened every time out of 10 or so I tried: http://www.youtube.com/watch?v=mC4EegjeWZA I fixed it by resetting the device back to factory settings and reinstalling Google Maps, but the question remains: why did this help? Did Google Maps get corrupted during installation? Can it happen to other apps too? I'm not even asking why a modern, preemptively multitasking operating system can enter a reboot triggered by application code. I don't have an answer for this situation either. It's just something I have to deal with every day, costing me a lot of wasted time and a depressed mood. The irony is, users always assume it's the app which must be doing something weird, unlike Windows, where they're quick to blame MS and Bill Gates personally. Must be some kind of Google magic. -- K 2013/7/26 Omer Gilad omer.gi...@gmail.com The point of the original post (the concrete question) was beyond just rant and rave - the question asked is How to deal with it. To put in other words - What do you suggest as a practical solution to the problem, beyond just dumping Android and developing for iOS. To filter out some possible answers: 1. Buying 50+ devices and doing QA on each one of them is NOT an option. It shouldn't ever be. 2. Paying constantly to remote testing services just to know what bugs we have (without even the ability to debug and resolve them) is NOT an option. 3. Chasing after devices (borrowing from friends, getting debug logs from users, etc.) and writing ugly code for workarounds time after time is what I've been doing for some time, but that is NOT an option. 3. Filtering many devices on Google Play console is our current solution, which is far from ideal as you can imagine. Currently, I don't have an effective way to deal with it, to the point that I've decided to move to another platform - the current state is impossible to cope with. I'm an independent developer, working in cooperation with some people, and we fail to address the fragmentation issue. All our efforts invested in creating a quality product are in vain when it's being run on countless broken devices that we can't keep track of. Just to back myself up - I've been developing for Android for more than 3 years, and have been constantly chasing after devices since the beginning. I experienced that in multiple types of projects (apps and games), as a hired or freelance developer and as an entrepreneur. It applies to every aspect of developing for Android, so this issue can't be evaded. To me, this is far more important than answering the questions on API usage, etc. On Friday, July 26, 2013 2:03:28 PM UTC+3,
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
That doesn't justify. An open source project can be maintained with strict regulations and high-quality standards. Google can allow anyone to create his own Android device and sell however they want - but don't allow it to run Google Play and rate apps! I don't recall problems in this massive scope on Linux for example. As far as I can tell, if I run a Linux program it's going to work 99% of the time. On Friday, July 26, 2013 3:31:26 PM UTC+3, Paul-Peter Tournaris wrote: Can't agree more with everything that has already been said here, but let me remind you something guys: WE chose the Android way, they didn't force us! Android is an Open Source Project and therefore it was more than 100% sure that problems like the ones mentioned above, would appear by the time. There is nothing we can do when almost every brand (Samsung, LG, Sony) uses it's own custom ROM. This should have been handled at the beggining of Android's carreer! It's kind of difficult to deal with it at this moment with this huge penetration of Android on numerous devices! On Fri, Jul 26, 2013 at 3:19 PM, Kostya Vasilyev kman...@gmail.comjavascript: wrote: The conversation so far, and app testing services, assume that there are certain broken device models / firmwares and they are broken in a deterministic way. This implies that those bad devices can be discovered and excluded or workarounds implemented, again, in a deterministic way. From my experience, it's worse than that. I can get a user bug report that makes my jaw drop to the floor, and have a an exact or similar device on my desk that does not exhibit the issue. Basic things get broken: the app not being able to connect to well known servers, a toast notification getting stuck on the screen, the system ActionBar overflow button not showing on a device without a Menu button, etc. Reinstaling or clearing the Dalvik cache (or some other magic) often resolves these. That itself is a bad sign -- meaning that system level things can randomly break and randomly heal themselves, in a non-deterministic way. Here is a video I made of Galaxy Nexus with 4.0.2 rebooting when trying to start Google Maps, happened every time out of 10 or so I tried: http://www.youtube.com/watch?v=mC4EegjeWZA I fixed it by resetting the device back to factory settings and reinstalling Google Maps, but the question remains: why did this help? Did Google Maps get corrupted during installation? Can it happen to other apps too? I'm not even asking why a modern, preemptively multitasking operating system can enter a reboot triggered by application code. I don't have an answer for this situation either. It's just something I have to deal with every day, costing me a lot of wasted time and a depressed mood. The irony is, users always assume it's the app which must be doing something weird, unlike Windows, where they're quick to blame MS and Bill Gates personally. Must be some kind of Google magic. -- K 2013/7/26 Omer Gilad omer@gmail.com javascript: The point of the original post (the concrete question) was beyond just rant and rave - the question asked is How to deal with it. To put in other words - What do you suggest as a practical solution to the problem, beyond just dumping Android and developing for iOS. To filter out some possible answers: 1. Buying 50+ devices and doing QA on each one of them is NOT an option. It shouldn't ever be. 2. Paying constantly to remote testing services just to know what bugs we have (without even the ability to debug and resolve them) is NOT an option. 3. Chasing after devices (borrowing from friends, getting debug logs from users, etc.) and writing ugly code for workarounds time after time is what I've been doing for some time, but that is NOT an option. 3. Filtering many devices on Google Play console is our current solution, which is far from ideal as you can imagine. Currently, I don't have an effective way to deal with it, to the point that I've decided to move to another platform - the current state is impossible to cope with. I'm an independent developer, working in cooperation with some people, and we fail to address the fragmentation issue. All our efforts invested in creating a quality product are in vain when it's being run on countless broken devices that we can't keep track of. Just to back myself up - I've been developing for Android for more than 3 years, and have been constantly chasing after devices since the beginning. I experienced that in multiple types of projects (apps and games), as a hired or freelance developer and as an entrepreneur. It applies to every aspect of developing for Android, so this issue can't be evaded. To me, this is far more important than answering the questions on API usage, etc. On Friday, July 26, 2013 2:03:28 PM UTC+3, Kristopher Micinski wrote: I guess I'm trying to ascertain: is there
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
I feel like what's been said here is more directed toward Google management than Android AOSP, per se: not that that's not also an issue. I understand and agree with what Kostya is saying, and wasn't trying to imply that there are a fixed number of builds with deterministic issues. Even for a certain device, things change and manifest in different ways: from firmware problems, to radio issues, etc... I think there are multiple problems here: - Fragmented OS installs over time - Operating system bugs - The fact that users can't upgrade their OS except through their provider, which usually sucks at writing firmware and often includes apps with special hooks into the OS doing really crazy things (e.g., HtcLoggers) - Poor management of certification to run google play - Certain roms running Google play even though they *shouldn't* be - etc... Many of these are management related, and potentially caused by the fact that Android doesn't control the OS. I think your argument for Linux isn't necessarily applicable here. Linux is all open source, you can install propietary drivers and mess up your device, but that's *extremely* different than going to Gateway (e.g.,) and having them hand you a custom version of Linux which can't be removed from the system. Note that in Linux's case, the codebase stays overwhelmingly the same, where in Android a huge part of the work is done with relatively few engineers working on writing firmware for radios they didn't necessarily design, sticking together proprietary components. I'm not using that as a defense for Android: I just think it's a poor comparison. Kris On Fri, Jul 26, 2013 at 9:18 AM, Omer Gilad omer.gi...@gmail.com wrote: That doesn't justify. An open source project can be maintained with strict regulations and high-quality standards. Google can allow anyone to create his own Android device and sell however they want - but don't allow it to run Google Play and rate apps! I don't recall problems in this massive scope on Linux for example. As far as I can tell, if I run a Linux program it's going to work 99% of the time. On Friday, July 26, 2013 3:31:26 PM UTC+3, Paul-Peter Tournaris wrote: Can't agree more with everything that has already been said here, but let me remind you something guys: WE chose the Android way, they didn't force us! Android is an Open Source Project and therefore it was more than 100% sure that problems like the ones mentioned above, would appear by the time. There is nothing we can do when almost every brand (Samsung, LG, Sony) uses it's own custom ROM. This should have been handled at the beggining of Android's carreer! It's kind of difficult to deal with it at this moment with this huge penetration of Android on numerous devices! On Fri, Jul 26, 2013 at 3:19 PM, Kostya Vasilyev kman...@gmail.com wrote: The conversation so far, and app testing services, assume that there are certain broken device models / firmwares and they are broken in a deterministic way. This implies that those bad devices can be discovered and excluded or workarounds implemented, again, in a deterministic way. From my experience, it's worse than that. I can get a user bug report that makes my jaw drop to the floor, and have a an exact or similar device on my desk that does not exhibit the issue. Basic things get broken: the app not being able to connect to well known servers, a toast notification getting stuck on the screen, the system ActionBar overflow button not showing on a device without a Menu button, etc. Reinstaling or clearing the Dalvik cache (or some other magic) often resolves these. That itself is a bad sign -- meaning that system level things can randomly break and randomly heal themselves, in a non-deterministic way. Here is a video I made of Galaxy Nexus with 4.0.2 rebooting when trying to start Google Maps, happened every time out of 10 or so I tried: http://www.youtube.com/watch?v=mC4EegjeWZA I fixed it by resetting the device back to factory settings and reinstalling Google Maps, but the question remains: why did this help? Did Google Maps get corrupted during installation? Can it happen to other apps too? I'm not even asking why a modern, preemptively multitasking operating system can enter a reboot triggered by application code. I don't have an answer for this situation either. It's just something I have to deal with every day, costing me a lot of wasted time and a depressed mood. The irony is, users always assume it's the app which must be doing something weird, unlike Windows, where they're quick to blame MS and Bill Gates personally. Must be some kind of Google magic. -- K 2013/7/26 Omer Gilad omer@gmail.com The point of the original post (the concrete question) was beyond just rant and rave - the question asked is How to deal with it. To put in other words - What do you suggest as a practical solution to the problem, beyond just dumping
[android-developers] Dealing with 1000's of different devices, each one with its own bugs
.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 So what do you do when you develop a game, for example, and try to create a high-quality user experience on Google Play? Do you do your QA on 50 different devices? 100? 1000? Or do you just shoot blindly and hope that it works, or wait for users to send you bug reports? 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? I'm really fed up with it. About 50% of my Android development time is wasted on babysitting broken devices. I'm waiting for an official Google response about this, and what have you been doing in all those years to fix that. I've heard about things like conformance tests for devices and so on, but the reality is far from acceptable in this area. ,Looking forward for helpful responses Omer -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
My solution: banging my head against the wall really hard. Fed up with it too. Maybe I picked the wrong line of work, and should become a garbage truck driver instead. It's not just crashes, it's things that some devices do, which break the UI in significant (to the users) ways. Nothing like getting emails like this window doesn't scroll the right way or text selection not working -- -- on my Samsung Blah Blah Platinum Plus Gold Pro model XXXZZZ3433, firmware XXjjjuui384u8934, but also reproducible with firmware 887jjhXXX. Google certified with preinstalled Play, of course. -- K 2013/7/26 Omer Gilad omer.gi...@gmail.com: .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 So what do you do when you develop a game, for example, and try to create a high-quality user experience on Google Play? Do you do your QA on 50 different devices? 100? 1000? Or do you just shoot blindly and hope that it works, or wait for users to send you bug reports? 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? I'm really fed up with it. About 50% of my Android development time is wasted on babysitting broken devices. I'm waiting for an official Google response about this, and what have you been doing in all those years to fix that. I've heard about things like conformance tests for devices and so on, but the reality is far from acceptable in this area. ,Looking forward for helpful responses Omer -- -- 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. -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
This is basically what the CTS enforcement is attempting to rectify: but it's obviously not a perfect solution. Many small developers just accept this as fact, and handle only the API. Bigger developers are forced to deal with the real problems, and then it's a matter of extensive knowledge, testing, metaprogramming, etc... Kris On Thu, Jul 25, 2013 at 6:39 PM, Omer Gilad omer.gi...@gmail.com 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 So what do you do when you develop a game, for example, and try to create a high-quality user experience on Google Play? Do you do your QA on 50 different devices? 100? 1000? Or do you just shoot blindly and hope that it works, or wait for users to send you bug reports? 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? I'm really fed up with it. About 50% of my Android development time is wasted on babysitting broken devices. I'm waiting for an official Google response about this, and what have you been doing in all those years to fix that. I've heard about things like conformance tests for devices and so on, but the reality is far from acceptable in this area. ,Looking forward for helpful responses Omer -- -- 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. -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
I've found that even the biggest app developers like Skype, Gameloft, etc. have device issues, and they don't look in such a good shape. Just scan the reviews of any super-popular Android app, and you can see the same disease... This app doesn't even work, it sucks, and I PAID FOR IT! (from some crappy device). Obviously, those bigger developers have the budget and capacity to own 100's or Android devices and run a big QA department. What is an independent developer, or even a small startup supposed to do? The solution that me and my partners decided on is to aggressively filter down any device that gives us bad ratings in Google Play (from the developer console). That feels like taking painkillers when you have a broken leg. On Friday, July 26, 2013 2:47:49 AM UTC+3, Kristopher Micinski wrote: This is basically what the CTS enforcement is attempting to rectify: but it's obviously not a perfect solution. Many small developers just accept this as fact, and handle only the API. Bigger developers are forced to deal with the real problems, and then it's a matter of extensive knowledge, testing, metaprogramming, etc... Kris On Thu, Jul 25, 2013 at 6:39 PM, Omer Gilad omer@gmail.comjavascript: 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 So what do you do when you develop a game, for example, and try to create a high-quality user experience on Google Play? Do you do your QA on 50 different devices? 100? 1000? Or do you just shoot blindly and hope that it works, or wait for users to send you bug reports? 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? I'm really fed up with it. About 50% of my Android development time is wasted on babysitting broken devices. I'm waiting for an official Google response about this, and what have you been doing in all those years to fix that. I've heard about things like conformance tests for devices and so on, but the reality is far from acceptable in this area. ,Looking forward for helpful responses Omer -- -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-d...@googlegroups.comjavascript: To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com javascript: 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 javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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.
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
There are potential solutions, but in practice it's a constant battle. Certainly there are people that provide internet based test services that test your app on huge numbers of devices for a subscription based fee. Kris On Thu, Jul 25, 2013 at 8:12 PM, Omer Gilad omer.gi...@gmail.com wrote: I've found that even the biggest app developers like Skype, Gameloft, etc. have device issues, and they don't look in such a good shape. Just scan the reviews of any super-popular Android app, and you can see the same disease... This app doesn't even work, it sucks, and I PAID FOR IT! (from some crappy device). Obviously, those bigger developers have the budget and capacity to own 100's or Android devices and run a big QA department. What is an independent developer, or even a small startup supposed to do? The solution that me and my partners decided on is to aggressively filter down any device that gives us bad ratings in Google Play (from the developer console). That feels like taking painkillers when you have a broken leg. On Friday, July 26, 2013 2:47:49 AM UTC+3, Kristopher Micinski wrote: This is basically what the CTS enforcement is attempting to rectify: but it's obviously not a perfect solution. Many small developers just accept this as fact, and handle only the API. Bigger developers are forced to deal with the real problems, and then it's a matter of extensive knowledge, testing, metaprogramming, etc... Kris On Thu, Jul 25, 2013 at 6:39 PM, Omer Gilad omer@gmail.com 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 So what do you do when you develop a game, for example, and try to create a high-quality user experience on Google Play? Do you do your QA on 50 different devices? 100? 1000? Or do you just shoot blindly and hope that it works, or wait for users to send you bug reports? 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? I'm really fed up with it. About 50% of my Android development time is wasted on babysitting broken devices. I'm waiting for an official Google response about this, and what have you been doing in all those years to fix that. I've heard about things like conformance tests for devices and so on, but the reality is far from acceptable in this area. ,Looking forward for helpful responses Omer -- -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-d...@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. -- -- 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. -- -- You received this message because you are subscribed to the Google Groups Android Developers
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
Yes, I've encountered those services. This is still not a solution. It requires substantial money investment, and in a lot of cases it doesn't give you the ability to debug on those devices. Personal example - I'm developing a game, and we've found (after a friend checked it) that it has major display artifacts on Samsung Galaxy S4. No logs or attempts to remotely resolve the issue helped - so we had to get our hands on the device for a day. It turned out that the device's GPU is buggy, and miscalculates some common shader operations (like matrix multiplication). There's no remote testing platform in the world that can assist you in resolving issues like that. The issue is at the core, and must be solved at a design and attitude level - devices like that SHOULD NOT be allowed to run Google Play apps (and of course, they should be deprived of their certification), until the vendor fixes those issues. On Friday, July 26, 2013 3:27:49 AM UTC+3, Kristopher Micinski wrote: There are potential solutions, but in practice it's a constant battle. Certainly there are people that provide internet based test services that test your app on huge numbers of devices for a subscription based fee. Kris On Thu, Jul 25, 2013 at 8:12 PM, Omer Gilad omer@gmail.comjavascript: wrote: I've found that even the biggest app developers like Skype, Gameloft, etc. have device issues, and they don't look in such a good shape. Just scan the reviews of any super-popular Android app, and you can see the same disease... This app doesn't even work, it sucks, and I PAID FOR IT! (from some crappy device). Obviously, those bigger developers have the budget and capacity to own 100's or Android devices and run a big QA department. What is an independent developer, or even a small startup supposed to do? The solution that me and my partners decided on is to aggressively filter down any device that gives us bad ratings in Google Play (from the developer console). That feels like taking painkillers when you have a broken leg. On Friday, July 26, 2013 2:47:49 AM UTC+3, Kristopher Micinski wrote: This is basically what the CTS enforcement is attempting to rectify: but it's obviously not a perfect solution. Many small developers just accept this as fact, and handle only the API. Bigger developers are forced to deal with the real problems, and then it's a matter of extensive knowledge, testing, metaprogramming, etc... Kris On Thu, Jul 25, 2013 at 6:39 PM, Omer Gilad omer@gmail.com 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 So what do you do when you develop a game, for example, and try to create a high-quality user experience on Google Play? Do you do your QA on 50 different devices? 100? 1000? Or do you just shoot blindly and hope that it works, or wait for users to send you bug reports? 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? I'm really fed up with it. About 50% of my Android development time is wasted on babysitting broken devices. I'm waiting for an official Google response about this, and what have you been doing in all those years to fix that. I've heard about things like conformance tests for devices and so on, but the reality is far from acceptable in this area. ,Looking forward for helpful responses Omer -- -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-d...@googlegroups.com To unsubscribe from this group, send email to
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
Your last paragraph is *exactly* what the CTS is all about, but obviously if you don't work for google you can't mandate what goes in and what does not :-). I'm not recommending that these services are the solution to everyone's problems: but I do contend they get you farther than you would be otherwise. Games are particularly hard to test, since GPUs vary more widely across devices and aren't part of the most common pieces of the SDK. The fact of the matter is, there are always going to be hacked up ROMs running on the market: that's the design decision made by Android. The CTS helps get you farther to a holistic / cohesive platform, but in the end it's a numbers game: knowing which devices, API levels, user bases, countries, etc.. to care about is something the experienced developer has to have a handle on. Kris On Thu, Jul 25, 2013 at 9:05 PM, Omer Gilad omer.gi...@gmail.com wrote: Yes, I've encountered those services. This is still not a solution. It requires substantial money investment, and in a lot of cases it doesn't give you the ability to debug on those devices. Personal example - I'm developing a game, and we've found (after a friend checked it) that it has major display artifacts on Samsung Galaxy S4. No logs or attempts to remotely resolve the issue helped - so we had to get our hands on the device for a day. It turned out that the device's GPU is buggy, and miscalculates some common shader operations (like matrix multiplication). There's no remote testing platform in the world that can assist you in resolving issues like that. The issue is at the core, and must be solved at a design and attitude level - devices like that SHOULD NOT be allowed to run Google Play apps (and of course, they should be deprived of their certification), until the vendor fixes those issues. On Friday, July 26, 2013 3:27:49 AM UTC+3, Kristopher Micinski wrote: There are potential solutions, but in practice it's a constant battle. Certainly there are people that provide internet based test services that test your app on huge numbers of devices for a subscription based fee. Kris On Thu, Jul 25, 2013 at 8:12 PM, Omer Gilad omer@gmail.com wrote: I've found that even the biggest app developers like Skype, Gameloft, etc. have device issues, and they don't look in such a good shape. Just scan the reviews of any super-popular Android app, and you can see the same disease... This app doesn't even work, it sucks, and I PAID FOR IT! (from some crappy device). Obviously, those bigger developers have the budget and capacity to own 100's or Android devices and run a big QA department. What is an independent developer, or even a small startup supposed to do? The solution that me and my partners decided on is to aggressively filter down any device that gives us bad ratings in Google Play (from the developer console). That feels like taking painkillers when you have a broken leg. On Friday, July 26, 2013 2:47:49 AM UTC+3, Kristopher Micinski wrote: This is basically what the CTS enforcement is attempting to rectify: but it's obviously not a perfect solution. Many small developers just accept this as fact, and handle only the API. Bigger developers are forced to deal with the real problems, and then it's a matter of extensive knowledge, testing, metaprogramming, etc... Kris On Thu, Jul 25, 2013 at 6:39 PM, Omer Gilad omer@gmail.com 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 So what do you do when you develop a game, for example, and try to create a high-quality user experience on Google Play? Do you do your QA on 50 different devices? 100? 1000? Or do you just shoot blindly and hope that it works, or wait for users to send you bug reports? 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
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
I agree that it's better than nothing. But, since it's a paid service that has nothing to do with the official SDK, it doesn't come in the SDK's favor at all. The problem appears in much more obvious parts of the SDK than the one I presented. I can give countless examples on demand and I'm sure others can too. Also, I never even bothered to fix custom ROMs and such - this is really beyond my scope. I'm having constant issues with stock, popular devices from Samsung, HTC, etc. - the ones that get shipped in the millions and dominate the Google Play statistics. As you said, statistics are also a temporary solution to the issue - just focus on workarounds for the most popular buggy devices - mainly the Samsung Galaxy series and its endless variations. On Friday, July 26, 2013 4:33:52 AM UTC+3, Kristopher Micinski wrote: Your last paragraph is *exactly* what the CTS is all about, but obviously if you don't work for google you can't mandate what goes in and what does not :-). I'm not recommending that these services are the solution to everyone's problems: but I do contend they get you farther than you would be otherwise. Games are particularly hard to test, since GPUs vary more widely across devices and aren't part of the most common pieces of the SDK. The fact of the matter is, there are always going to be hacked up ROMs running on the market: that's the design decision made by Android. The CTS helps get you farther to a holistic / cohesive platform, but in the end it's a numbers game: knowing which devices, API levels, user bases, countries, etc.. to care about is something the experienced developer has to have a handle on. Kris On Thu, Jul 25, 2013 at 9:05 PM, Omer Gilad omer@gmail.comjavascript: wrote: Yes, I've encountered those services. This is still not a solution. It requires substantial money investment, and in a lot of cases it doesn't give you the ability to debug on those devices. Personal example - I'm developing a game, and we've found (after a friend checked it) that it has major display artifacts on Samsung Galaxy S4. No logs or attempts to remotely resolve the issue helped - so we had to get our hands on the device for a day. It turned out that the device's GPU is buggy, and miscalculates some common shader operations (like matrix multiplication). There's no remote testing platform in the world that can assist you in resolving issues like that. The issue is at the core, and must be solved at a design and attitude level - devices like that SHOULD NOT be allowed to run Google Play apps (and of course, they should be deprived of their certification), until the vendor fixes those issues. On Friday, July 26, 2013 3:27:49 AM UTC+3, Kristopher Micinski wrote: There are potential solutions, but in practice it's a constant battle. Certainly there are people that provide internet based test services that test your app on huge numbers of devices for a subscription based fee. Kris On Thu, Jul 25, 2013 at 8:12 PM, Omer Gilad omer@gmail.com wrote: I've found that even the biggest app developers like Skype, Gameloft, etc. have device issues, and they don't look in such a good shape. Just scan the reviews of any super-popular Android app, and you can see the same disease... This app doesn't even work, it sucks, and I PAID FOR IT! (from some crappy device). Obviously, those bigger developers have the budget and capacity to own 100's or Android devices and run a big QA department. What is an independent developer, or even a small startup supposed to do? The solution that me and my partners decided on is to aggressively filter down any device that gives us bad ratings in Google Play (from the developer console). That feels like taking painkillers when you have a broken leg. On Friday, July 26, 2013 2:47:49 AM UTC+3, Kristopher Micinski wrote: This is basically what the CTS enforcement is attempting to rectify: but it's obviously not a perfect solution. Many small developers just accept this as fact, and handle only the API. Bigger developers are forced to deal with the real problems, and then it's a matter of extensive knowledge, testing, metaprogramming, etc... Kris On Thu, Jul 25, 2013 at 6:39 PM, Omer Gilad omer@gmail.com 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,
