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
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
[android-developers] Re: Dealing with 1000's of different devices, each one with its own bugs
I just came upon this by accident http://officialandroid.blogspot.co.il/2012/09/the-benefits-importance-of-compatibility.html This seems like the right approach, but my own experience is that the Android reality is very far from this ideal. I've heard about the CTS. The question is - are vendors actually forced to pass the CTS with their customizations? On Friday, July 26, 2013 1:39:14 AM UTC+3, 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 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
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.
[android-developers] Re: Dealing with 1000's of different devices, each one with its own bugs
Hey Mike I still didn't get answers to my questions about this service... What are the remote devices that the code is running on? Do I need to instruct a user to install this on his own device? On Monday, July 29, 2013 8:56:12 PM UTC+3, Mike wrote: Use my App, you can run code on remote device, not just read logs: https://cloudshellapp.appspot.com/ https://play.google.com/store/apps/details?id=com.cloudshell The App will allow you to run code on remote Android phones, so you can fix the bug on the phone you do not have physical access to. On Monday, July 29, 2013 2:57:18 AM UTC-4, Piren wrote: Well, after i started encountering such issues i just LOADED my app with debugging information, like, seriously redonkulous amounts of logging. There's nothing the app didn't log, sorted with tags and extra information to say exactly what is doing on and why. It was easier to fix bugs of even things i did not have in my hand... heck, most of the bugs i solved were of devices i never even held. (all the logs were surrounded by a constant variable that was set during compilation, so that code never made it to release versions, it makes it easier to manage app versions). I guess that will not be as easy to do with a game, but it should still be better than what you have now. You can make it a feature of the app, let the user community engage with you (the developer) and actively participate in the creation of the game and what not... you'll solve bugs, they'll feel as a contributer and get their apps running better. If your game is a paid game, make sure the debug versions are limited in capability and will only be good for debugging. On Monday, July 29, 2013 12:29:25 AM UTC+3, Omer Gilad wrote: What you wrote is the obvious part of what I do - test with beta users. I agree that this is a must. The problem is, sometimes it's impossible to debug what you find. When the issue is not a simple crash stack trace - but rather some behavior, or display issue, you can't just keep ping-ponging versions with a user without wasting whole days on that... You need the device in your hand. And as an indie developer, it's practically impossible to get a hold of many different devices. On Sunday, July 28, 2013 12:47:30 PM UTC+3, Piren wrote: Wrote a lengthy response but my browser decided not to post it, so here's the short version: - That's a known problem with android development, it was obvious about a couple of months after it came out. when the premise of the system is to be open and as varied as possible, this kind of issues are a given. - Under your limitations, the best approach is to release the app only to a small subset of devices it was tested on and expand that subset as time goes on. Use an open beta group for devices you do not have access to. Even Netflix was released on only 5 devices. - iOS development might not have this issue (it has fragmentation, but it isn't the same as android's), but over all i believe android has a more developer friendly ecosystem... instead of being frustrated with this, you'll find more than enough other iOS specific issues that will frustrate you.. especially since you're used to how Android is. On Friday, July 26, 2013 1:39:14 AM UTC+3, 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 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
[android-developers] Re: Dealing with 1000's of different devices, each one with its own bugs
What you wrote is the obvious part of what I do - test with beta users. I agree that this is a must. The problem is, sometimes it's impossible to debug what you find. When the issue is not a simple crash stack trace - but rather some behavior, or display issue, you can't just keep ping-ponging versions with a user without wasting whole days on that... You need the device in your hand. And as an indie developer, it's practically impossible to get a hold of many different devices. On Sunday, July 28, 2013 12:47:30 PM UTC+3, Piren wrote: Wrote a lengthy response but my browser decided not to post it, so here's the short version: - That's a known problem with android development, it was obvious about a couple of months after it came out. when the premise of the system is to be open and as varied as possible, this kind of issues are a given. - Under your limitations, the best approach is to release the app only to a small subset of devices it was tested on and expand that subset as time goes on. Use an open beta group for devices you do not have access to. Even Netflix was released on only 5 devices. - iOS development might not have this issue (it has fragmentation, but it isn't the same as android's), but over all i believe android has a more developer friendly ecosystem... instead of being frustrated with this, you'll find more than enough other iOS specific issues that will frustrate you.. especially since you're used to how Android is. On Friday, July 26, 2013 1:39:14 AM UTC+3, 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 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.
[android-developers] Re: Dealing with 1000's of different devices, each one with its own bugs
That looks innovative, I'll definitely dig into this... How versatile is this solution? Can you run only a select part of Android APIs, wrapped by your script? How is the distribution being done (like, where are all those devices that run the test code)? On Sunday, July 28, 2013 10:05:54 PM UTC+3, Mike wrote: I wrote an free App and web site to help myself on the Android fragmentation problem: https://cloudshellapp.appspot.com/ https://play.google.com/store/apps/details?id=com.cloudshell The App will allow you to run code on remote Android phones, so you can fix the bug on the phone you do not have physical access to. I asked my friend in cell phone store to test on the different Android phones, then I will remote read the log and test the code. On Thursday, July 25, 2013 6:39:14 PM UTC-4, 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 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.
[android-developers] Re: Dealing with 1000's of different devices, each one with its own bugs
The best workaround I know for that is to filter devices on Google Play console. Yes, you lose tons of customers, but at least you don't get 1 star reviews like IT SHOWS BLACK SCREEN ON MY CRAPSUNG S4 CRAP EDITION, DON'T DOWNLOAD On Sunday, July 28, 2013 11:51:32 PM UTC+3, Thomas Jakway wrote: Does anyone have a workaround for one of the bigger problems of this mess: users will blame your app and write bad reviews? That sounds like a joke, but really, has anyone had success just telling users sorry, Samsung's fault :(? Would be a shame to lose sales because of the vendor's problems. On Thursday, July 25, 2013 3:39:14 PM UTC-7, 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 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] Re: Dealing with 1000's of different devices, each one with its own bugs
With all this talk I still haven't seen an example of a testing service that can actually help me... Got any links? Anything with a reasonable price that can ease the pain (and that you used for yourself)? BTW, I have worked in the past with some of those remote device providers (like http://www.keynotedeviceanywhere.com/). It's very expensive to get a few hours with a device, especially if this is something you have to do constantly with different devices each time there's an issue. And the deal-breaker part - it's so slow, you'll actually have to waste a whole hour just on installing your app and seeing LogCat. On Monday, July 29, 2013 12:48:16 AM UTC+3, Kristopher Micinski wrote: So in this case, how does a subscription based test service not help you? I'm not saying that a concrete one exists, but I think this kind of debugging service (or coop, essentially) would be a good tool. You include a time metric, do some tasks to help other developers', and they do some work of doing yours. One of the problems here is the heterogenous distribution of devices, but I don't think that's an inherent limitation. I've thought about starting up one of these services for a while, but don't really have the resources to do so. (I think in my previous posts you thought I was advocating a pushbutton testing service: I wasn't. But the point still stands: if you want to test on greater devices, do it with a service and possibly humans in the loop. Big testing services should integrate this work cycle too, for when pushbutton tests don't work...) Kris On Sun, Jul 28, 2013 at 5:29 PM, Omer Gilad omer@gmail.comjavascript: wrote: What you wrote is the obvious part of what I do - test with beta users. I agree that this is a must. The problem is, sometimes it's impossible to debug what you find. When the issue is not a simple crash stack trace - but rather some behavior, or display issue, you can't just keep ping-ponging versions with a user without wasting whole days on that... You need the device in your hand. And as an indie developer, it's practically impossible to get a hold of many different devices. On Sunday, July 28, 2013 12:47:30 PM UTC+3, Piren wrote: Wrote a lengthy response but my browser decided not to post it, so here's the short version: - That's a known problem with android development, it was obvious about a couple of months after it came out. when the premise of the system is to be open and as varied as possible, this kind of issues are a given. - Under your limitations, the best approach is to release the app only to a small subset of devices it was tested on and expand that subset as time goes on. Use an open beta group for devices you do not have access to. Even Netflix was released on only 5 devices. - iOS development might not have this issue (it has fragmentation, but it isn't the same as android's), but over all i believe android has a more developer friendly ecosystem... instead of being frustrated with this, you'll find more than enough other iOS specific issues that will frustrate you.. especially since you're used to how Android is. On Friday, July 26, 2013 1:39:14 AM UTC+3, 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 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
Re: [android-developers] Re: Dealing with 1000's of different devices, each one with its own bugs
I'm amused by what came to my mind because of what you wrote - I thought of having a website like that for mutual testing between Android developers. We can call it DroidSurfing (like CouchSurfing), and the point is simple - registered like-minded Android developers let your code surf on their devices, and in exchange you provide the same luxury for other developers. Of course, some minimal reputation monitoring is required, just to prevent malicious developers from spreading false results or from distributing someone's paid app for free... On Monday, July 29, 2013 1:14:48 AM UTC+3, Kristopher Micinski wrote: I didn't posit that there were concrete things you could go out and buy right now, so apologies if I misphrased. I know a group who works on a research project which does basically this, but there's no word on whether it will be open source any time soon. I think the idea is what I just mentioned, collaborative crowd based testing services that allow you to test on a wide range and variety of devices with very expressive test scripts and possible end user testing when applicable. Kris On Sun, Jul 28, 2013 at 6:05 PM, Omer Gilad omer@gmail.comjavascript: wrote: With all this talk I still haven't seen an example of a testing service that can actually help me... Got any links? Anything with a reasonable price that can ease the pain (and that you used for yourself)? BTW, I have worked in the past with some of those remote device providers (like http://www.keynotedeviceanywhere.com/). It's very expensive to get a few hours with a device, especially if this is something you have to do constantly with different devices each time there's an issue. And the deal-breaker part - it's so slow, you'll actually have to waste a whole hour just on installing your app and seeing LogCat. On Monday, July 29, 2013 12:48:16 AM UTC+3, Kristopher Micinski wrote: So in this case, how does a subscription based test service not help you? I'm not saying that a concrete one exists, but I think this kind of debugging service (or coop, essentially) would be a good tool. You include a time metric, do some tasks to help other developers', and they do some work of doing yours. One of the problems here is the heterogenous distribution of devices, but I don't think that's an inherent limitation. I've thought about starting up one of these services for a while, but don't really have the resources to do so. (I think in my previous posts you thought I was advocating a pushbutton testing service: I wasn't. But the point still stands: if you want to test on greater devices, do it with a service and possibly humans in the loop. Big testing services should integrate this work cycle too, for when pushbutton tests don't work...) Kris On Sun, Jul 28, 2013 at 5:29 PM, Omer Gilad omer@gmail.com wrote: What you wrote is the obvious part of what I do - test with beta users. I agree that this is a must. The problem is, sometimes it's impossible to debug what you find. When the issue is not a simple crash stack trace - but rather some behavior, or display issue, you can't just keep ping-ponging versions with a user without wasting whole days on that... You need the device in your hand. And as an indie developer, it's practically impossible to get a hold of many different devices. On Sunday, July 28, 2013 12:47:30 PM UTC+3, Piren wrote: Wrote a lengthy response but my browser decided not to post it, so here's the short version: - That's a known problem with android development, it was obvious about a couple of months after it came out. when the premise of the system is to be open and as varied as possible, this kind of issues are a given. - Under your limitations, the best approach is to release the app only to a small subset of devices it was tested on and expand that subset as time goes on. Use an open beta group for devices you do not have access to. Even Netflix was released on only 5 devices. - iOS development might not have this issue (it has fragmentation, but it isn't the same as android's), but over all i believe android has a more developer friendly ecosystem... instead of being frustrated with this, you'll find more than enough other iOS specific issues that will frustrate you.. especially since you're used to how Android is. On Friday, July 26, 2013 1:39:14 AM UTC+3, 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
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
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
[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
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
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 android-developers+unsubscr
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
[android-developers] Running code right after installation
Hi, I am looking for a way to run code right after being installed - without waiting for activity launch\boot\etc. I have used the following manifest declaration: receiver android:name =xxx.yyy.zzz.PackageInstallReceiver intent-filter action android:name=android.intent.action.PACKAGE_ADDED/ action android:name=android.intent.action.PACKAGE_REMOVED/ data android:scheme=package / /intent-filter /receiver And created a BroadcastReceiver - my onReceive gets called only after another package is being installed, not my own. Thanks in advance! -- 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
[android-developers] Activity won't display on Motorola Milestone
Hi, I've encountered a weird situation on Motorola Milestone where an activity (started from background) doesn't get displayed visually on the screen, although it thinks it does (onCreate() gets called, ActivityManager logs Displayed activity XXX...). It doesn't happen on other devices so I know it is not a code problem. On Milestone, it doesn't happen 100% of the time and it seems random. The effect, from a user's point of view, is that the touch doesn't work. The activity is running by all means, and taking touch events, it just doesn't show on the screen itself and makes the user think that the activity behind it is running. Has anyone experienced that? Thanks -- 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
[android-developers] Launching an activity with the task affinity of the phone application
Hi, I want to launch an activity that will display on top of the native phone application as a dialog. I suppose that the best way to do that is to launch as a new task, with the task affinity of the phone application. How can I safely obtain the correct task affinity? Is that the best solution for this case? Thanks -- 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
[android-developers] Re: WebView native crash when overriding WebChromeClient.onCreateWindow()
New issue opened: http://code.google.com/p/android/issues/detail?id=11655 -- 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
[android-developers] Re: WebView native crash when overriding WebChromeClient.onCreateWindow()
I'm jumping it. Could anyone help? On Sep 21, 10:32 am, Omer Gilad omer.gi...@gmail.com wrote: Hello, I'm using a webview inside my application in order to display a web interface. One part of the web interface is a javascript that opens a popup. I'm currently attempting to use onCreateWindow exactly as documented, and after the call finishes (And a new window is supposed to be created), there's a native crash in libwebcore.so: 09-20 19:36:53.953: INFO/DEBUG(1523): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 09-20 19:36:53.953: INFO/DEBUG(1523): Build fingerprint: 'google/ passion/passion/mahimahi:2.2/FRF91/43546:user/release-keys' 09-20 19:36:53.953: INFO/DEBUG(1523): pid: 5185, tid: 5215 com.fring 09-20 19:36:53.964: INFO/DEBUG(1523): signal 11 (SIGSEGV), fault addr 0064 09-20 19:36:53.973: INFO/DEBUG(1523): r0 r1 0035b8b4 r2 r3 419df178 09-20 19:36:53.973: INFO/DEBUG(1523): r4 r5 00408f20 r6 r7 0001 09-20 19:36:53.983: INFO/DEBUG(1523): r8 47788101 r9 4988 10 a87dcb20 fp 4879e2b8 09-20 19:36:53.983: INFO/DEBUG(1523): ip afc010c4 sp 4879de00 lr a8490047 pc a83dac90 cpsr 0030 09-20 19:36:53.993: INFO/DEBUG(1523): d0 643a64696f72646e d1 6472656767756265 09-20 19:36:53.993: INFO/DEBUG(1523): d2 002e0034002f0064 d3 006f004d0020 09-20 19:36:53.993: INFO/DEBUG(1523): d4 0065006c00690062 d5 0066006100530020 09-20 19:36:54.003: INFO/DEBUG(1523): d6 002f006900720061 d7 002e003300330035 09-20 19:36:54.003: INFO/DEBUG(1523): d8 40004354 d9 006a 09-20 19:36:54.013: INFO/DEBUG(1523): d10 d11 09-20 19:36:54.013: INFO/DEBUG(1523): d12 d13 09-20 19:36:54.013: INFO/DEBUG(1523): d14 d15 09-20 19:36:54.013: INFO/DEBUG(1523): d16 145f44a048b8 d17 09-20 19:36:54.023: INFO/DEBUG(1523): d18 4129d132 d19 4020 09-20 19:36:54.023: INFO/DEBUG(1523): d20 3ff0 d21 09-20 19:36:54.023: INFO/DEBUG(1523): d22 d23 09-20 19:36:54.023: INFO/DEBUG(1523): d24 d25 3fd56000 09-20 19:36:54.023: INFO/DEBUG(1523): d26 d27 3fd56000 09-20 19:36:54.023: INFO/DEBUG(1523): d28 002000200020001b d29 3ff0 09-20 19:36:54.023: INFO/DEBUG(1523): d30 d31 3ff0 09-20 19:36:54.033: INFO/DEBUG(1523): scr 6013 09-20 19:36:54.053: INFO/DEBUG(1523): #00 pc 000dac90 / system/lib/libwebcore.so 09-20 19:36:54.053: INFO/DEBUG(1523): #01 pc 00190042 / system/lib/libwebcore.so 09-20 19:36:54.063: INFO/DEBUG(1523): code around pc: 09-20 19:36:54.063: INFO/DEBUG(1523): a83dac70 ef98f790 b1086e78 e0023004 18e44b02 09-20 19:36:54.063: INFO/DEBUG(1523): a83dac80 bdfe68a0 003f8778 6080 4604b570 09-20 19:36:54.063: INFO/DEBUG(1523): a83dac90 460d6e40 3004b138 fd98f030 6e60b918 09-20 19:36:54.073: INFO/DEBUG(1523): a83daca0 f0014621 4628fed3 fd90f030 b1104606 09-20 19:36:54.073: INFO/DEBUG(1523): a83dacb0 66636e23 6e20e00a ffa8f7ff 46286626 09-20 19:36:54.073: INFO/DEBUG(1523): code around lr: 09-20 19:36:54.073: INFO/DEBUG(1523): a8490024 f0084630 4606fb2f f741b158 4606f98b 09-20 19:36:54.073: INFO/DEBUG(1523): a8490034 f7414620 f74af987 4601fe01 f74a4630 09-20 19:36:54.073: INFO/DEBUG(1523): a8490044 b145fe23 2b01682b 3b01d002 e002602b 09-20 19:36:54.083: INFO/DEBUG(1523): a8490054 f6dc4628 4630feff ecbdb003 bdf08b02 09-20 19:36:54.083: INFO/DEBUG(1523): a8490064 f6dc2008 4621ff11 f74e4605 f896f81f 09-20 19:36:54.083: INFO/DEBUG(1523): stack: 09-20 19:36:54.083: INFO/DEBUG(1523): 4879ddc0 419df178 /dev/ ashmem/dalvik-LinearAlloc (deleted) 09-20 19:36:54.083: INFO/DEBUG(1523): 4879ddc4 80844e51 /system/ lib/libdvm.so 09-20 19:36:54.083: INFO/DEBUG(1523): 4879ddc8 a87d9df4 /system/ lib/libwebcore.so 09-20 19:36:54.094: INFO/DEBUG(1523): 4879ddcc a87d33c0 /system/ lib/libwebcore.so 09-20 19:36:54.094: INFO/DEBUG(1523): 4879ddd0 a87d9440 /system/ lib/libwebcore.so 09-20 19:36:54.094: INFO/DEBUG(1523): 4879ddd4 a87d9444 /system/ lib/libwebcore.so 09-20 19:36:54.094: INFO/DEBUG(1523): 4879ddd8 00259bd8 [heap] 09-20 19:36:54.094: INFO/DEBUG(1523): 4879dddc afd0cd31 /system/ lib/libc.so 09-20 19:36:54.094: INFO/DEBUG(1523): 4879dde0 a87d9444 /system/ lib/libwebcore.so 09-20 19:36:54.094: INFO/DEBUG(1523): 4879dde4 afc00877 /system/ lib/libstdc++.so 09-20 19:36:54.104: INFO/DEBUG(1523): 4879dde8 a87d33c0 /system/ lib/libwebcore.so 09-20 19:36:54.104: INFO/DEBUG(1523): 4879ddec a83dac75 /system/ lib/libwebcore.so 09-20 19:36:54.104: INFO/DEBUG(1523): 4879ddf0 00259bd8 [heap] 09-20 19:36:54.104: INFO/DEBUG(1523): 4879ddf4
[android-developers] Re: Problem with AudioRecord on Samsung Moment
Samsung devices (all of them) have many bugs related to audio API. In our application we've handled this by applying specific solutions to known device models - you will have to investigate and find workarounds for that. On Sep 26, 4:05 am, Steve Hugg hun...@fasterlight.com wrote: We have been getting reports of audio recording not working on Samsung Moment phones on 2.1-update1. int bufferSize = AudioRecord.getMinBufferSize(sampleRate, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); this.audioRecord = new AudioRecord(MediaRecorder.AudioSource.MIC, sampleRate, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSize); generates these logs: I/AudioPolicyManager( 1889): getInput() inputSource 1, samplingRate 16000, format 1, channels 10, acoustics 0 W/AudioHardwareALSA( 1889): openInputStream : mInput already exists!! E/AudioRecord( 2618): Could not get audio input for record source 1 E/AudioRecord-JNI( 2618): Error creating AudioRecord instance: initialization check failed. E/AudioRecord-Java( 2618): [ android.media.AudioRecord ] Error code -20 when initializing native AudioRecord object. I can't find the mInput already exists anywhere in the source base, could this perhaps be an error message included by the OEM? Thanks! -- 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
[android-developers] WebView native crash when overriding WebChromeClient.onCreateWindow()
Hello, I'm using a webview inside my application in order to display a web interface. One part of the web interface is a javascript that opens a popup. I'm currently attempting to use onCreateWindow exactly as documented, and after the call finishes (And a new window is supposed to be created), there's a native crash in libwebcore.so: 09-20 19:36:53.953: INFO/DEBUG(1523): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 09-20 19:36:53.953: INFO/DEBUG(1523): Build fingerprint: 'google/ passion/passion/mahimahi:2.2/FRF91/43546:user/release-keys' 09-20 19:36:53.953: INFO/DEBUG(1523): pid: 5185, tid: 5215 com.fring 09-20 19:36:53.964: INFO/DEBUG(1523): signal 11 (SIGSEGV), fault addr 0064 09-20 19:36:53.973: INFO/DEBUG(1523): r0 r1 0035b8b4 r2 r3 419df178 09-20 19:36:53.973: INFO/DEBUG(1523): r4 r5 00408f20 r6 r7 0001 09-20 19:36:53.983: INFO/DEBUG(1523): r8 47788101 r9 4988 10 a87dcb20 fp 4879e2b8 09-20 19:36:53.983: INFO/DEBUG(1523): ip afc010c4 sp 4879de00 lr a8490047 pc a83dac90 cpsr 0030 09-20 19:36:53.993: INFO/DEBUG(1523): d0 643a64696f72646e d1 6472656767756265 09-20 19:36:53.993: INFO/DEBUG(1523): d2 002e0034002f0064 d3 006f004d0020 09-20 19:36:53.993: INFO/DEBUG(1523): d4 0065006c00690062 d5 0066006100530020 09-20 19:36:54.003: INFO/DEBUG(1523): d6 002f006900720061 d7 002e003300330035 09-20 19:36:54.003: INFO/DEBUG(1523): d8 40004354 d9 006a 09-20 19:36:54.013: INFO/DEBUG(1523): d10 d11 09-20 19:36:54.013: INFO/DEBUG(1523): d12 d13 09-20 19:36:54.013: INFO/DEBUG(1523): d14 d15 09-20 19:36:54.013: INFO/DEBUG(1523): d16 145f44a048b8 d17 09-20 19:36:54.023: INFO/DEBUG(1523): d18 4129d132 d19 4020 09-20 19:36:54.023: INFO/DEBUG(1523): d20 3ff0 d21 09-20 19:36:54.023: INFO/DEBUG(1523): d22 d23 09-20 19:36:54.023: INFO/DEBUG(1523): d24 d25 3fd56000 09-20 19:36:54.023: INFO/DEBUG(1523): d26 d27 3fd56000 09-20 19:36:54.023: INFO/DEBUG(1523): d28 002000200020001b d29 3ff0 09-20 19:36:54.023: INFO/DEBUG(1523): d30 d31 3ff0 09-20 19:36:54.033: INFO/DEBUG(1523): scr 6013 09-20 19:36:54.053: INFO/DEBUG(1523): #00 pc 000dac90 / system/lib/libwebcore.so 09-20 19:36:54.053: INFO/DEBUG(1523): #01 pc 00190042 / system/lib/libwebcore.so 09-20 19:36:54.063: INFO/DEBUG(1523): code around pc: 09-20 19:36:54.063: INFO/DEBUG(1523): a83dac70 ef98f790 b1086e78 e0023004 18e44b02 09-20 19:36:54.063: INFO/DEBUG(1523): a83dac80 bdfe68a0 003f8778 6080 4604b570 09-20 19:36:54.063: INFO/DEBUG(1523): a83dac90 460d6e40 3004b138 fd98f030 6e60b918 09-20 19:36:54.073: INFO/DEBUG(1523): a83daca0 f0014621 4628fed3 fd90f030 b1104606 09-20 19:36:54.073: INFO/DEBUG(1523): a83dacb0 66636e23 6e20e00a ffa8f7ff 46286626 09-20 19:36:54.073: INFO/DEBUG(1523): code around lr: 09-20 19:36:54.073: INFO/DEBUG(1523): a8490024 f0084630 4606fb2f f741b158 4606f98b 09-20 19:36:54.073: INFO/DEBUG(1523): a8490034 f7414620 f74af987 4601fe01 f74a4630 09-20 19:36:54.073: INFO/DEBUG(1523): a8490044 b145fe23 2b01682b 3b01d002 e002602b 09-20 19:36:54.083: INFO/DEBUG(1523): a8490054 f6dc4628 4630feff ecbdb003 bdf08b02 09-20 19:36:54.083: INFO/DEBUG(1523): a8490064 f6dc2008 4621ff11 f74e4605 f896f81f 09-20 19:36:54.083: INFO/DEBUG(1523): stack: 09-20 19:36:54.083: INFO/DEBUG(1523): 4879ddc0 419df178 /dev/ ashmem/dalvik-LinearAlloc (deleted) 09-20 19:36:54.083: INFO/DEBUG(1523): 4879ddc4 80844e51 /system/ lib/libdvm.so 09-20 19:36:54.083: INFO/DEBUG(1523): 4879ddc8 a87d9df4 /system/ lib/libwebcore.so 09-20 19:36:54.094: INFO/DEBUG(1523): 4879ddcc a87d33c0 /system/ lib/libwebcore.so 09-20 19:36:54.094: INFO/DEBUG(1523): 4879ddd0 a87d9440 /system/ lib/libwebcore.so 09-20 19:36:54.094: INFO/DEBUG(1523): 4879ddd4 a87d9444 /system/ lib/libwebcore.so 09-20 19:36:54.094: INFO/DEBUG(1523): 4879ddd8 00259bd8 [heap] 09-20 19:36:54.094: INFO/DEBUG(1523): 4879dddc afd0cd31 /system/ lib/libc.so 09-20 19:36:54.094: INFO/DEBUG(1523): 4879dde0 a87d9444 /system/ lib/libwebcore.so 09-20 19:36:54.094: INFO/DEBUG(1523): 4879dde4 afc00877 /system/ lib/libstdc++.so 09-20 19:36:54.104: INFO/DEBUG(1523): 4879dde8 a87d33c0 /system/ lib/libwebcore.so 09-20 19:36:54.104: INFO/DEBUG(1523): 4879ddec a83dac75 /system/ lib/libwebcore.so 09-20 19:36:54.104: INFO/DEBUG(1523): 4879ddf0 00259bd8 [heap] 09-20 19:36:54.104: INFO/DEBUG(1523): 4879ddf4 09-20 19:36:54.104: INFO/DEBUG(1523): 4879ddf8 df002777 09-20 19:36:54.113: INFO/DEBUG(1523): 4879ddfc e3a070ad 09-20 19:36:54.113: INFO/DEBUG(1523): #00 4879de00 00357608 [heap] 09-20
[android-developers] Installing new root CA certificate from application
Hello, My application redirects its users to a known domain (secure.gate2shop.com) that its root certificate doesn't exist on Android devices. Normal PC browsers have no problem accessing the site, but Android browser displays to the user that the certificate is untrusted. I don't want that behavior, not even once, so I'm looking for a way to install this certificate on the device from my app. Does anyone know about a way to do that? Thanks -- 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
[android-developers] Re: Accurate sleep()\timer in Android
On Jul 6, 10:38 pm, Dianne Hackborn hack...@android.com wrote: 2. The operation I'm doing involves network activity - UDP\TCP packet sending. Is there good native support for networking that is device independent (like the normal libc, libz)? Or maybe I should ask this in the NDK group? You have extremely strict jitter requirements for something involving NETWORKING? That is... strange. I suspect the jitter happening on the network end is going to way outweigh what is happening on the device. That is true, but I need this kind of optimization. The network path will be very clear in some cases, and there's no reason to introduce extra jitter because of garbage collection. -- 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
[android-developers] Re: Accurate sleep()\timer in Android
Thanks! Doing it in native might be a good idea. 1. Will increasing the thread priority improve accuracy (starving other threads in the meanwhile of course)? 2. The operation I'm doing involves network activity - UDP\TCP packet sending. Is there good native support for networking that is device independent (like the normal libc, libz)? Or maybe I should ask this in the NDK group? On Jul 5, 10:08 pm, Dianne Hackborn hack...@android.com wrote: You are doomed if you just want to be able to schedule exactly 80ms every time so that you add it all up after 1000 times and you get 80 seconds. At the very least, you should schedule your events so that even if there is some jitter in individual timings they add up correctly -- that is start at the current time, then schedule each next event for a successive 80ms from that base time, regardless of when the previous event actually fired. At this point, then, the only question is how much jitter between events you will find acceptable. As Richard said, some big events can cause a fair amount of jitter, in particular GCs. The platform is designed to avoid thrashing through objects and thus not cause GCs, so if you are likewise careful you may be able to do things so that GCs don't happen enough to be an issue. For perspective: on low-end hardware, a GC can take on the order of 100ms; on higher-end devices like the Droid it is more like 30ms. If that is still not sufficient, you may want to consider dropping down to native code and doing the timing in a separate native thread (which thus won't be paused by GCs). Of course you still won't have 100% accurate 80ms every time because there will still be other processes wanting to run at times, though the jitter will be significantly smaller (as long as your process is not in the background scheduling group). On Mon, Jul 5, 2010 at 7:30 AM, Omer Gilad omer.gi...@gmail.com wrote: Hello, Does anyone know of a precise way of measuring 80 milliseconds for scheduling purposes? Thread.sleep() and SystemClock.sleep() don't seem accurate enough. Purpose - I want to schedule a certain event to happen in an exact interval of 80 milliseconds and I don't want the time to skew (scheduling 1000 such events must take 80 seconds in total). Thanks -- 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.comandroid-developers%2Bunsubs cr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Accurate sleep()\timer in Android
Hello, Does anyone know of a precise way of measuring 80 milliseconds for scheduling purposes? Thread.sleep() and SystemClock.sleep() don't seem accurate enough. Purpose - I want to schedule a certain event to happen in an exact interval of 80 milliseconds and I don't want the time to skew (scheduling 1000 such events must take 80 seconds in total). Thanks -- 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
[android-developers] Unexplained error from MediaPlayer
My code tries to play an MP3 file from res/raw.
FileDescriptor fd =
appContext.getResources().openRawResourceFd(R.raw.ringtone)
.getFileDescriptor();
player = new MediaPlayer();
try
{
player.setAudioStreamType(AudioManager.STREAM_RING);
player.setDataSource(fd);
player.prepare();
}
catch (IllegalArgumentException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
player = null;
return;
}
catch (IllegalStateException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
player = null;
return;
}
catch (IOException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
player = null;
return;
}
player.setLooping(true);
player.start();
The log shows:
02-21 15:18:18.360: ERROR/PlayerDriver(51): Command
PLAYER_SET_DATA_SOURCE completed with an error or info
PVMFErrNotSupported
02-21 15:18:18.380: ERROR/MediaPlayer(693): error (1, -4)
02-21 15:18:18.390: WARN/PlayerDriver(51):
PVMFInfoErrorHandlingComplete
After player.prepare() is called.
I really don't have a hint.
I won't use MediaPlayer.create() because I need
player.setAudioStreamType(AudioManager.STREAM_RING);
Would appreciate any help on this...
--
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
[android-developers] Synchronizing AudioTrack and AudioRecord
Hello, My application uses AudioTrack in streaming mode and AudioRecord simultaneously. My problem is that I start them at the same time, but I have no guarantee that they will actually start playback\recording in the same timestamp. The reason I need this kind of accuracy is because I use echo cancellation (subtracting audio played to speaker from the recording). My echo canceller doesn't require an exact delay, but the delay introduced between AudioTrack and AudioRecord moves in the range of 250ms (between different runs), and that's too much - each run is different because they start themselves asynchronously. The API doesn't provide me a way to make sure they start in the same time, so I thought about measuring this starting delay somehow and then using it in my calculation. Does anyone have an idea how to do that, utilizing their API or in any other way? Thanks for any help! -- 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
[android-developers] Problem using AudioRecord in Motorola Milestone
My application uses AudioRecord to record streaming voice. On ANY
OTHER Android device it initializes properly and works great,
excluding Motorola Milestone, which force closes and the log shows:
01-17 14:08:41.124: DEBUG/AudioHardwareMot(1059):
AudioMgr:AudioHardwareMot::openInputStream enter
01-17 14:08:41.124: DEBUG/AudioHardwareMot(1059):
AudioMgr:AudioStreamInMot::set(0xaf00, 4, 1, 10, 8000)
01-17 14:08:41.124: ERROR/AudioRecord(2190): AudioFlinger could not
create record track, status: -22
01-17 14:08:41.124: ERROR/AudioRecord-JNI(2190): Error creating
AudioRecord instance: initialization check failed.
01-17 14:08:41.124: ERROR/AudioRecord-Java(2190):
[ android.media.AudioRecord ] Error code -20 when initializing native
AudioRecord object.
Sometimes it happens, sometimes it doesn't, and looking into the
platform source code doesn't clarify it. It returns with BAD_VALUE
error code. The code in AudioFlinger.cpp that does that:
[CODE]spIAudioRecord AudioFlinger::openRecord(
2890 pid_t pid,
2891 int input,
2892 uint32_t sampleRate,
2893 int format,
2894 int channelCount,
2895 int frameCount,
2896 uint32_t flags,
2897 status_t *status)
2898 {
2899 spRecordThread::RecordTrack recordTrack;
2900 spRecordHandle recordHandle;
2901 spClient client;
2902 wpClient wclient;
2903 status_t lStatus;
2904 RecordThread *thread;
2905 size_t inFrameCount;
2906
2907 // check calling permissions
2908 if (!recordingAllowed()) {
2909 lStatus = PERMISSION_DENIED;
2910 goto Exit;
2911 }
2912
2913 // add client to list
2914 { // scope for mLock
2915 Mutex::Autolock _l(mLock);
2916 thread = checkRecordThread_l(input);
2917 if (thread == NULL) {
2918 lStatus = BAD_VALUE;
2919 goto Exit;
2920 }
2921
2922 wclient = mClients.valueFor(pid);
2923 if (wclient != NULL) {
2924 client = wclient.promote();
2925 } else {
2926 client = new Client(this, pid);
2927 mClients.add(pid, client);
2928 }
2929
2930 // create new record track. The record track uses one
track in mHardwareMixerThread by convention.
2931 recordTrack = new RecordThread::RecordTrack(thread,
client, sampleRate,
2932format,
channelCount, frameCount, flags);
2933 }
2934 if (recordTrack-getCblk() == NULL) {
2935 // remove local strong reference to Client before
deleting the RecordTrack so that the Client
2936 // destructor is called by the TrackBase destructor with
mLock held
2937 client.clear();
2938 recordTrack.clear();
2939 lStatus = NO_MEMORY;
2940 goto Exit;
2941 }
2942
2943 // return to handle to client
2944 recordHandle = new RecordHandle(recordTrack);
2945 lStatus = NO_ERROR;
2946
2947 Exit:
2948 if (status) {
2949 *status = lStatus;
2950 }
2951 return recordHandle;
2952 }[/CODE]
The code that initializes AudioRecord:
[CODE]record = new AudioRecord(MediaRecorder.AudioSource.MIC, 8000,
AudioFormat.CHANNEL_CONFIGURATION_MONO,
AudioFormat.ENCODING_PCM_16BIT,
AudioRecord.getMinBufferSize
(8000,
AudioFormat.CHANNEL_CONFIGURATION_MONO,
AudioFormat.ENCODING_PCM_16BIT) * 4);[/CODE]
Again, it works fine on any other device, including Droid.
Thanks for any help!
--
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
[android-developers] Echo Cancellation
Does anyone know how to use the device's echo cancellation functionality? I'm implementing my custom VoIP and it would save me a lot of work and CPU usage if the device did that for me, like in a GSM \CDMA call. -- 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
[android-developers] DatagramSocket.receive() sometimes blocks for too long
Hello,
I have a thread that constantly polls a UDP connection and posts the
received data to another thread. It uses a connected DatagramSocket,
reads a packet (which is always the same side), gets the data and
posts it to a message queue (not the android one, my implementation).
The problem happens mainly over 3G connection, not wifi.
Code looks like:
protected void work() {
byte[] buffer = new byte[SOME_BUFFER_SIZE];
// Read UDP packet
DatagramPacket packet = new DatagramPacket(buffer, buffer.length);
long startTime = System.currentTimeMillis();
socket.receive(packet);
long elapsed = System.currentTimeMillis() - startTime;
Log.out.d(UDPReader: time for socket read: + elapsed);
// Post the data
messageQueue.post(packet.getData());
}
My server side sends the UDP packets at a constant rate (About 80
millis) and I expect that rate more or less for streaming purposes.
Problem is: in the beginning all is fine (log print shows a good
interval - around 80ms), then there a huge gap (about half a second),
then some packets arrive with no interval at all (like they were
buffered somewhere), then everything gets normal for the rest of the
operation.
So the effect for me is having a glitch in the beginning of the
stream, and the everything is back to normal infinitely.
I verified that my reader thread isn't blocking anywhere else, and
that the socket read elapsed time really covers just the read itself,
so I get reliable log prints (as seen in the code). I also used
wireshark in the server side to verify constant packet rate.
So the 2 left options are:
1. Network issue - but that would happen for the whole duration, not
just in the beginning, right? It always glitches like mad in the
start, then everything is normal.
2. Platform issue - is there anything about DatagramSocket
implementation on Android that might cause this? It seems like there's
an initial capacity for buffering and then it's increased after that
first glitch and it doesn't happen anymore...
I also checked: 1. CPU usage during the glitch and after (using
traceview), nothing unusual. 2. DatagramSocket receive buffer size -
it seems to default to 10+ bytes which is far more than my packet
size.
I would appreciate any help =)
--
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
[android-developers] Blocking on a Socket read operation while in sleep mode
I have code that runs in the background and holds a connected Socket and it's InputStream. It calls read() infinitely until something is received, then continues to parse. Socket timeout is 0 of course. I am interested in what would happen when the device goes to sleep? Is the CPU off? Will this socket be responsive in this case (Say, my server sends some notification)? Thanks -- 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
[android-developers] DatagramSocket.receive() sometimes blocks for too long
Hello,
I have a thread that constantly polls a UDP connection and posts the
received data to another thread. It uses a connected DatagramSocket,
reads a packet (which is always the same side), gets the data and
posts it.
Code looks like:
protected void work() {
byte[] buffer = new byte[SOME_BUFFER_SIZE];
// Read UDP packet
DatagramPacket packet = new DatagramPacket(buffer, buffer.length);
long startTime = System.currentTimeMillis();
socket.receive(packet);
long elapsed = System.currentTimeMillis() - startTime;
Log.out.d(UDPReader: time for socket read: + elapsed);
// Post the data
--
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
