API Documentation

Documentation for developing SailfishOS applications

Sailfish OS MDM Framework

Mobile device management (MDM) is an important requirement for many use cases, allowing the functionality of a particular device or fleet of devices to be restricted or controlled in a variety of ways or in response to certain events (e.g. in the case of a lost or stolen device).

Sailfish OS provides the Sailfish OS MDM Framework to allow permitted MDM applications to apply restrictive policies or to manually enable, disable, or trigger specific functionality on the device.

Disclaimer! The 2nd party API provided by MDM Framework is still in active development and to some extent subject to change. Normal 3rd party API backward compatibility promises don't hold. Follow Together Jolla release notes and Sailfish OS Developers mailing list to get notified of API changes.

Using the Sailfish OS MDM Framework

There are two separate facets to the Sailfish OS MDM Framework. The first facet consists of policies which define whether the user can modify certain settings or access certain functionality, and is provided by libsailfishpolicy. The second facet consists of specific system functionality which is offered to MDM applications but may or may not be available via other system APIs, and this functionality is provided by libsailfishmdm.

To use these libraries, the MDM application should use the pkgconfig files "sailfishpolicy.pc" and "sailfishmdm.pc" respectively.

e.g. in a qmake-based project:

 CONFIG += link_pkgconfig
 PKGCONFIG += sailfishpolicy sailfishmdm

The APIs are intended to be executed as sailfish-mdm user. As an exception policy state reading with Sailfish OS Policy API can be done with any user.

Sailfish OS Policy API

The Sailfish OS Policy API allows the MDM application to write the current policies defined for specific settings or functionality. For example, the MDM application may want to prevent the user from changing the GPS settings.

See the Sailfish Policy documentation for further details.

Sailfish OS MDM API

The Sailfish OS MDM API allows an MDM application to perform specific actions or trigger specific functionality on the device. For example the MDM application may want to turn on the GPS device so that it can track the current location of the device.

A wide variety of system functionality is offered via the Sailfish OS MDM API, encapsulated by the following classes:


API to provision accounts


Information on installed applications and packages


Controls auto-starting of applications


Retrieves information about base stations. To use this class, clients must add the following to their qmake project:


Battery charge information


Access to phone call history


Access to phone call statistics


Manages system CA certificates


Controls network connectivity


Controls the system date and time


Controls security codes and device locking


Device location data


Controls device positioning features


Controls the network proxy servers in use


Monitors network data usage


Creates user-visible notifications


Controls the installation of insecure software


Access to SIM card information


Controls filter rules for mobile data


Controls access to SMS features


Controls access to voice-call features


Access to sms history


Triggers OS software updates


Access to device information


Manages system users. To use this class, clients must add the following to their qmake project:

WLAN provisioning and network access control is handled through Connman connection manager:

SSU can be configured through the SsuProxy D-Bus interface:

User management for shared device is handled through User Manager Daemon D-Bus interface:

Allowed API and Access

MDM applications are meant to be run with sailfish-mdm user, which means both extra permissions and also extra restrictions on what can be done.

First, there is no access to the user's files under /home/<user> nor D-Bus session bus. This includes also libraries on top of D-Bus such as notifications and dconf. Because of that, user notification support is provided separately by the MDM API.

Second, the MDM application is run on the background without a user-visible UI. If such is needed, there needs to be a separate UI application that communicates with the background daemon. For example, a system or p2p D-Bus can be used for that.

Some environments also require inet group to allow network access. Unlike regular user, sailfish-mdm doesn't belong to that group, thus if an MDM application needs to have access, it should have the group included on execution manually. It should be noted that other environments might not include such a group at all.

Creating an MDM Application

An example daemon MDM application and a client which connects to it has been provided, however it is recommended that vendors implement their own MDM application in order be compatible with their own existing services and IT infrastructure.

In most cases, the MDM application will be a fully-fledged, persistent system daemon, started on boot by Systemd, which links against and uses the Sailfish OS MDM Framework libraries directly. Those libraries provide interfaces to allow or disallow actions (via libsailfishpolicy), and other interfaces to allow changing the system state (via libsailfishmdm).

Starting the MDM Application with Systemd

To ensure that the MDM daemon application will be started by Systemd, the MDM application must include a file /usr/lib/systemd/system/mdm-application-name.service in the package and create a symbolic link to it under multi-user.target.wants, as the following example shows:

 Description=An MDM application
 Requires=basic.target network.target
 After=basic.target network.target



Automating startup on RPM packaging operations can be done on the .spec file as:

 mkdir -p %{buildroot}%{_unitdir}/multi-user.target.wants/
 ln -sf ../mdm-application-name.service %{buildroot}%{_unitdir}/multi-user.target.wants/

 if [ "$1" = "1" ]; then
   systemctl daemon-reload || :
   systemctl start mdm-application-name.service || :
 elif [ "$1" = "2" ]; then
   systemctl daemon-reload || :
   systemctl restart mdm-application-name.service || :

 if [ "$1" = "0" ]; then
   # remove
   systemctl daemon-reload || :
   systemctl stop mdm-application-name.service || :


MDM Application Files

Any configuration, cache or data files required by the MDM application can be stored under /var or /run as according to the Filesystem Hierarchy Standard, in MDM-application-specific subdirectories.

Specifically, cache data should be stored under /var/cache/, configuration, state data and databases should be stored under /var/lib/, lock files should be stored under /run/lock/, log files should be stored under /var/log/, and temporary files should be stored under /run/tmp/, in MDM-application-specific subdirectories.

We use cookies to improve your user experience and to help us to develop our services. By continuing to browse the site, you approve of our use of cookies.