Update downloads hang when connection changes

[Lorn Potter]

Downloads that use QNetworkRequest will seemingly hang when the connection changes from mobile data to wifi and vice versa.

It would be nice if they would resume when the connection switch is completed.

This requires changes in the bearer backend to enable forced session roaming, as well as some changes in QNAM.

[Tony Espy (awe)]

@ Lorn

Could you add the qtbase-opernsource-src version # this bug applies to?

Also what are the steps to reproduce ( test program? running system-settings updates? download-mgr? )?

You mentioned test tools / test plans in the trello board. Could you add a link here?

Also, what's the current status? Are all the blockers resolved, or are you still chasing the open issues you mentioned yesterday in trello?

[Lorn Potter (lorn-potter)]

The test app I wrote that downloads big file:
https://code.launchpad.net/~lorn-potter/+git/test-servicenetwork
Of course, this runs from commandline so is uncontained.

Steps to reproduce:
Landing for testing:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-060

* open system settings->update
* when there is a larger update available, start the download.
* turn off wifi or walk from wifi zone

Known issues:

1. Euronews, Engadget and Today scope to not ever see network
2. Occasionally update check will hang when changing network device(wifi -> 3g)
3. Occasionally update download will not resume properly when network change.

I am fairly certain that #1 can only be fixed by moving QtBearer plugin to connectivity-api, although I do not see any apparmor denials in the log, with this change it makes QNetworkRequest require a QNetworkSession, which in turn I believe fails as the known and unfixable QtNetwork network-manager backend issues with apparmor. I am assuming that scopes run in contained space, because other commandline based tests with QtNetworking access work, but Click apps that use QtNetworking fail similarly.

#2 and #3 most likely will continue to occur as I believe they are timing issues with the actual network process and the linux networking subsystem does not migrate the actual data/sockets and behave like the Symbian networking backend (which this feature was originally written for) to have seamless network transitions/migration.

[Lorn Potter (lorn-potter)]

It seems Today scope sometimes behaves...

[Scott Sweeny (ssweeny)]

IIRC the Today scope doesn't make any network calls itself, but farms the queries out to the child scopes.

[Lorn Potter (lorn-potter)]

Dug into system-update and it seems it does not use QNetwork to download, but some python script (system-image) com.canonical.SystemImage so resuming the download may or may not work.

IN my testing it seems to work sometimes, but other times, it will stop with an installation error.