Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
I guess I'm trying to ascertain: is there a concrete question you have, or just a bunch of bad points about how the Android ecosystem sucks right now? If it's the second, everyone agrees it sucks, there's not a good solution. I suppose one thing that Android could have done better from the start was to offer UI modes that would be guaranteed to homogenous across all certified devices. I don't think that I said statistics were a solution to the issue (though apologies if I gave that impression): I meant to merely give the idea that because of Android's fragmentation a good way to get a handle on what you're facing would be to use device install statistics. I never meant to imply that it was in any way a solution. But everyone agrees that fragmentation sucks. Everyone has agreed it sucks since the beginning (even Android 2.0), and people knew it would get *worse*. You have to worry about API levels, screen configurations, hardware configurations, etc... I know of a few groups developing open source test services, that could presumably end up making a co op or something: that would definitely give more leeway than traditional expensive test services. (If people would be interested, this would be possible to do in the community right now: just buy a server, write some code to distribute the APKs with a feedback / review system, etc..) Kris On Thu, Jul 25, 2013 at 10:01 PM, Omer Gilad omer.gi...@gmail.com wrote: I agree that it's better than nothing. But, since it's a paid service that has nothing to do with the official SDK, it doesn't come in the SDK's favor at all. The problem appears in much more obvious parts of the SDK than the one I presented. I can give countless examples on demand and I'm sure others can too. Also, I never even bothered to fix custom ROMs and such - this is really beyond my scope. I'm having constant issues with stock, popular devices from Samsung, HTC, etc. - the ones that get shipped in the millions and dominate the Google Play statistics. As you said, statistics are also a temporary solution to the issue - just focus on workarounds for the most popular buggy devices - mainly the Samsung Galaxy series and its endless variations. On Friday, July 26, 2013 4:33:52 AM UTC+3, Kristopher Micinski wrote: Your last paragraph is *exactly* what the CTS is all about, but obviously if you don't work for google you can't mandate what goes in and what does not :-). I'm not recommending that these services are the solution to everyone's problems: but I do contend they get you farther than you would be otherwise. Games are particularly hard to test, since GPUs vary more widely across devices and aren't part of the most common pieces of the SDK. The fact of the matter is, there are always going to be hacked up ROMs running on the market: that's the design decision made by Android. The CTS helps get you farther to a holistic / cohesive platform, but in the end it's a numbers game: knowing which devices, API levels, user bases, countries, etc.. to care about is something the experienced developer has to have a handle on. Kris On Thu, Jul 25, 2013 at 9:05 PM, Omer Gilad omer@gmail.com wrote: Yes, I've encountered those services. This is still not a solution. It requires substantial money investment, and in a lot of cases it doesn't give you the ability to debug on those devices. Personal example - I'm developing a game, and we've found (after a friend checked it) that it has major display artifacts on Samsung Galaxy S4. No logs or attempts to remotely resolve the issue helped - so we had to get our hands on the device for a day. It turned out that the device's GPU is buggy, and miscalculates some common shader operations (like matrix multiplication). There's no remote testing platform in the world that can assist you in resolving issues like that. The issue is at the core, and must be solved at a design and attitude level - devices like that SHOULD NOT be allowed to run Google Play apps (and of course, they should be deprived of their certification), until the vendor fixes those issues. On Friday, July 26, 2013 3:27:49 AM UTC+3, Kristopher Micinski wrote: There are potential solutions, but in practice it's a constant battle. Certainly there are people that provide internet based test services that test your app on huge numbers of devices for a subscription based fee. Kris On Thu, Jul 25, 2013 at 8:12 PM, Omer Gilad omer@gmail.com wrote: I've found that even the biggest app developers like Skype, Gameloft, etc. have device issues, and they don't look in such a good shape. Just scan the reviews of any super-popular Android app, and you can see the same disease... This app doesn't even work, it sucks, and I PAID FOR IT! (from some crappy device). Obviously, those bigger developers have the budget and capacity to own 100's or
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
The point of the original post (the concrete question) was beyond just rant and rave - the question asked is How to deal with it. To put in other words - What do you suggest as a practical solution to the problem, beyond just dumping Android and developing for iOS. To filter out some possible answers: 1. Buying 50+ devices and doing QA on each one of them is NOT an option. It shouldn't ever be. 2. Paying constantly to remote testing services just to know what bugs we have (without even the ability to debug and resolve them) is NOT an option. 3. Chasing after devices (borrowing from friends, getting debug logs from users, etc.) and writing ugly code for workarounds time after time is what I've been doing for some time, but that is NOT an option. 3. Filtering many devices on Google Play console is our current solution, which is far from ideal as you can imagine. Currently, I don't have an effective way to deal with it, to the point that I've decided to move to another platform - the current state is impossible to cope with. I'm an independent developer, working in cooperation with some people, and we fail to address the fragmentation issue. All our efforts invested in creating a quality product are in vain when it's being run on countless broken devices that we can't keep track of. Just to back myself up - I've been developing for Android for more than 3 years, and have been constantly chasing after devices since the beginning. I experienced that in multiple types of projects (apps and games), as a hired or freelance developer and as an entrepreneur. It applies to every aspect of developing for Android, so this issue can't be evaded. To me, this is far more important than answering the questions on API usage, etc. On Friday, July 26, 2013 2:03:28 PM UTC+3, Kristopher Micinski wrote: I guess I'm trying to ascertain: is there a concrete question you have, or just a bunch of bad points about how the Android ecosystem sucks right now? If it's the second, everyone agrees it sucks, there's not a good solution. I suppose one thing that Android could have done better from the start was to offer UI modes that would be guaranteed to homogenous across all certified devices. I don't think that I said statistics were a solution to the issue (though apologies if I gave that impression): I meant to merely give the idea that because of Android's fragmentation a good way to get a handle on what you're facing would be to use device install statistics. I never meant to imply that it was in any way a solution. But everyone agrees that fragmentation sucks. Everyone has agreed it sucks since the beginning (even Android 2.0), and people knew it would get *worse*. You have to worry about API levels, screen configurations, hardware configurations, etc... I know of a few groups developing open source test services, that could presumably end up making a co op or something: that would definitely give more leeway than traditional expensive test services. (If people would be interested, this would be possible to do in the community right now: just buy a server, write some code to distribute the APKs with a feedback / review system, etc..) Kris On Thu, Jul 25, 2013 at 10:01 PM, Omer Gilad omer@gmail.comjavascript: wrote: I agree that it's better than nothing. But, since it's a paid service that has nothing to do with the official SDK, it doesn't come in the SDK's favor at all. The problem appears in much more obvious parts of the SDK than the one I presented. I can give countless examples on demand and I'm sure others can too. Also, I never even bothered to fix custom ROMs and such - this is really beyond my scope. I'm having constant issues with stock, popular devices from Samsung, HTC, etc. - the ones that get shipped in the millions and dominate the Google Play statistics. As you said, statistics are also a temporary solution to the issue - just focus on workarounds for the most popular buggy devices - mainly the Samsung Galaxy series and its endless variations. On Friday, July 26, 2013 4:33:52 AM UTC+3, Kristopher Micinski wrote: Your last paragraph is *exactly* what the CTS is all about, but obviously if you don't work for google you can't mandate what goes in and what does not :-). I'm not recommending that these services are the solution to everyone's problems: but I do contend they get you farther than you would be otherwise. Games are particularly hard to test, since GPUs vary more widely across devices and aren't part of the most common pieces of the SDK. The fact of the matter is, there are always going to be hacked up ROMs running on the market: that's the design decision made by Android. The CTS helps get you farther to a holistic / cohesive platform, but in the end it's a numbers game: knowing which devices, API levels, user
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
The conversation so far, and app testing services, assume that there are certain broken device models / firmwares and they are broken in a deterministic way. This implies that those bad devices can be discovered and excluded or workarounds implemented, again, in a deterministic way. From my experience, it's worse than that. I can get a user bug report that makes my jaw drop to the floor, and have a an exact or similar device on my desk that does not exhibit the issue. Basic things get broken: the app not being able to connect to well known servers, a toast notification getting stuck on the screen, the system ActionBar overflow button not showing on a device without a Menu button, etc. Reinstaling or clearing the Dalvik cache (or some other magic) often resolves these. That itself is a bad sign -- meaning that system level things can randomly break and randomly heal themselves, in a non-deterministic way. Here is a video I made of Galaxy Nexus with 4.0.2 rebooting when trying to start Google Maps, happened every time out of 10 or so I tried: http://www.youtube.com/watch?v=mC4EegjeWZA I fixed it by resetting the device back to factory settings and reinstalling Google Maps, but the question remains: why did this help? Did Google Maps get corrupted during installation? Can it happen to other apps too? I'm not even asking why a modern, preemptively multitasking operating system can enter a reboot triggered by application code. I don't have an answer for this situation either. It's just something I have to deal with every day, costing me a lot of wasted time and a depressed mood. The irony is, users always assume it's the app which must be doing something weird, unlike Windows, where they're quick to blame MS and Bill Gates personally. Must be some kind of Google magic. -- K 2013/7/26 Omer Gilad omer.gi...@gmail.com The point of the original post (the concrete question) was beyond just rant and rave - the question asked is How to deal with it. To put in other words - What do you suggest as a practical solution to the problem, beyond just dumping Android and developing for iOS. To filter out some possible answers: 1. Buying 50+ devices and doing QA on each one of them is NOT an option. It shouldn't ever be. 2. Paying constantly to remote testing services just to know what bugs we have (without even the ability to debug and resolve them) is NOT an option. 3. Chasing after devices (borrowing from friends, getting debug logs from users, etc.) and writing ugly code for workarounds time after time is what I've been doing for some time, but that is NOT an option. 3. Filtering many devices on Google Play console is our current solution, which is far from ideal as you can imagine. Currently, I don't have an effective way to deal with it, to the point that I've decided to move to another platform - the current state is impossible to cope with. I'm an independent developer, working in cooperation with some people, and we fail to address the fragmentation issue. All our efforts invested in creating a quality product are in vain when it's being run on countless broken devices that we can't keep track of. Just to back myself up - I've been developing for Android for more than 3 years, and have been constantly chasing after devices since the beginning. I experienced that in multiple types of projects (apps and games), as a hired or freelance developer and as an entrepreneur. It applies to every aspect of developing for Android, so this issue can't be evaded. To me, this is far more important than answering the questions on API usage, etc. On Friday, July 26, 2013 2:03:28 PM UTC+3, Kristopher Micinski wrote: I guess I'm trying to ascertain: is there a concrete question you have, or just a bunch of bad points about how the Android ecosystem sucks right now? If it's the second, everyone agrees it sucks, there's not a good solution. I suppose one thing that Android could have done better from the start was to offer UI modes that would be guaranteed to homogenous across all certified devices. I don't think that I said statistics were a solution to the issue (though apologies if I gave that impression): I meant to merely give the idea that because of Android's fragmentation a good way to get a handle on what you're facing would be to use device install statistics. I never meant to imply that it was in any way a solution. But everyone agrees that fragmentation sucks. Everyone has agreed it sucks since the beginning (even Android 2.0), and people knew it would get *worse*. You have to worry about API levels, screen configurations, hardware configurations, etc... I know of a few groups developing open source test services, that could presumably end up making a co op or something: that would definitely give more leeway than traditional expensive test services. (If people would be interested, this would be possible to do in the community right now: just buy
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
Can't agree more with everything that has already been said here, but let me remind you something guys: WE chose the Android way, they didn't force us! Android is an Open Source Project and therefore it was more than 100% sure that problems like the ones mentioned above, would appear by the time. There is nothing we can do when almost every brand (Samsung, LG, Sony) uses it's own custom ROM. This should have been handled at the beggining of Android's carreer! It's kind of difficult to deal with it at this moment with this huge penetration of Android on numerous devices! On Fri, Jul 26, 2013 at 3:19 PM, Kostya Vasilyev kmans...@gmail.com wrote: The conversation so far, and app testing services, assume that there are certain broken device models / firmwares and they are broken in a deterministic way. This implies that those bad devices can be discovered and excluded or workarounds implemented, again, in a deterministic way. From my experience, it's worse than that. I can get a user bug report that makes my jaw drop to the floor, and have a an exact or similar device on my desk that does not exhibit the issue. Basic things get broken: the app not being able to connect to well known servers, a toast notification getting stuck on the screen, the system ActionBar overflow button not showing on a device without a Menu button, etc. Reinstaling or clearing the Dalvik cache (or some other magic) often resolves these. That itself is a bad sign -- meaning that system level things can randomly break and randomly heal themselves, in a non-deterministic way. Here is a video I made of Galaxy Nexus with 4.0.2 rebooting when trying to start Google Maps, happened every time out of 10 or so I tried: http://www.youtube.com/watch?v=mC4EegjeWZA I fixed it by resetting the device back to factory settings and reinstalling Google Maps, but the question remains: why did this help? Did Google Maps get corrupted during installation? Can it happen to other apps too? I'm not even asking why a modern, preemptively multitasking operating system can enter a reboot triggered by application code. I don't have an answer for this situation either. It's just something I have to deal with every day, costing me a lot of wasted time and a depressed mood. The irony is, users always assume it's the app which must be doing something weird, unlike Windows, where they're quick to blame MS and Bill Gates personally. Must be some kind of Google magic. -- K 2013/7/26 Omer Gilad omer.gi...@gmail.com The point of the original post (the concrete question) was beyond just rant and rave - the question asked is How to deal with it. To put in other words - What do you suggest as a practical solution to the problem, beyond just dumping Android and developing for iOS. To filter out some possible answers: 1. Buying 50+ devices and doing QA on each one of them is NOT an option. It shouldn't ever be. 2. Paying constantly to remote testing services just to know what bugs we have (without even the ability to debug and resolve them) is NOT an option. 3. Chasing after devices (borrowing from friends, getting debug logs from users, etc.) and writing ugly code for workarounds time after time is what I've been doing for some time, but that is NOT an option. 3. Filtering many devices on Google Play console is our current solution, which is far from ideal as you can imagine. Currently, I don't have an effective way to deal with it, to the point that I've decided to move to another platform - the current state is impossible to cope with. I'm an independent developer, working in cooperation with some people, and we fail to address the fragmentation issue. All our efforts invested in creating a quality product are in vain when it's being run on countless broken devices that we can't keep track of. Just to back myself up - I've been developing for Android for more than 3 years, and have been constantly chasing after devices since the beginning. I experienced that in multiple types of projects (apps and games), as a hired or freelance developer and as an entrepreneur. It applies to every aspect of developing for Android, so this issue can't be evaded. To me, this is far more important than answering the questions on API usage, etc. On Friday, July 26, 2013 2:03:28 PM UTC+3, Kristopher Micinski wrote: I guess I'm trying to ascertain: is there a concrete question you have, or just a bunch of bad points about how the Android ecosystem sucks right now? If it's the second, everyone agrees it sucks, there's not a good solution. I suppose one thing that Android could have done better from the start was to offer UI modes that would be guaranteed to homogenous across all certified devices. I don't think that I said statistics were a solution to the issue (though apologies if I gave that impression): I meant to merely give the idea that because of Android's fragmentation a good way to get a
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
I had no idea it was this broken when I started developing for Android in early 2010. The only technology I can recall that was comparably broken was the early releases of Direct 3D, back in 96-98 or so... MS moved very quickly to improve it, though, and got hardware vendors to fix their drivers too. There are 58 thousand issues reported in the Android bug tracker. Dividing by three years, and accounting for installed base growth, that's, let's say, a hundred issues reported a day. Will they all be looked at, fixed, verified? I seriously doubt it. -- K 2013/7/26 Παύλος-Πέτρος Τουρνάρης p.tourna...@gmail.com: Can't agree more with everything that has already been said here, but let me remind you something guys: WE chose the Android way, they didn't force us! Android is an Open Source Project and therefore it was more than 100% sure that problems like the ones mentioned above, would appear by the time. There is nothing we can do when almost every brand (Samsung, LG, Sony) uses it's own custom ROM. This should have been handled at the beggining of Android's carreer! It's kind of difficult to deal with it at this moment with this huge penetration of Android on numerous devices! On Fri, Jul 26, 2013 at 3:19 PM, Kostya Vasilyev kmans...@gmail.com wrote: The conversation so far, and app testing services, assume that there are certain broken device models / firmwares and they are broken in a deterministic way. This implies that those bad devices can be discovered and excluded or workarounds implemented, again, in a deterministic way. From my experience, it's worse than that. I can get a user bug report that makes my jaw drop to the floor, and have a an exact or similar device on my desk that does not exhibit the issue. Basic things get broken: the app not being able to connect to well known servers, a toast notification getting stuck on the screen, the system ActionBar overflow button not showing on a device without a Menu button, etc. Reinstaling or clearing the Dalvik cache (or some other magic) often resolves these. That itself is a bad sign -- meaning that system level things can randomly break and randomly heal themselves, in a non-deterministic way. Here is a video I made of Galaxy Nexus with 4.0.2 rebooting when trying to start Google Maps, happened every time out of 10 or so I tried: http://www.youtube.com/watch?v=mC4EegjeWZA I fixed it by resetting the device back to factory settings and reinstalling Google Maps, but the question remains: why did this help? Did Google Maps get corrupted during installation? Can it happen to other apps too? I'm not even asking why a modern, preemptively multitasking operating system can enter a reboot triggered by application code. I don't have an answer for this situation either. It's just something I have to deal with every day, costing me a lot of wasted time and a depressed mood. The irony is, users always assume it's the app which must be doing something weird, unlike Windows, where they're quick to blame MS and Bill Gates personally. Must be some kind of Google magic. -- K 2013/7/26 Omer Gilad omer.gi...@gmail.com The point of the original post (the concrete question) was beyond just rant and rave - the question asked is How to deal with it. To put in other words - What do you suggest as a practical solution to the problem, beyond just dumping Android and developing for iOS. To filter out some possible answers: 1. Buying 50+ devices and doing QA on each one of them is NOT an option. It shouldn't ever be. 2. Paying constantly to remote testing services just to know what bugs we have (without even the ability to debug and resolve them) is NOT an option. 3. Chasing after devices (borrowing from friends, getting debug logs from users, etc.) and writing ugly code for workarounds time after time is what I've been doing for some time, but that is NOT an option. 3. Filtering many devices on Google Play console is our current solution, which is far from ideal as you can imagine. Currently, I don't have an effective way to deal with it, to the point that I've decided to move to another platform - the current state is impossible to cope with. I'm an independent developer, working in cooperation with some people, and we fail to address the fragmentation issue. All our efforts invested in creating a quality product are in vain when it's being run on countless broken devices that we can't keep track of. Just to back myself up - I've been developing for Android for more than 3 years, and have been constantly chasing after devices since the beginning. I experienced that in multiple types of projects (apps and games), as a hired or freelance developer and as an entrepreneur. It applies to every aspect of developing for Android, so this issue can't be evaded. To me, this is far more important than answering the questions on API usage, etc. On Friday, July 26, 2013 2:03:28 PM UTC+3,
Re: [android-developers] Dealing with 1000's of different devices, each one with its own bugs
That doesn't justify. An open source project can be maintained with strict regulations and high-quality standards. Google can allow anyone to create his own Android device and sell however they want - but don't allow it to run Google Play and rate apps! I don't recall problems in this massive scope on Linux for example. As far as I can tell, if I run a Linux program it's going to work 99% of the time. On Friday, July 26, 2013 3:31:26 PM UTC+3, Paul-Peter Tournaris wrote: Can't agree more with everything that has already been said here, but let me remind you something guys: WE chose the Android way, they didn't force us! Android is an Open Source Project and therefore it was more than 100% sure that problems like the ones mentioned above, would appear by the time. There is nothing we can do when almost every brand (Samsung, LG, Sony) uses it's own custom ROM. This should have been handled at the beggining of Android's carreer! It's kind of difficult to deal with it at this moment with this huge penetration of Android on numerous devices! On Fri, Jul 26, 2013 at 3:19 PM, Kostya Vasilyev kman...@gmail.comjavascript: wrote: The conversation so far, and app testing services, assume that there are certain broken device models / firmwares and they are broken in a deterministic way. This implies that those bad devices can be discovered and excluded or workarounds implemented, again, in a deterministic way. From my experience, it's worse than that. I can get a user bug report that makes my jaw drop to the floor, and have a an exact or similar device on my desk that does not exhibit the issue. Basic things get broken: the app not being able to connect to well known servers, a toast notification getting stuck on the screen, the system ActionBar overflow button not showing on a device without a Menu button, etc. Reinstaling or clearing the Dalvik cache (or some other magic) often resolves these. That itself is a bad sign -- meaning that system level things can randomly break and randomly heal themselves, in a non-deterministic way. Here is a video I made of Galaxy Nexus with 4.0.2 rebooting when trying to start Google Maps, happened every time out of 10 or so I tried: http://www.youtube.com/watch?v=mC4EegjeWZA I fixed it by resetting the device back to factory settings and reinstalling Google Maps, but the question remains: why did this help? Did Google Maps get corrupted during installation? Can it happen to other apps too? I'm not even asking why a modern, preemptively multitasking operating system can enter a reboot triggered by application code. I don't have an answer for this situation either. It's just something I have to deal with every day, costing me a lot of wasted time and a depressed mood. The irony is, users always assume it's the app which must be doing something weird, unlike Windows, where they're quick to blame MS and Bill Gates personally. Must be some kind of Google magic. -- K 2013/7/26 Omer Gilad omer@gmail.com javascript: The point of the original post (the concrete question) was beyond just rant and rave - the question asked is How to deal with it. To put in other words - What do you suggest as a practical solution to the problem, beyond just dumping Android and developing for iOS. To filter out some possible answers: 1. Buying 50+ devices and doing QA on each one of them is NOT an option. It shouldn't ever be. 2. Paying constantly to remote testing services just to know what bugs we have (without even the ability to debug and resolve them) is NOT an option. 3. Chasing after devices (borrowing from friends, getting debug logs from users, etc.) and writing ugly code for workarounds time after time is what I've been doing for some time, but that is NOT an option. 3. Filtering many devices on Google Play console is our current solution, which is far from ideal as you can imagine. Currently, I don't have an effective way to deal with it, to the point that I've decided to move to another platform - the current state is impossible to cope with. I'm an independent developer, working in cooperation with some people, and we fail to address the fragmentation issue. All our efforts invested in creating a quality product are in vain when it's being run on countless broken devices that we can't keep track of. Just to back myself up - I've been developing for Android for more than 3 years, and have been constantly chasing after devices since the beginning. I experienced that in multiple types of projects (apps and games), as a hired or freelance developer and as an entrepreneur. It applies to every aspect of developing for Android, so this issue can't be evaded. To me, this is far more important than answering the questions on API usage, etc. On Friday, July 26, 2013 2:03:28 PM UTC+3, Kristopher Micinski wrote: I guess I'm trying to ascertain: is there
Re: [android-developers] How to communicate with Google Server for Android App License Verification?
I want to block users who are using backed up copy of my app i.e. without purchasing from Google Play. I found that it is possible to repackage apk by modifying it. If repackaging is done in such a way that the license verification check is skipped then user of that app will be able to access all features in paid app without payment. In such case, how do I block unauthorized users? On Friday, July 26, 2013 1:10:50 AM UTC+5:30, TreKing wrote: On Thu, Jul 25, 2013 at 4:40 AM, gauri gauri...@gmail.com javascript:wrote: But I want do verification from my server which will directly communicate with Google Server. Why? - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- -- 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: Deposits From Google Wallet Weirdness
I just received this email from Google Wallet: ---8-- Earlier this week there was a technical issue that resulted in some Play developers receiving duplicate disbursement payments. You may have seen this reflected on the “Transactions” page of your Google Wallet Merchant Center account. We plan to recoup the overpayment by debiting the amount against future earnings. Please note, this may take multiple months depending on the amount of your future earnings. We apologize for any inconvenience this has caused and appreciate your patience. Please feel free to reach out to me if you have additional questions. ---8--- So, no payments for me in about 3 months :) On Thu, Jul 25, 2013 at 1:17 PM, Felix Long felixl...@gmail.com wrote: I also meet this issue. What's worse, My bank account wil charge 1% fee for per transcation. And Today Google Wallet withdraw it from my bank account, And My google play account is still negative. Sign. 2013/7/24 Nathan nathan.d.mel...@gmail.com On Tuesday, July 23, 2013 10:35:39 AM UTC-7, Steve Gabrilowitz wrote: Mine didn't get reversed so it looks like I got paid a couple of months in advance for sales I haven't made yet. Like you, my daily revenue is being subtracted from the negative balance which it should be so I guess all will be square in a couple of months! Well, your business just got an interest free loan! You can hire some more developers and make some more apps. But whatever you do, it better pay off in two months. Nathan -- -- 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. -- Best Regards Felix Long -- -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[android-developers] Unable to create archives folder using mkdirs.
Once in a while I see problems that are just weird.
A customer said that certain functionality was failing. We put in an
explicit check to see if we were failing to do something basic, create a
folder.
Now they get a message instead of a more silent or confusing failure.
Unable to create folder: /storage/sdcard1/navigator/apname/archives
File archiveDir = new File(
/storage/sdcard1/navigator/apname/archives);
if(!archiveDir.exists()){
boolean success = archiveDir.mkdirs();
Note that /storage/sdcard1/navigator/apname/ is already created (by the
app) and has a few or maybe a gazillion other folders under that, also
created by mkdirs.
But mkdirs is returning false.
The person went to the file explorer and manually created that folder and a
few subfolders under it. The app continued on and worked.
That person had Hisense Sero 7 Pro
Another user reported this, I don't what device model yet.
I expect there will be more since we have only recently shown any such
message to users, and suspected it may have failed silently or confusingly
before that.
Would some devices be using archives as some sort of reserved word on
their filesystem?
Why would the user be able to create that folder when the app cannot, given
it has already created many peers to it?
Nathan
--
--
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 feel like what's been said here is more directed toward Google management than Android AOSP, per se: not that that's not also an issue. I understand and agree with what Kostya is saying, and wasn't trying to imply that there are a fixed number of builds with deterministic issues. Even for a certain device, things change and manifest in different ways: from firmware problems, to radio issues, etc... I think there are multiple problems here: - Fragmented OS installs over time - Operating system bugs - The fact that users can't upgrade their OS except through their provider, which usually sucks at writing firmware and often includes apps with special hooks into the OS doing really crazy things (e.g., HtcLoggers) - Poor management of certification to run google play - Certain roms running Google play even though they *shouldn't* be - etc... Many of these are management related, and potentially caused by the fact that Android doesn't control the OS. I think your argument for Linux isn't necessarily applicable here. Linux is all open source, you can install propietary drivers and mess up your device, but that's *extremely* different than going to Gateway (e.g.,) and having them hand you a custom version of Linux which can't be removed from the system. Note that in Linux's case, the codebase stays overwhelmingly the same, where in Android a huge part of the work is done with relatively few engineers working on writing firmware for radios they didn't necessarily design, sticking together proprietary components. I'm not using that as a defense for Android: I just think it's a poor comparison. Kris On Fri, Jul 26, 2013 at 9:18 AM, Omer Gilad omer.gi...@gmail.com wrote: That doesn't justify. An open source project can be maintained with strict regulations and high-quality standards. Google can allow anyone to create his own Android device and sell however they want - but don't allow it to run Google Play and rate apps! I don't recall problems in this massive scope on Linux for example. As far as I can tell, if I run a Linux program it's going to work 99% of the time. On Friday, July 26, 2013 3:31:26 PM UTC+3, Paul-Peter Tournaris wrote: Can't agree more with everything that has already been said here, but let me remind you something guys: WE chose the Android way, they didn't force us! Android is an Open Source Project and therefore it was more than 100% sure that problems like the ones mentioned above, would appear by the time. There is nothing we can do when almost every brand (Samsung, LG, Sony) uses it's own custom ROM. This should have been handled at the beggining of Android's carreer! It's kind of difficult to deal with it at this moment with this huge penetration of Android on numerous devices! On Fri, Jul 26, 2013 at 3:19 PM, Kostya Vasilyev kman...@gmail.com wrote: The conversation so far, and app testing services, assume that there are certain broken device models / firmwares and they are broken in a deterministic way. This implies that those bad devices can be discovered and excluded or workarounds implemented, again, in a deterministic way. From my experience, it's worse than that. I can get a user bug report that makes my jaw drop to the floor, and have a an exact or similar device on my desk that does not exhibit the issue. Basic things get broken: the app not being able to connect to well known servers, a toast notification getting stuck on the screen, the system ActionBar overflow button not showing on a device without a Menu button, etc. Reinstaling or clearing the Dalvik cache (or some other magic) often resolves these. That itself is a bad sign -- meaning that system level things can randomly break and randomly heal themselves, in a non-deterministic way. Here is a video I made of Galaxy Nexus with 4.0.2 rebooting when trying to start Google Maps, happened every time out of 10 or so I tried: http://www.youtube.com/watch?v=mC4EegjeWZA I fixed it by resetting the device back to factory settings and reinstalling Google Maps, but the question remains: why did this help? Did Google Maps get corrupted during installation? Can it happen to other apps too? I'm not even asking why a modern, preemptively multitasking operating system can enter a reboot triggered by application code. I don't have an answer for this situation either. It's just something I have to deal with every day, costing me a lot of wasted time and a depressed mood. The irony is, users always assume it's the app which must be doing something weird, unlike Windows, where they're quick to blame MS and Bill Gates personally. Must be some kind of Google magic. -- K 2013/7/26 Omer Gilad omer@gmail.com The point of the original post (the concrete question) was beyond just rant and rave - the question asked is How to deal with it. To put in other words - What do you suggest as a practical solution to the problem, beyond just dumping
[android-developers] Re: How to GIF image for a finate time
how to do this? please give me the sample link thanks On Wednesday, January 6, 2010 11:21:00 PM UTC+3:30, TonyDoc wrote: Convert it to multiple png's use androids animation manager. On Jan 6, 5:31 am, RamaMohan rama.mohan...@gmail.com wrote: Hi all, I want to show a loading Image of GIF type for a finite time .how to do this. Please tell me the solution if anyone knows. Thanks, Ram -- -- 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: Can't always get unique identifier
On Wednesday, July 24, 2013 3:45:58 PM UTC-4, Tobiah wrote: I needed to send an identifier to our server to identify users as they use my application. I first used the phone number, but found that tablets without service had none. So failing getting a phone number, I did this: android_id = Secure.getString(this.getContentResolver(), Secure.ANDROID_ID); But it seems now, that a handful of users, notably those using T-mobile, have phones that will not yield the above ID. So I was wondering whether there was some other unique identifier I could use, or failing that, would like to here suggestions on generating an identifier that would (almost?) never be a duplicate. Seems to me that if you combine your two ideas you get something that should work for all devices. Better to use than the phone number would be the IMEI (GSM) or MEID (CDMA) of the device, and if it doesn't have one then go for the Secure.ANDROID_ID. If this fails and you have to use one of the other suggestions on this thread and need to store the generated ID somewhere then instead of storing it on the file system and requiring extra permission just put it in a shared preference. -- -- 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] How to communicate with Google Server for Android App License Verification?
So the solution is to not use LVL? ... That just sounds like a bad idea to me, since this is what LVL was designed to do. Kris On Fri, Jul 26, 2013 at 9:29 AM, gauri gauri.v...@gmail.com wrote: I want to block users who are using backed up copy of my app i.e. without purchasing from Google Play. I found that it is possible to repackage apk by modifying it. If repackaging is done in such a way that the license verification check is skipped then user of that app will be able to access all features in paid app without payment. In such case, how do I block unauthorized users? On Friday, July 26, 2013 1:10:50 AM UTC+5:30, TreKing wrote: On Thu, Jul 25, 2013 at 4:40 AM, gauri gauri...@gmail.com wrote: But I want do verification from my server which will directly communicate with Google Server. Why? - TreKing - Chicago transit tracking app for Android-powered devices -- -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[android-developers] Re: Stretch videostrong
Thanks. I got that working. Any tips on how to stick an AdView at the top? I think it might be tricky since that RelativeLayout thing is kind of a hack. On Tuesday, July 23, 2013 8:09:56 AM UTC-5, Matt wrote: Take the VideoView under a RelativeLayout and define it as below: VideoView android:layout_width=fill_parent android:layout_height=fill_parent android:layout_alignParentBottom=true android:layout_alignParentLeft=true android:layout_alignParentRight=true android:layout_alignParentTop=true / On Saturday, July 20, 2013 7:04:46 PM UTC+5:30, bob wrote: Anyone know if there's an easy way to scale a VideoView so the video takes up the whole screen? I want it to be stretched. 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 --- 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] How to communicate with Google Server for Android App License Verification?
On Fri, Jul 26, 2013 at 8:29 AM, gauri gauri.v...@gmail.com wrote: In such case, how do I block unauthorized users? You don't really. Anyone that is determined enough to crack your app eventually will. The question is how much time and effort do you want to spend trying to put these checks and validations. I don't think you can do what you're asking, so your best option is to use LVL as is. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- -- 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.
