Application classes
Status. Native
.debapps and Flatpak apps run today. Android packages run through rustdroid without a sandbox of their own yet. The local-executable launcher and the AppArmor confinement that makes it the only door are designed, not built.
Eydos runs three kinds of application, plus a fourth case for code that is none of them. They share one permission system, one consent dialog and one settings page, so from the user’s point of view there is only one kind.
| Native | Flatpak | Android | Local executable | |
|---|---|---|---|---|
| Packaging | .deb, part of the system | Flatpak, from the Eydos repository or Flathub | APK, from the Eydos repository or F-Droid | None: a binary or script on disk |
| Who ships it | Eydos | Anyone | Anyone | The user |
| Identity | AppArmor label | App id from /.flatpak-info | Package name | App id generated by the launcher |
| Confinement | System profile | bwrap sandbox | rustdroid, later bwrap | bwrap sandbox created at launch |
| Permissions | Portals through ltk | Portals | Android API mapped to the portals | Portals |
| Updated by | apt, with the system | Flatpak, independently | The app store, independently | Not managed |
Native applications
First-party apps such as Settings, Calls and Contacts are built with ltk and shipped as Debian packages. They are part of the system and trusted like it, in the same way preinstalled apps are trusted on Android. They still call the portals for anything a sandboxed app would, so that app code is the same whether it is confined or not; the sandbox provides the security, the API stays uniform.
Third-party .deb apps are not an application class. Eydos does not offer them a way in: third parties ship Flatpaks. A user who roots the device can install whatever they like, and takes the system out of the supported configuration by doing so.
Flatpak applications
Flatpak is the packaging for native Linux applications from third parties. Each app runs in its own bwrap sandbox with the identity Flatpak gives it, and everything it needs from outside the sandbox goes through the portals. Eydos adds nothing to Flatpak’s model beyond the consent dialog: camera, location, background activity and notifications prompt the user and the answer persists. Static permissions from the app’s manifest are shown in Settings and can be overridden there.
Android applications
Android packages run through rustdroid, which hosts an Android runtime on Linux and draws the app with ltk. The Android permission API is mapped onto the same portals and the same decision store as everything else, with Android’s own semantics preserved: normal permissions granted at install, dangerous ones asked per group, denials remembered. Its sandbox is the part still to come; until then, permission checks bind the Android API but not native libraries an APK may carry.
Local executables
A binary someone downloaded, a script written in an editor, a program compiled in the terminal: none of these has an identity, so the permission system has nobody to ask about. Rather than run them unconfined or refuse them outright, Eydos turns them into an application at launch. The system launcher, eydos-run, creates a bwrap sandbox with a generated app id, hands it the Wayland socket and a filtered session bus, and starts the program inside. From then on it is a Flatpak-like app: the portals prompt for it, its decisions are stored under its id, and it appears in Settings under local apps.
What makes this a barrier rather than a convention is that the launcher is the only door: the shell, the file manager and the confined terminal cannot execute anything outside the system themselves. The security model page explains how.