KService as a platform abstraction framework?

Volker Krause vkrause at kde.org
Sat Jul 3 09:25:12 BST 2021


while looking at implementing a pretty straightforward KApplicationTrader/
KIO::ApplicationLauncherJob use ([1]) for Android, I found myself wondering 
whether we should have an Android backend for KService.

KService conceptually matches android.content.pm.PackageManager/PackageInfo 
[2, 3], ie. the platform API to list installed applications and their 
respective features (essentially what's in the Android manifest XML files). In 
detail it however is full of .desktop file specifics, and leaks platform 
implementation details (e.g. KService inheriting from sycoca types).

KIO::ApplicationLauncherJob is also something that makes sense conceptually on 
Android, implemented on top of Intents there.

Has anyone thought about/looked into using KService as platform abstraction 
rather than as an functional/platform implementation framework already? I 
could imagine this to also be relevant on Windows.

Is anyone aware of a current use on Android relying on the .desktop based 
implementation of KService? That might be theoretically possible, unlike for 

And while retrofitting platform abstraction support into KService wont be 
pretty, the alternative approaches (a new abstraction framework on top, or let 
applications deal with that with platform-specific code paths) aren't exactly 
convincing either.



[1] https://invent.kde.org/plasma-mobile/qrca/-/merge_requests/35
[2] https://developer.android.com/reference/android/content/pm/PackageManager
[3] https://developer.android.com/reference/android/content/pm/PackageInfo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20210703/cbc0eb15/attachment.sig>

More information about the Kde-frameworks-devel mailing list