Marking as "Won't Fix" for qtsystems-opensource-src since there is now a connectivity-api that apps can use.
** Changed in: qtsystems-opensource-src (Ubuntu Trusty) Status: Confirmed => Won't Fix ** Changed in: qtsystems-opensource-src (Ubuntu) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtsystems-opensource-src in Ubuntu. https://bugs.launchpad.net/bugs/1226844 Title: QtSystemInfo fails when using ofono and there are DBus denials to ofono Status in “qtsystems-opensource-src” package in Ubuntu: Won't Fix Status in “qtsystems-opensource-src” source package in Saucy: Won't Fix Status in “qtsystems-opensource-src” source package in Trusty: Won't Fix Bug description: = Background = Applications in the Ubuntu appstore are packaged as click packages and run under confinement. Applications sometimes need to know if they are connected to the internet, on an expensive connection or disconnected. QtSystemInfo::NetworkInfo (via qtdeclarative5-systeminfo-plugin) provides this information to QML applications. Attached is a simple QML application to test this and an apparmor profile. Save the qml file as /tmp/test-network.qml and the apparmor profile as /tmp/profile. In one terminal, run: $ tail -f /var/log/syslog | grep DEN In another, run: $ sudo apparmor_parser -r /tmp/profile && aa-exec -p test-network -- qmlscene /tmp/test-network.qml On a desktop system, the application should say that it is connected to the home network (or similar) and there will be no apparmor denials for NetworkManager (there will be one for GConf, but that can be ignored). On a system with a working ofono (eg, Nexus 4 with up to date Ubuntu Touch), this the application will report an error. For the error to go away, the following ofono rules must be added to the apparmor profile: # ofono dbus (send) bus=system path=/ interface=org.ofono.Manager member=GetModems peer=(name=org.ofono), dbus (send) bus=system path=/ril_* interface=org.ofono.NetworkRegistration member=GetProperties peer=(name=org.ofono), dbus (receive) bus=system path=/ril_* interface=org.ofono.NetworkRegistration member=PropertyChanged peer=(name=org.freedesktop.DBus), Then rerun 'sudo apparmor_parser -r /tmp/profile && aa-exec -p test- network -- qmlscene /tmp/test-network.qml' and the application works correctly. Unfortunately, giving access to org.ofono.NetworkRegistration.GetProperties reveals far too much information to confined applications. On the desktop system, /proc and /sys entries are consulted to see if online, but on a system with ofono, this is not enough. Ideally we would provide a simple dbus service (I think 'uconnectd' would be a great name-- feel free to use it ;) with methods like OnlineWired, OnlineWireless and OnlineCostlyNetwork. This dbus service would consult network manager and ofono, we could declare a simple QML plugin as the correct way to check for connectivity. Right now, apparmor policy (correctly) denies access to ofono over DBus, but applications are unable to determine if they are on the network using standard APIs. To fix this in the short term, we can adjust to use what is in /proc and /sys and not throw an error if it gets an apparmor denial. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1226844/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp