tags:

views:

125

answers:

2

I am based in Germany and publish the "Last Call Widget" on the Android Market. I have been steady improving it over time, but one group of users still complain about it not working on their devices.

My widget listens for the "android.intent.action.PHONE_STATE" intent, and then sets an alarm to update the last call UI in 20 seconds, then 60 seconds, then 5 minutes, 1 hour, etc. This works reliably on all my test devices, even with aggressive task killers (try it yourself). Unfortunately I have a cluster of users with Motorola Droids on the Verizon network who complain that the UI does not automatically update.

I believe Verizon is a CDMA network (we have GSM here in Europe), though the Android API docs don't specify any implementation differences. This could also be a driver issue on the Motorola Droid (we have GSM Motorola Milestones in Europe).

I am wondering if anyone reading is in a position to offer any ideas, or test the widget on a Droid and/or CDMA network to see if they can reproduce an issue (with logs)?

Regards Mark

A: 

Well, while I have DROIDs, none have active Verizon accounts, as I moved my Verizon account to an Incredible. Hence, I cannot test your app, as I cannot place phone calls (except 911, and the police really won't appreciate my calling them just to test your app widget).

You might integrate some Flurry-type logging to see if it's that you are not getting the Intent at all, or if it is somehow not meeting your expectations (e.g., EXTRA_STATE not what you're expecting).

Beyond that, you can use the Build class to detect the DROID and have the alarm go off every N seconds all the time the phone is awake, instead of based on the incoming call. This will chew up more battery, and DROID users with your app who attack you with a task killer will stop those alarms. That's why I'd only do this for the DROID, or any other devices that you determine have similar behavior.

CommonsWare
Here's some good news: as of Froyo the APIs used by task killers no longer remove alarms since it breaks other apps exactly in the way you describe. http://developer.android.com/reference/android/app/ActivityManager.html#restartPackage(java.lang.String) for some more info.
adamp
Hi Mark MurphyAs far as I can tell, Flurry doesn't work for widgets:http://blog.zedray.com/2010/04/24/using-flurry-with-a-android-home-screen-widget/Right now I haven't a clue what could be wrong with my widget, i.e. it could be the device, service killer, or maybe the CMDA network API. If you could reproduce the issue with a zero second call (on Verizon or another network) that would be great, and by reproduce, I mean the UI does not say "1 minute ago" a minute after making a call (without you clicking on the Widget).Thanks for the feedback.Mark
Mark Brady
A: 

I have a droid on verizon. I installed your widget and tried it out. It seemed to update fine until 27 minutes, then stayed on 27 minutes for several hours. When I clicked on the widget, it updated the time to 3 hours. Is that how it supposed to work? I can send you logs if you tell me what you need and how I can get it to you.

Burke
Hi BurkeIts supposed to go smoothly from minutes, to hours, to days. Logs would be great, a reproducible test case would be even better.Thanks for the feedback.RegardsMark
Mark Brady