"And sure, there are other app stores, that ain't integrated into the OS, so how about updates."
I assume, therefore, that you never install third-party applications on Windows, OS X, Windows Mobile, Symbian, or any of the countless other operating systems for which third-party "app stores" are the norm.
Just because Apple wants a monopoly on app distribution doesn't mean you should give Google one, too.
If you are paying per user for the back-end Web services, you better stop, or you will go bankrupt.
If, instead, you are paying for back-end Web services based on overall usage (e.g., Amazon SQS per-message rates), then piracy has no more effect than higher-than-expected legitimate usage of your app. Now, that still may be a money-losing proposition, depending on the rates you have to pay, but it is a decision you should make not based exclusively on piracy.
I completely agree that the lack of a common SMS message store is big, and I sincerely hope it gets addressed sooner rather than later. I'm not convinced that "Google will probably be forced to have a compatibility layer" -- heck, the compatibility layer for some official-but-deprecated APIs is a little shaky (e.g., the old Contacts provider API on top of the ContactsContract doesn't work well in the emulator).
You are certainly welcome to your opinion. I don't agree with the vast majority of what you wrote, since you seem to be advocating creating products that rely upon beyond-the-SDK APIs. I have no problem with people poking past the SDK for proofs of concept, private demos, and the like, and that should be all that true "visionaries" need to get their points across vis a vis areas where the SDK needs improvement. Trying to get the SDK improved is great -- having ordinary users be collateral damage along the way is not.
I used Flurry on one consulting engagement, at the customer's request, and they were happy with it. I have not had an opportunity to try the others as yet. Sorry I don't have more concrete experience to share.
Ah, yeah, forgot that one! Thanks for the link!
"Mark Murphy listed a service to aid developers in his Android Business Models article in September of this year"
Good news, everyone! I don't have a business model patent on the idea! ;-)
Ah. That makes sense, though tying keys to R. values seems to be an odd restriction in this case. Many "other libraries" won't have R. values of their own, because, well, they're libraries and therefore don't have resources. I can see how you were aiming for it to be a unique value that way, and I'm not sure how else you could do it, but it does mean I can't use the new getTag()/setTag() in a reusable JAR unless I require a unique ID to be given to my by the application via a method on some object, which may or may not be convenient for me or the application.
All that being said, I understand now the role the new getTag()/setTag() are supposed to play. Thanks for the info!
Sorry about that -- it's been fixed.
Uh, OK. What the heck is it there for, if not this? Considering the key has to be an ID, and the limited set of use cases for View tags in the first place, this seemed like the logical explanation.