Re: [android-developers] Old versions still being downloaded from Google Play?
On Sat, Dec 15, 2012 at 1:50 AM, Bram Stolk b.st...@gmail.com wrote: See this screen grab: Yesterday, at least four different versions got installed by users, even though most of these versions are weeks old. Yeah, I see the same behavior. *shrugs* The Market statistics have never been a thing you could fully trust. The Market ... er Play ... works in mysterious ways. - 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
[android-developers] Android Geocoder yields inaccurate results only with MY package name
I have an app that is quite dependent on reverse geocoding results using the built-in Geocoding support in Android. However, I've been noticing that the geocoder object returns inaccurate results, which can be off several hundreds of meters/yards. The strangest thing however, is that this inaccuracy seems to be caused by my package name! If I run the sample code that you can download at http://developer.android.com/training/basics/location/geocoding.html everything works like a charm. The reverse geocoder almost always gets the right street number, and in some cases my neighbor's street number. However, if I take the same sample code, and ONLY change the package name into my app's package name, suddenly the reverse geocoding is very inaccurate. Also, the latitude and longitude that the geocoder service returns are very different from the ones that I provided the geocoder with. As far as I can tell, the Android geocoder is NOT subject to any usage limits. But how can I get inaccurate results just based on the package name? That's really frustrating for both me and my users (over half a million). -- 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: In App Billing Error
I had the same problem which was resolved by itself several hours after I've uploaded app. lauantai, 15. joulukuuta 2012 7.54.38 UTC+2 ajmer singh kirjoitti: Hi All I am implementing In app billing(Version 3) in android app. 1. I had put the Signed apk on the Play Store. 2. Also had a managed Product Activated. 3. Using a Signed apk for testing on phone. 4. Managed Product is also showing up in my Query for the inventory. 5. Also created and using a Google account for Testing In app Billing. Still getting the Item Unavailable and User is not eligible for this purchase , Please refer to attached Screen shot for more details ,Please anybody here who has got this type of error please help. -- Thanks and Regards Ajmer Singh -- 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] Android Lint Tool - Suggestions for 2 fatal problems (missed)
The Android Lint tool is very good at spotting potential errors.
But I think it missed 2 fatal problems:
1) No parent style defined for a custom style. [Flag as error]
If you create a custom style in res/values/styles.xml, and your new
style does not inherit from a standard Android theme, then your app
will crash at startup on a minority of devices. It's hard to spot
because most devices and the emulator do not crash. You will only find
out when you release your app, and receive loads of crash reports...
...But the crash log is weird and the solution is here:
http://stackoverflow.com/questions/2605999
2) Call getActionBar() without explicitly requesting the ActionBar to
show. [Flag as error]
If you do this...
protected void onCreate() {
getActionBar().setDisplayHomeAsUpEnabled(true);
}
...It will work on most devices. But a minority will crash at startup,
because they don't show the ActionBar by default, so getActionBar()
returns null. The correct way is like this:
protected void onCreate() {
getWindow().requestFeature(Window.FEATURE_ACTION_BAR);
getActionBar().setDisplayHomeAsUpEnabled(true);
}
Please add these checks to the Android Lint tool. 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: How to create new PreferenceFragment from XML
On 12/14/2012 09:05 PM, Jim Duda wrote: When selecting the pref_hosts_title, I want the SettingsActivity$HostsFragment to display. This new fragment does display, however, it doesn't replace the original fragment, it instead overlays the original fragment. The two fragments display at the same time. What might I be doing wrong? When I select the android:fragment, I've found out that what happens is an entire new SettingActivity is started. I was only expecting a new HostsFragment to be created. I'm obviously missing something fundamental about the PresenceFragment life cycle. I'm reading the docs, but I just don't see my misunderstanding. Well, it turns out I didn't read the documentation well enough. I was using preference fragments in a preferenceactivity without the preference-headers. So, I was mixing the OLD and NEW API methodology. Once I realized that I needed preference-headers, my understanding was corrected. I hope this helps the next person which makes the same mistake :-) Jim -- 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] Android Lint Tool - Suggestions for 2 fatal problems (missed)
If the minority of devices have legitimately licensed copies of the
Play Store, then these crashes represent missing tests in the CTS, for
which we can file some issues.
If the minority of devices do not have the Play Store on them, or
are likely to have a pirated copy of the Play Store, then the problem
may lie in the devices themselves. Android developers are not
responsible for adjusting all their apps to work on non-standard
devices.
The second problem, in particular, has nothing whatsoever to do with
Lint. So long as you have called setContentView() before messing with
the action bar, nothing more needs to be requested.
Your first problem (missing parent style) might be a legitimate Lint
check, though I am not sure it is worth an error severity if
compatible devices should work properly.
So, please provide some details as to which devices you are seeing
these problems on, so we can determine the proper course of action --
thanks!
On Sat, Dec 15, 2012 at 7:46 AM, I.E. inib...@gmail.com wrote:
The Android Lint tool is very good at spotting potential errors.
But I think it missed 2 fatal problems:
1) No parent style defined for a custom style. [Flag as error]
If you create a custom style in res/values/styles.xml, and your new
style does not inherit from a standard Android theme, then your app
will crash at startup on a minority of devices. It's hard to spot
because most devices and the emulator do not crash. You will only find
out when you release your app, and receive loads of crash reports...
...But the crash log is weird and the solution is here:
http://stackoverflow.com/questions/2605999
2) Call getActionBar() without explicitly requesting the ActionBar to
show. [Flag as error]
If you do this...
protected void onCreate() {
getActionBar().setDisplayHomeAsUpEnabled(true);
}
...It will work on most devices. But a minority will crash at startup,
because they don't show the ActionBar by default, so getActionBar()
returns null. The correct way is like this:
protected void onCreate() {
getWindow().requestFeature(Window.FEATURE_ACTION_BAR);
getActionBar().setDisplayHomeAsUpEnabled(true);
}
Please add these checks to the Android Lint tool. 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
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy
_The Busy Coder's Guide to Android Development_ Version 4.4 Available!
--
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: Android Lint Tool - Suggestions for 2 fatal problems (missed)
Android developers are not responsible for adjusting all their apps to work on non-standard devices. In theory yes. In practice no: 1) We can't assume they are non-standard devices. We just see crash reports. 2) If you have a high average app rating, and suddenly start recieving 1-star ratings after an update, you have to respond. 3) If you have a free app that uses advertising, and suddenly your daily app revenue goes down after an update, or users are uninstalling, then you have to respond. The second problem, in particular, has nothing whatsoever to do with Lint. So long as you have called setContentView() before messing with the action bar, nothing more needs to be requested. I think it is a Lint problem. I usually call getWindow().requestFeature(...) first and then call setContentView() to display the layout below the ActionBar / TitleBar. setContentView() doesn't know anything about the ActionBar, as far as I'm aware. So, please provide some details as to which devices you are seeing these problems on, so we can determine the proper course of action -- thanks! Many different devices. Examples: Acer Iconia tablet A500, Dell Streak 7, ARCHOS 70it2. Various Samsung devices: GT-P6800, GT-P6210, ... -- 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] Re: Android Lint Tool - Suggestions for 2 fatal problems (missed)
On Sat, Dec 15, 2012 at 9:12 AM, I.E. inib...@gmail.com wrote: 1) We can't assume they are non-standard devices. We just see crash reports. If you are distributing through the Play Store, you only have to worry about devices that pass the CTS. Any other non-CTS-compliant device with the Play Store is using a pirated copy of the store, and we have no way of predicting the behavior of such devices. We cannot have all non-compliant device flaws be Lint errors. Lint is for CTS-compliant devices. I usually call getWindow().requestFeature(...) first and then call setContentView() to display the layout below the ActionBar / TitleBar. setContentView() doesn't know anything about the ActionBar, as far as I'm aware. It may if you are using ActionBarSherlock, I think, which is why I mentioned it. I agree that the native action bar is probably oblivious to setContentView(). Many different devices. Examples: Acer Iconia tablet A500, Dell Streak 7, ARCHOS 70it2. Various Samsung devices: GT-P6800, GT-P6210, ... Then these are problems in the CTS, and should be treated as such, as the Acer, and probably the Samsungs, should be CTS-compliant. Feel free to file issues on http://b.android.com with reproducible test cases, to get new CTS tests added to cover these scenarios. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 4.4 Available! -- 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: Updating home screen shortcut icon
As fast as I know once shortcuts are created they are no longer related to the application that created it. So you wont be able to update the icon on old shortcuts. On Thursday, August 4, 2011 8:00:49 AM UTC-4, mad stuntman wrote: Hi Willian, Did you solve the problem? I have the same issue. I have relocated .action.MAIN intent filter to newer activity in the new app version, and users report me that they are not able to lunch application from older shortcut after upgrade. They need delete previous shortcut and create a new one. I also able to reproduce the issue. So I also looking for a way to update app shortcut. On Jul 24, 4:08 pm, William Ferguson william.ferguson...@gmail.com wrote: No, just the icon. On Jul 24, 7:29 pm, Zsolt Vasvari zvasv...@gmail.com wrote: Did you also change your main activity? Doing that can cause the icon not to update until the next reboot. On Jul 24, 2:23 pm, William Ferguson william.ferguson...@gmail.com wrote: The latest version of my app has a new launcher icon, and when the new version is installed (at least on the emulators and a 2.3.3 device) the icon for existing home screen shortcuts to the app are not updated. Is there a way to force existing home screen shortcuts to update their icons? William -- 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] [Help!]Can't get any thread in DDMS window when debugging
Hi guys, I downloaded android source code and set up the development environment in eclipse. I wanted to debug some system apps(like mms, etc). But when I attached my galaxy nexus into my laptop, I can't see any thread in the ddms. I have already enabled debug mode in the setting page. The Android version of my device is 4.2.1. I wonder if the 4.2.1 needs additional drivers or something when debugging? You can refer the image attached. https://lh5.googleusercontent.com/-9DgU75SvZhs/UMylxvWuW-I/AH4/uvwasL-UDKU/s1600/2.png Any help would be very nice Cheers~ -- 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] [Help!]Can't get any thread in DDMS window when debugging
I'm not quite sure I understand what you're trying to achieve, but if you want to debug pre-installed apps you should understand those are unlikely to be flagged as debuggable in their manifests. This is why they don't show up in DDMS. -- 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: Android Geocoder yields inaccurate results only with MY package name
What device did you test that one? According to the Geocoder documentation the actual implementation is device dependent. On Saturday, December 15, 2012 5:03:46 AM UTC-6, Franklin wrote: I have an app that is quite dependent on reverse geocoding results using the built-in Geocoding support in Android. However, I've been noticing that the geocoder object returns inaccurate results, which can be off several hundreds of meters/yards. The strangest thing however, is that this inaccuracy seems to be caused by my package name! If I run the sample code that you can download at http://developer.android.com/training/basics/location/geocoding.htmleverything works like a charm. The reverse geocoder almost always gets the right street number, and in some cases my neighbor's street number. However, if I take the same sample code, and ONLY change the package name into my app's package name, suddenly the reverse geocoding is very inaccurate. Also, the latitude and longitude that the geocoder service returns are very different from the ones that I provided the geocoder with. As far as I can tell, the Android geocoder is NOT subject to any usage limits. But how can I get inaccurate results just based on the package name? That's really frustrating for both me and my users (over half a million). -- 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
[android-developers] Re: set camera focus distance programmatically in the FOCUS_FIXED mode
Did you ever figure this out? On Friday, July 8, 2011 9:10:23 AM UTC-4, Qianqian Fang wrote: hi everyone I need to let the camera to focus to a user supplied distance. In the SDK, I only found getFocusDistance to inquire the focus distance, but not one to set the focus distance manually. Can someone give me a hint how to achieve this? thanks Qianqian -- 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: Android Geocoder yields inaccurate results only with MY package name
I tested it on a Galaxy Nexus, Galaxy S3, Nexus 7, and an emulator running 4.2. In all cases, the results were as I described. Op zaterdag 15 december 2012 18:21:05 UTC+1 schreef Nobu Games het volgende: What device did you test that one? According to the Geocoder documentation the actual implementation is device dependent. On Saturday, December 15, 2012 5:03:46 AM UTC-6, Franklin wrote: I have an app that is quite dependent on reverse geocoding results using the built-in Geocoding support in Android. However, I've been noticing that the geocoder object returns inaccurate results, which can be off several hundreds of meters/yards. The strangest thing however, is that this inaccuracy seems to be caused by my package name! If I run the sample code that you can download at http://developer.android.com/training/basics/location/geocoding.htmleverything works like a charm. The reverse geocoder almost always gets the right street number, and in some cases my neighbor's street number. However, if I take the same sample code, and ONLY change the package name into my app's package name, suddenly the reverse geocoding is very inaccurate. Also, the latitude and longitude that the geocoder service returns are very different from the ones that I provided the geocoder with. As far as I can tell, the Android geocoder is NOT subject to any usage limits. But how can I get inaccurate results just based on the package name? That's really frustrating for both me and my users (over half a million). -- 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] [Help!]Can't get any thread in DDMS window when debugging
Thanks, but I did debug pre-installed apps before, now I can't Is there any change in the 4.2.1? Or say if I want to debug them , I need a self-build rom? 在 2012年12月16日星期日UTC+8上午1时08分52秒，latimerius写道： I'm not quite sure I understand what you're trying to achieve, but if you want to debug pre-installed apps you should understand those are unlikely to be flagged as debuggable in their manifests. This is why they don't show up in DDMS. -- 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] Fragment ID
At http://developer.android.com/guide/components/fragments.html, it mentions If you provide neither of the previous two, the system uses the ID of the container view. in the section of Adding a fragment to an activity. What does the ID of the container view means? -- 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
[android-developers] Custom theme for android ?
Hey I want to do custom theme for tablet. please help me out with this ? 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
Re: [android-developers] Custom theme for android ?
On Sun, Dec 16, 2012 at 12:21 AM, mohammed Nuhail nuhail...@gmail.comwrote: Hey I want to do custom theme for tablet. please help me out with this ? http://www.catb.org/esr/faqs/smart-questions.html - 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
