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
[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] 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
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
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
[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
[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] 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
Re: [android-developers] Testing in-app purchases is incompatible with monotonically increasing Android versions
Aaaah, I see now. Okay. Thanks. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Testing in-app purchases is incompatible with monotonically increasing Android versions
I'm debugging in-app purchases. This requires me to create the app profile on the console and upload the apk (but not necessarily publish it). With an invited test gmail account, I can then test in-app purchases. The problem is, there is no way to upload changes to the app if I have to fix something. Say I upload an apk with version number 1. Google requires that I increase the apk number with every upload, so I have to increase the number to 2 to change the code, and version 3 to change it again. I may go through numerous iterations of development getting the final code in place...but none of these are actual new releases, the app isn't even published yet! I want the first published version to be version 1, regardless of any initial testing and there doesn't seem to be any way to do this. If I delete the apk from the app description in the hopes of wiping out the version numbers so I can upload an apk with version 1, the ENTIRE app profile is destroyed and I have to create a new one from scratch, including the required screenshot uploads and other tedium unrelated to testing. This imposes a tremendous burden on the debugging process. Is there any way to do what I am trying to accomplish here? I am at a loss. Thank you. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Testing in-app purchases is incompatible with monotonically increasing Android versions
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
[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] 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] 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] 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] 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] 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] 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] 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
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] 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
[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] 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] Nexus 7 has no menu button?
I don't have access to a Nexus 7 but I'm getting feedback from users that they can't access the menus in my app...like, at all...which I find perplexing since I use the same standard menus that all Android apps use (including the Android home-screen). If the Nexus 7 doesn't have a relatively obvious menu button, it seems to me that the majority of Android apps, including the home-screen, would be veritably unusable. Can anyone help me understand what's going on here? 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: Nexus 7 has no menu button?
Right, so since it targets a very old SDK, you're saying they should be able to simply access the menus through an option in the system bar. In other words, these people don't know how to use their tablets; their problem has nothing to do with my app being incompatible with their device, or even necessarily that my app is poorly designed. They just don't know how to find the menu button on their own device, right? I'm just verifying, that's what you're saying right? I mean, I don't need to change anything about my app to make it work properly, they just need to use the system bar to access the menus and they haven't learned that trick yet. Is that basically correct? 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: Nexus 7 has no menu button?
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?
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 javascript: 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?
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] 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] 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] 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] 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] 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] 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] 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] 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] Intercept/override context menu on EditText long-press?
I want to intercept an EditText long-press and do something with it other than present a contextual menu. Obviously, I cannot simply disable the GestureDetector's long press detection because I do in fact want to use the long press. By the time onCreateContextMenu() is called, it seems to be too late to prevent the contextual menu from occurring. Not calling super.onCreateContextMenu for example doesn't prevent it, nor does anything else I have tried...and onCreateContextMenu() is called before onLongPress(), so the answer to my question can't be some behavior in onLongPress(). Should I be doing something in dispatchTouchEvent(), onDown(), or showPress() to accomplish this goal? Those seem to be the only methods that are called before onCreateContextMenu(). 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: Intercept/override context menu on EditText long-press?
Sorry, quick followup. The EditText in question is a subclass of my own creation, not just a generic EditText. It already extends EditText and implements TextWatcher, OnKeyListener, OnGestureListener, and GestureDetector.OnDoubleTapListener for various uses. 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: Intercept/override context menu on EditText long-press?
On Apr 24, 3:02 pm, Mark Murphy mmur...@commonsware.com wrote: On Sun, Apr 24, 2011 at 5:54 PM, Keith Wiley kbwi...@gmail.com wrote: I want to intercept an EditText long-press and do something with it other than present a contextual menu. Please don't. Users will expect the standard EditText context menu to appear, so they can do silly things like edit the text. Android developers get ripped to shreds by users and the media for having zero UI discipline, breaking existing UI patterns and causing no two apps to work the same -- your proposal is a case in point. If your goal is for users to not edit the text, then don't use an EditText. If your goal is for users to edit the text, leave the context menu alone, and find some other way to trigger whatever it is that you are trying to do. I understand your point, but you aren't being completely fair. My Edit text can detect not only single also double and triple taps (I had to hack triple tap detection from scratch of course). I want to provide additional functionality on double or triple tap long presses, but it won't work if the contextual menu is forced upon all long presses. Furthermore my app offers a fully configurable UI where single/double/triple taps/long-presses/drags can be assigned to numerous complex functions in a way that greatly empowers the user. So, with all due respect, we can debate the philosophy how to present such UIs in a parallel or separate discussion, but it is tangential to my question of how to technically achieve such powerful goals. Do you know how to do what I'm trying to do? 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: Intercept/override context menu on EditText long-press?
Just to wrap up this thread for anyone else who finds it and is looking for relevant information, I was able to achieve the intended goal by overriding showContextMenu() and either passing the call up to the super class or dropping the call on the floor. So when my app detects a double or triple tap in advance of the call to showContextMenu(), I simply ignore the call and proceed with the alternate behavior instead. ...and to wrap up the philosophical argument that this thread unintentionally flared, I really don't see why double or triple tap long presses should be expected to exhibit redundant behavior with that of single tap long presses. The scenario is perfectly analogous to single, double, and triple taps (sans long press), or mouse- clicks. Clearly, no one expects double taps to exhibit behavior redundant with single taps. If that were the case, double tap support would never have been programmed into the API in the first place (and let's be honest with ourselves, double-mouse-clicks have been a common UI for 25 years!). Triple clicks and triple taps, I concede, are a bit more contentious in that they are not particularly wide-spread, but they are not unheard of either and I felt entitled to offer such support to my app's power users who might benefit from the added flexibility and ease of use. Mark, I have always appreciated your input and I'm sorry my original question offended you. It was technical, not philosophical, and I am always weary of attempts to thread-jack an original question because threads rarely recover and the original question generally goes unanswered as a consequence. I would have been more than happy to politely debate the philosophical and design issues with you, but such was a tangent from the purely technical question I was asking and I saw no reason to confuse the two topics; I just wanted an answer to my question (and perhaps faith that I was not running afoul of wise design specs even if I had not fully qualified the scenario pertaining to my question). I hope you aren't too offended by all of this. Best of luck. 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: Intercept/override context menu on EditText long-press?
On Apr 24, 4:38 pm, Mark Murphy mmur...@commonsware.com wrote: On Sun, Apr 24, 2011 at 6:36 PM, Keith Wiley kbwi...@gmail.com wrote: You have all this stuff for every other touch operation known to humanity, apparently, yet you can't just leave the long-press alone to do what an EditText is supposed to do on a long-press? Why not move your long-press functions to a quadruple tap or something? What is so magical about you hacking a long-press that is worth breaking the existing expectations of the users? It sounds like you didn't understand my problem. The contextual menu was being triggered on the double and trip tap long presses also. That was fundamental to my problem. I couldn't prevent it from happening under reasonable circumstances. That was what I needed help with. You assume that I am here exclusively to help you. I am also here to put opinions in the record for those who read this thread in the future (e.g., via a search). I don't want developers thinking that messing with system menus is a good idea. Well, I understand that, but you didn't do both. You didn't make a clear philosophical argument and then explain how to achieve the technical goal of a double-tap long press that does not trigger a contextual menu. You stopped half way through. That was frustrating from my point of view. I take your point about the single-tap long press. I will either forcibly prevent it from being over-rided in my UI configuration settings or I will accompany with red flashing alarm-bell associated warnings that it should only be done if the user is certain they know what they are doing (I hate telling genuine power users that they can't do what they want, I love configured UIs to my own nuanced behaviors, it's the same reason my trackball has gazillions of DOF on it). I had already put in a warning message when overriding the long- press command but you have my thinking that I should make the warning more aggressive now...or perhaps even lock it out entirely just for the sake of conformity. I'll take it under consideration. 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: Intercept/override context menu on EditText long-press?
On Apr 24, 5:00 pm, Mark Murphy mmur...@commonsware.com wrote: On Sun, Apr 24, 2011 at 7:49 PM, Keith Wiley kbwi...@gmail.com wrote: ...and to wrap up the philosophical argument that this thread unintentionally flared, I really don't see why double or triple tap long presses should be expected to exhibit redundant behavior with that of single tap long presses. That seems reasonable. Your opening line of the thread (I want to intercept an EditText long-press and do something with it other than present a contextual menu) didn't explain that, I admit, I did not qualify my question with much backround. BTW, just so I'm on the right page: a double-tap long-press would be tap + long-press? And triple-tap long-press is tap + tap + long-press? Yes, precisely. Double-tap long-press in my lingo is down-up-dooown. Triple is down-up-down-up-dooown. I used similar actions for a different app almost a year and a half ago (WildSpectra) but they weren't on an EditText, they were just on a custom view, so the context menu issue never came up before. Regarding the actual solution, unless I have mistaken what I am seeing, it does look like my solution works: override showContextMenu(). 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: Intercept/override context menu on EditText long-press?
We're talking around each other a little bit as the posts interweave. Reading the thread in post order will come off needlessly argumentative in posterity. Unless I find that my solution is not working as expected, I'm declared peace made. 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: dispatchTouchEvent which view hit?
'k, thanks. On Apr 19, 9:41 am, Dianne Hackborn hack...@android.com wrote: I don't understand exactly what you are looking for, but event dispatching works as I described -- ViewGroup's impl looks at the event and views to decide which view it should dispatch to, modifying the MotionEvent at that point to be appropriate for the target view. Be careful how tricky you get here -- for example don't rely on the implementation detail that the same motion event is used, because that won't always be the case. For example in Android 3.0 ViewGroup will split multi-touch events across multiple views and generate new motion events as part of that, and older versions of the platform will generate motion events at some points. In other words, put your logic in dispatchTouchEvent, and implement it to be self-consistent. If you want to decide which view the event will go through, you can look at the position of the event and find the view that is under it. On Tue, Apr 19, 2011 at 7:48 AM, Keith Wiley kbwi...@gmail.com wrote: So, I have two views, a background that covers the screen, and an EditText that I reposition over the screen at various times. They both implement dispatchTouchEvent (as well as zillions of gesture detection methods), but I really only want to operate on one or the other in any given instance. Taps on the background should be processed by the background view and taps on the EditText (my derived subclass) should be processed by that view. I already tried storing the event reference itself and in each dispatchTouchEvent() call, first asking the other view if it already processed that view, but the reference does not change from one action to another -- it's always the same event, so I have resorted to saving the event's eventTime, and that seems to work, but it feels like hack, meaning, I would imagine there is a more direct way to accomplish my goal. Do you think I'm on the right track or would your recommend a different approach? On Apr 18, 7:48 pm, Dianne Hackborn hack...@android.com wrote: It isn't know at that time; it won't be determined until you call the superclass to ViewGroup.dispatchTouchEvent, which determines the child view and adjusts the motion event to dispatch to the child. On Mon, Apr 18, 2011 at 7:07 PM, Keith Wiley kbwi...@gmail.com wrote: Given the MotionEvent received dispatchTouchEvent(), is there anyway to determine at that time which view received (or is about to receive) the event, assuming it is a down event I suppose? -- 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 -- Dianne Hackborn Android framework engineer hack...@android.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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] How to initialize visibly gone UI elements?
I have a large layout and I hide whole sections of it at a time by wrapping numerous related UI elements in a sublayout and toggling that sublayout's visibility between visible and gone via a button (which is obvious not contained within the sublayout itself). I want to start with all these section sublayouts in the gone state (either in the xml itself, or by setting those layouts to gone in onCreate(), I've tried it both ways, same erroneous result occurs). That is, I want all sections to be initially minimized and the overall layout as minimal as possible. At onCreate() time I initialize all my UI elements. Later, when the user closes the layout I want to read all the settings of all the elements. However, those that were gone during initialization (which is to say, all of them since I start with everything gone) were never initialized (for example, a spinner's selected view is null despite having been assign in onCreate()). I interpret this as indicating that UI elements are not really assigned when you assign them, but rather, during layout time, so if the element is never visible, the command to assign its value (a spinner's selection) never follows through. So, it seems like commands to assign UI element values only occur after the elements are laid out, meaning after they become visible. Will commands to initialize an element never take effect if the element is never made visible? If so, how do I achieve my intended goal of a bunch of hidden settings, some of which may not even be unhidden at all before the user decides to exit the settings? -- 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 initialize visibly gone UI elements?
I agree that yours seems to work. I'm trying to figure out the difference between our code now. Thanks. On Apr 21, 6:42 am, Mark Murphy mmur...@commonsware.com wrote: I cannot reproduce your problem. For example, try: http://misc.commonsware.com.s3.amazonaws.com/SpinnerGone.zip This is the Selection/Spinner example from one of my books, with two changes: 1. It sets android:visibility=gone on the Spinner in the layout 2. It logs the selected item from the Spinner in onDestroy() It works properly, showing the automatically-selected first word out of the ArrayAdapter. On Thu, Apr 21, 2011 at 9:21 AM, Keith Wiley kbwi...@gmail.com wrote: I have a large layout and I hide whole sections of it at a time by wrapping numerous related UI elements in a sublayout and toggling that sublayout's visibility between visible and gone via a button (which is obvious not contained within the sublayout itself). I want to start with all these section sublayouts in the gone state (either in the xml itself, or by setting those layouts to gone in onCreate(), I've tried it both ways, same erroneous result occurs). That is, I want all sections to be initially minimized and the overall layout as minimal as possible. At onCreate() time I initialize all my UI elements. Later, when the user closes the layout I want to read all the settings of all the elements. However, those that were gone during initialization (which is to say, all of them since I start with everything gone) were never initialized (for example, a spinner's selected view is null despite having been assign in onCreate()). I interpret this as indicating that UI elements are not really assigned when you assign them, but rather, during layout time, so if the element is never visible, the command to assign its value (a spinner's selection) never follows through. So, it seems like commands to assign UI element values only occur after the elements are laid out, meaning after they become visible. Will commands to initialize an element never take effect if the element is never made visible? If so, how do I achieve my intended goal of a bunch of hidden settings, some of which may not even be unhidden at all before the user decides to exit the settings? -- 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 3.0 Programming Books:http://commonsware.com/books -- 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 initialize visibly gone UI elements?
I have determined the discrepancy. Your code calls getSelectedItem() on the spinner. Mine calls getSelectedTextView(). In your case, you get a non-null response regardless of the visible status. In mine, I get a null if it is initially gone, but I get a TextView if it is initially visible. Furthermore, if I toggle the spinner's visibility from gone to visible, I get a non-null response, AND if I toggle twice, thus hiding the spinner again, I still get a nonnull response. Here's my modification of your code that demonstrates this point: http://www.keithwiley.com/Downloads/Spinner2.zip If you exit immediately, it says the selected text view is null. If you toggle the button once to show the spinner and exit, it says the text view is not null. BUT, if you toggle it twice, showing and hiding the text view, then exit, it STILL says the text view is not null, so it needs to draw the spinner once and then it's good to go even if the spinner is subsequently hidden. -- 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 initialize visibly gone UI elements?
I agree, and I can adapt my code to use the selected item instead of the selected view...but it is worth noting that the consequence of this is that seemingly identical layouts can yield very different behavior. In this case, two layouts containing invisible items can return either a valid view or a null, which is both dangerous and somewhat arbitrary...not random of course, but slightly arbitrary. I'm just pointing that out, I'm not arguing against the optimization necessarily. On Apr 21, 8:24 am, Mark Murphy mmur...@commonsware.com wrote: On Thu, Apr 21, 2011 at 11:17 AM, Keith Wiley kbwi...@gmail.com wrote: I have determined the discrepancy. Your code calls getSelectedItem() on the spinner. Mine calls getSelectedTextView(). In your case, you get a non-null response regardless of the visible status. In mine, I get a null if it is initially gone, but I get a TextView if it is initially visible. Furthermore, if I toggle the spinner's visibility from gone to visible, I get a non-null response, AND if I toggle twice, thus hiding the spinner again, I still get a nonnull response. Right. If an AdapterView is hidden, it is not querying the Adapter for any rows/cells/whatever, and so you'll get null for getSelectedView(). This is a perfectly reasonable optimization, IMHO. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android 3.0 Programming Books:http://commonsware.com/books -- 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: dispatchTouchEvent which view hit?
So, I have two views, a background that covers the screen, and an EditText that I reposition over the screen at various times. They both implement dispatchTouchEvent (as well as zillions of gesture detection methods), but I really only want to operate on one or the other in any given instance. Taps on the background should be processed by the background view and taps on the EditText (my derived subclass) should be processed by that view. I already tried storing the event reference itself and in each dispatchTouchEvent() call, first asking the other view if it already processed that view, but the reference does not change from one action to another -- it's always the same event, so I have resorted to saving the event's eventTime, and that seems to work, but it feels like hack, meaning, I would imagine there is a more direct way to accomplish my goal. Do you think I'm on the right track or would your recommend a different approach? On Apr 18, 7:48 pm, Dianne Hackborn hack...@android.com wrote: It isn't know at that time; it won't be determined until you call the superclass to ViewGroup.dispatchTouchEvent, which determines the child view and adjusts the motion event to dispatch to the child. On Mon, Apr 18, 2011 at 7:07 PM, Keith Wiley kbwi...@gmail.com wrote: Given the MotionEvent received dispatchTouchEvent(), is there anyway to determine at that time which view received (or is about to receive) the event, assuming it is a down event I suppose? -- 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 -- Dianne Hackborn Android framework engineer hack...@android.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] dispatchTouchEvent which view hit?
Given the MotionEvent received dispatchTouchEvent(), is there anyway to determine at that time which view received (or is about to receive) the event, assuming it is a down event I suppose? -- 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] eclipse/sdk combo crash
If I right-click the res folder of a project, I can create a menu folder. If I right click that folder and try to create a menu.xml file, eclipse hangs. I have to force quit it. After relaunching eclipse, menu.xml is there. I've seen this behavior on two different computers now. If I then try to open the empty menu.xml to edit it, on one computer eclipse hangs again, although on the other it opens and I can then edit the file. I'm running eclipse Helios and the very latest Android SDK 3.0. Both computers are running Snow Leopard although one is a core 2 duo (macbook) and the other is an i7 (macbook pro). Anyone else run into this? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Emulator doesn't recognize -audio-in option
I've been using -audio-in core-audio two years without any trouble. I just bought a new computer, install eclipse and the SDK, and now I can't run the emulator anymore. It says: .. Emulator] unknown option: -audio-in I haven't found any obvious documents online saying this setting is deprecated or otherwise changed in a recent SDK update. Does anyone know what's going on here? 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: Emulator doesn't recognize -audio-in option
Admittedly, running the emulator with -help suggested that the flag had been changed from -audio-in to -audio. Implementing that change seems to have fixed the problem. Are these kinds of version-dependent changes documented? I'm sure I missed something obvious, but it didn't show up on the relevant developer webpages. For example, the following webpage doesn't say that audio-in is no longer supported, it still lists it as a valid option: http://developer.android.com/guide/developing/tools/emulator.html Anyway, false alarm. 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] ImageView hardcoded into layout referencing drawable resources
If I reference a drawable in the drawable directory, I see the image in my layout, but if I reference a drawable in the drawable-hdpi directory, I don't see it (but I don't get an error of any sort either). I want to include the app icon on the splash screen, and would prefer to use the high-res icon. This works: ImageView android:layout_width=wrap_content android:layout_height=wrap_content android:layout_gravity=center android:layout_marginRight=20dip android:src=@drawable/app_icon / This doesn't: ImageView android:layout_width=wrap_content android:layout_height=wrap_content android:layout_gravity=center android:layout_marginRight=20dip android:src=@drawable-hdpi/app_icon / Thoughts? -- 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: ImageView hardcoded into layout referencing drawable resources
Fair enough. My project has such a folder, but of course I suppose it is only accessed when the app is run on certain devices. Thanks. Cheers! On Feb 19, 4:25 pm, Justin Anderson magouyaw...@gmail.com wrote: Drawables in the drawable-hdpi folder are only available on high-density devices. When you say you don't see it are you sure you are on a high-density device? See here for more info:http://developer.android.com/guide/topics/resources/providing-resourc... Hope that helps, Justin On Sat, Feb 19, 2011 at 5:17 PM, Keith Wiley kbwi...@gmail.com wrote: If I reference a drawable in the drawable directory, I see the image in my layout, but if I reference a drawable in the drawable-hdpi directory, I don't see it (but I don't get an error of any sort either). I want to include the app icon on the splash screen, and would prefer to use the high-res icon. This works: ImageView android:layout_width=wrap_content android:layout_height=wrap_content android:layout_gravity=center android:layout_marginRight=20dip android:src=@drawable/app_icon / This doesn't: ImageView android:layout_width=wrap_content android:layout_height=wrap_content android:layout_gravity=center android:layout_marginRight=20dip android:src=@drawable-hdpi/app_icon / Thoughts? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Where to report app update problems?
I'm not sure if this is a Market problem or a developer problem...it isn't a coding issue per se...I just don't know where to report it. I can't update my app. I go my market publisher webpage and see a list of my apps. I click on one of them to update it. It's a free app btw. All I want to do is change the 512px icon, so I upload a new one and click Save at the bottom. Instead of returning to the publisher page it jumps to the top of the same page, presumably flagging a problem. I scroll down to find the problem and see that many countries now say Invalid price in red writing with a red box (those messages weren't there before I clicked Save)...BUT IT'S A FREE APP!!! and to make matters worse, the United States is one of those countries (I'm in the U.S.)!!! Anyway, here's what I've tried: - Unchecking availability in the troublesome countries, including the United States (Save still won't work) - Unchecking All Countries (Save still won't work) - Backing out to the publisher page, reentering the app edit page and just clicking Save without changing anything at all...still won't work. What on Earth am I going to do about this? I'm feeling rather desperate at the moment. I realize there is a market forum but (http://www.google.com/support/forum/p/Android+Market) but I have never figured out how to get that forum to distinguish between user and developer problems, so developer problems get rather lost in the mix...unless I'm missing something. I realize the main help on this might be pointing me to a more proper forum for it. If so, I appreciate that. 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: Where to report app update problems?
On Feb 6, 10:01 am, JP joachim.pfeif...@gmail.com wrote: On Feb 6, 9:20 am, Keith Wiley kbwi...@gmail.com wrote: I scroll down to find the problem and see that many countries now say Invalid price in red writing with a red box (those messages weren't there before I clicked Save)...BUT IT'S A FREE APP!!! and to make matters worse, the United States is one of those countries (I'm in the U.S.)!!! Had the same issue yesterday updating free app. Exact same WTF moment BYW. So I wiggled around logging out/in for Google Account and tried a few other thing that I cannot remember, and eventually it went through. That did it. I just kept trying to push it through and eventually it stuck. Phew, that was a scary one for a moment. Thanks to everyone who chipped in on the discussion. 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: Fast way to write and read buffered data from AudioRecord
On Jan 5, 12:57 am, Serdel adam.lichwierow...@gmail.com wrote: I have accomplished sth. by using the ByteArrayOutputStream - I divide the recorder short sample into 2 bytes. Thats again - not as efficient as It could be but significantly faster than ArrayList Regarding your code. System.arraycopy(mReceivedAudioBufferSrt, 0, mRecordingDesc.mRecordingSrt, mRecordingEndPos, mBufferFrames); What are the declarations of: a) mReceivedAudioBufferSrt b) mRecordingDesc.mRecordingSrt double audioRecordBuffersPerSec = (double) sampleRate / (double) (mBufferFrames / numChannels); int recordingNumAudioRecordBuffers = (int) (audioRecordBuffersPerSec * mRecordingDurationSecs); mRecordingNumFrames = mBufferFrames * recordingNumAudioRecordBuffers; mReceivedAudioBufferSrt = new short[mBufferFrames]; mRecordingDesc.mRecordingSrt = new short[mRecordingNumFrames * numChannels]; I'm not actually looking at my code too carefully, I'm just regurgitating it for you. I would have to study it a bit more to grok the deeper concepts, but that's certainly *what* it's doing...if not so much *why* it's doing it that particular way. :-D I guest that a) is either an byte or short array (depending on your PCM encoding). It does look that way. But most important what is b)? Is it an Array? Yes. If it is an Array how do you set the size of it ? Very carefully from the look of things above. :-) Sigh, it's certainly a bit tricky. At least in my app the recording is controlled by start/stop buttons so I can't predict how long would it be... Or is it another type of container/stream? Ah, now I see. You have a different problem than I did. My app isn't a recording app, it's a real-time audio analyzer. I allocate the largest possible buffer I can fit into RAM and use that for recording. When I fill the buffer my app offers the option of automatically stopping the recording or looping back to the beginning of the buffer for the purpose of neverending realtime analysis such that the final accumulated recording always represents the most recent duration of time of length limited by the RAM buffer. After recording stops, my app offers the option of dumping the buffer to a file on disk, but this is secondary to the app's primary purpose as a real- time analyzer. As such, my app cannot record for tremendously long periods of time (and has received some rude 1-star comments to that effect by morons who fail to honor the fact that it is, at heart, a real-time analyzer and not a recorder. I wish people like that would just disappear off the face of the Earth and leave the rest of us alone...but that's a discussion for another day. I still am not able to run ENCODING_PCM_8BIT - the getMinBufferSize functions returns -2 when I use ENCODING_PCM_8BIT as an argument. I tried setting up a fixed value of ie 20 but still no progress - it's seems stupid that 16 bits is working and 8 bits is not working. Every phone uses 8bits encoding for transferring human voice... My app has as a little utility in it that performs a full scan of all possible recording settings. It tries every sampling rate between 1 and 44100 with both 1 and 2 byte sample sizes (I fixed the number of channels at 1, no point in trying 2 on a mono-mic I figure). After the scan the app then knows the full capability of the phone and can limit the options is presents to the user to those which are supported by the hardware. I forget off the top of my head whether my G1 supports 8-bit samples. It would seem logical for the reason you just stated, but I don't recall for sure. -- 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] external or usb mic for audio recording?
I realize that MediaRecorder.AudioSource supports several input sources, although I think they all boil down to one of two physical sources: either a microphone on the bottom for phone-style-speaking and one on the back for camcorder recording (on phones that have such a secondary mic)...but do any Android devices physically support external mics, say through the USB port, and if so, what software hooks does the Android API offer for accessing those mics? I haven't found anything like this yet. 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: Fast way to write and read buffered data from AudioRecord
On Jan 4, 12:41 am, Serdel adam.lichwierow...@gmail.com wrote:
How do you predict the size of the destination array? I mean I think
you also copy the samples from audiostream into a smaller temp buffer
and then into your dest. larger one - if you use an array for the
dest. one how do you set size of that?
Hmmm. It's been a very long time since I looked at this code. I kick-
start it with something like this:
int minBufferBytes = AudioRecord.getMinBufferSize(sampleRate,
channelConfig, audioFormat);
mBufferBytes = /*Some value = minBufferBytes*/;
mBufferFrames = mBufferBytes / (numChannels * sampleBytes);
mReceivedAudioBufferSrt = new short[mBufferFrames];
mRecordingEndPos = 0;
mAudioRecord = new AudioRecord(source, sampleRate, channelConfig,
audioFormat, numBufferBytes);
mAudioRecord.startRecording();
new Thread(new Runnable() {
public void run() {
processRecording();
} // Runnable.run()
}).start(); // New Runnable inside New Thread
...where processRecording(), obviously now running on its own thread
parallel to the ongoing recording, does something like this:
while (mAudioRecord.getRecordingState() ==
AudioRecord.RECORDSTATE_RECORDING) {
int numDataRead = mAudioRecord.read(mReceivedAudioBufferSrt, 0,
mBufferFrames);
System.arraycopy(mReceivedAudioBufferSrt, 0,
mRecordingDesc.mRecordingSrt, mRecordingEndPos, mBufferFrames);
mRecordingEndPos += mBufferFrames;
if (mRecordingEndPos == mRecordingNumFrames)
mRecordingEndPos = 0;
}
That's heavily pseudoized from my considerably more complicated
overall setup, but it's the basic idea. I have to be very careful the
size of the data chunks I grab because I need to perform realtime
power-2 FFTs on them in my app. Plus I have switches all over the
place to handle a variety of sampling rates, sample sizes (1 or 2
bytes), number of channels, etc. The complexity grows very quickly
once you start worrying about all of that stuff.
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: Fast way to write and read buffered data from AudioRecord
On Jan 4, 12:41 am, Serdel adam.lichwierow...@gmail.com wrote:
How do you predict the size of the destination array? I mean I think
you also copy the samples from audiostream into a smaller temp buffer
and then into your dest. larger one - if you use an array for the
dest. one how do you set size of that?
Hmmm. It's been a very long time since I looked at this code. I kick-
start it with something like this:
int minBufferBytes = AudioRecord.getMinBufferSize(sampleRate,
channelConfig, audioFormat);
mBufferBytes = /*Some value = minBufferBytes*/;
mBufferFrames = mBufferBytes / (numChannels * sampleBytes);
mReceivedAudioBufferSrt = new short[mBufferFrames];
mRecordingEndPos = 0;
mAudioRecord = new AudioRecord(source, sampleRate, channelConfig,
audioFormat, numBufferBytes);
mAudioRecord.startRecording();
new Thread(new Runnable() {
public void run() {
processRecording();
} // Runnable.run()
}).start(); // New Runnable inside New Thread
...where processRecording(), obviously now running on its own thread
parallel to the ongoing recording, does something like this:
while (mAudioRecord.getRecordingState() ==
AudioRecord.RECORDSTATE_RECORDING) {
int numDataRead = mAudioRecord.read(mReceivedAudioBufferSrt, 0,
mBufferFrames);
System.arraycopy(mReceivedAudioBufferSrt, 0,
mRecordingDesc.mRecordingSrt, mRecordingEndPos, mBufferFrames);
mRecordingEndPos += mBufferFrames;
if (mRecordingEndPos == mRecordingNumFrames)
mRecordingEndPos = 0;
}
That's heavily pseudoized from my considerably more complicated
overall setup, but it's the basic idea. I have to be very careful the
size of the data chunks I grab because I need to perform realtime
power-2 FFTs on them in my app. Plus I have switches all over the
place to handle a variety of sampling rates, sample sizes (1 or 2
bytes), number of channels, etc. The complexity grows very quickly
once you start worrying about all of that stuff.
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: external or usb mic for audio recording?
Except that we know cell phones (Android included) support headset devices which use a microphone plugged into the USB port, or perhaps a 3.5mm audio jack. I'm uncertain of the implications of that capability w.r.t. my original question. Thanks for the input. Cheers! On Jan 4, 12:00 pm, FrankG frankgru...@googlemail.com wrote: IMHO a usb microphone would require usb host functionality and support for human device interface .. Their is in my eyes no out of the box support for this. On 4 Jan., 09:03, Keith Wiley kbwi...@gmail.com wrote: I realize that MediaRecorder.AudioSource supports several input sources, although I think they all boil down to one of two physical sources: either a microphone on the bottom for phone-style-speaking and one on the back for camcorder recording (on phones that have such a secondary mic)...but do any Android devices physically support external mics, say through the USB port, and if so, what software hooks does the Android API offer for accessing those mics? I haven't found anything like this yet. 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: Fast way to write and read buffered data from AudioRecord
In my audio app I just use System.arraycopy() to transfer samples from the recording buffer to a secondary buffer for real-time processing. -- 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] Eclipse never sees AVDs anymore
I recently upgraded to Helios and installed the latest and greatest SDK, ADT, and everything else I could think of. Eclipse no longer sees the AVDs when launching (debugging) the app. I tried deleting all my old AVDs and making new ones, but it's just hopeless, nothing fixes the problem. It simply can't see the AVDs. I've set my run configuration target to manual (instead of automatic). When I attempt to run or debug my app, I get the dialog with two sections, one on top of devices and one below for AVDs. The top section shows my phone plugged in my USB and I can run on the phone just fine, but the lower section (Launch a new Android Virtual Device) doesn't list anything. I can easily verify that the AVDs exist by going WindowMenu-AndroidSDKAndAVDManager. It shows my AVDs with green checkmarks. If I launch an AVD from that dialog, I can then run on it, but it appears in the top section of the launch dialog, with the devices (with my phone), the lower portion for AVDs remains empty. It's frustrating to have to manually launch the AVD now. I certainly did not have to do this before. I'm running Eclipse Helios, with ADT 8.0.1.v201012061207-82219. Any ideas? -- 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: Eclipse never sees AVDs anymore
On Jan 2, 8:00 pm, Nikolay Elenkov nikolay.elen...@gmail.com wrote: On Mon, Jan 3, 2011 at 8:18 AM, Keith Wiley kbwi...@gmail.com wrote: It's frustrating to have to manually launch the AVD now. I certainly did not have to do this before. I'm running Eclipse Helios, with ADT 8.0.1.v201012061207-82219. Any ideas? Unplug your phone. If the phone is plugged in, it only shows AVDs with the same or higher Android version as your phone. Not sure why someone thought this is a good idea... Turns out you're both right and wrong. Unplugging the phone did make the AVDs appear. However, no AVDs appeared at all with the phone plugged in, which is only 1.6. Apparently Eclipse won't show any AVDs at all regardless of version if the phone is plugged in. Nevertheless, you did solve the problem for me. 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
