Enabling/disableing receiver (CONNECTIVITY_CHANGE) causes APPWIDGET_UPDATE broadcast

Question

I have a receiver listening for android.net.conn.CONNECTIVITY_CHANGE so that I can update my appwidget when connectivity is restored. This works fine except I am getting some strange behavior when I enable or disabled my receiver via:

ComponentName receiver = new ComponentName(this, NetworkStateReceiver.class);
PackageManager pm = getPackageManager();
pm.setComponentEnabledSetting(receiver, PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
        PackageManager.DONT_KILL_APP);

When the state is changed I also receive an android.appwidget.action.APPWIDGET_UPDATE broadcast to my appwidget's receiver causing my appwidget to update again after detecting connectivity lost, and then twice when connectivity is returned (Once intentionally from my NetworkStateReceiver and then again from the APPWIDGET_UPDATE broadcast).

Also, this only seems to happen on my 4.04 device and not on my 2.1 device.

Manifest for NetworkStateReceiver and AppWidgetProvider

    <receiver
        android:name=".AppWidgetProvider"
        android:label="@string/widget_name" >
        <intent-filter>
            <action android:name="android.appwidget.action.APPWIDGET_UPDATE" />
        </intent-filter>

        <meta-data
            android:name="android.appwidget.provider"
            android:resource="@xml/appwidget" />
    </receiver>
    <receiver 
        android:name=".NetworkStateReceiver" 
        android:enabled="false">
        <intent-filter>
            <action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
        </intent-filter>
    </receiver>

I have tried a few ways to work around this, but none are very good solutions.

I can ignore any update from an APPWIDGET_UPDATE broadcast. Actually I do this already since all my appwidget updating happens through a service via an alarm manager or config activity when first created. For some reasons though (and perhaps indicative of whats going on), the APPWIDGET_UPDATE broadcast also causes my remoteviews to revert back to its XML state like its been added for the first time. I could probably work around that too by saving extra state, which would include bitmaps. Not ideal.

I could have the NetworkStateReceiver listen all the time instead of enableing/disabling, but this goes against Android's recommendations and for good reasons since it means unnecessary broadcasts.

Other ideas?

EDIT: Further explanation of my current workaround.

I can't ignore the APPWIDGET_UPDATE broadcast even though I use alarms to trigger my updates. This is because the APPWIDGET_UPDATE also resets my widget to its initial state like its been added to the homescreen for the first time. In cases where I have a connection I can do double updates because all the info can be re-populated. I also still have to do my own update since the bug seems device specific and non-affected devices still need an update.

In cases where I do not have connectivity, I then restore the widget from earlier saved state. This means that every time I do a successful update, I also save everything to SharedPreferences so it can be restored under one of these "forced updates" when internet isn't available to properly re-populate the data.

In my AppWidgetProvider I do (simplified):

Intent intent = new Intent(context, WidgetUpdateService.class);
intent.putExtra("loadFromSaved", true);   // this will be false when coming from AlarmManager
context.startService(intent);

WidgetUpdateService.onStartCommand() (also simplified):

if (intent.getExtras().getBoolean("loadFromSaved") {
    widgetLoader.loadFromSavedData();
} else {
    widgetLoader.load()
}

Answer 1

So, if I've understood correctly, there are two distinct things going on:

1. When network state change notificiation is enabled you are getting extra ACTION_APPWIDGET_UPDATE broadcasts to your AppWidgetProvider.

   Whilst this isn't as one would expect (although I can imagine a coded thinking that widgets would want to update themselves when the network state changes), it isn't outside the defined behaviour of the android system, and so our code needs to be robust to arbitrary ACTION_WIDGET_UPDATE calls. Keeping track of the appWidgetId list and the latest state of each widget on that list is a common way to identify new widgets and immediately required updates, whilst leaving other updating to timer mechanisms.

2. As you put it: even if the update does nothing the problem still occurs.

   If your onUpdate does nothing, then this means that the re-initialisation has nothing to do with the ACTION_WIDGET_UPDATE. Somewhere, somehow, your code to initialise is being called when you don't expect it to. Now, this is a pain, especially if there's no code reason this should be so. However, I, and others, have experienced this, so I point you two:

   • My list of things that helped: Service being re-Created by AlarmManager
   • A brief discussion and solution for services being started unexpectedly (which, in the case of services managing widgets, often means that they are re-initialised): Android service onCreate is called multiple times without calling onDestroy

When faced with the issue myself, I spent a lot of time putting Log statements in my code to see which parts of my code were called when, and it became clear that the system was restarting my service for no defined reason, but that this was solved as described in those two links. If I had to pick one thing I think was the key, it was running the Service in a separate process to the other activities (including the AppWidgetProvider).