Ignoring thw broadcast if its not for the main widget host, or if
the Launcher DB is already in use. Launcher already handles missing
widget-Id map broadcast, by binding a new widgetId at runtime.
Bug: 63389280
Change-Id: Iaa9774d6d7adde3711cba9615328020e2b2e66aa
Instead of maintaining 3 different states, each tied to a subset of data,
maintaing a single state that represents all the data. Individual subset
data is invalidated in rare cases and these invalidates are tightly tied
to the UI. This also allows us to add new data to the model, without worring
about classifying the data into a subset.
Bug: 34112546
Change-Id: Id9cb273de35b79e84a2ef8d6556fcf1e72fb4b75
> We are making the DB call (IO) on the UI thread which is costlier than
the AppWidgetHost call.
> The process can get killed after the broadcast receiver returns, which
can prevent these ids from getting deleted.
Change-Id: I47746cf03d0eae573b6baa25cde9e573fd1f1a60
> Show 'widget-not-ready' until the widget app is installed
> Once the app is installed, bind a new widget id (not required on L if
id-remap was received).
**Remove the widget if bind failed
> If the widget has no configuration screen, show the widget, otherwise
show 'setup-widget'.
> Clicking 'setup-widget' shows the config screen, and updates the
widget on RESULT_OK.
issue: 10779035
Change-Id: I2f8b06d09dd6acbc498cdd93edc59c26e5ce17af
When the app is restored, it displays placeholders for all pending widgets.
These placeholders can be moved and removed similar to a widget (size is fixed
to what defined in backup). Once the system notifies the launcher of the new
widget ids, the place holders are replaced with actual widgets.
issue: 10779035
Change-Id: I68cbe4da01e9ca2978cb4471a7c645d2aa592055
