Re: [android-developers] Testing in-app purchases is incompatible with monotonically increasing Android versions
Your statement is true for testing app licensing. When using a debugging APK with higher version number than the currently uploaded one the LVL still works for the debug version. On Saturday, December 15, 2012 9:48:19 PM UTC-6, Raymond C. Rodgers wrote: I may be mistaken, but I think that with the first apk uploaded to test with, you can then distribute updated debug copies outside of the Play Store/developer console and the correct (or at least updated) behavior will be exhibited in those debug copies. As far as I know, you only need to have an initial apk in the developer console so you can create the in-app items and debug prior to release. I *don't think* you have to continually upload the updated the apk as you work on the app. I also think that if it bothers you to have the version code set at something other than 1 when you're ready to release the app that you can actually delete the app entry from the console, upload the final apk, and recreate the items. I *don't think* you'd have to change the package name for that to work properly. Everything I'm saying here (with the exception of this statement) should be taken with a grain of salt; I haven't created an app using in-app billing at this point. I could be completely wrong about these behaviors. Raymond On 12/15/2012 7:19 PM, Keith Wiley wrote: Yeah, I know, but I still want to use the versionCode to label public releases, not just one-off momentary debug versions. I'm not even talking about officially versioned betas here, I'm just talking about pushing the code through a rapid build-test-debug-fix cycle. Every time I want to try another little thing on out in-app purchasing I have to delete the entire app profile and start over. On Saturday, December 15, 2012 1:24:43 PM UTC-8, mbanzon wrote: In your manifest you should have both android:versionCode and android:versionName attributes. The versionCode is the one you need to increment but the versionName is the one the user sees and that one can be whatever you like afaik. On Sat, Dec 15, 2012 at 10:15 PM, Keith Wiley kbw...@gmail.com javascript: wrote: I'm debugging in-app purchases. This requires me to create the app profile on the console and upload the apk (but not necessarily publish it). With an invited test gmail account, I can then test in-app purchases. The problem is, there is no way to upload changes to the app if I have to fix something. Say I upload an apk with version number 1. Google requires that I increase the apk number with every upload, so I have to increase the number to 2 to change the code, and version 3 to change it again. I may go through numerous iterations of development getting the final code in place...but none of these are actual new releases, the app isn't even published yet! I want the first published version to be version 1, regardless of any initial testing and there doesn't seem to be any way to do this. If I delete the apk from the app description in the hopes of wiping out the version numbers so I can upload an apk with version 1, the ENTIRE app profile is destroyed and I have to create a new one from scratch, including the required screenshot uploads and other tedium unrelated to testing. This imposes a tremendous burden on the debugging process. Is there any way to do what I am trying to accomplish here? I am at a loss. Thank you. -- Michael Banzon http://michaelbanzon.com/ -- 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 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
Re: [android-developers] Testing in-app purchases is incompatible with monotonically increasing Android versions
On Sun, Dec 16, 2012 at 12:48 PM, Raymond C. Rodgers raym...@badlucksoft.com wrote: I may be mistaken, but I think that with the first apk uploaded to test with, you can then distribute updated debug copies outside of the Play Store/developer console and the correct (or at least updated) behavior will be exhibited in those debug copies. As far as I know, you only need to have an initial apk in the developer console so you can create the in-app items and debug prior to release. The draft app in the console needs to have the same version number and signature (release key) as the one you are testing. As long as your test APK has the same version number and signature, testing should work. The binaries don't need to be the same, so you can test, fix, etc. until you are done. You can of course set the debuggable flag in your test APK to true if you need to. Then just replace the APK in the console. It also takes a few hours for the draft apk to be picked up by Play Store servers. That's for v1 and v2 in-app billing, it might be slightly different for v3. I *don't think* you have to continually upload the updated the apk as you work on the app. Right, you don't need to do this. And the of course the version number doesn't have inherent meaning for the Play Store servers or client, so it really doesn't matter whether you start from 1 or 42. You users will also see the string versionName. No reason to obsess about the actual number. -- 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
Re: [android-developers] Testing in-app purchases is incompatible with monotonically increasing Android versions
Aaaah, I see now. Okay. 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] Testing in-app purchases is incompatible with monotonically increasing Android versions
I'm debugging in-app purchases. This requires me to create the app profile on the console and upload the apk (but not necessarily publish it). With an invited test gmail account, I can then test in-app purchases. The problem is, there is no way to upload changes to the app if I have to fix something. Say I upload an apk with version number 1. Google requires that I increase the apk number with every upload, so I have to increase the number to 2 to change the code, and version 3 to change it again. I may go through numerous iterations of development getting the final code in place...but none of these are actual new releases, the app isn't even published yet! I want the first published version to be version 1, regardless of any initial testing and there doesn't seem to be any way to do this. If I delete the apk from the app description in the hopes of wiping out the version numbers so I can upload an apk with version 1, the ENTIRE app profile is destroyed and I have to create a new one from scratch, including the required screenshot uploads and other tedium unrelated to testing. This imposes a tremendous burden on the debugging process. Is there any way to do what I am trying to accomplish here? I am at a loss. Thank you. -- 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
Re: [android-developers] Testing in-app purchases is incompatible with monotonically increasing Android versions
In your manifest you should have both android:versionCode and android:versionName attributes. The versionCode is the one you need to increment but the versionName is the one the user sees and that one can be whatever you like afaik. On Sat, Dec 15, 2012 at 10:15 PM, Keith Wiley kbwi...@gmail.com wrote: I'm debugging in-app purchases. This requires me to create the app profile on the console and upload the apk (but not necessarily publish it). With an invited test gmail account, I can then test in-app purchases. The problem is, there is no way to upload changes to the app if I have to fix something. Say I upload an apk with version number 1. Google requires that I increase the apk number with every upload, so I have to increase the number to 2 to change the code, and version 3 to change it again. I may go through numerous iterations of development getting the final code in place...but none of these are actual new releases, the app isn't even published yet! I want the first published version to be version 1, regardless of any initial testing and there doesn't seem to be any way to do this. If I delete the apk from the app description in the hopes of wiping out the version numbers so I can upload an apk with version 1, the ENTIRE app profile is destroyed and I have to create a new one from scratch, including the required screenshot uploads and other tedium unrelated to testing. This imposes a tremendous burden on the debugging process. Is there any way to do what I am trying to accomplish here? I am at a loss. Thank you. -- 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 -- Michael Banzon http://michaelbanzon.com/ -- 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
Re: [android-developers] Testing in-app purchases is incompatible with monotonically increasing Android versions
Yeah, I know, but I still want to use the versionCode to label public releases, not just one-off momentary debug versions. I'm not even talking about officially versioned betas here, I'm just talking about pushing the code through a rapid build-test-debug-fix cycle. Every time I want to try another little thing on out in-app purchasing I have to delete the entire app profile and start over. On Saturday, December 15, 2012 1:24:43 PM UTC-8, mbanzon wrote: In your manifest you should have both android:versionCode and android:versionName attributes. The versionCode is the one you need to increment but the versionName is the one the user sees and that one can be whatever you like afaik. On Sat, Dec 15, 2012 at 10:15 PM, Keith Wiley kbw...@gmail.comjavascript: wrote: I'm debugging in-app purchases. This requires me to create the app profile on the console and upload the apk (but not necessarily publish it). With an invited test gmail account, I can then test in-app purchases. The problem is, there is no way to upload changes to the app if I have to fix something. Say I upload an apk with version number 1. Google requires that I increase the apk number with every upload, so I have to increase the number to 2 to change the code, and version 3 to change it again. I may go through numerous iterations of development getting the final code in place...but none of these are actual new releases, the app isn't even published yet! I want the first published version to be version 1, regardless of any initial testing and there doesn't seem to be any way to do this. If I delete the apk from the app description in the hopes of wiping out the version numbers so I can upload an apk with version 1, the ENTIRE app profile is destroyed and I have to create a new one from scratch, including the required screenshot uploads and other tedium unrelated to testing. This imposes a tremendous burden on the debugging process. Is there any way to do what I am trying to accomplish here? I am at a loss. Thank you. -- Michael Banzon http://michaelbanzon.com/ -- 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
Re: [android-developers] Testing in-app purchases is incompatible with monotonically increasing Android versions
I may be mistaken, but I think that with the first apk uploaded to test with, you can then distribute updated debug copies outside of the Play Store/developer console and the correct (or at least updated) behavior will be exhibited in those debug copies. As far as I know, you only need to have an initial apk in the developer console so you can create the in-app items and debug prior to release. I *don't think* you have to continually upload the updated the apk as you work on the app. I also think that if it bothers you to have the version code set at something other than 1 when you're ready to release the app that you can actually delete the app entry from the console, upload the final apk, and recreate the items. I *don't think* you'd have to change the package name for that to work properly. Everything I'm saying here (with the exception of this statement) should be taken with a grain of salt; I haven't created an app using in-app billing at this point. I could be completely wrong about these behaviors. Raymond On 12/15/2012 7:19 PM, Keith Wiley wrote: Yeah, I know, but I still want to use the versionCode to label public releases, not just one-off momentary debug versions. I'm not even talking about officially versioned betas here, I'm just talking about pushing the code through a rapid build-test-debug-fix cycle. Every time I want to try another little thing on out in-app purchasing I have to delete the entire app profile and start over. On Saturday, December 15, 2012 1:24:43 PM UTC-8, mbanzon wrote: In your manifest you should have both android:versionCode and android:versionName attributes. The versionCode is the one you need to increment but the versionName is the one the user sees and that one can be whatever you like afaik. On Sat, Dec 15, 2012 at 10:15 PM, Keith Wiley kbw...@gmail.com javascript: wrote: I'm debugging in-app purchases. This requires me to create the app profile on the console and upload the apk (but not necessarily publish it). With an invited test gmail account, I can then test in-app purchases. The problem is, there is no way to upload changes to the app if I have to fix something. Say I upload an apk with version number 1. Google requires that I increase the apk number with every upload, so I have to increase the number to 2 to change the code, and version 3 to change it again. I may go through numerous iterations of development getting the final code in place...but none of these are actual new releases, the app isn't even published yet! I want the first published version to be version 1, regardless of any initial testing and there doesn't seem to be any way to do this. If I delete the apk from the app description in the hopes of wiping out the version numbers so I can upload an apk with version 1, the ENTIRE app profile is destroyed and I have to create a new one from scratch, including the required screenshot uploads and other tedium unrelated to testing. This imposes a tremendous burden on the debugging process. Is there any way to do what I am trying to accomplish here? I am at a loss. Thank you. -- Michael Banzon http://michaelbanzon.com/ -- 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 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
