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
