We have moved to a new Sailfish OS Forum. Please start new discussions there.
9

Does Sailfish offer APIs for battery, installed apps enumeration, WiFi and cellular info, etc?

asked 2016-06-10 22:30:19 +0300

Fiery gravatar image

updated 2016-08-17 10:50:38 +0300

jiit gravatar image

I'm in the progress of porting my existing 'droid app as a native Sailfish QML + QT5 C++ app. I've tried to find a native Sailfish or QT5 API for the following goals, but without a luck so far. As far as I understand, QtMobility is phased out, and QtSystemInfo it not yet implemented. Am I out of luck, or are there some tricks or special ways to achieve these?

  • battery properties detection, like current battery charge level, battery temperature (alternative to the green robot OS' BatteryManager)
  • installed apps enumeration (alternative to PackageManager.getInstalledPackages)
  • WiFi network and connection detection, like SSID, RSSI (alternative to WifiManager)
  • cellular network and connection properties, like SIM state, network operator code (alternative to TelephonyManager)
  • detection of inserted SD-card state, capacity, available space

Thank you :-)

edit retag flag offensive close delete

Comments

maybe not everything have such high-level apis, but there are many ways to get that info from device.

coderus ( 2016-06-11 11:58:41 +0300 )edit

Thank you for your reply. Other than poking into /sys/class or /proc, and sadly only finding a subset of the required readings, what other ways would there be to find those information? Especially the list of installed Sailfish apps, which seems to be a really head-scratcher.

Fiery ( 2016-06-11 15:16:07 +0300 )edit

learn packagekit api :)

coderus ( 2016-06-11 21:27:42 +0300 )edit

I'ld write such an app in Python using all the fine tolls provided there. Most of the stuff you want to access is covered by the psutil package.

Eierkopp ( 2016-06-12 12:05:11 +0300 )edit

Thank you for your tips. I'm still hoping (one day, in the future) to see a high-level API, since packagekit, dbus and python all sound too quirky and not generic enough.

Fiery ( 2016-06-12 23:03:42 +0300 )edit

2 Answers

Sort by » oldest newest most voted
6

answered 2016-06-11 00:45:11 +0300

hoschi gravatar image

updated 2016-06-13 19:23:14 +0300

Sounds rough, but tools like lscpu (maybe the famous lspci and lsusb, too) use just the files offered by /sys, /proc or /run. In case of battery-infos everything is available below /sys/class/power/supply/ as simple file. I use that files sinces years for a simple shell-script, which tells me my current battery-percentage. The files exist for us, that is easy and generic.

This is a UNIX, everything is a file. Actually this is the API. Otherwise here is the API from the kernel: https://www.kernel.org/doc/Documentation/power/power_supply_class.txt

// edit
Did anyone called for UPower? Includes DBUS-API, command-line utility and maybe abstracts away the differences (to some degree)? https://upower.freedesktop.org/

edit flag offensive delete publish link more

Comments

Thank you for your reply. I'm aware of the kernel files, that's where I have to extract a lot of other information, like CPU type, CPU clock, uptime, etc. The problem is: I can't seem to find standard ways to do that for the list of issues above in my OP. /sys/class/power_supply is a great resource, but sadly it's not fully standardized at all. You cannot really rely on it, unless you tailor it to every device out there, basically one by one. E.g. the battery readings are in /sys/class/power_supply/battery on the Jolla Phone, but they are in /sys/class/power_supply/dollar_cove_battery on the Jolla Tablet. It's even worse, and even less usable when it comes to detecting the power source (USB port vs. A/C charger vs. battery). It would be miles easier if there was a standard battery API in SFOS.

As for e.g. WiFi detection, I cannot seem to find most of the necessary details under /sys/class/net/wlan0. And obviously, the kernel filesystem wouldn't help when it comes to enumerating installed Sailfish apps :-(

Fiery ( 2016-06-11 15:24:22 +0300 )edit

I understand your point and think your right, on GNOME you will find probably a API inside GNOME-POWER-MANAGER or a DBUS-API. I bet, if they implement something similiar on SailfishOS the will use DBUS. The changing nature of /sys comes from the different hardware out there and that it is a low-level API. As for now, you just need support two or three devices (depending if you count Jolla C or the Tablet), which is doable. But if SailfishOS really succeed in future you could have more work. It seems that the most batteries just flips between Charge (Ampere) and Energy (Watt). The kernel documentation mentions, that no libbattery or batteryd exists.

// edit

But upower exists! And it is installed already on my phone. I'm not sure, but does it abstract the differences away? It also offers an DBus-API or via command-line:
upower -e + upower -i /org/free...

hoschi ( 2016-06-11 20:31:24 +0300 )edit

Thanks, I'll check UPower. The problem is: the lack of battery API is the smallest issue I'm facing. Using some tricks it's quite possible to live with the /sys/class/power_supply solution, at least until Sailfish really takes off and the market gets flooded with devices :) That would generate more awareness from developers, an expanded developer team at Jolla, and hopefully that would trigger them to add more hardware APIs to the OS. Fingers crossed.

Fiery ( 2016-06-12 23:07:17 +0300 )edit
4

answered 2016-06-14 01:46:47 +0300

chemist gravatar image

SFOS utilizes statefs https://git.merproject.org/mer-core/statefs

edit flag offensive delete publish link more

Comments

Very interesting, thank you! Now that I've quickly gone through the list of modules in Mer... Can a SFOS app use any of those modules, e.g. ofono, upower? Is it guaranteed that those modules would stay as part of SFOS in the future too?

Fiery ( 2016-06-14 08:33:35 +0300 )edit
2

@Fiery: It is supposed to work the other way around: Modules can come and go, statefs provides a stable api. For example upowerd & related statefs modules were dropped and battery data is now obtained from udev - but apps / interfaces that use data provided by statefs work just as before.

spiiroin ( 2016-06-14 09:40:11 +0300 )edit
1

Is there any description of stateFS provided namespaces? For example, what are the units of the provided values in /run/state/namespaces/Battery/TimeUntilFull ? I presume its seconds, but would be good to see some docs on it

rinigus ( 2016-06-14 10:46:38 +0300 )edit

At least at the old repo of statefs there is some docs left: https://nemomobile.github.io/statefs/index.html

inta ( 2016-06-14 11:59:11 +0300 )edit

For the what is what https://git.merproject.org/mer-core/statefs-providers/tree/master/inout helps, for what value that is it is probably depending on what the software you extract info for is handling. So if bme handles everything in seconds, statefs will show seconds unless some fancy dev did add some math before hand.

chemist ( 2016-06-14 12:08:37 +0300 )edit
Login/Signup to Answer

Question tools

Follow
5 followers

Stats

Asked: 2016-06-10 22:30:19 +0300

Seen: 1,013 times

Last updated: Jun 14 '16