Re: [android-developers] Re: Nexus 7 has no menu button?
Shead Spreet Lite. I would also be curious about WildSpectra Mobile Lite. Since they are built in very similar ways (w.r.t. the basic OS framework and model) I expect their menu behavior to be similar such that verifying with either one should inform me about both...I presume. Thanks a bunch! On Wednesday, September 19, 2012 2:47:56 PM UTC-7, Fran wrote: What's your app? Is on Google play? On Sep 19, 2012 11:36 PM, Keith Wiley kbw...@gmail.com javascript: wrote: Well, that's fair. I'm not denying the the current release is a little old and targets older SDKs. The app could certainly benefit from some sprucing up. However, I wanted to verify whether the app *should* essentially work on modern hardware given that some users were emailing me saying they didn't know how to access the menus. There's a big difference between saying I ought to update my app when I get a chance to keep things smooth and modern and saying the app is effectively broken on modern hardware and won't work until I release an emergency patch to get it going again. I was just trying to get a better picture of the circumstances. I *think* this discussion has cleared it up, and I *think* my app should be working on modern devices, albeit through an OS sidedoor meant as a temporary fix until older apps are updated. I'll have to try to find a Nexus to test it on myself to be absolutely certain of the circumstances. Thanks again. On Wednesday, September 19, 2012 2:27:36 PM UTC-7, Fran wrote: What Mark said is that you did things the standard way, users without hard menu button will see a soft one. But if you did it another way, it won't be shown. So you should update your app. On Sep 19, 2012 11:08 PM, Keith Wiley kbw...@gmail.com wrote: On Wednesday, September 19, 2012 1:58:42 PM UTC-7, bob wrote: *Many of the latest Android devices have eliminated the hard menu key found on earlier hardware. Consequently, it's now the responsibility of app developers to include soft menu keys in their apps. * * * Um, forgive me, but this response seems fundamentally at odds with Mark's initial response. Which response is closer to the correct answer? Is my app inherently broken on such devices or not? 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] Re: Nexus 7 has no menu button?
Right, ugh. Thanks. I'm out of practice. I've been testing over USB on my own device for several months now and have completely blanked on the emulator. I'll see how that works. Good suggestions. On Wednesday, September 19, 2012 2:51:37 PM UTC-7, Mark Murphy (a Commons Guy) wrote: On Wed, Sep 19, 2012 at 5:33 PM, Keith Wiley kbw...@gmail.comjavascript: wrote: I'll have to try to find a Nexus to test it on myself to be absolutely certain of the circumstances. Or, test it on an emulator where you have disabled support for the MENU button. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- 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: Nexus 7 has no menu button?
Thanks. Either Shead Spreet Lite or WildSpectra Mobile Lite. Since boths apps are built using a similar overall approach to the OS, testing either should reveal the situation for both apps simultaneously. On Wednesday, September 19, 2012 2:53:31 PM UTC-7, Tommy wrote: Yeah what is the app name, I might have access to a nexus 7. I do have access to a 4.0 tablet that does not have any hard menu keys. I’d be happy to take a look and see if I can find the menu. I would consider myself an above average user who should be able to find the menu if it really is there hidden someplace J *From:* android-d...@googlegroups.com javascript: [mailto: android-d...@googlegroups.com javascript:] *On Behalf Of *Francisco Marzoa *Sent:* Wednesday, September 19, 2012 5:46 PM *To:* android-d...@googlegroups.com javascript: *Subject:* Re: [android-developers] Re: Nexus 7 has no menu button? What's your app? Is on Google play? On Sep 19, 2012 11:36 PM, Keith Wiley kbw...@gmail.com javascript: wrote: Well, that's fair. I'm not denying the the current release is a little old and targets older SDKs. The app could certainly benefit from some sprucing up. However, I wanted to verify whether the app *should* essentially work on modern hardware given that some users were emailing me saying they didn't know how to access the menus. There's a big difference between saying I ought to update my app when I get a chance to keep things smooth and modern and saying the app is effectively broken on modern hardware and won't work until I release an emergency patch to get it going again. I was just trying to get a better picture of the circumstances. I *think* this discussion has cleared it up, and I *think* my app should be working on modern devices, albeit through an OS sidedoor meant as a temporary fix until older apps are updated. I'll have to try to find a Nexus to test it on myself to be absolutely certain of the circumstances. Thanks again. On Wednesday, September 19, 2012 2:27:36 PM UTC-7, Fran wrote: What Mark said is that you did things the standard way, users without hard menu button will see a soft one. But if you did it another way, it won't be shown. So you should update your app. On Sep 19, 2012 11:08 PM, Keith Wiley kbw...@gmail.com wrote: On Wednesday, September 19, 2012 1:58:42 PM UTC-7, bob wrote: *Many of the latest Android devices have eliminated the hard menu key found on earlier hardware. Consequently, it's now the responsibility of app developers to include soft menu keys in their apps. * Um, forgive me, but this response seems fundamentally at odds with Mark's initial response. Which response is closer to the correct answer? Is my app inherently broken on such devices or not? 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] Re: Nexus 7 has no menu button?
OYE! We're off topic and this is a very common complaint. People butt heads with me over the permissions all. the. time. It's so frustrating. I do the best I can to explain these things up front on the Android Market (or Google Play [worst name ever]) but the Google Play interface is not amenable to disseminating this kind of information efficiently. For example, I offer an explanation for the various permissions right there on Google Play in the app description, but people don't read it anyway...and then they give me a hard time about the permissions even though I explained before they ever install the app! I can't stand it!!! :-D laughing-at-the-absurdity-of-the-situation The app is a spreadsheet. The ability to jump to the phone dialer was a specific user request (not even my idea) to enable users to tap phone numbers in spread sheets and jump to the dialer app to easy calling. It's really quite an intuitive concept when you think about it, I thought it was a fantastic suggestion from a user interfaced point of view, but you honestly would not believe how much grief I've gotten over it. On Wednesday, September 19, 2012 3:09:30 PM UTC-7, Fran wrote: Why it needs permission to call phone numbers? I rather like to try it on my N7, but no with such permission, indeed. On Sep 19, 2012 11:53 PM, Keith Wiley kbw...@gmail.com javascript: wrote: Shead Spreet Lite. I would also be curious about WildSpectra Mobile Lite. Since they are built in very similar ways (w.r.t. the basic OS framework and model) I expect their menu behavior to be similar such that verifying with either one should inform me about both...I presume. Thanks a bunch! On Wednesday, September 19, 2012 2:47:56 PM UTC-7, Fran wrote: What's your app? Is on Google play? On Sep 19, 2012 11:36 PM, Keith Wiley kbw...@gmail.com wrote: Well, that's fair. I'm not denying the the current release is a little old and targets older SDKs. The app could certainly benefit from some sprucing up. However, I wanted to verify whether the app *should* essentially work on modern hardware given that some users were emailing me saying they didn't know how to access the menus. There's a big difference between saying I ought to update my app when I get a chance to keep things smooth and modern and saying the app is effectively broken on modern hardware and won't work until I release an emergency patch to get it going again. I was just trying to get a better picture of the circumstances. I *think* this discussion has cleared it up, and I *think* my app should be working on modern devices, albeit through an OS sidedoor meant as a temporary fix until older apps are updated. I'll have to try to find a Nexus to test it on myself to be absolutely certain of the circumstances. Thanks again. On Wednesday, September 19, 2012 2:27:36 PM UTC-7, Fran wrote: What Mark said is that you did things the standard way, users without hard menu button will see a soft one. But if you did it another way, it won't be shown. So you should update your app. On Sep 19, 2012 11:08 PM, Keith Wiley kbw...@gmail.com wrote: On Wednesday, September 19, 2012 1:58:42 PM UTC-7, bob wrote: *Many of the latest Android devices have eliminated the hard menu key found on earlier hardware. Consequently, it's now the responsibility of app developers to include soft menu keys in their apps. * * * Um, forgive me, but this response seems fundamentally at odds with Mark's initial response. Which response is closer to the correct answer? Is my app inherently broken on such devices or not? 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] Re: Nexus 7 has no menu button?
Thanks. On Wednesday, September 19, 2012 3:14:11 PM UTC-7, Mark Murphy (a Commons Guy) wrote: On Wed, Sep 19, 2012 at 5:51 PM, Keith Wiley kbw...@gmail.comjavascript: wrote: Shead Spreet Lite. I would also be curious about WildSpectra Mobile Lite. Since they are built in very similar ways (w.r.t. the basic OS framework and model) I expect their menu behavior to be similar such that verifying with either one should inform me about both...I presume. Shead Spreet Lite has the menu affordance in the system bar on a Galaxy Tab 2 7.0, running ICS. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- 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: Nexus 7 has no menu button?
Oh cool. I see what you're getting at. Thanks. I actually know exactly how that happened. I originally used ACTION_CALL (and therefore had to put CALL_PHONE in). I didn't like having it immediately dial so I switched to ACTION_DIAL and liked the interaction a lot better that way (allowing the user to confirm the call) but CALL_PHONE got left in as a by-product. In evolution this process is referred to as scaffolding by the way, where the evolution of feature X requires feature Y but at a later time Y fades away leaving X looking fairly inexplicable. Thanks. On Wednesday, September 19, 2012 3:31:30 PM UTC-7, Mark Murphy (a Commons Guy) wrote: On Wed, Sep 19, 2012 at 6:24 PM, Keith Wiley kbw...@gmail.comjavascript: wrote: The ability to jump to the phone dialer was a specific user request (not even my idea) to enable users to tap phone numbers in spread sheets and jump to the dialer app to easy calling. You do not need CALL_PHONE to use ACTION_DIAL (jump to the dialer app). You need CALL_PHONE to use ACTION_CALL. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- 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: Nexus 7 has no menu button?
I appreciate you helping me clarify the situation. Cheers! On Wednesday, September 19, 2012 3:39:11 PM UTC-7, Fran wrote: Well, bear in mind that I was about to install the application just for helping you for free, so I am actually not interested on it enough to read the app description... Anyway I realized after writing my previous message that N7 has no phone at all, so that permission has no effect neither... so I installed the app and it actually SHOWS the menu soft button at bottom right as expected. May be some users are just special... On Sep 20, 2012 12:26 AM, Keith Wiley kbw...@gmail.com javascript: wrote: OYE! We're off topic and this is a very common complaint. People butt heads with me over the permissions all. the. time. It's so frustrating. I do the best I can to explain these things up front on the Android Market (or Google Play [worst name ever]) but the Google Play interface is not amenable to disseminating this kind of information efficiently. For example, I offer an explanation for the various permissions right there on Google Play in the app description, but people don't read it anyway...and then they give me a hard time about the permissions even though I explained before they ever install the app! I can't stand it!!! :-D laughing-at-the-absurdity-of-the-situation The app is a spreadsheet. The ability to jump to the phone dialer was a specific user request (not even my idea) to enable users to tap phone numbers in spread sheets and jump to the dialer app to easy calling. It's really quite an intuitive concept when you think about it, I thought it was a fantastic suggestion from a user interfaced point of view, but you honestly would not believe how much grief I've gotten over it. On Wednesday, September 19, 2012 3:09:30 PM UTC-7, Fran wrote: Why it needs permission to call phone numbers? I rather like to try it on my N7, but no with such permission, indeed. On Sep 19, 2012 11:53 PM, Keith Wiley kbw...@gmail.com wrote: Shead Spreet Lite. I would also be curious about WildSpectra Mobile Lite. Since they are built in very similar ways (w.r.t. the basic OS framework and model) I expect their menu behavior to be similar such that verifying with either one should inform me about both...I presume. Thanks a bunch! On Wednesday, September 19, 2012 2:47:56 PM UTC-7, Fran wrote: What's your app? Is on Google play? On Sep 19, 2012 11:36 PM, Keith Wiley kbw...@gmail.com wrote: Well, that's fair. I'm not denying the the current release is a little old and targets older SDKs. The app could certainly benefit from some sprucing up. However, I wanted to verify whether the app *should* essentially work on modern hardware given that some users were emailing me saying they didn't know how to access the menus. There's a big difference between saying I ought to update my app when I get a chance to keep things smooth and modern and saying the app is effectively broken on modern hardware and won't work until I release an emergency patch to get it going again. I was just trying to get a better picture of the circumstances. I *think* this discussion has cleared it up, and I *think* my app should be working on modern devices, albeit through an OS sidedoor meant as a temporary fix until older apps are updated. I'll have to try to find a Nexus to test it on myself to be absolutely certain of the circumstances. Thanks again. On Wednesday, September 19, 2012 2:27:36 PM UTC-7, Fran wrote: What Mark said is that you did things the standard way, users without hard menu button will see a soft one. But if you did it another way, it won't be shown. So you should update your app. On Sep 19, 2012 11:08 PM, Keith Wiley kbw...@gmail.com wrote: On Wednesday, September 19, 2012 1:58:42 PM UTC-7, bob wrote: *Many of the latest Android devices have eliminated the hard menu key found on earlier hardware. Consequently, it's now the responsibility of app developers to include soft menu keys in their apps. * * * Um, forgive me, but this response seems fundamentally at odds with Mark's initial response. Which response is closer to the correct answer? Is my app inherently broken on such devices or not? 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
[android-developers] Market device-filtering question
I realize this question is more about the market than android code development, but by Google's own admission they have completely shut down the market forums coincident with the switch to Google Play, and my question *is* about how to properly configure an app for the market, so that's sort of a developer question. My problem is that a potential customer with a 10.1 Galaxy Tab says he can't see my app in the market (or Play or whatever stupid name they recently gave it that makes it seem like Google only sells silly games and not serious business software!), but he *can* see it from his phone...so it isn't excluded for his region or some currency issue. Rather, it would appear that the market is filter-excluding my app specifically on his tablet. I have the following entry in my manifest, which I would have expected to avoid this kind of problem: supports-screens android:xlargeScreens=true android:largeScreens=true android:normalScreens=true android:smallScreens=true android:anyDensity=true / Is there something else I need to put in the manifest to make the app appear on tablets? At a higher level of abstraction, is there a general way of knowing precisely why an app is being excluded for certain devices so that developers can readily solve these kinds of problems? Thank you. 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
[android-developers] Re: Market device-filtering question
Thanks for responding. Here's my permission list: uses-permission android:name=android.permission.INTERNET / uses-permission android:name=android.permission.ACCESS_FINE_LOCATION / uses-permission android:name=android.permission.WAKE_LOCK / uses-permission android:name=android.permission.WRITE_EXTERNAL_STORAGE / uses-permission android:name=android.permission.CALL_PHONE / Hmmm, your followup question concerns me. My manifest doesn't have the uses-feature tag at all (the app goes back to 2009 and as I have upgraded it I haven't added extraneous stuff that was unnecessary; I have only made changes that new SDKs require in order to build and run the app). At the very least I would expect that leaving the filter wide open (by specifying no required features) would make it maximally visible. Why wouldn't someone with a Galaxy Tab be able to see the app as a result of the uses-feature tag? It seems to me like the uses- feature tag could only make an app *less* visible (by indicating a feature which someone's device lacks). If I indicate no features at all, doesn't that prevent it from being filtered on anyone's device? I think I misunderstand how this tag works. Thank you. On Mar 17, 11:50 am, Mark Murphy mmur...@commonsware.com wrote: What permissions are you requesting? And, did you add the appropriate uses-feature elements as needed for things the permissions imply that you do not actually need? http://developer.android.com/guide/topics/manifest/uses-feature-eleme... On Sat, Mar 17, 2012 at 2:12 PM, Keith Wiley kbwi...@gmail.com wrote: I realize this question is more about the market than android code development, but by Google's own admission they have completely shut down the market forums coincident with the switch to Google Play, and my question *is* about how to properly configure an app for the market, so that's sort of a developer question. My problem is that a potential customer with a 10.1 Galaxy Tab says he can't see my app in the market (or Play or whatever stupid name they recently gave it that makes it seem like Google only sells silly games and not serious business software!), but he *can* see it from his phone...so it isn't excluded for his region or some currency issue. Rather, it would appear that the market is filter-excluding my app specifically on his tablet. I have the following entry in my manifest, which I would have expected to avoid this kind of problem: supports-screens android:xlargeScreens=true android:largeScreens=true android:normalScreens=true android:smallScreens=true android:anyDensity=true / Is there something else I need to put in the manifest to make the app appear on tablets? At a higher level of abstraction, is there a general way of knowing precisely why an app is being excluded for certain devices so that developers can readily solve these kinds of problems? Thank you. 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 -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android Training in DC:http://marakana.com/training/android/ -- 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: Market device-filtering question
On Mar 18, 8:48 am, Mark Murphy mmur...@commonsware.com wrote: On Sun, Mar 18, 2012 at 11:27 AM, Keith Wiley kbwi...@gmail.com wrote: Thanks for responding. Here's my permission list: uses-permission android:name=android.permission.INTERNET / uses-permission android:name=android.permission.ACCESS_FINE_LOCATION / uses-permission android:name=android.permission.WAKE_LOCK / uses-permission android:name=android.permission.WRITE_EXTERNAL_STORAGE / uses-permission android:name=android.permission.CALL_PHONE / Hmmm, your followup question concerns me. My manifest doesn't have the uses-feature tag at all And therein lies your problem. Tablets are not phones, and CALL_PHONE implies android.hardware.telephony. At the very least I would expect that leaving the filter wide open (by specifying no required features) would make it maximally visible. You did not read the page I linked to: http://developer.android.com/guide/topics/manifest/uses-feature-eleme... Yes I did. Thank you. I simply missed the reference to cell-phones. I don't think of my app as requiring cell-phone capability (it's a spread sheet), so I tend to completely forget about it and not consciously reference any cell-phone aspect of a webpage or discussion since it's barely relevant to my app. The app only needs the associated permission because it's possible to dial a phone number directly from a spreadsheet in my app, but obviously, by no means does that extra capability prevent the app from being useful on android nonphone devices (and it's such a tiny inconsequential feature I totally forget it's even in there). I'll look into how to make that permission or feature optional so it still appears in the market on nonphone devices. 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: Market device-filtering question
Looks like this is the trick: uses-feature android:name=android.hardware.telephony android:required=false / ...plus a few related entries for location access, etc. Thanks again. 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
[android-developers] Logcat is broken every time phone is unplugged
Every time the phone is unplugged from USB, the logcat is permanently corrupted in that the when the phone is reconnected, logcat does not reestablish. Restarting an app, either in debug or run mode produces zero logcat output after that point. Closing the logcat window view and reopening it has no effect. The only solution is to quit and restart Eclipse. Therefore, I must quit and restart Eclipse every time I take my phone with me and then later return. I've been having this problem since day one with Android development, three years ago. In that time I have installed new versions of Eclipse and numerous updates to the Android SDK and Eclipse plugin. Nothing has ever improved the situation w.r.t. this bug. Anyone know anything about this? 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: Logcat is broken every time phone is unplugged
G1, OS 1.6 Eclipse Helious I'm part way through installing Android SDK rev 16, but like I said, this has been persistent across a variety of versions of all the associated pieces. I don't understand why I haven't seen more reports of this. Thanks for any help. On Jan 14, 12:27 pm, Mark Murphy mmur...@commonsware.com wrote: I haven't seen that on any of my devices. What's the phone? On Sat, Jan 14, 2012 at 3:24 PM, Keith Wiley kbwi...@gmail.com wrote: Every time the phone is unplugged from USB, the logcat is permanently corrupted in that the when the phone is reconnected, logcat does not reestablish. Restarting an app, either in debug or run mode produces zero logcat output after that point. Closing the logcat window view and reopening it has no effect. The only solution is to quit and restart Eclipse. Therefore, I must quit and restart Eclipse every time I take my phone with me and then later return. I've been having this problem since day one with Android development, three years ago. In that time I have installed new versions of Eclipse and numerous updates to the Android SDK and Eclipse plugin. Nothing has ever improved the situation w.r.t. this bug. Anyone know anything about this? 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/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android Training in NYC:http://marakana.com/training/android/ -- 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: Logcat is broken every time phone is unplugged
Hmmm, okay. I don't have one that fits the G1's connecter, but I'll consider the suggestion. Sigh. On Jan 14, 12:47 pm, Mark Murphy mmur...@commonsware.com wrote: Perhaps try a different micro USB cable. -- 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] Run mode engages debug mode!
I have generally run in either run mode or debug mode depending on my needs, using the former if I want to see the app run considerably faster but still observe the logcat. All of a sudden, out of the blue, run mode starts in debug mode every time. I have to click the detach button to get it out. I tried quiting Eclipse, I tried unplugging my phone. I have no idea how to fix this at this point. Anyone ever heard of such a thing? -- 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: Logcat is broken every time phone is unplugged
The following appears in the Console window when I plug the usb cable into the phone. Any ideas? [2012-01-24 18:27:21 - Unexpected error while launching logcat. Try reselecting the device.] device not found com.android.ddmlib.AdbCommandRejectedException: device not found at com.android.ddmlib.AdbHelper.setDevice(AdbHelper.java:736) at com.android.ddmlib.AdbHelper.executeRemoteCommand(AdbHelper.java: 373) at com.android.ddmlib.Device.executeShellCommand(Device.java:372) at com.android.ddmuilib.logcat.LogCatReceiver $1.run(LogCatReceiver.java:100) at java.lang.Thread.run(Thread.java:680) -- 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] avds not visible
My app is built against the 3.0 SDK (which I think is the equivalent of android 11 or something like that, I can't keep these numbers straight) but the manifest specifies merely min sdk 3 and target sdk 4 (3 should be 1.6 if I recall correctly). I have a phone running 2.3.3. and I have various avds. If I try to debug the app, Eclipse can see the phone (it shows a red X instead of a green check which suggests the phone's OS is lower than some perceived ideal, I'm not sure what given the manifest settings quoted above), but it runs nonetheless. However, Eclipse can't see the avds at all, even though some of them have exactly the same OS as the phone 2.3.3.. It sees avds with OS 3, not lower. How can it see a phone but not an avd with exactly the same OS version and why is it insisting on such high avd versions for this app? 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: avds not visible
Whoops, like I said, the manifest specifies min 3 and target 4. That's OS 1.5 and 1.6 respectively. I suggest 3 was 1.6 earlier which is incorrect. -- 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] -audio coreaudio no longer works
I used to be able to simulate audio recording in the emulator by passing in -audio coreaudio. Something has changed though (I've undergone several SDK updates of course) and now my app doesn't get any audio. It initializes AudioRecord just fine but each call to mAudioRecord.read() leaves the buffer full of 0s. It returns the buffer length so it acts like it put bytes in the buffer, but it put 0s as if it isn't getting any audio signal at all. Any ideas what changed or how to fix it? 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: -audio coreaudio no longer works
Sorry, I figured it out. I had to edit the AVD and explicitly add audio support to the parameters. I don't recall doing that before, but it made sense when I saw it. Head's up to anyone else having similar problems. Cheers! On Mar 10, 7:51 pm, Keith Wiley kbwi...@gmail.com wrote: I used to be able to simulate audio recording in the emulator by passing in -audio coreaudio. Something has changed though (I've undergone several SDK updates of course) and now my app doesn't get any audio. It initializes AudioRecord just fine but each call to mAudioRecord.read() leaves the buffer full of 0s. It returns the buffer length so it acts like it put bytes in the buffer, but it put 0s as if it isn't getting any audio signal at all. Any ideas what changed or how to fix it? 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] Custom contextual menu options don't appear
I am getting bug reports from a very small number of users (two so far) that my custom contextual menu options don't appear and are therefore unavailable. This is in an app that has been around for several years and has an installed customer base of around 130,000. I have only had two such bug reports so far. Has anyone else ever heard of such a bug, and in a user-specific manner no less? I know that in one case the user's setup is an HTC Desire S (he didn't tell me the OS version) and in the other case the user's setup is an HTC Incredible S running Android 2.3.3 with HTC Sense 2.1. Anyone know anything about this? I am rather flustered since I can't replicate or otherwise easily investigate the problem. I'm worried this might have something to do with a nonstock Android UI of some sort, although I thought HTC was generally pretty good about honoring the Android specs (after all, they built the G1 and the G2 for heaven's sake). 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: Custom contextual menu options don't appear
I hate to do a bump, but this is a real error (two independent reports) and it definitely phone or model specific (1000s of people have never reported any such error even though it would be obvious to practically anyone who tried to use the app for more than a few minutes). I don't know what causes it or what to do about it since I don't own the models that it is being reported on. I really need to know if anyone else has ever seen something like this, and otherwise, if anyone with deeper knowledge of how this part of the OS (contextual menus) can speculate as to what is going on. 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
[android-developers] Re: Custom contextual menu options don't appear
I see the other thread now. I'll pick it up from there. 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] Detect AdMob AdView tap?
I would like to detect (and then pass on through) AdMob clicks but I'm not sure how to do this. My efforts so far have not been entirely fruitful. Has anyone done this before? I overrode the AdView class and detected touch events in onInterceptEvent(), but only tap events actually trigger an ad and I can't detect those (I implemented OnGestureListener but onSingleTapUp() isn't called). There's no easy easy to determine that an 'up' event is a tap in onInterceptEvent(). 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] Does Android cache http-requested data?
Does Android cache http-requested data? I keep a small text file with various app-settings on my webserver. When my app launches, it sends an http request to my webserver to grab the text file and retrieve the settings. This enables me to update the settings of an app installed on a phone in the field from the server. The problem is, when I update the text file on the server, I usually don't see an immediate change in the text file retrieved by my app. It can take hours for the change to show up in my app's http requests. I know that the problem is not merely one of the file updating through various buffers/caches on the webserver because I can see the new version of the file if I load the same URL in a web browser...including a web browser on the exact same Android device I am running my app on...so a web browser (even one on the phone itself) sees the updated file immediately after I change it, but my app doesn't see it for several hours. It feels like Android is caching previous http request results and returning those to apps that make repeated requests instead of reloading the URLs from the web...and it takes a very long time to label this presumed cache as stale and reload the file from the server...several hours. On a side note, I have tried killing the app to make sure it's totally gone. I have even tried rebooting the phone and yet the problem still persists...which is mind-boggling. I am quite flummoxed. I am aware that Android is requesting and receiving a GZipInputStream, and I can see the input stream's type in the debugger, but that seems irrelevant to my issue. Here's how I pull the text file from the web server into my app. Any ideas why a browser on the same device successfully retrieves the updated file and my code doesn't? String address = http://URL_of_text_file_on_my_webserver.txt;; URL url = new URL(address); HttpURLConnection conn = (HttpURLConnection) url.openConnection(); InputStream is = (InputStream) conn.getContent(); Reader reader = new InputStreamReader(is, UTF-8); StringWriter writer = new StringWriter(); char[] buffer = new char[1024]; for (int length = 0; (length = reader.read(buffer)) 0;) writer.write(buffer, 0, length); is.close(); reader.close(); writer.close(); String fileStr = writer.toString(); 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
Re: [android-developers] Does Android cache http-requested data?
Thanks, I'll definitely look into that. I can see that it the cache value is set to true but I can't test whether turning it off fixes the problem right now. I'll try it later. That seems like a very strong possibility for this issue. Thanks again. -- 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: Does Android cache http-requested data?
Thanks for the great feedback on this everyone! -- 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] Is the 'back' button still kosher?
My understanding is that modern Android best practice is to not use the system-level menu button or system-level options menu anymore since such buttons are frequently difficult to access or even absent on some devices. I have gutted all menu access from my app as a result (I admit, it is quite tedious to get access to the menus on some devices since you have to tap at least once just to get a menu bar to appear and then again on a menu icon to get the menu...and I'm not sure even that approach works on all of the most modern devices). What I'm not sure about is whether I can still rely on the standard 'back' button or whether I need to add such functionality to my UI (add a soft button on my screen) on the concern that some devices may not present a usable back button to the user. Any thoughts on this subject? -- 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] Is the 'back' button still kosher?
All right. I brought this up a few weeks ago on this list and some of the advice on the topic was to avoid menus entirely and replace them with in-app soft-menus from now on...despite the action bar. I guess that advice was incorrect. Thanks for the clarification. On Thursday, November 1, 2012 10:42:21 PM UTC-7, Nirav Parmar wrote: My understanding is that modern Android best practice is to not use the system-level menu button or system-level options menu anymore since such buttons are frequently difficult to access or even absent on some devices. Keith , Your understanding is wrong here. Read about ActionBar. http://developer.android.com/design/patterns/actionbar.html you can use that..Also, if device have hardware buttons(menu buttons) Action Overlay will not display in Action bar otherwise you will get Action Overlay..so all your functionality can be now placed in Action bar (which we used to put in menu previously) What I'm not sure about is whether I can still rely on the standard 'back' button or whether I need to add such functionality to my UI (add a soft button on my screen) on the concern that some devices may not present a usable back button to the user. Again, that's not true.Each Android device will come up with standard back button..This is how Android OS is designed..any device doesn't have hardware buttons..Android OS will display Back ,Recent and Home buttons on screen at bottom. Also, According to Android's new Design Navigation pattern, UP button is added.You can show UP button in Action Bar(Which can be used for Application nevigation) Read Here , http://developer.android.com/design/patterns/navigation.html .This will clear you doubts. Thanks Regards, Nirav. On Fri, Nov 2, 2012 at 10:41 AM, Keith Wiley kbw...@gmail.comjavascript: wrote: My understanding is that modern Android best practice is to not use the system-level menu button or system-level options menu anymore since such buttons are frequently difficult to access or even absent on some devices. I have gutted all menu access from my app as a result (I admit, it is quite tedious to get access to the menus on some devices since you have to tap at least once just to get a menu bar to appear and then again on a menu icon to get the menu...and I'm not sure even that approach works on all of the most modern devices). What I'm not sure about is whether I can still rely on the standard 'back' button or whether I need to add such functionality to my UI (add a soft button on my screen) on the concern that some devices may not present a usable back button to the user. Any thoughts on this subject? Thanks Regards, Nirav -- 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] (Http)URLConnection.setUseCaches(false) isn't working
A few weeks ago I mentioned that I was experiencing unwanted http caching (I mentioned it here because I wasn't sure if the cause of the problem was the Android OS performing the caching in a way that didn't make sense to me). At the time, it was suggested that I experiment with getUseCaches() and setUseCaches(). This has definitely not solved the problem. First of all, it does indeed appear that caching is enabled by default (as is GZipping the stream interestingly, I think I've read about this somewhere). However, setting caching false doesn't help. Not only does my app not confidently load an updated version of the file from the server, but it doesn't even detect that the file is gone from the server (if I change its name for example). Rather, the app still happily retrieves the cached version of the file, even though I'm calling setUseCaches(false). Does anyone have any thoughts on how else to fix this problem? I know there is a solution because the phone's web browser app (actually, I'm using Dolphin) properly loads the server version of the file every time. Once again, I don't mean to bring this up on an Android forum if it really isn't an Android issue...but I'm not sure whether the problem is coming from the Android system for some reason (I'm not sure whether I should expect my code to work in any other Java environment, just not Android). Where else might the cache be coming from if the URLConnection's useCaches variable is definitely false (verified as I step over setUseCaches(false) in the debugger)? I'm sorry if this is off-topic, I appreciate any help. Here's how I load the file: String address = httpUrlOfFileOnMyWebserver; URL url = new URL(address); HttpURLConnection conn = (HttpURLConnection) url.openConnection(); if (conn.getUseCaches()) conn.setUseCaches(false); InputStream is = (InputStream)conn.getContent(); Reader reader = new InputStreamReader(is, UTF-8); StringWriter writer = new StringWriter(); char[] buffer = new char[1024]; for (int length = 0; (length = reader.read(buffer)) 0;) writer.write(buffer, 0, length); is.close(); reader.close(); writer.close(); String fileStr = writer.toString(); -- 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: (Http)URLConnection.setUseCaches(false) isn't working
I guess one solution that seems to show promise is appending an unused randomized GET variable to the end of the URL. That seems pretty hackish though. -- 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] Is the 'back' button still kosher?
Thanks for coming back to my original question. So, perhaps we can all consider my situation from a higher level and discuss the possible design options we might choose from (and which options are most in the spirit of intended Android user experience). Although I have a few Android apps, the one I'm concerned with at the moment is a game and the back button is used to move between the various screens. So, when the game launches you get an on-screen menu of options (settings, scoreboard, play, credits). Tapping those takes you to a corresponding screen while tapping the back button takes you from those secondary screens back to the main menu (or from the main menu it exits the app). Likewise, while playing, the back button doesn't immediately exit play mode back to the main menu but rather first pauses the game. From the paused view, a second back button tap cancels play and returns to the main menu...while tapping the paused screen (anywhere) resumes play. That's pretty much it...and my question is whether I need to offer a nonback-button method for these various actions? Should each of the secondary screens have an on-screen return to main menu button? Should the main menu have an explicit quit option? Should in-game-play not rely on the back button to either pause the game or cancel and return to the main menu? These are the things I'm thinking about with as far as this discussion is concerned. Thanks. On Friday, November 2, 2012 6:22:50 AM UTC-7, latimerius wrote: On Fri, Nov 2, 2012 at 1:02 PM, Mark Murphy mmu...@commonsware.comjavascript: wrote: On Fri, Nov 2, 2012 at 2:10 AM, Keith Wiley kbw...@gmail.comjavascript: wrote: All right. I brought this up a few weeks ago on this list and some of the advice on the topic was to avoid menus entirely and replace them with in-app soft-menus from now on...despite the action bar. I guess that advice was incorrect. There are developers who do not want to use the action bar, such as game developers who find that an always-present action bar is a distraction or clashes with their game-focused UI. A subset of those developers are clinging desperately to the old options menu behavior (e.g., setting android:targetSdkVersion to be under 11) -- the right answer for these game developers is to add in-app soft menus that blend in with the game UI. The right answer would have been for Google to leave the button alone - but we've talked about that already, the button was universally useful, and there's not always a UI to blend in anyway. Back on topic, my lesson for my remaining days on Android from the Menu button fiasco and other breakages caused by previously guaranteed stuff being pulled at whim from under people using them would be - interact as little as possible with the platform. Don't rely on stuff on being there cause it likely won't, don't rely on APIs cause they will be deprecated or changed. As far as the Back button specifically, one would think that should be safe to rely on. Based on experience though, my advice would be, think hard about what you need it for and what your alternatives are. If you find any half-decent one, consider using it. You might be glad you did once next version of the platform is 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
[android-developers] Re: (Http)URLConnection.setUseCaches(false) isn't working
I don't generally use wifi unless there is an explicit reason to do so (poor cell coverage AND good wifi coverage...a rare combination). My data plan and data usage do not drive me to go to wifi (e.g. to save bandwidth). On Friday, November 2, 2012 7:06:52 AM UTC-7, bob wrote: Are you using WiFi or your phone's data connection? I saw this strange issue with this Origami Iris game where it would somehow load a page from the cache if I used my MetroPCS connection. Didn't happen on Wifi though. Very weird. On Friday, November 2, 2012 1:27:38 AM UTC-5, Keith Wiley wrote: A few weeks ago I mentioned that I was experiencing unwanted http caching (I mentioned it here because I wasn't sure if the cause of the problem was the Android OS performing the caching in a way that didn't make sense to me). At the time, it was suggested that I experiment with getUseCaches() and setUseCaches(). This has definitely not solved the problem. First of all, it does indeed appear that caching is enabled by default (as is GZipping the stream interestingly, I think I've read about this somewhere). However, setting caching false doesn't help. Not only does my app not confidently load an updated version of the file from the server, but it doesn't even detect that the file is gone from the server (if I change its name for example). Rather, the app still happily retrieves the cached version of the file, even though I'm calling setUseCaches(false). Does anyone have any thoughts on how else to fix this problem? I know there is a solution because the phone's web browser app (actually, I'm using Dolphin) properly loads the server version of the file every time. Once again, I don't mean to bring this up on an Android forum if it really isn't an Android issue...but I'm not sure whether the problem is coming from the Android system for some reason (I'm not sure whether I should expect my code to work in any other Java environment, just not Android). Where else might the cache be coming from if the URLConnection's useCaches variable is definitely false (verified as I step over setUseCaches(false) in the debugger)? I'm sorry if this is off-topic, I appreciate any help. Here's how I load the file: String address = httpUrlOfFileOnMyWebserver; URL url = new URL(address); HttpURLConnection conn = (HttpURLConnection) url.openConnection(); if (conn.getUseCaches()) conn.setUseCaches(false); InputStream is = (InputStream)conn.getContent(); Reader reader = new InputStreamReader(is, UTF-8); StringWriter writer = new StringWriter(); char[] buffer = new char[1024]; for (int length = 0; (length = reader.read(buffer)) 0;) writer.write(buffer, 0, length); is.close(); reader.close(); writer.close(); String fileStr = writer.toString(); -- 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: (Http)URLConnection.setUseCaches(false) isn't working
I haven't considered testing different kinds of connections...I figured the phone was responsible for the caching and the issue was unrelated to the connection...but I could test it. For that matter, it could be the fault of the particular phone (perhaps this phone caches http data without permission). At the current time, most of my tests have been performed over cell, not wifi (TMobile, Seattle area if that matters). On Friday, November 2, 2012 8:01:15 AM UTC-7, Robert Greenwalt wrote: Even if this is a carrier issue, please let us know - we'd like the carriers to do the right thing and do have some contacts to explore issues like this. Kieth, was this on mobile data or on wifi (or other)? -- 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: (Http)URLConnection.setUseCaches(false) isn't working
Why was my response to this message deleted? At any rate, all I said was that I wasn't familiar with the methods you suggested and that I'll look them up. Thanks. On Friday, November 2, 2012 6:59:25 AM UTC-7, Streets Of Boston wrote: Did you try to add caching headers to the request and/or response: Your android client app' request: If-None-Match: **, If-Modified-Since: **, If-Unmodified-Since: ** Your server's response: Cache-Control: *no-cache*, ETag: *x* On Friday, November 2, 2012 2:40:57 AM UTC-4, Keith Wiley wrote: I guess one solution that seems to show promise is appending an unused randomized GET variable to the end of the URL. That seems pretty hackish though. -- 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] ProGuard docs are inconsistent with the actual config files
I'm working off these instructions, which as you can see are a proper and formal component of the official Android dev docs: *http://developer.android.com/tools/help/proguard.html* (Side-note: that file has no date written on it and no applicable Android SDK version written on it; it is temporally unresolvable. Perhaps my problems arise from the fact that the docs are out-of-date, but there's no way to know. Those docs could be four years old for all I know. Online files should always be dated.) At any rate, near the top of those docs, just trying to get started with ProGuard, it says this: *To enable ProGuard so that it runs as part of an Ant or Eclipse build, set the proguard.config property in the project_root/project.properties file. * First of all, it would be helpful if those docs would offer more up-front information about how to get the crucial proguard.cfg file to appear in the project directory. I found out that I needed to run this: $ android update project -p . -t 6 ...but that was in rather tangential documentation (a StackOverflow discussion if I recall correctly). Regardless, the next step as described in the docs is to edit project.properties, but if I open that file, I immediately see the following warning: *# This file is automatically generated by Android Tools. # Do not modify this file -- YOUR CHANGES WILL BE ERASED! * ...which is where I currently stand, rather stuck as you can imagine. The docs say to edit that file, but the file clearly says not to edit it! This overall process does not appear to be adequately documented and I'm not sure how to proceed. Does anyone have any thoughts on how to best get ProGuard up and running with an Eclipse based Android project. I'm finding a lot of casual discussion online but little in the way of formal procedure. Even the formal Android docs I'm working off of seem to be incompatible with the circumstances, as I just described above. I understand it sounds like whining to complain about these problems, but the official docs on *http://developer.android.com* don't match the do-not-edit warning in the actual files generated by the Android SDK and I honestly don't know what the next step is. This is a troublesome inconsistency. I would be very grateful for any help in getting this going. Thanks a bunch! *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
[android-developers] You need to enter a valid Youtube address.
I realize this issue is not really about Android development, but ever since the Android Market Forum went away, I have not been sure where developers should discuss Google Play Store administration problems. If you know a better place than this group, please politely inform me, I would appreciate the clarification. Otherwise, here goes... I'm trying to set up a new app and it won't let me enter a promo video URL. I keep getting an error *You need to enter a valid Youtube address.*, which is staggeringly unspecific feedback. Isn't a proper youtube URL of the form *https://www.youtube.com/watch?v=XXX*? I don't know what else to try. Any ideas? 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: You need to enter a valid Youtube address.
Incidentally, I don't think the problem is my video. For example, I found another app on the market, not my app, which had a video. I attempted to attach the youtube URL to that video to my app (just to test of course) and I got the same error. Presumably, the URL format in my first post in this thread is not, in fact, correct...but I am confounded as to what the correct format is. Gah! Why is the error message so unhelpful. Please help. 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: You need to enter a valid Youtube address.
I also tried the youtube short URL, btw, i.e., http://youtu.be/XXX. http://youtu.be/KmBVrga0mGw -- 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] You need to enter a valid Youtube address.
On Monday, November 19, 2012 3:13:32 AM UTC-8, TreKing wrote: Does this occur on both the old console and the new version they're working on? That's an excellent question. Unfortunately, I can't test it. When I revert to the old system I can't see the new app I am preparing at all...which is presumably because it is not published yet but rather in the app-preparation mode which the new system offers. I can see how that might be related to my original problem...but I'm not sure what to do. I certainly don't want to make a second and duplicate app in the old system...at least not without deleting the version in the new system. Ugh. -- 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: You need to enter a valid Youtube address.
I couldn't get that to work. Did you add it using the old console system or the new one? On Monday, November 19, 2012 1:08:14 AM UTC-8, Ralph Bergmann wrote: Am 19.11.12 09:39, schrieb Keith Wiley: I also tried the youtube short URL, btw, i.e., http://youtu.be/XXX . http://youtu.be/KmBVrga0mGw I have added this video with success http://www.youtube.com/watch?v=zHirwKGEfoE Ralph -- 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] You need to enter a valid Youtube address.
On Monday, November 19, 2012 3:13:32 AM UTC-8, TreKing wrote: Does this occur on both the old console and the new version they're working on? God! That was a good suggestion, but it didn't work. I recreated my entire app in the old system (so now it is duplicated with an in-progress draft through the new system) and it still won't take a youtube URL. I can't believe this. Why does this work for everyone else? I'm using a very standard youtube URL. Like I said, I even tried plugging in the URLs of apps that aren't mine, promo videos for other people's apps that I know work because those apps show the videos...and I couldn't even get those to go through. And of course google has not responded to my request for helpso I'm screwed. There is simply no way to figure out what's wrong or how to fix it. -- 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: You need to enter a valid Youtube address.
So, I have sort of found the problem and solution. This is really really weird. If I type a youtube address into FireFox or click on a youtube clip in youtube to go to that video, it automatically forwards to https even if I start with http. If I copy/paste the https URL into the dev console, it rejects it as I have described in this thread even though the https URL loads the video just fine. I must manually edit the URL to be http in the dev console in order to make it go through. Admittedly, Safari didn't seem to convert the URL to https so the error is somewhat browser specific. Nonetheless, I am amazed that I found absolutely no description of this problem as I was trying to figure out what was going on. So, now it's documented, here, in this thread...forever. 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
[android-developers] Best approach for incorporating in-app purchase demo code into real project.
The 'Dungeons' demo code goes to some length to emphasize the security issues involved in implementing in-app purchases. One thing it makes some issue of is being careful about dropping the demo code into an existing project as opposed to reimplementing it from scratch (ugh). I'm using CodeDefender (or whatever it's called, I don't have it in front of me right now) for basic obfuscation, and I certainly intend to mix up the demo code some...but I'm curious if there is a more explicit prescription for how to fold in-app purchases into a project. Would others strongly advise against literally duplicating the Dungeons code into a subpackage of my actual project and then proceeding to make various cosmetic, yet functionally null, changes to the code? Is there a better way to accomplish this overall task? 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: Best approach for incorporating in-app purchase demo code into real project.
*CodeDefender* - *ProGuard*. Sorry for the confusion. -- 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] How do other developers handle IAP refunds on unmanaged purchases?
I'm trying to design a policy for processing (or refusing) refunds for unmanaged in-app purchases. Refunds for managed purchases are quite simple in concept since the app can simply unflip the bit that the managed purchase corresponds to. If you granted access to higher levels, you can simply take them away again. The refund is tightly correlated with the account and the device so you (the developer) don't have to keep that association, you let google process the money and you let the app undo the managed purchase. However, unmanaged purchases are kind of messy. You can buy the same thing over and over again, they cannot be easily associated with a google account to verify the inventory, and unmanaged purchases are often nonbinary in nature, i.e., if an unmanaged purchase is in-game-currency (canonical gold coins) then you could buy 100 coins for $.99 and spend half those coins in the game...and then -- rather unfairly -- want a refund of your original purchase. It is difficult from for the developer to identify that this is an unfair request at the time the refund request is made, so the developer cannot easily determine whether to refuse the refund. As described above, it is difficult to flatly refuse to grant refunds on unmanaged purchases because it is difficult to determine whether the original purchase has been fully or partially used up in the game. I am attempting to implement a server-side database of unmanaged purchases so I know who had bought what *and* the extent to which those purchased items have been used up...but it is difficult to associate google purchases (google accounts) with devices or app installations...and it is devices which would report their unmanaged purchases to my server, not google accounts. Sure, my app can identify itself with a UUID, but how do I know which *google account* that installation (and its unmanaged purchases) go with. To put it differently, if I receive a refund request, how do I look the installation up in my server database to see if the unmanaged purchase has been partially or fully used up such that the refund request from that google account is unfair and should be denied? At any rate, I'm just swimming through these issues trying to decide how I want to handle them, and I'm extremely curious what sorts of solutions other developers have come up with. This could make for a very riveting discussion if others care to participate. *Cheers!* 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
[android-developers] Re: How do other developers handle IAP refunds on unmanaged purchases?
On Monday, December 3, 2012 12:45:33 PM UTC-8, Brill Pappin wrote: Tough one and something I'm about to get into myself. As a rule we simply give anyone a refund who asks, but in app, unmanaged purchased would be much tougher to handle. Sure, I always refund actual baseline app purchases (good old fashioned direct app purchases)...but I've never used IAP before so these new issues are...new. What I would do in your case is simply reuse whatever system you have for delivering the unmanaged purchase goods to flag as soon as the user did anything with what they bought, and make the policy: refund on unopened merchandise only. You may need to modify your app a little to make this clear to the users, but should be a small price to pay for smoother integration :) I agree, but that's the problem. I admit I didn't explain it very well. The server-side database for managing purchased items identifies installations by a UUID which is created when the app is run for the first time. This is conceptually similar to using a unique *device* id except that if you research unique Android device identifiers you quickly learn there is no across-the-board 100% operational way to get such ids...so I use UUIDs generated in-app at first launch. Fine...but google purchases don't identify their device (much less my own personal UUID scheme obviously). So when a google account (a person or gmail address in effect) requests a refund...how on Earth do I look them up in my database of in-app unmanaged purchases (tied to installation UUIDs) to see if the purchased item has ever been used within the app? How do I do that? That's what I cannot, for the life of me, figure 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
[android-developers] Re: How do other developers handle IAP refunds on unmanaged purchases?
Thanks! I really appreciate you sharing that with us. I suppose part of my problem is that I'm not sure what the refund experience is like from the user's end. I'm not even sure *how* an IAP refund is requested. Since I know it isn't supported proper through Google Play (as opposed to app refunds) I'm not actually sure how it's done. Are all IAP refund requests issued by way of personal email from the user to the developer or is there some existing mechanism for sending a refund request? I may have to go the no refunds route too. May I ask *where* you put your refund policy notice? Is this just informational in your own app through a UI of your design, or is there an official place to put a refund policy in Google Play which is seen when the user tries to make a purchase? I haven't seen anywhere in the developer console where a policy notice would be updated. Thanks. On Monday, December 3, 2012 1:46:08 PM UTC-8, John Coryat wrote: We simply have No refunds under any circumstances in our refund policy. That covers most of the situations. We use IAP unmanaged items to do subscriptions, managed by our server and not Google. If a user purchases twice, they get twice the subscription period. It's pretty easy to determine if a user accidentally made a mistake and in that case, I refund the duplicates. Sometimes a user is just unhappy and whines about the product in which case I usually give them a refund unless it's near the subscription period end, in which case I quote the refund policy. One recent case a user asked for a refund Because I am going to an iPhone. Needless to say, I quoted him the no refunds under any circumstances policy. In the last year, I may have given 25 refunds so it's not a big deal. -John Coryat -- 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: When can every developer reply to reviews?
I'm a little confused. You posted your question on 11/29. As far as I could tell, this feature went into effect sometime around the end of November for me. I realize all the primo developers got this six months ago, but I assume that when it suddenly clicked on for me last week that it also clicked on for everyone else. Are there still developers who don't have the ability to respond to comments and ratings? Is Google rolling this new feature out slowly over time? When is the date after which all developers will have it. For my part, I have to say I have been very grateful for it. Like I said, I've only had it a a little less than a week now, but I have put it to good use. I must admit, I had to be very careful not to write anything snarky or angry...it was reeeally tempting. Let's all use this new feature as intended and not disappoint the folks at google who have entrusted us with it. *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] Re: When can every developer reply to reviews?
On Tuesday, December 4, 2012 4:07:47 PM UTC-8, TreKing wrote: On Tue, Dec 4, 2012 at 4:51 PM, Keith Wiley kbw...@gmail.comjavascript: wrote: Hmm ... it might be better for my business if I don't get this feature ... :D Don't respond to comments: - Within an hour of first noticing them. - When you're rushed for time. - Late at night. - Buzzed/drunk. - After fighting with your wife about the dish washer and your cat scratched up one of the good chairs and your mother-in-law called to say she'll be dropping in the next day and your boss gave you hard time and your check engine light just turned on. -- 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] 2 really simple Google Wallet / in-app purchase questions
To test in-app purchases I need to create a second google account and add it as a test account through the dev console. I also have to attach a credit card to the account through Google Wallet so it can actually purchase my in-app items. Question: Google Wallet's webpage seems to have some notion of Google Wallet on the device. I presume this is some square-like thing for making day to day payments with one's phone, right? As such, am I correct in assuming I don't need to take that step to test in-app purchases? Is merely attaching a credit card to the test account sufficient to enable it to purchase the in-app items available through my app? Followup: I have read a few horror stories of people having their developer accounts suspended even though they correctly set up a test account and listed it through the developer console. Can anyone report on this? I am terrified to even try to test the in-app purchases on my app for fear that Google will ban me...but I absolutely have to test the system before I will willingly trust it to the wild. Thoughts? 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
Re: [android-developers] 2 really simple Google Wallet / in-app purchase questions
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
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
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] In-app purchase: Connection between merchant console and app?
The merchant console offers two ways to undo an order. You can cancel entire order or you can refund some money, that letter often being disabled or otherwise unavailable on recent purchases. When the developer/seller uses each of these options, what should be the corresponding signal back to the app on the buyer's phone? I ask because it isn't working. My test account app doesn't receive any sort of signal or message back through Google Wallet, Google Play, or the billing service/receiver in my app. I've followed the Dungeons example, naturally, and I have no idea how to get cancel/refund messages back to my app from Google. If I use the test refund sku, my app gets a refund purchase event as expected, but if I use the real skus with a secondary test account, issuing a cancel from the merchant console never triggers any event on the test account's phone. -- 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] How to delete app in new console
In the old console, if you delete the last APK, the entire app goes away...for better or worse. However, in the new console there appears to be no way at all to delete an app. Is this correct? Is my console now littered with unintended apps that will persist forever? I have a version of the Dungeons app and I have draft versions of an app in-prep that I divided between free and paid before abandoning them in favor of a freemium model. Is there anyway to clean up this clutter in the console? 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 delete app in new console
Where in the app manager is there a delete-app command? I honestly don't see it. -- 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: How to delete app in new console
I don't think we're having the same conversation here. I'm not talking about anything on the phone at all. I'm talking about the web console Android developers use to manage their apps in Google Play. I'm honestly surprised no one else has chimed in on this discussion. It seems like a legitimate question. -- 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: How to delete app in new console
Thanks, that makes a lot of sense I suppose. I haven't tried unpublishing a previously published app because I don't have a good candidate at the current time, but I do know that draft or otherwise as-yet unpublished apps offer no obvious method for removal...in stark contrast with the old console which could explicitly remove unpublished apps entirely. Thanks again. -- 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: How to delete app in new console
Like I said, I haven't tested it on a previously published app, only on draft apps that were never published in the first place...but in the old console if you delete the last APK associated with the app, the entire app description vanishes. I don't know if it would do that for an app once it was published, but it is certainly different from the new console in this regard. On Friday, December 21, 2012 5:47:24 AM UTC-8, TreKing wrote: On Thu, Dec 20, 2012 at 11:04 AM, Keith Wiley kbw...@gmail.comjavascript: wrote: .in stark contrast with the old console which could explicitly remove unpublished apps entirely. Where exactly could you remove unpublished apps? I was under the impression that once an app was published, if you unpublished it afterwards, there was no way to delete it. - 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
Re: [android-developers] Re: How to delete app in new console
On Friday, December 21, 2012 6:02:10 PM UTC-8, TreKing wrote: It's also fantastic because the new app made in the new console doesn't appear in the old console, so you can't delete it that way. Womp womp. YEP! I've noticed that too. It defies rationalization. Sigh. -- 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] Did Google just kill MobFox?
I admit I haven't logged into my developer console in a few days, but when I did this morning I saw a message that there are new guidelines to agree to and that existing apps not in compliance might be removed 30 days hence (less than 30 since I missed a few days). Part of the new agreement says the following [my emphasis in red]: - *In-app purchases:* - - *Developers offering virtual goods* or currencies* within a game downloaded from Google Play must use Google Play's in-app billing service http://developer.android.com/google/play/billing/index.htmlas the method of payment. * - Developers offering additional content, services or functionality within another category of app downloaded from Google Play must use Google Play's in-app billing servicehttp://developer.android.com/google/play/billing/index.htmlas the method of payment, except: - where payment is primarily for physical goods or services (e.g. buying movie tickets, or buying a publication where the price also includes a hard copy subscription); or - where payment is for digital content or goods that may be consumed outside of the application itself (e.g. buying songs that can be played on other music players). One approach to interpreting this would be to try to nit-pick it apart (to debate the meaning of *virtual good* for instance, but another approach is to simply ask the larger question: Can we no longer use MobFox or any other non-Google in-app payment system (in a game, perhaps other apps, but not in a game for whatever reason)? I have a game on Google Play that uses in-app purchases to sell various upgrades or additional capabilities (sort of extra-life like things) within the game. Is Google going to remove my app three weeks from now if I don't complete gut all the MobFox payments from it or am I misunderstanding these new guidelines? ...or, alternatively, does *virtual good* refer to something very specific, not just app upgrades but actual pretend items of some nebulous definition (like magic swords or stuff like that, which my game doesn't have anything like anyway), such that the *mere presence of MobFox* in an app won't necessarily be grounds for summary removal by Google. I'm quite confused about this. 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.
[android-developers] Re: Did Google just kill MobFox?
Fair enough. Thanks for the info. That leaves me rather confused though. What is the point of third party systems like MobFox? How do they work? Is their entire business model predicated on hoping confused developers such as myself will accidentally violate the Google TOS? That strikes me as somewhat unbelievable. -- 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: Did Google just kill MobFox?
WAIT. Oh man am I confused. I'm sorry. I use MobFox for my in-app ads (as opposed to whatever ad system Google supports, AdMob I believe), but my in-app purchases are processed using Google. Yeesh! In fact, IIRC, I coded up both MobFox and AdMob ads and can switch to use either, both, or neither of those ad systems, but I don't think I ever turned the AdMob option on, only MobFox. Anyway, this whole discussion is something of a red herring now. Sorry. -- 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: Did Google just kill MobFox?
Like I said in an earlier response, I was confusing in-app ads and in-app purchases. This entire thread (my original question) is essentially invalid. Please disregard. Sorry. -- 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] Physical address is required for paid apps or in-app purchases
I didn't see it either. I think the description is that it will appear by the 30th, so presumably the settings page is going to change and have a physical address space in the next few weeks. After that, I guess anyone can look up where I live and come by and harass me at my home, so, that'll be nice. Thanks Google. On Friday, September 19, 2014 2:38:19 PM UTC-7, DevDallas wrote: Does anyone see a place to add an address in the settings of the Dev Console? If so, can you post a screenshot I can't seem to find it. As far as I can see, there is no field for address in my Dev console settings. On Sep 19, 2014 5:21 PM, Kostya Vasilyev kman...@gmail.com javascript: wrote: Not just a blatant privacy violation. They're putting developers' lives at risk. Not every developer lives in relatively safe place like the US, or Western Europe. The world is larger than that, and there are places where criminal activity is relatively high. It's quite easy for someone to do the math, multiplying an app's price by its install count, and then to pay a visit to the developer -- with the intent of extortion, racket, theft, or other criminal activity. A PO box won't work for me personally, and Google may not accept them either. -- K 2014-09-20 1:00 GMT+04:00 Mark Phillips ma...@phillipsmarketing.biz javascript:: Rent a post office box near where you live. Then call it a suite in your address. You can pick up the mail once a week. Not a big deal. I completely agree about the privacy issue with using your home address. I wouldn't use my home address, nor my private email address. Mark On Sep 17, 2014 11:24 PM, nagamatu naga...@gmail.com javascript: wrote: Dear Android Developers, I got the following notification at Google play Developer Console. | Add a physical contact address Beginning September 30, 2014, you need to add a physical address | to your Settings page. After you've added an address, it will be available on your app's detail page to | all users on Google Play. If your physical address changes, make sure to update your information on | your Settings page. | If you have paid apps or apps with in-app purchases, it's mandatory to provide a physical address | where you can be contacted. If you don't provide a physical address on your account, it may result in | your apps being removed from the Play Store. I do not want to disclose my home address in public, because I am an individual developer. This is privacy issue. I don't understand why Google requires my physical address. I disclose my e-mail address and users can contact me. Also I can reply to messages that is written in review at Google Play. If I am working for a company and office address is disclosed in public, I do not care for it. But do you want to know your home address in public? # I sent a feedback about objection for this requirement. -- nagamatu -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-d...@googlegroups.com javascript: To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-d...@googlegroups.com javascript: To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-d...@googlegroups.com javascript: To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to
