[android-developers] Enhancing Google Play developer console to allow third-party developer access

[Ted Hopp]

Google Play seems to be set up under the assumption that the developer of 
an app is also the publisher. This is not always the case and, as described 
below, it causes us (and, I suspect, many others) a lot of time and 
aggravation. I'm interested in feedback on whether others have encountered 
these problems and, if so, how they deal with them, and whether an 
enhancement of some kind to Google Play might help. (I have a suggestion at 
the end.)

We develop and publish a number of apps and we are also developing apps for 
a business partner to be published by our partner on Google Play. Our 
partner, for obvious reasons, does not want to share their logon 
credentials for Google Play with us, so our work flow as we test the app 
(licensing, in-app purchases) prior to publication is very inefficient. We 
have two choices:

   1. Publish a copy of the app, under a different package name, in the 
   alpha channel of our own developer console;
   2. Ship the app to our partner to publish in their alpha channel, set us 
   up as testers, and then coordinate with them during testing.

The problem with the first approach is that our own account will eventually 
become cluttered with garbage apps that were never intended for publishing. 
It used to be that we could simply save the app as a draft and when we were 
finished testing, we could remove all traces of it. No more.

There are many difficulties with the second approach. Our partner is not a 
developer, so all the developer documentation is rather hard for them to 
navigate and absorb. We need to provide them pointers to specific sections 
of the documentation. Sometimes we need to interact with them in real time, 
particularly for setting test responses and canceling test purchases. Such 
interactions are necessarily inefficient. As it happens, our partner is 
seven time zones away from us, so real-time interaction is particularly 
difficult to schedule (and costly, as well).

I think Google Play could be enhanced to address these issues. One 
possibility would be for an account owner to be able to grant to third 
parties limited access rights to the developer account to perform specific 
operations for specific apps. For instance, our partner could grant us 
rights to upload draft APKs for one app, publish them to the app's alpha 
and beta channels only, and set test responses, but not allow us to set 
test accounts, publish to the production channel or to see any developer 
console information about their other apps. Perhaps they could also allow 
us to manually cancel test purchases (which would require access to a 
subset of their Google Wallet merchant account). The granularity and scope 
of the privileges that could be granted in this way would need to be 
carefully designed.

What do others think?

-- 
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/d/optout.

[android-developers] Re: License client issue: can NOT_LICENSED be returned due to being off-line?

[Ted Hopp]

I'm not sure I understand this suggestion. What state are you tracking? How 
is it "separate from what Google Play returns"? As I described, we are 
already separately maintaining the last definitive response received. Do 
you do something beyond that?

More to the point: our app *seems* to be receiving a NOT_LICENSED response 
in situations where it is technically impossible that any response was 
received from the Google Play license server. How would we distinguish 
these responses (received from the licensing client running on the device) 
from legitimate NOT_LICENSED responses (which would also be delivered via 
the licensing client)?

On Tuesday, April 1, 2014 9:38:40 AM UTC-4, Digipom wrote:
>
> I've run into similar issues, and found that it's more reliable in terms 
> of impact on the end user to implement a second level of state tracking 
> separately from what Google Play returns. So, you might want to do that 
> depending on what your license policy is.
>
>

-- 
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/d/optout.

[android-developers] License client issue: can NOT_LICENSED be returned due to being off-line?

[Ted Hopp]

We have an app that uses the following license policy:

   - if a definitive response of LICENSED is stored in the app's 
   preferences and has not expired, allow access.
   - if a definitive response is not stored in the app's preferences, or if 
   it has expired, or if the cached response is NOT_LICENSED, request a 
   license check from the server.
   - if a definitive response (LICENSED or NOT_LICENSED) is received, it is 
   stored in the prefs, along with the license validity period returned by the 
   server. Access is permitted if the definitive response is LICENSED.
   - if anything other than a definitive response is received (airplane 
   mode, server error, etc.), the last stored definitive response is used to 
   determine access, even if expired. If no response is stored, allow access.

(This is basically the same as the LenientPolicy described in this 
thread.
 
We're aware of its weaknesses, but generally it works for us.)

The problem is that we occasionally receive reports of customers being 
denied use of the app due to a license problem. These are installations 
that definitely should be receiving a server response of LICENSED. When the 
problem happens, and when we've been able to obtain details, it always 
turns out that the user's device was not fully connected. When full network 
connectivity was restored, the app ran fine. Here's (part of) a report from 
a customer who has been unusually helpful:

I'm using an Acer Iconia A500 tablet, running Android 4.0.3, kernel 
2.6.39.4+. . . . So, I don't seem to be able to simulate it with airplane 
mode on. I also tried turning airplane mode back off, and it works fine 
right now. The situation where this happened to me it happened three 
different times, it was during a reading group at another person's house, 
and I don't have any access to their wifi network.  So, there was wifi in 
the area, but I wasn't connected to any at all, but I wasn't on airplane 
mode either. . . If it happens again, I will try to watch more closely and 
take note of any network circumstances.

We have not been able to reproduce the problem on either an emulator or on 
our test devices. As far as I can tell from our code, our app will always 
run unless it receives a response of NOT_LICENSED from the license client. 
Our assumption had been that this was only possible if the licensing client 
successfully contacted the license server and received a response of 
NOT_LICENSED (or had an unexpired NOT_LICENSED server response previously 
cached). But perhaps our assumption is wrong. Is there any situation where 
the licensing client on the device will return a response of NOT_LICENSED due 
to a communication problem (or any other reason besides having received 
that response from the license server)? Is there anything we could ask the 
customer to do that might help sort out what's going wrong?

-- 
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/d/optout.

[android-developers] How to position TextView scrollbar always at trailing side of text

[Ted Hopp]

Now that we have RTL text support in KitKat, I thought that a TextView that 
displays a vertical scrollbar would by default display it on the trailing 
side of the text. A simple experiment, though, shows that it always 
positions the scrollbar on the right, even when the text is right-to-left. 
(RTL text is correctly right-aligned automatically, but the scrollbar 
obscures the start of the text when it shows.) Is there a way of setting 
the TextView so that when the text is RTL, the scrollbar is automatically 
positioned on the left?

I suppose I could just use View.SCROLLBAR_POSITION_LEFT, but that's a 
terrible solution when the text directionality can change under user 
control (e.g., an EditText).

-- 
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: in-app billing disconnects from activity on configuration change

[Ted Hopp]

But the event is initiated by the user---when the user starts an in-app 
purchase. Also, the IAB flow involves user interaction to complete the 
purchase. The sample 
app<http://developer.android.com/training/in-app-billing/preparing-iab-app.html#GetSample>that
 Google provides initiates the purchase from an activity. The in-app 
billing library is designed around a work 
flow<http://developer.android.com/google/play/billing/api.html#purchase>that 
returns results through 
onActivityResult(). There's nothing in the docs for in-app billing that 
suggests this should be done (or how it could be done) by a service.

On Wednesday, September 25, 2013 11:44:53 AM UTC-4, Ian Ni-Lewis wrote:
>
> It seems like the main problem is that you're initiating IAB from an 
> activity, not a service. Activity lifetime is governed primarily by user 
> actions, so an activity is rarely the right container for something that 
> needs to respond to events that aren't initiated by the user.
>
> On Tuesday, September 24, 2013 7:35:26 PM UTC-7, Ted Hopp wrote:
>>
>> In testing an app with in-app billing, we found a nasty problem that 
>> occurs if there is a configuration change while a purchase flow is in 
>> progress. The initiating activity is destroyed and restarted, breaking the 
>> link from Google checkout process to the activity. To the user, it appears 
>> that the purchase flow is intact, but when the purchase is complete, the 
>> activity does not receive a result; hence the app is not informed of the 
>> purchase. This results in a very bad user experience--the user has spent 
>> money, but the app behaves as if it didn't happen! (If the user exits the 
>> app and restarts, it will re-query IAB and notice the change, but that's 
>> not a viable solution.)
>>
>> I suppose I could declare in the manifest that the activity that 
>> initiates the purchase will handle all configuration changes internally, 
>> but that seems rather extreme (not to mention difficult to implement, as we 
>> currently rely on the restart to recreate the activity with the correct 
>> resources).
>>
>> Are there any recommended best practices for how to deal with this?
>>
>> I should note that we also implemented in-app purchasing for the Amazon 
>> Appstore version of the app. Their library does not seem to have the same 
>> problem: the user can start a purchase, change device orientation, and 
>> complete the transaction, and the activity correctly receives the result.
>>
>

-- 
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] in-app billing disconnects from activity on configuration change

[Ted Hopp]

In testing an app with in-app billing, we found a nasty problem that occurs 
if there is a configuration change while a purchase flow is in progress. 
The initiating activity is destroyed and restarted, breaking the link from 
Google checkout process to the activity. To the user, it appears that the 
purchase flow is intact, but when the purchase is complete, the activity 
does not receive a result; hence the app is not informed of the purchase. 
This results in a very bad user experience--the user has spent money, but 
the app behaves as if it didn't happen! (If the user exits the app and 
restarts, it will re-query IAB and notice the change, but that's not a 
viable solution.)

I suppose I could declare in the manifest that the activity that initiates 
the purchase will handle all configuration changes internally, but that 
seems rather extreme (not to mention difficult to implement, as we 
currently rely on the restart to recreate the activity with the correct 
resources).

Are there any recommended best practices for how to deal with this?

I should note that we also implemented in-app purchasing for the Amazon 
Appstore version of the app. Their library does not seem to have the same 
problem: the user can start a purchase, change device orientation, and 
complete the transaction, and the activity correctly receives the result.

-- 
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] New warning when exporting Android application

[Ted Hopp]

Thanks for the lead, TreKing. It would be a big relief if Google disarmed 
this time bomb. If you happen to run across the thread, I'd appreciate a 
pointer to it; I definitely would like to follow any developments.

-- 
-- 
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] Recover Certificate from APK

[Ted Hopp]

On Thursday, June 14, 2012 12:43:51 PM UTC-4, Dianne Hackborn wrote:

> The platform has an app signed with a cert.  If you want to install an 
> update to that app under a different cert, how could the platform trust 
> that this is actually coming from the author who owns the original cert 
> without the new app also being signed in some way with the original cert? 
>  Note that we don't use certificate authorities, so there is no root cert 
> or such to go back to, to try to verify some relationship between two 
> certs.  Because we use self-signing, you are ultimately the CA, and have 
> responsibility for the certs you generate.
>

I know this is an old thread, but this caught my attention. Would it not be 
possible to come up with a tool with which a developer could somehow use 
the old cert as the authority for the new one? After all, the developer is 
the only one with access to the private key, so a new cert could be 
"signed" by the old one just as an .apk file is signed.

-- 
-- 
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: finish() method of an activity inside of oncreate() and onpause() behaves differently. why?

[Ted Hopp]

This is because of the activity 
lifecycle.
 
When you call finish() from within onCreate(), none of the other activity 
start-up events have occurred, so the corresponding shut-down events are 
also skipped. This behavior is mentioned in the documentation for 
onCreate()
.

-- 
-- 
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] New warning when exporting Android application

[Ted Hopp]

We have an app that was first submitted to Android Market several years 
ago. We've published several updates and are preparing a new update. We 
recently started receiving the following warning when exporting a signed 
.apk file:

Certificate expires on Thu Sep 16 19:19:35 EDT 2038.

The Certificate expires in 25 years.

Make sure the certificate is valid for the planned lifetime of the product.

If the certificate expires, you will be forced to sign your application 
with a different one.

Applications cannot be upgraded if their certificate changes from one 
version to another, forcing a full uninstall/install, which will make the 
user lose his/her data.

Google Play(Android Market) currently requires certificates to be valid 
until 2033.


Since the certificate expires in 25 years plus 7 weeks, I wonder why I'm 
getting this warning. Of much more concern, however, is the last line. Is 
the expiration date requirement (currently 2033) a sliding window? (In 
other words, will Google Play next year require certificates to be valid 
until 2034?) If so, does that apply to certificates applied to product 
updates? Because if it does, then the effective life of our product will 
have been reduced by 20 years, since we won't be able to update it starting 
five years from now.

Just as bad, if, in order to maintain our product we need to change 
certificates in five years (instead of 25), then (as I understand it) 
Google Play will treat a release signed with a new certificate as an 
entirely new product. This is because (again, I may not understand this 
exactly correctly) if the certificate changes, we will be forced to also 
change the package name for the apk. This will do great damage to our 
position in the market.

Can someone provide some clarity here? All of these constraints regarding 
signing certificates seems extremely unforgiving to publishers.

-- 
-- 
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: API to submit stack traces to Google Play

[Ted Hopp]

On Tuesday, June 25, 2013 5:02:43 PM UTC-4, a1 wrote:

>
>> You are attacking a strawman. I've commented on a very specific quote 
> from original post:
>
>> The alternative is to start removing catch clauses so that the app will, 
>> in fact, crash and the developer can at least see something. This seems 
>> like a silly approach, though.
>
> From this and rest of the post I get an impression (maybe wrong) that OP 
> catches aggressively everything - and this is of course invalid approach 
> (that makes debugging harder), and I did explain why.
>

Well, I never said I was catching everything indiscriminately. I catch 
things that I can do something about. Sometimes there's a silent fall-back 
and the app doesn't even need to bother the user about it. Sometimes I need 
to involve the user in what to do next. Sometimes I simply tell the user 
that something didn't work. In all those cases, the app doesn't crash, but 
in many of those cases, as a developer I'd like to see what happened; there 
may be an underlying flaw in our code or an unforeseen incompatibility with 
the user's device. What I was asking about was whether there was a way of 
obtaining the benefits of a crash report without forcing the app to crash 
(that was what "removing catch clauses" was referring to). Call it a 
"glitch report". What I've been doing in cases where I tell the user that 
something went wrong is to provide a button that composes an email for the 
user to review and then send to us. This seems bad for several reasons:

   - it's a pain to code
   - users are often reluctant to send emails (or to take any action other 
   than dismiss an error notification dialog)
   - an error message is already disruptive to the user; asking the user to 
   take some action makes the disruption worse
   - it's out-of-band communication
   - it would be useful to report problematic events without involving the 
   user (especially events for which the user would otherwise not need to be 
   involved)

I'll look into the ACRA-style bug reporting that TreKing suggests and at 
the crashlytics and android-log-collector tools suggested by Nathan. At 
first glance these look interesting, although something integrated with the 
developer console would be ideal.

-- 
-- 
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] API to submit stack traces to Google Play

[Ted Hopp]

When an app crashes due to an uncaught exception, the user can submit a 
crash report, that shows up in the developer console, showing a stack trace 
and other useful information. But if the app catches the exception, it 
doesn't crash and I don't know of a good way of receiving diagnostic 
information about the exception. I suppose I could compose a report and 
either send it to a server somewhere or prompt the user to email it. But it 
would be really useful if the app could generate something like a crash 
report (without actually crashing) and have it reported through the 
developer console.

Similarly, we sometimes hear from a customer about an app behaving 
incorrectly (e.g., blank screen). Again, it would be nice to have a tool by 
which the customer could report the logcat output from the app (in case any 
exceptions were caught and logged, or simply to see the flow of 
activities). (As of Jelly Bean, third-party apps like CatLog cannot read my 
app's logcat output.) Ideally, the tool could be invoked at the system 
level (maybe through app management settings?) to submit a report through 
the developer console. The alternative is to start removing catch clauses 
so that the app will, in fact, crash and the developer can at least see 
something. This seems like a silly approach, though.

Any suggestions for what to do about these situations?

-- 
-- 
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: APKs different with the same source code

[Ted Hopp]

The usual way to do this is to create a library project with the common 
elements and then to create separate projects containing only those 
elements of the app that are unique to each APK. See the docs on working 
with library 
projects
 for 
more info.

-- 
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 this licensing policy have weaknesses?

[Ted Hopp]

I asked a version of the following on 
StackOverflowand
 received only one response, which was off-point.

The default ServerManagedPolicy that Google provides in their License 
Verification 
Library
 relies 
on the server responses to determine the license revalidation interval. 
This results in requiring a revalidation every few days, apparently in 
perpetuity. This is not only a nuisance to users, it can be a serious 
problem for users who go extended periods with no connectivity. (We just 
had an inquiry from a user who expects to be without Internet connectivity 
for several weeks, which is what motivates this question.)

In summary, I'm looking for an algorithm that will accomplish two things: 
1) drastically reduce the connectivity requirements compared to 
ServerManagedPolicy; 2) provide the same level of anti-piracy protection.

In an answer to this other 
question,
 the 
suggested policy algorithm is to ignore the times provided in the response 
from Google's server and instead to use a grace period of about a month, 
with license checks being attempted every few days (to extend the grace 
period if a LICENSED response is received).

While this approach partially addresses the first goal, it still requires 
users to be connected once a month while using the app, so it would not 
work for (at least one of) our users.

The following algorithm accomplishes the first goal, but I don't know about 
the second. Any comments pointing out weaknesses of this algorithm, or 
suggestions for another approach, would be welcome.

   1. On first run, do a license check and insist on a LICENSED response 
   before providing full functionality. Once received, set a relatively short 
   expiration period (but longer than the refund period that Google Play 
   provides, currently 15 minutes). Also register a grace period of a few days 
   beyond that.
   2. The app would start checking again after the license expiration 
   period. If it failed to connect (airplane mode, etc.), it would still 
   function until the expiration of the grace period.
   3. After expiration of the grace period, insist on a second LICENSED 
   response before allowing normal app functioning.
   4. After receiving a second LICENSED response (whether before or after 
   expiration of the grace period), permanently enable all features of the app 
   and never bother checking again.
   5. If an UNLICENSED response is received, permanently disable full 
   functionality. (The user can revert to step 1 by deleting all app data.)

Additional points:

   - A suggestion was made to forgo the first license check and simply wait 
   until the expiration of the return period before checking. The purpose of 
   insisting on the first LICENSED response is to prevent the exploit where, 
   after a license check fails, the user simply stops the app process, clears 
   the app data, and restarts the app. (The app provides value even if usable 
   for only 15 minutes at a time.)
   - The purpose of insisting on a second LICENSED response is to get 
   around the buy-run-backup-return-restore exploit.
   - I'm not asking whether call-back license checking is a good idea or 
   not. I'm also well aware that no anti-piracy protection is foolproof and 
   Google's entire licensing mechanism can be circumvented (in which case all 
   questions about design of a policy algorithm are irrelevant). The main 
   point of this question is the relative risks (to us) and benefits (to the 
   user) of the above algorithm *as compared to other policies* (such as 
   the ServerManagedPolicy).

-- 
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 can I configure the Refund Period when using ServerManagedPolicy () in Android LVL

[Ted Hopp]

You cannot control the values for VT, GT, GR and UT. The server sets these 
values automatically (as described 
here
).

-- 
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] Library project manifest contents

[Ted Hopp]

I'm not clear on what needs to be declared in the manifest file for a 
library project. On the one hand, the documentation for setting up a 
library project in 
Eclipsesays:

A library project's manifest file must declare all of the shared components 
> that it includes, just as would a standard Android application.


On the other hand, the TicTacToeLib sample application doesn't declare its 
(single) activity, even though that activity is then used in the 
TicTacToeMain sample project. The sample project seems to be consistent 
with what it says later in the documentation:

In the manifest file of the application project, you must add declarations 
> of all components that the application will use that are imported from a 
> library project.


I've experimented with this with my own library project and it seems that 
the build process ignores any component declarations in the library 
manifest. The only thing that seems to be needed in the library is the 
 tag itself (with a package name attribute). No other tags seem 
to be required, including  or . The build process 
seems to work equally well and the resulting .apk files seem to be the same 
regardless of what activities (if any) are declared in the library manifest.

It would also seem a poorly designed build process to require declaring the 
same components in two different places. Is the documentation just wrong, 
or do we really need to declare components once in the library project and 
again in the main project? (Perhaps there's some future build functionality 
that this would support?) If the documentation is wrong, is the minimum 
declaration really just the  tag?

-- 
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 deal with expensive view height calculation?

[Ted Hopp]

Thanks, Adam. It seems that onSizeChanged is the way to go. I can cache the 
last width passed in onSizeChanged and only trigger new work if the width 
changes. I'm glad you pointed out that onSizeChanged can be called with 0 
width; I wouldn't want to do any work in response to that!

Just to be clear, though, when I mentioned doing something in onDraw, it was 
the following: retrieve the current width; check that the height 
calculations were valid for that width; if so, proceed with normal 
rendering; if not, then fire up a background thread to update the height and 
skip rendering. I was never thinking about doing the height calculation in 
onDraw itself. (I gather that both you and Blake had that impression.) Your 
point about the frequency with which onDraw may be called suggests, however, 
that if I can keep this test out of onDraw it might be better.

-- 
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 deal with expensive view height calculation?

[Ted Hopp]

I asked this question on 
SOa
 month ago but got no answer. Maybe I'll have better luck here. :)

I keep running into a sizing and layout problem for custom views and I'm 
wondering if anyone can suggest a "best practices" approach. The problem is 
as follows. Imagine a custom view where the height required for the content 
depends on the width of the view (similar to a multi-line TextView). 
(Obviously, this only applies if the height isn't fixed by the layout 
parameters.) The catch is that for a given width, it's rather expensive to 
compute the content height in these custom views. In particular, it's too 
expensive to be computed on the UI thread, so at some point a worker thread 
needs to be fired up to compute the layout and when it is finished, the UI 
needs to be updated.

The question is, how should this be designed? I've thought of several 
strategies. They all assume that whenever the height is calculated, the 
corresponding width is recorded.

The first strategy is shown in this code:

protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
   int width = measureWidth(widthMeasureSpec);
   setMeasuredDimension(width, measureHeight(heightMeasureSpec, width));
}

private int measureWidth(int widthMeasureSpec) {
   // irrelevant to this problem
}

private int measureHeight(int heightMeasureSpec, int width) {
   int result;
   int specMode = MeasureSpec.getMode(measureSpec);
   int specSize = MeasureSpec.getSize(measureSpec);
   if (specMode == MeasureSpec.EXACTLY) {
   result = specSize;
   } else {
   if (width != mLastWidth) {
   interruptAnyExistingLayoutThread();
   mLastWidth = width;
   mLayoutHeight = DEFAULT_HEIGHT;
   startNewLayoutThread();
   }
   result = mLayoutHeight;
   if (specMode == MeasureSpec.AT_MOST && result > specSize) {
   result = specSize;
   }
   }
   return result;
}

When the layout thread finishes, it posts a Runnable to the UI thread to set 
mLayoutHeight to the calculated height and then call requestLayout() (and 
invalidate()).

A second strategy is to have onMeasure always use the then-current value for 
mLayoutHeight (without firing up a layout thread). Testing for changes in 
width and firing up a layout thread would be done by overriding 
onSizeChanged.

A third strategy is to be lazy and wait to fire up the layout thread (if 
necessary) in onDraw.

I would like to minimize the number of times a layout thread is launched 
and/or killed, while also calculating the required height as soon as 
possible. It would probably be good to minimize the number of calls to 
requestLayout() as well.

>From the docs, it's clear that onMeasure might be called several times 
during the course of a single layout. It's less clear (but seems likely) 
that onSizeChanged might also be called several times. So I'm thinking that 
putting the logic in onDraw might be the better strategy. But that seems 
contrary to the spirit of custom view sizing, so I have an admittedly 
irrational bias against it.

Other people must have faced this same problem. Are there approaches I've 
missed? Is there a best approach?

-- 
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: Broken market update process

[Ted Hopp]

Well, it took the better part of two hours, but the updated .apk did finally 
appear. What a harebrained way of doing things.

-- 
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] Broken market update process

[Ted Hopp]

On Sunday, August 14, 2011 7:00:43 PM UTC-4, TreKing wrote:
>
>
> http://www.google.com/support/androidmarket/developer/bin/request.py?contact_type=publishing
>
 
Been there. Done that.
 

> Good luck.
>
 
Indeed. To us all. 

-- 
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] Broken market update process

[Ted Hopp]

The new update process, where the apk and product details tabs operate 
independently, is horrible. We updated our app by uploading a new apk, 
clicking "activate" and then clicking "save". We then updated the product 
details and clicked "save". Now the market shows all the details for the 
update, but it still is delivering the previous apk version! Our publisher 
console shows the new .apk version, but the market page shows the old 
version.

This is ridiculous. How long should we expect to wait for .apk updates to 
appear in the market? Moreover, why is the publisher console set up in such 
a disjointed manner that updated information about the app appears on a 
different schedule from the update itself? It's been at least half an hour 
now that our app's market page describes version 1.2 of the app and the apk 
file is still at 1.1. Our customers are going to (rightfully) feel that 
someone screwed something up. Unfortunately, they are going to assume it is 
us.

The release of .apk updates and marketing material updates need to be 
synchronized. Please fix 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] When is LICENSED_OLD_KEY returned?

[Ted Hopp]

The documentation for application 
licensingdescribes
 LICENSED_OLD_KEY as meaning:

The application is licensed to the user, but there is an updated application 
version available that is signed with a different key.

On the other hand, the documentation for signing 
strategiessays:

If you sign the new version without using matching certificates, you will 
also need to assign a different package name to the application — in this 
case, the user installs the new version as a completely new application.

Since applications are identified by their package names, this seems to say 
that you can't change the signing key for a published application. (Rather, 
you can change the key and package, but then it will be treated by the 
market as a new application.)

I can't think of a scenario where it is possible to receive a 
LICENSED_OLD_KEY response. Am I missing something?

-- 
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] License response codes -- what does a policy actually see?

[Ted Hopp]

In the docs on server response 
extras, 
I find this:

When network problems prevent or interrupt a license check, the Android 
Market client notifies the application by returning a "RETRY" response code 
to the Policy's processServerResponse() method. In the case of system 
problems, such as when the application is unable to bind with Android 
Market's ILicensingService implementation, the LicenseChecker library itself 
calls the Policy processServerResonse() method with a "RETRY" response code.

Unfortunately, RETRY is not listed one of the listed response 
codesthat
 the server returns, and when I look at the LVL source code, it appears 
that the Android Market client actually returns one of the server response 
codes and it is the LicenseValidator class in the library that decides when 
to turn that into a RETRY response status.

Furthermore, in the section on implementing a custom 
policy,
 
there's this in the guidelines:

Note that the Android Market client automatically retries failed requests, 
so in most cases there is no need for your Policy to retry them.

I find this confusing. Does the client simply report one of the documented 
server response codes, or does it do more? If the device is in airplane 
mode, for instance, does a custom policy need to deal with RETRY or does it 
need to deal with ERROR_CONTACTING_SERVER? Should the policy (or 
application) deal with retries, or does the client do it automatically?

-- 
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] Layout problem: equal margins in XML

[Ted Hopp]

I thought I had addressed that. Assuming that the smaller margins are at 
least the minimum, then the larger margins should shrink (the ListView 
should expand in that dimension) until they are equal all around. I think 
you are right that this cannot be done in XML alone, but I asked hoping that 
I'm wrong.

-- 
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] Layout problem: equal margins in XML

[Ted Hopp]

I have a rather involved requirement for a rather simple layout. I have an 
activity with a single ListView floating in the middle of the screen with a 
background margin of uniform width all around. So far no problem. Now I need 
the margin to be as large as possible given the content of the ListView, but 
always equal all around. Furthermore, if the ListView contents are higher 
than the screen, then there needs to be a minimum margin (that is, the 
margin cannot shrink to zero). Another way of stating the problem: the 
ListView should be nominally sized to wrap_content, except it should then 
expand in x or y as necessary to equalize the margins.

Without the equal-all-around requirement, or without the 
margin-as-large-as-possible requirement, this would all be fairly simple to 
do using layout_weight. Is there a way to implement both requirements? (In 
XML with stock UI elements, that is; I know I could do this in code.)

-- 
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] Using one publishing key on two accounts in Android Market & vice versa

[Ted Hopp]

Good point about selling app ownership. I take it, then, that the only 
issues have to do with key management (security; recovery; transfer)? The 
market itself doesn't care what keys are used where?

-- 
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] Using one publishing key on two accounts in Android Market & vice versa

[Ted Hopp]

Are there any downsides to using the same signing key for publishing
apps under different Android Market accounts? (Different apps under
each account.) Likewise, are there any problems in using different
signing keys for different apps in the same account? I would assume
not in both cases, but I couldn't find anything definitive posted
about this. So I thought it prudent to ask if anyone knows for sure.

[I asked this on stackoverflow a couple of months ago but got no
responses.]

-- 
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: Proguard and onClick attribute

[Ted Hopp]

Well, evidently it's already mentioned in passing in issue 16384. I
added my vote to the issue.


On May 1, 11:01 pm, Romain Guy  wrote:
> Methods referred by the XML onClick attributes are invoked by reflection,
> which is why Proguard believes they should be removed. You should file a
> feature request (enhancement) at b.android.com if you'd like the tools to
> keep these methods.
>
>
>
>
>
> On Sun, May 1, 2011 at 6:55 PM, Ted Hopp  wrote:
> > Apparently proguard decides that it's an unused method because nothing
> > in my code references it, and optimizes it away.
>
> > On May 1, 9:10 pm, a a  wrote:
> > > 2011/5/2 Ted Hopp :
>
> > > > For every new project, I always have to add the following lines to
> > > > proguard.cfg:
>
> > > >    -keepclassmembers class * extends android.app.Activity {
> > > >       public void *(android.view.View);
> > > >    }
>
> > > > Otherwise the onClick methods disappear when I publish the app. Is
>
> > > why?
>
> > > > there a way for us to change the default proguard.cfg file that's
> > > > created with a new project?
>
> > > > --
> > > > 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
>
> --
> Romain Guy
> Android framework engineer
> romain...@android.com
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support.  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] Re: Proguard and onClick attribute

[Ted Hopp]

Apparently proguard decides that it's an unused method because nothing
in my code references it, and optimizes it away.


On May 1, 9:10 pm, a a  wrote:
> 2011/5/2 Ted Hopp :
>
> > For every new project, I always have to add the following lines to
> > proguard.cfg:
>
> >    -keepclassmembers class * extends android.app.Activity {
> >       public void *(android.view.View);
> >    }
>
> > Otherwise the onClick methods disappear when I publish the app. Is
>
> why?
>
>
>
> > there a way for us to change the default proguard.cfg file that's
> > created with a new project?
>
> > --
> > 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] Proguard and onClick attribute

[Ted Hopp]

For every new project, I always have to add the following lines to
proguard.cfg:

-keepclassmembers class * extends android.app.Activity {
   public void *(android.view.View);
}

Otherwise the onClick methods disappear when I publish the app. Is
there a way for us to change the default proguard.cfg file that's
created with a new project?

-- 
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: Developing Android apps for someone else

[Ted Hopp]

Thanks, Kostya. I'm curious why the (public) publisher account key would 
need to be obfuscated. What vulnerability would there be if the key were 
publicly known?

-- 
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: Developing Android apps for someone else

[Ted Hopp]

> The Google Market team is very responsive to requests for transferring 
your app to a different account.
Did the app use the licensing library? If so, I imagine that the process 
wouldn't be quite so simple as asking the Google team to move it. Wouldn't 
it involve a new .apk file that used the public key for the target account?

-- 
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: Aw: Re: Developing Android apps for someone else

[Ted Hopp]

Thanks, Michael. We hadn't thought about the possible need to hand over the 
signing keys. That's a good argument against using our usual key pair.
I'm a bit leery of publishing to one account and then asking the Google team 
to switch the app to another account. I've read postings here and on 
StackOverflow that suggest that your experience is not 100% reproducible. In 
any event, we don't want to do that--the whole idea of partnering with the 
other company is to leverage their marketing strengths, so publishing to 
their account from the start is the most sensible thing.

This still leaves unresolved my questions about the licensing key and about 
managing the technical aspects of the publishing process.

-- 
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: Developing Android apps for someone else

[Ted Hopp]

Thanks, Chris. That seems obvious now that you point it out. :)
Is there any reason that they could not use an .apk file signed with our key 
to publish to their Android Market account? Signing (and then running 
zipalign) seems like the kind of work that should fall to us as the 
developers, and we'd like to keep it that way if possible.

-- 
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] Developing Android apps for someone else

[Ted Hopp]

 We have developed several apps and published them on Android Market. We are 
now writing an app that another company will brand and sell through their 
own publisher account. The other company has no experience with Android 
Market or with Android development. I'd appreciate any insights from others 
who have faced similar situations. I'm specifically concerned about the 
following areas:

*Signing the app*
The alternatives we see are: sign with our usual key; create a signing key 
pair specific to the other company and sign with that; or help the other 
company install a development system, generate a key pair, and do the 
signing themselves. The latter would require us sending them the project 
sources, which presents its own problems. Other than our concern about 
sending the source, does the choice matter in any way?

*Licensing*
Since the license check will be done against their account, the code will 
need to embed their public key for decrypting the license response. Is there 
any reason they should be concerned about sharing that key with us? Are 
there any alternatives to them sharing the key with us?

*Publishing*
The other company is responsible for all marketing and sales; we are 
responsible for the app development. From what we can tell, Android Market 
is not set up to allow a clean separation of these roles. (It assumes that 
the developer will also be the publisher.) This makes it difficult to work 
out a division of responsibilities for the publication process. Our initial 
thought was to deliver the .apk file to them and let them handle it from 
there. The licensing issue was the first indication that we were being naive 
about this. The publishing process itself is rather technical, and we see 
two alternatives: walk them through all the steps or ask them to give us 
access to their publisher account and do it ourselves. How do others handle 
this situation?

-- 
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: 2.3 Platform Google APIs missing Licensing Service..?

[Ted Hopp]

The problem persists in 2.3.3 (API level 10) emulator, at least for
us.

On Feb 5, 11:36 am, Marcin Orlowski  wrote:
> > Same code works on version 2.2 of the Google API emulator, but not 2.3
> > of the Google API emulator.
>
> It's known, confirmed 
> issue:https://groups.google.com/group/android-developers/msg/69ad5f4a5ec9f3e9
> If you want to test LVL use 2.2 emulator instead.

-- 
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] File extensions stripped from some assets and not others

[Ted Hopp]

When I add a GZIPed file to my Android project's assets, the ".gz"
extension is stripped when the project is packaged in Eclipse. (So,
for instance, "foo.gz" in my assets folder needs to be accessed in
code using getAssets().open("foo").) This doesn't seem to happen with
other extensions (e.g., ".html") that I'm using. The asset is still
GZIPed (I have to wrap the input stream in a GZIPInputStream to read
it).

Is this standard behavior or a bug? If it's standard, is there any
documentation about which extensions are stripped and which are
preserved?

-- 
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] Enabling ProGuard in Eclipse

[Ted Hopp]

The new documentation on ProGuard (http://developer.android.com/guide/
developing/tools/proguard.html) says to add a line to the
default.properties file in the project home directory. However, on
opening this file, I read at the top:

# This file is automatically generated by Android Tools.
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!

Am I missing something?

It would be nice if there was a way to enable ProGuard only for a
production build from Eclipse (i.e., when exporting the finished
product).

-- 
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 alpha mask a color fill?

[Ted Hopp]

I'm given a large number of grayscale images in the form of byte arrays. I 
want to use the values in each image as an alpha mask for drawing a solid 
color in a Canvas. The images are fixed but the color changes. I can create 
Bitmap objects for each image/color combination, but that seems terribly 
inefficient. What would be a good way to approach this problem, in terms of 
both memory and speed? (I need to render each image/color combo many times.) 
I'd prefer a solution that works on SDK 1.5 and up.

-- 
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: LinearLayout touch mode scrolling/focus problem

[Ted Hopp]

Okay. So there's some mysterious magic about focusable in touch mode,
and when you say "outside of the framework," I take it that I should
interpret that to mean "by me." So be it. (Although it's a sad thing
that I apparently can't write an app where the user points at one of
my custom widgets and then types a letter to take an action, at least
not if I want to combine that with scrolling. Maybe someday these
mysteries will be revealed to us?)

But what about the bizarre scrolling behavior I described in my follow-
up? No focusable in touch mode, and yet under not-so-remarkable
conditions the ScrollView moves contrary to whichever arrow key is
pressed!


On Apr 13, 1:46 pm, "Romain Guy" <[EMAIL PROTECTED]> wrote:
> Focusable in touch mode should not be used outside of the framework.
> It is meant for very specific widgets that know how to handle this
> case.
>
> On Sun, Apr 13, 2008 at 10:04 AM, Ted Hopp <[EMAIL PROTECTED]> wrote:
>
> >  A couple of follow-up details. Turning off focusable in touch mode
> >  (while undesirable for my app) fixes the scrolling problem...mostly.
> >  Now, when I scroll in touch mode to a position where no focusable view
> >  is visible it stays there. So far so good. However, if I now switch to
> >  keypad mode by pressing the UP key, focus transfers (and scrolling
> >  jumps) to the first focusable BELOW the current position, and if I
> >  press the DOWN key, focus transfers to the first focusable above. This
> >  seems completely backwards to me.
>
> --
> Romain Guywww.curious-creature.org
--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Re: LinearLayout touch mode scrolling/focus problem

[Ted Hopp]

A couple of follow-up details. Turning off focusable in touch mode
(while undesirable for my app) fixes the scrolling problem...mostly.
Now, when I scroll in touch mode to a position where no focusable view
is visible it stays there. So far so good. However, if I now switch to
keypad mode by pressing the UP key, focus transfers (and scrolling
jumps) to the first focusable BELOW the current position, and if I
press the DOWN key, focus transfers to the first focusable above. This
seems completely backwards to me.

--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] LinearLayout touch mode scrolling/focus problem

[Ted Hopp]

I have a LinearLayout embedded in a ScrollView that fills the screen.
The LinearLayout is set to focusable, focusable in touch mode, and
weak focus type. Within it, I have a mix of focusable and non-
focusable views (the focusable views are set to focusable, focusable
in touch mode, and strong focus type).

I'm having a problem when one of the non-focusable views is larger
than a full screen. If I scroll in touch mode to a position where none
of the focusable views is visible, then when my finger lifts, focus is
set to the first focusable sub-view and scrolling is adjusted so that
view becomes visible. This doesn't happen if I stick to keypad mode.
It also doesn't seem to happen in touch mode if I fling the scroll
view and it happens to end up at a position where nothing focusable is
visible. (In that case, if I scroll again in touch mode to where a
focusable view is visible, it receives focus, but if my finger goes up
with nothing focusable on the screen: boom.) It doesn't seem to matter
whether the activity was launched in touch or keypad mode, or what
mode was used in earlier scrolling.

I don't know if this was the intended behavior, but it is a very bad
user experience to be scrolling down and suddenly be back near the top
(with no visual feedback from the scroll bar, either!) Is there some
way around this (other than turning off focusable in touch mode, which
is not desirable for what I'm doing)?

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
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Re: check internet connection

[Ted Hopp]

Well, I'm not too familiar with the apache packages. I've been using
the java.net classes instead. Typical code looks like this:

URL url;
// ...
HttpURLConnection urlc = (HttpURLConnection) url.openConnection();
urlc.setRequestProperty("User-Agent", "My Android Demo");
urlc.setRequestProperty("Connection", "close");
urlc.setConnectTimeout(1000 * mTimeout); // mTimeout is in seconds
urlc.connect();
if (urlc.getResponseCode() == 200) {
// all is well
InputStream is = urlc.getInputStream();
// ...
} else {
// oops
}

That seems to work just fine for me. There are lots of examples on the
web of how to use the java.net classes to post, and setting the
connection timeout should work pretty much the same.

There may be other classes
Good luck.


On Mar 31, 6:27 am, alvin <[EMAIL PROTECTED]> wrote:
> HiTed,
>
> Thanks for your help. I really appreciate it. I have a couple of
> issues:
>
> 1) I used an HttpConnection to open a connection. And by calling the
> method .getConnectionWithTimeout (host, timeout) I can get the
> connection to timeout. HOWEVER, I performed a test where I open the
> connection WITH internet FIRST, then I disable my internet, and run it
> AGAIN. This results in the connection taking forever to break out.
> EVENTUALLY it does break out (after about 3 or 4 minutes). This isn't
> exactly ideal. I feel like it resets to default or the connection
> maintains some sort of persistent state. I have no idea why it doesn't
> "refresh" itself and time out like it's supposed to.
>
> 2) In another part of my code, I try to post some data to a server
> using HttpClient.execute(HttpPost) [in the
> org.apache.http.client.HttpClient package]. I have no idea how to time
> this out. There doesn't seem to be any methods associated with
> httpclient to set a timeout characteristic.
>
> Any help would be appreciated. I've also been looking into
> datastateintentreceiver, except there is very little documentation on
> it and I think that might be useful. Thanks in advanced.
>
> On Mar 30, 11:06 pm,TedHopp<[EMAIL PROTECTED]> wrote:
>
> > You can call setConnectTimeout() before making the connection. If
> > there is no internet connection, the response code should be -1. (Note
> > that the default timeout is 0, which means that your connection will
> > wait forever for a response.)
>
> >TedHopp
>
> > On Mar 30, 7:17 am, aTai <[EMAIL PROTECTED]> wrote:
>
> > > How do I check whether the phone/emulator is connected to the
> > > internet?
>
> > > I'm trying to connect with a server, and I need to figure out how to
> > > detect whether I have connectivity. Is there any way to do this on
> > > 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
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Re: Storing Transient Data Across an Application

[Ted Hopp]

If the data will only be accessed strictly within your application,
then extending Application is the easiest way to go. Otherwise the
Android way is to create a content provider. Storing transient data in
static variables is not reliable.


On Apr 8, 3:15 pm, Soonil Nagarkar <[EMAIL PROTECTED]> wrote:
> I am wondering, what is the best way to store somewhat transient data
> in a manner so that it is easily reachable across an entire
> application? In this case, it is a type of buddy list that is valid
> across a session. I would like any Activity, Service, etc... in my
> application to be able to read the same data.
>
> There seem to be two possibilities, storing the information or storing
> on disk. Storing on disk offers the SQLite database or files as a
> backend, but this is a bit heavierweight than I want. I would prefer
> to store the information in memory. I cannot find any good advice as
> to what the best way to do this is however.
>
> I have found some information about the Application class, which
> offers some of what I am looking for, but I am not sure if this is the
> best method, or the proper -Android way- to accomplish this. Any
> thoughts or advice?
--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Scrolling with internal focus problem

[Ted Hopp]

I'm trying to work out how to do this properly in Android: I have a
tall custom view embedded in a ScrollView. The custom view has a few
scattered "hot spots" that can receive focus. (So far, this is more or
less like the internal selection demo in ApiDemos.) I'd like the
following behavior: the view initially appears scrolled to the top. If
at least one hot spot is visible, the first one has focus. If the user
presses the down arrow and the next hot spot is also visible, transfer
focus without scrolling (or minor scrolling if partially visible);
otherwise, scroll in the ordinary manner of a ScrollView. If another
hot spot comes into view when scrolling, transfer focus to it.
Analogous behavior should happen with the up arrow.

The problem is that if I transfer focus in the manner of the internal
selection demo, scrolling will skip down the view until the next hot
spot is visible. I'd like it to scroll to intermediate positions where
there may be no hot spot visible.

I actually get more or less the behavior I want with a LinearLayout
inside a ScrollView when only some of the items are focusable.
(However, the LinearLayout comes up scrolled so the first focusable
child is visible.)

Thanks for any help with this!

Ted Hopp
--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Documentation errors re custom layout resources?

[Ted Hopp]

In the documentation for creating custom layout resources (http://
code.google.com/android/reference/available-resources.html), it says,
"Define your element in a .
See res/layout/attrs.xml in ApiDemos." But in that file, the tag uses
a "name=" attribute instead. I assume that "name=" is correct, since
it seems to work. Is this just a documentation bug (maybe left over
from an earlier version)?

Also, the documentation lists the source file format as "XML file
without an  declaration". Again, this is at variance with the
file in ApiDemos, which does have an xml header declaration. Another
documentation bug? In general, in all resource xml files, which ones
must have an  declaration, which ones must not, and which ones
does it make no difference?

Thanks,

Ted Hopp
--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Re: Custom drawing states possible?

[Ted Hopp]

Thanks! That's very cool.


On Mar 31, 6:22 pm, "Megha Joshi" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> You can use the mergeDrawableStates() method of the View class to provide
> your custom states:
>
> http://code.google.com/android/reference/android/view/View.html#merge...[],%20int[])
>
> Try the steps below to create new custom states:
>
> 1) Define the state resources in res/values/attrs.xml
>
>
> 
> 
> 
>
> 2) In your custom view class :
>
> A)   Declare the state variables:
>
>private static final int[] FRIED_STATE_SET = {
> R.attr.state_fried
>};
>
>private static final int[] BAKED_STATE_SET = {
> R.attr.state_baked
>};
>
> B) Override the onCreateDrawableState() method:
>
>@Override
> protected int[] onCreateDrawableState(int extraSpace) {
> final int[] drawableState = super.onCreateDrawableState(extraSpace +
> 2);
> if (isFried()) {
> mergeDrawableStates(drawableState, FRIED_STATE_SET);
> }
> if (isBaked()) {
> mergeDrawableStates(drawableState, BAKED_STATE_SET);
> }
> return drawableState;
> }
>
> Once this is done, you should be able to use these in
> ColorStateListDrawable, but you should use your app's namespace to use these
> new states:
>
> http://schemas.android.com/apk/res/android";
> xmlns:app="http://schemas.android.com/apk/res/">
>  state_fried="false" />
>  state_fried="true" />
>  state_fried="true" />
>  state_fried="false" />
> 
>
> On Mon, Mar 31, 2008 at 9:48 AM, Ted Hopp <[EMAIL PROTECTED]> wrote:
>
> > With some searching I've found several examples and explanations of
> > customizing the look of a component based on the drawing states. But I
> > haven't found anything about defining custom drawing states. For
> > instance, suppose I have a component that maintains states that I
> > might call "baked" and "fried" and I want it's appearance to track
> > these states. So I'm imagining this drawable:
>
> > http://schemas.android.com/apk/res/android";>
> >  > state_fried="false" />
> >  > state_fried="true" />
> >  > state_fried="true" />
> >  > state_fried="false" />
> > 
>
> > Is this possible? I see that it is possible (with setState,
> > mergeDrawableStates, etc.) to have custom state data, but I don't see
> > how to put this to use. I can't figure out from the documentation
> > whether it is even possible to define custom item state attributes in
> > xml, much less how to do it and link them to the state vector. (I'm
> > assuming that if this is possible, I could also mix custom attributes
> > with standard ones like android:state_pressed.) A pointer to an
> > example or two would be very helpful.
>
> > 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
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Custom drawing states possible?

[Ted Hopp]

With some searching I've found several examples and explanations of
customizing the look of a component based on the drawing states. But I
haven't found anything about defining custom drawing states. For
instance, suppose I have a component that maintains states that I
might call "baked" and "fried" and I want it's appearance to track
these states. So I'm imagining this drawable:

http://schemas.android.com/apk/res/android";>






Is this possible? I see that it is possible (with setState,
mergeDrawableStates, etc.) to have custom state data, but I don't see
how to put this to use. I can't figure out from the documentation
whether it is even possible to define custom item state attributes in
xml, much less how to do it and link them to the state vector. (I'm
assuming that if this is possible, I could also mix custom attributes
with standard ones like android:state_pressed.) A pointer to an
example or two would be very helpful.

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
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Re: check internet connection

[Ted Hopp]

You can call setConnectTimeout() before making the connection. If
there is no internet connection, the response code should be -1. (Note
that the default timeout is 0, which means that your connection will
wait forever for a response.)

Ted Hopp


On Mar 30, 7:17 am, aTai <[EMAIL PROTECTED]> wrote:
> How do I check whether the phone/emulator is connected to the
> internet?
>
> I'm trying to connect with a server, and I need to figure out how to
> detect whether I have connectivity. Is there any way to do this on
> 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
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Re: DOM Parser crashes

[Ted Hopp]

The DOM parser has some problems. See, for instance,
http://code.google.com/p/android/issues/detail?id=225&colspec=ID%20Type%20Version%20Security%20Status%20Owner%20Summary

You might try calling normalize() on the top document element. That's
supposed to merge adjacent text elements and eliminate empty text
elements. (In theory, you shouldn't have to do this on the results of
a straight parse--it's a way to fix things up when you muck with the
DOM tree procedurally--but it sounds from your description like the
parser is returning a non-normalized tree.)

To avoid cast errors, switch on the value of getNodeType() and cast
(or ignore) accordingly.

Ted Hopp


On Mar 30, 2:27 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Hi!
>
> I tried parsing an XML file which I had created through code. The file
> has lines seperated by System.getProperty("line.seperator",""). The
> DOM engine parses the files but when I try to access the elements, the
> code crashes giving cast errors. On quick inspection of the memory
> dump it seems DOM parser creates a textimp node for each '\n' inserted
> in the file. Is this a correct behavior. If yes, can you suggest a
> generic way to handle elements in a tree.
>
> Regards
> Nitin Khanna
> Assistant Manager
> Hughes Systique Corp
--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Re: application always persistent?

[Ted Hopp]

Thank you. That clears things up nicely!


On Mar 25, 11:36 am, hackbod <[EMAIL PROTECTED]> wrote:
> This behavior is described here:
>
> http://code.google.com/android/intro/lifecycle.html
>
> On Mar 25, 7:00 am, Ted Hopp <[EMAIL PROTECTED]> wrote:
>
> > I have an app that declares an Application class in the manifest. I
> > noticed that by having an application class, a process hangs around
> > after all my activities exit. The process name is the same as the
> > package name for my app, and I'm assuming that this holds an instance
> > of my Application subclass. (onCreate gets called the first time I run
> > my app in an emulator instance, and thereafter only if I kill this
> > process first.)
>
> > This behavior doesn't change if I add android:persistent="false" to
> > the application tag in the manifest.
>
> > Is this a bug or a feature? (I'm using m5-rc15, if that makes a
> > difference.)
--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] application always persistent?

[Ted Hopp]

I have an app that declares an Application class in the manifest. I
noticed that by having an application class, a process hangs around
after all my activities exit. The process name is the same as the
package name for my app, and I'm assuming that this holds an instance
of my Application subclass. (onCreate gets called the first time I run
my app in an emulator instance, and thereafter only if I kill this
process first.)

This behavior doesn't change if I add android:persistent="false" to
the application tag in the manifest.

Is this a bug or a feature? (I'm using m5-rc15, if that makes a
difference.)

--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Re: Good example for showing exchanging of data mostly arrays or non premitive data types,objects

[Ted Hopp]

I read another thread here a few days ago that pointed out that an
Application object can be used as a central place for data shared
between activities. It seems to be working nicely for me. I don't use
it to pass data back from subactivites, but I imagine it would work
just as well.

However, in M5 the Application process seems to hang around after all
my activities have finished, even if I explicitly set
android:persistent="false" in the manifest. I don't know if this is
just a disadvantage of having an Application class or a bug. But I'd
be concerned if I were keeping large amounts of data there.


On Mar 24, 5:39 pm, hackbod <[EMAIL PROTECTED]> wrote:
> On Mar 24, 2:42 pm, "Dan U." <[EMAIL PROTECTED]> wrote:
>
> > 1. I could not get the serializable passing ability of a Bundle to
> > work. It has to do with a incorrect classloader error. I think it's
> > the same error that got in the road of serialization in the m3 sdk. It
> > was possible to work around though.
>
> We had a really, really stupid mistake in M5.  All of the support for
> propagating custom Parcelable and Serializable objects is there in M5,
> but at one place in the system code we print the Intent that is being
> used to start an activity...  which prints the extras bundle
> associated with the intent...  which causes the bundle to try to
> instantiate its data...  which goes boom.
>
> This will be fixed in an upcoming SDK.  I know it is unfortunate. :(
>
> > 2. I've heard serialization is slower than implementing your object as
> > a parcelable.
>
> Yes it is.  We highly suggest using Parcelable if you can.
--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---