SweeterHome

OK, I wrote a big reply here and it disappeared so I'll try again.

Widget binding is a huge pain in the ass in Android. Forcing you to activate widgets on each theme means that widgets you're not using will not be running. This is currently set up in the Sweeter Home framework so can't be changed by net vs SD.

The dev has a bunch of issues around bad implementations in Android that he has written up and is lobbying Google/Android for changes...

EG:

Description

According to the documentation, it is possible for home screens to bind widget components to IDs without user intervention, if they are granted the APPWIDGET_LIST permission:

http://developer.android.com/reference/android/appwidget/AppWidgetManager.html#bindAppWidgetId(int,%20android.content.ComponentName)

In reality, the OS ignores this permission, and in fact the android source code does not even refer to it when binding a widget.

The source code seems to really require the BIND_APPWIDGET permission, and also seems to really require that the calling app be signed by the authority used to sign the Android OS core components. This means in effect regular apps on the market cannot bind widgets, unless they get google or a telco or whoever controls the keys to sign their app. My read of the source code here might be a little off, but at a minimum, the documented behavior of bindAppWidgetId does not work with any permission that documentation and/or source indicate should work.

I think it would be best to simply implement this permission as with other permissions and let users decide if they want to grant it or not. There does not seem to be any security risk here. The entire widget infrastructure could be easily re-implemented by a home screen so as not to require this permission, but doing that would require that widget authors use at least a trivially different widget API. Fragmenting the widget API space would be very bad for the android ecosystem. Not only would it be an inefficient and duplicative development effort, but it would confuse users and impose a bigger burden on widget authors. Also, it would increase the possibility of there being bugs or security vulnerabilities in the forked widget infrastructure code.

Ah. Thanks for the clarification, Lemon.

Its never easy is it? From a user point of view its always "Um, why doesn't this just work?"

But from the coder's point of view it's "There's no way this will work."

Hahaha. Well, luckily the appointment of Tim Bray to Developer Advocate was pretty timely - so I've made contact with him on the devs behalf and sent him a bunch of info that the SH dev had written up about poor implementation in Android.

Fingers crossed it makes some headway.

The private build I have right now has more widget memory changes - so you know the dev is trying to find that balance of performance versus memory that Android seems to be making quite difficult for this type of app.