Widgets don't survive power cycle

[creideiki]

HTC Wildfire with stock Android 2.2. Soundboard, all content packs and widget installed from the Market.

I can add sound-playing widgets to the home screen, and they work as expected until I turn the phone off. When it's turned back on, the widgets display as white squares with text:

• "Loading" forever (or at least several hours), if the soundboard application is stored on the SD card.
• "Error", if the soundboard application is stored on the phone.

Behaviour persists after re-installation of application, widget and content packs.

[TBBle]

Thankyou for the report. There's definitely something wrong with the Widgets, the same thing appears to happen sometimes on my new Motorola Milestone 3 (Running Motoblur) but never happened on my HTC Dream (Running an AOSP-based custom rom and Launcher2). I've also had a report of a similar problem (or the same problem, I suspect) with Go Launcher.

The root of the problem is that large parts of the widget-handling are done by the Launcher, not my code, so it's not an easy problem to solve. But I am looking at it, and hopefully will be able to produce a resolution soonish.

My first inclination is to make the widgets refresh every hour, rather than relying on a thread that runs until they are successfully created as I do now. That way at least, any problems during startup will be fixed an hour later, without putting too much load on the system.

I suspect that on some platforms the thread is being killed during the boot process due to low-memory as the launcher first starts up, but haven't been able to demonstrate this successfully yet.

However, I'm considering instead making the Widgets work more like the Ringtones, and actually take a copy of their icon and sound when they are created, rather than simply referencing the content pack. This would fix the other problem where uninstalling a content pack from which a widget has been created will cause the launcher to be killed as it's holding an icon reference.

However, this has potential to waste a fair bit of space as there's no notification when a widget is deleted, and no way I know of to ask a launcher what widgets it has, so there's no way to clean-up any files that a deleted widget was using.

So that solution needs more consideration and experimentation before I go with it. Perhaps the solution is to combine Soundboard Ringtones and Soundboard Widget into one application, since Soundboard Ringtones already has code for users to manage sound and icon copies.

[TBBle]

Sorry. "The root of the problem is obscured by the fact that large parts of the widget-handling are done by the Launcher...", I meant. The actual root of the problem I'm not yet sure of, but I think it's an interaction between the background widget code and the large content packs causing the low-memory killer to kill the widget thread before it finishes working. The widgets currently only get one shot at configuring themselves until the Launcher is restarted, and I suspect third-party Launchers (such as Motoblur's Launcher and Go Launcher) actually don't even ask the widget to reconfigure itself when they restart, but use a cached value.

I definitely saw Motoblur's Launcher reading cached values when I forced it to restart while I was expecting my widget's configure code to be run again.

[creideiki]

I suspect that on some platforms the thread is being killed during the boot process due to low-memory as the launcher first starts up, but haven't been able to demonstrate this successfully yet.

After closely observing my phone's 3-minute (!!!) boot process a couple of times, I have seen a sign of something, but I don't know what. A system dialog box (like the one I get when an application doesn't respond) popped up saying "Sorry! The application Soundboard Widget [...]" and then a wall of text I didn't have time to read before the box disappeared half a second later. I have not seen this box before (but I don't usually spend the whole 3 minutes starting at the phone screen), nor in the five reboots since.

[TBBle]

Hmm, sounds like a crash rather than being killed for not responding. Drat.

Still, that's given me something to go on. Doesn't look like it generated a crash log in the Android Market publisher interface though. Or if it did, the crash actually happened somewhere else and it was just propagating an SQL error.

I have to say that I need to get the content-pack issues fixed first, as it's possible they are causing this issue -- content packs have threading bugs which I need to upload fixes for,and having multiple widgets is easiest path that seems likely to trigger the threading bugs.