[android-developers] Galaxy Nexus JB OTA fails
I reported this as an issue and I have done lots of googling but I have not found a satisfactory answer. I work for a company that is using the Galaxy Nexus to deploy an application. We have literally hundreds of handsets. With the roll-out of the Jelly Beans OTA update we are finding that roughly 80% of our handsets fail to process the update. We are running stock 4.0.4 and the handsets are not rooted, our app does nothing special to the system files. This must be happening to thousands of ordinary phone users out there. We now have the pain of repeated notifications to install and we do not have a clean method yet to make these updates actually happen. Has anyone else had this problem? Is google aware of it? Is there any advice on how we can get hundreds of handsets to accept the OTA update? -- 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] Jelly Bean OTA fails on Galaxy Nexus
This is not a programming question per se, it is a question about how to get information from Google about Android. The company I am working for has hundreds of Galaxy Nexus handsets which are used as the standard operating platform of a company specific app. The app is not important. We have found that about 70% of the devices fail to install the standard OTA Jelly Beans update. We are running completely stock OS (4.0.4 ICS) and the devices are not rooted. My questions are: 1. Why does the OTA fail for completely standard builds? Factory reset makes no difference. 2. How can I get some idea as to why the OTA fails? 3. Where does Google provide support for this situation? 4. Can I disable the OTA updates? We are getting very frustrated with the regular interruptions to normal service when the OTA notification pops up no matter what the user is doing. 5. Is there a Google web site that describes how to do the OS update manually? Perhaps we can manually handle the hundreds of handsets, costing us thousands of dollars in labour costs? I have reported this to the code.google.com Android issues list, no response from that. I tried to post a notice on Android Developers but the moderation process there seems to take four or more days, perhaps never. This must be happening the thousands of non-developer users of the Galaxy Nexus, they can not be expected to hack their way around it. Where is the Google fix (or does Google simply not care?). -- 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: Widget Product Updates
On Jun 3, 7:09 pm, Kostya Vasilyev kmans...@gmail.com wrote: 03.06.2012 14:22, David Ross написал: Sadly, this does not work at all well. Just as when you have a widget and you uninstall the app you get the horrid Problem Loading Widget message, the same thing happens when the user accepts the update from the Play site. Never seen this with my own widgets, or other installed widgets on any of my phones. Now, if the updated package uses a different class name for the same widgets, the home screen won't know this, and the user will get the message you describe. No, no changes to package name, nope. My users have reported this. I have seen it. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Widget Product Updates
Sadly, this does not work at all well. Just as when you have a widget and you uninstall the app you get the horrid Problem Loading Widget message, the same thing happens when the user accepts the update from the Play site. I think this is a serious problem and I am certain I loose users because of it but there is absolutely nothing to be done about it. I don't think the Android developers thought this through at all. Also watch out for irritating things like ghost widgets on lower API levels (1.6) when unexpected things happen like there's not enough home screen space for your widget. I keep my own track of the widgets so I can detect and ignore ghost widgets. Your might even consider whether or not you should use Live Wallpaper instead. It is active behind the unlock screen and handles the update cycle better but of course it is only available on 2.2+. On Jun 3, 7:36 am, Doug Gordon gordo...@gmail.com wrote: I'll shortly be releasing my first widget product and am wondering if there are any restrictions as to how the user updates a widget when a new version is posted. I've noticed that if you use the App Manager to delete a widget that's in use without removing it from the home screens, an error message ends up being displayed in that location on the screen (which you then have to remove in the standard way). But if an updated version is installed over the existing version, is the updated widget now displayed as expected on the home screen? Or would the user be forced to remove the existing instances and add back the updated widget? Doug Gordon GHCS Software -- 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: Will google plan to fix bug #26446 in next release?
That's a useless answer, why post it? There is are two meta issues here: 1) Google's support system for reported issues is hopeless. 2) ICS on the Nexus is a disaster, there is so much wrong with it and it is poisoning the Android brand severely. In both instances, Google should be pro-actively working to fix these meta issues. On May 28, 6:45 pm, Mark Murphy mmur...@commonsware.com wrote: I am sure that somebody knows. I am equally sure that you will find out when the rest of us find out, sometime after a new version of Android ships. On Sun, May 27, 2012 at 10:05 PM, Chuan Zhou chuan.z...@gmail.com wrote: Is there anybody know that will google plan to fix bug #26446(https://code.google.com/p/android/issues/detail?id=26446)?It is a bad performance bug which will impact the video/camera application. Thanks, Chuan -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android Training...At Your Office:http://commonsware.com/training -- 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: resolution of the system clock
The nominal resolution is millisecond, however the accuracy is of the order of a minute or so unless you root the phone and use NTP. Standard Android time keeping is hopeless. See: https://code.google.com/p/android/issues/detail?id=12497 http://code.google.com/p/android/issues/detail?id=4581 On May 30, 8:00 pm, Marcin Orlowski webnet.andr...@gmail.com wrote: assuming that you can get system time in millis, assume it is millis. it's irrelevant if hw clock is ticking in higher frequency or not. Regards, Marcin Orlowski *Tray Agenda http://bit.ly/trayagenda* - keep you daily schedule handy... *Date In Tray* http://bit.ly/dateintraypro - current date at glance... WebnetMobile on *Facebook http://webnetmobile.com/fb/*, *Google+*http://bit.ly/webnetmobile-gpand *Twitter http://webnetmobile.com/twitter/* On 30 May 2012 07:17, bob b...@coolfone.comze.com wrote: What is the resolution of the system clock of a typical Android device? (such as a Galaxy Tab) -- 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] Re: time sync
Time keeping on Android is lousy, you will not be able to synchronise multiple phones unless you implement your own time keeping (perhaps using NTP) aside from the Android date/time. See: See: https://code.google.com/p/android/issues/detail?id=12497 http://code.google.com/p/android/issues/detail?id=4581 On May 31, 2:33 am, TreKing treking...@gmail.com wrote: On Wed, May 30, 2012 at 7:31 AM, bob b...@coolfone.comze.com wrote: Does having your app set the time on the Android device require root access? http://bit.ly/KWT6jJ - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: UI performance is slow on large screen tablet
Are you using the convert view parameter and getTag() with a viewHolder or are you creating the elements in the list from scratch each time? Using the convert view reduces GC and removes the time to create new objects for each row. See this for an explanation: http://logc.at/2011/10/10/handling-listviews-with-multiple-row-types/ I hope I'm not giving you stuff you already know, but this is an important pattern to improve UI speed. On May 31, 12:37 pm, TreKing treking...@gmail.com wrote: On Wed, May 30, 2012 at 11:02 PM, dara kok mrpc.cambo...@gmail.com wrote: Could somebody here point out what are the contributing factors to such issue? The size of the display, as you already noticed. More to draw = longer time to taken to draw. and what could be done to optimize the UI speed? Profile your code, then address the bottlenecks. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: GPS Location returns zero speed always
My problems is not with failure or inaccurate readings, it has to do with why the GPS provider does not provide speed and bearing values when it returns a new Location. I have done a simple test and reduced the minimum time between location updates from 1 minutes to 10s and then I consistently get speed and bearing. What bugs me is that on the HTC Dev 1 (1.6) and the Huawei Sonic (2.3.3) the GPS returns speed and bearing even when the update frequency is more than a minute (expected/desired behaviour). It sounds like a buggy GPS implementation either in the GPS chipset or in the low level drivers. On Apr 26, 7:05 pm, lbendlin l...@bendlin.us wrote: https://www.google.com/search?q=google+nexus+s+gps+issues -- 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] GPS Location returns zero speed always
Asked this over on Stackoverflow as well... I have code that successfully gets location updates from multiple providers and filters them to give a current best estimate. I added code to check for the returned Location.hasSpeed() and .hasBearing() values to do some bearing related calculations when the user is actually moving. It all works fine on a Huawei Sonic running 2.3.3, but on the Google Nexus S running 4.0.4 the GPS provider's Location always returns false for .hasSpeed() and 0 for .getSpeed(). When I register my location listener, the GPS provider returns true for .supportsSpeed() but it never returns the speed in a Location even when the accuracy is down to 30m and it is physically moving (in a car, on the dashboard for max reception, screen on). Is there some difference from 2.3.x to ICS 4.x? Do I have to implement my own speed calculation even when the provider reports support? -- 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] Spam apps in the Play search lists
Has anyone else experienced spam apps in Google's search results in Play? I have a season app for an annual sporting league in Australia, and aside from the mystery of how the big players manage to get their apps at the top of the search results immediately they publish them, the more irritating situation for me is where the search results are poisoned by obsolete, clearly unsupported apps appearing in the search list. These apps are from the previous system and have not been updated for the current season, they have clearly been abandoned, the last updates were nearly a year ago, but I guess because they have quite a lot of reviews from the previous season, they trump my app in the search list ordering. Worse is the developer has made per team apps for a league of 17 teams and most of them (about a dozen) appear in the search list results for the most likely search term. I tried to report them as spam, but despite Google's stated developer policies specifically banning spam apps, there seems to be no way to report them, no way to get a human being inside Google to look at the issue. Anyone else experienced anything similar, and if so were you able to work out a strategy to deal with it? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to keep activity running
Humbly suggest using BroadcastReceiver that handles a PendingIntent that you use with the AlarmManager as a RTC_WAKEUP if you want to do timed polling of location. Also, use BroadcastReceivers to catch location updates. There was an excellent Google Blog entry: http://android-developers.blogspot.com.au/2011/06/deep-dive-into-location.html On Mar 20, 12:40 am, RedBullet scottedchap...@gmail.com wrote: Yea, I'll create a service to essentially do the route tracking when I am doing a route. I am wondering if it makes sense to contain all that state/logic in the service, or if I should put as much of the common state into an Application class, and let the activities/services access it through the application class. On Monday, March 19, 2012 12:18:57 PM UTC-4, TreKing wrote: On Mon, Mar 19, 2012 at 10:01 AM, RedBullet wrote: So, is there an example that shows how an Application class interacts with activities? Application doesn't really interact with Activities. You can of course add your own logic that does, but it's not necessary, particularly for what you've described as your use case. My app to date is just activity based. Do I need to do anything aside from create a class derived from Application, store my own application state info in it, an update my manifest? Or do I need to more than that? Yes. I really sounds like you need a Service, not an Application. See the Google Navigation app for a prime example. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Newly installed widgets are not runnable on Honeycomb
Thank you. Sigh, this sort of change is so very, very irritating. Who makes these decisions? Why change working behaviour? This is the sort of code bomb drop nonsense that is making it so very hard for Android developers to make robust software. No cogent explanation as the 'why' of this decision in the release note you linked to. I don't own a 3.x or 4.x device and the 3.x emulator sucks, I can't get it to run on my modest laptop, so I have trouble even testing on the later platforms. I don't want my user to access functionality from the launcher at all, I want them to only access functionality from the Widget. All my Launcher Activity does is display a splash screen telling the user how to install the Widget. What was wrong with the old behaviour? Why not allow an installed application with a Widget be installed as Widget without Launching an Activity first? It makes no sense to me. In fact, aside from that mention you linked to of an Application's state as stopped or started, there seems to be no real explanation of this behaviour at the Application level anywhere in the developer documentation. How are we supposed to know and understand this sort of undocumented behaviour? Anyway, thanks for the info. On Feb 4, 7:40 pm, Kostya Vasilyev kmans...@gmail.com wrote: Yes, this changed starting with 3.1: http://developer.android.com/sdk/android-3.1.html#launchcontrols The end result is: App widget can't be added to the home screen immediately after the installation. The application's package needs to be moved from stopped to started state first. You can do this by providing an activity that the user can launch from Launcher. This is not the same as the widget config activity. -- Kostya 4 февраля 2012 г. 5:30 пользователь David Ross grand...@vacuumpunk.comнаписал: But that's not how it works in 2.3.x. Install the App (Widget), say from market. Don't run it when given the Open option in the market after download completes. Don't launch it from the Launcher either. Just navigate back to the Home Screen. Long press on home screen and select Widgets. Hey presto, it's there! No need to launch the App for it to be available as a Widget. The Android install process parses the manifest and places the new widget in the list of available Widgets without having to be launched first. And while you need to have the configuration Activity in the manifest and the widget config file, that Activity does not have to do anything at all really, you can just return RESULT_OKAY and handle the widget configuration in your WidgetProvider onEnabled() and onUpdate() when you get the APPWIDGET_xxx Intents. Has that changed in 3.0+? Am I missing something here? As I said before, this approach handles the bad use-cases that Android does not handle cleanly. -- 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: Newly installed widgets are not runnable on Honeycomb
But that's not how it works in 2.3.x. Install the App (Widget), say from market. Don't run it when given the Open option in the market after download completes. Don't launch it from the Launcher either. Just navigate back to the Home Screen. Long press on home screen and select Widgets. Hey presto, it's there! No need to launch the App for it to be available as a Widget. The Android install process parses the manifest and places the new widget in the list of available Widgets without having to be launched first. And while you need to have the configuration Activity in the manifest and the widget config file, that Activity does not have to do anything at all really, you can just return RESULT_OKAY and handle the widget configuration in your WidgetProvider onEnabled() and onUpdate() when you get the APPWIDGET_xxx Intents. Has that changed in 3.0+? Am I missing something here? As I said before, this approach handles the bad use-cases that Android does not handle cleanly. On Feb 3, 9:01 pm, Mark Murphy mmur...@commonsware.com wrote: On Thu, Feb 2, 2012 at 8:53 PM,DavidRossgrand...@vacuumpunk.com wrote: The Activity WidgetDummyConfiguration is called when the APK has been downloaded from the market and run. I sure hope not. Nothing is supposed to run in an APK file when it has been downloaded from the market and run. Certainly not the MAIN/LAUNCHER activity. You are welcome to provide source code to a sample project that demonstrates this effect. I guess what you mean is that the system must first run the invisible do-nothing activity of .WidgetDummyInstall in order for the manifest contents to be registered with the system which then means the Widget will be entered into the list of available Widgets? No, I mean that the user must tap on your WidgetDummyConfiguration icon in the launcher so that the Widget will be entered into the list of available Widgets. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 2.4 Available! -- 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: Newly installed widgets are not runnable on Honeycomb
I guess I was not clear. Downloaded from the Market and then run by the user. Yes, the download and install process does not run the APK automatically, but after it has been downloaded the Market App gives the user the the options to Open or to Uninstall. Even if the user exits the Market App after starting the download/install process, the Market posts a Notification where it will automatically launch the App if the user taps the Notification. That's what I meant by downloaded and run. But my point was that it only has to be installed for it to appear in the list of Widgets available from the home screen long- press dialogs. On Feb 3, 3:54 pm, phoku mboeh...@fh-muenster.de wrote: I do not really believe that your WidgetDummyConfiguration is called after installation of the app. Usually apps are not started via their main launcher after installation, or am I getting something wrong 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] Re: Newly installed widgets are not runnable on Honeycomb
In my Widget I have a dummy configuration App that does as the earlier poster said, it just runs, does some internal housekeeping like setting up default preferences and returns the provided AppWidgetId and RESULT_OK: Intent resultValue = new Intent(); resultValue.putExtra(AppWidgetManager.EXTRA_APPWIDGET_ID, appWidgetId); setResult(RESULT_OK, resultValue); It does not even inflate a layout, after setting the result it does a finish(). It is an invisible configuration activity so that the user gets the effect of the Widget appearing instantly after selecting it for installation. Are you saying that does not work? On Feb 3, 7:06 am, Mark Murphy mmur...@commonsware.com wrote: On Thu, Feb 2, 2012 at 6:01 PM, phoku mboeh...@fh-muenster.de wrote: Is there anything new about this bug? It is not a bug. I am developing a widget-only app, You can no longer do that. i.e. I do not have any activity to present to the user. How can I allow him to add my widget without rebooting? Put in an activity to present to the user. This is unavoidable, AFAICT, on Android 3.1+. You will need it at first install, and you will need it if the user elects to force-stop your application. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 3.7 Available! -- 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: Newly installed widgets are not runnable on Honeycomb
By the way, I went the invisible instant Activity path for the Widget configuration because there are a number of horrible use-cases with the Widget installation process that Android does not handle properly and spending any time in the config activity can result in bad things like ghost widgets (two types of ghost, one is where the OS thinks the widget is there but it is not, the other is where my App thinks the widget is there but is it not). These can be caused by things like not enough home screen space or unintented power down (eg battery fail) before the config activity returns the RESULT_OK. It took quite some time to nut out these rare use-cases. On Feb 3, 8:32 am, David Ross grand...@vacuumpunk.com wrote: In my Widget I have a dummy configuration App that does as the earlier poster said, it just runs, does some internal housekeeping like setting up default preferences and returns the provided AppWidgetId and RESULT_OK: Intent resultValue = new Intent(); resultValue.putExtra(AppWidgetManager.EXTRA_APPWIDGET_ID, appWidgetId); setResult(RESULT_OK, resultValue); It does not even inflate a layout, after setting the result it does a finish(). It is an invisible configuration activity so that the user gets the effect of the Widget appearing instantly after selecting it for installation. Are you saying that does not work? On Feb 3, 7:06 am, Mark Murphy mmur...@commonsware.com wrote: On Thu, Feb 2, 2012 at 6:01 PM, phoku mboeh...@fh-muenster.de wrote: Is there anything new about this bug? It is not a bug. I am developing a widget-only app, You can no longer do that. i.e. I do not have any activity to present to the user. How can I allow him to add my widget without rebooting? Put in an activity to present to the user. This is unavoidable, AFAICT, on Android 3.1+. You will need it at first install, and you will need it if the user elects to force-stop your application. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 3.7 Available! -- 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: Newly installed widgets are not runnable on Honeycomb
Not sure I understand that. My manifest has three activities:
activity
android:label=@string/app_name
android:name=.WidgetDummyConfiguration
intent-filter
action
android:name=android.intent.action.MAIN /
category
android:name=android.intent.category.LAUNCHER /
/intent-filter
/activity
activity
android:label=@string/app_name
android:name=.WidgetConfiguration
intent-filter
action android:name=android.intent.action.MAIN/
data android:scheme=com.vacuumpunk.CDTBD2012 /
category
android:name=android.intent.category.DEFAULT /
/intent-filter
/activity
activity
android:label=@string/app_name
android:name=.WidgetInstall
intent-filter
action
android:name=android.appwidget.action.APPWIDGET_CONFIGURE /
category
android:name=android.intent.category.DEFAULT /
/intent-filter
/activity
The Activity WidgetDummyConfiguration is called when the APK has been
downloaded from the market and run. It does nothing (literally) - the
onCreate() method has only two lines of code:
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
finish();
}
The .WidgetInstall Activity is referenced in the widget config file
pointed to in the Manifest:
appwidget-provider
xmlns:android=http://schemas.android.com/apk/res/android;
android:minWidth=294dp
android:minHeight=146dp
android:initialLayout=@layout/widget
android:configure= com.vacuumpunk.CDTBD2012.WidgetInstall
/
When the user installs the Widget on the home screen, the
Activity .WidgetInstall is used and again it is invisible, but it does
do some setting up of default preferences and then just calls
finish(). That's to handle the bad use-cases that Android doesn't
handle so well.
My AppWidgetProvider then registers a PendingIntent on the click
listener for the RemoteView which fires up the third activity
(.WidgetConfiguration) which is the business part of the UI behind the
widget.
I guess what you mean is that the system must first run the invisible
do-nothing activity of .WidgetDummyInstall in order for the manifest
contents to be registered with the system which then means the Widget
will be entered into the list of available Widgets?
In my production code I actually present a basic dialog when the App
is run that explains how to install the Widget and then exits. The
user can only access my App's functionality via a home screen Widget.
On Feb 3, 8:42 am, Mark Murphy mmur...@commonsware.com wrote:
On Thu, Feb 2, 2012 at 7:32 PM, David Ross grand...@vacuumpunk.com wrote:
Are you saying that does not work?
It should not work, because the user can't add the app widget to bring
up the configuration activity in the first place. The app widget does
not appear in the launcher until the user has done something to bring
your app out of the stopped state, such as launching an activity of
yours from the launcher.
It appears as though a reboot might also allow the app widget to show
in the launcher, though I have not played with this scenario. A reboot
definitely does not generally allow stopped apps to respond to
broadcasts, though.
--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
_The Busy Coder's Guide to *Advanced* Android Development_ Version 2.4
Available!
--
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: running UI thread with AppWidgetProvider class
Actually the Widget uses a RemoteView and you service that view in an AppWidgetProvider which must register one or more BroadcastReceivers to handle calls from the AppWidgetManager for updated views or your own events (through Intents). The Activity is only used for the optional configuration code that is run when the user installs the widget in the home screen but after that Activity finishes the system's AppWidgetManager activates your BroadcastReceivers. You can do things like register a click listener for the RemoteView that will invoke either the same config Activity or another Activity that provides perhaps extended functionality for the App. If you want to do something like update the Widget at regular intervals you must implement your own timer using the AlarmManager with a PendingIntent and a BroadcastReceiver to handle the event when the alarm is triggered. Best to keep your own record of the RemoteView to be updated for each appWidgetId so that your private internal BroadcastReceivers can update it. You can use the AppWidgetManager.updateAppWidget() at any time not just when you get the ACTION_UPDATE intent. Read the documentation: http://developer.android.com/guide/topics/appwidgets/index.html On Feb 2, 12:03 am, TreKing treking...@gmail.com wrote: On Wed, Feb 1, 2012 at 4:08 AM, surabhi jain surabhi17.j...@gmail.comwrote: I want to run UI thread with widget without using activity class. OK. And ... ?http://www.catb.org/~esr/faqs/smart-questions.html Plz help me. Plz spell please correctly. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Home screed Widget crash
I would suggest using AlarmManager for your repeating 15s update. Handle the Intent in a private BroadcastReceiver inside your AppWidgetProvider. Forget the Service as the scheduling mechanism but use it for the download of the next image from within your BroadcastReceiver. In BroadcastReceiver also (re)set the next alarm in AlarmManager to give the forever 15s repeat. Services can be killed basically at any time unless they are bound to a Notification but who wants a Notification if the Widget is on the screen already? Check your log, you might find the system is killing the Service. Then, handle Screen On/Off Intents so you only do your downloads when the screen is on. On Feb 1, 5:27 am, String sterling.ud...@googlemail.com wrote: The failed binder transaction issue basically happens whenever you send data too fast to an AppWidget, where too fast is loosely defined. You can definitely cause it by sending 1MB at once, but you can also get it by sending much smaller quantities at too fast a rate. Which is what it sounds like you're doing. Your best solution is probably to create a content provider and have your widget access that directly for the images, which will avoid the RemoteViews (and thus the binder which is causing the problem). A Google search for *image content provider* should get you started. Having said all that, updating an AppWidget with an image every 15 seconds sounds like a recipe for battery drain. You might want to test that hypothesis, see how bad the power drain is before you go to the trouble of re-implementing the image delivery mechanism. You may need to rethink your concept at a deeper level instead. String -- 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] Southern Hemisphere Developer Labs
I tried to find somewhere to make contact with someone from the ADL group but failed, this is the closest thing I could find. Can someone please explain why the Labs in Melbourne and Sydney have only 48 hr confirmation for attendance? I registered now twice (other than one brief HTML page there is no confirmation that my registration has been received, no email, nothing) and I have no idea if I will be accepted by the Googliers. My big grumble is that 48 hours confirmations is just plain obnoxious. What if you live on Brisbane, Adelaide or, heaven forbid, Perth? Yeah, people from Adelaide can just drive the four hours and stay at their aunty's place, but people from Brisbane and Perth have to make flight bookings, hotel bookings, maybe a hire car (the ADL announcement did not even give details like where it will be or how much it costs) and doing that on 48 hr notice is almost impossible and certainly the most expensive. Please Googliers, think about some common business courtesy for people who ulimately make Android the success Google wants it to be. -- 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 remove widget when the app is uninstalled in Android?
This is a design bug as far as I am concerned. There seems to be nothing you can do about it except let the poor phone user drag the toast to the trash can. I think you can listen for an Intent PACKAGE_UNINSTALL and then check to see if it is actually a reinstall for a new version, but there is no way to programatically remove the widget from the home screen. A related problem use-case is when the user does the CLEAR DATA option. This seems to be like an uninstall without actually removing the APK. The intention is that it is like taking the App back to the just installed state, but if the App is actually an active home screen widget then it just causes chaos. The widget remains, but any shared preferences and any registered receivers are removed. I call that a ghost widget. At least the user can drag it to the trash can. (Ghost Widgets occur also from things like a power off/on cycle when the widget config app is running and in pre 2.1 OS if the user tries to install the widget on a home screen with not enough space to fit the widget. Some ghosts are in the eye of the OS (it thinks the widget exists but it doesn't), others are in the eye of the App, but in all cases there is no functioning widget.) On Aug 11, 11:14 am, angel999 lehuy...@gmail.com wrote: In Android, I have created awidgetfor my application. When I uninstall the app, thewidgetshows problemloadingwidget error in home screen. I need a scenario wherewidgetshould be removed by the developer through code (and not by the drag and drop to the trash) when I uninstall the app. Is it possible? If so, what changes we need to do? Is there anything that can be set in the manifest so that it removes all references of the app once it is uninstalled? Please help me solve thisproblem. Thanks. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
