Anbox nutzt LXC anstatt systemd-nspawn, ansonsten machen die schon das Gleiche. SPURV scheint leichtgewichtiger und könnte sich damit etwa für das Librem 5 eignen.
Den Container in dem Android läuft, stellt in diesem Fall systemd-nspawn. Damit sind Vor- und Nachteile verbunden. Einer der Vorteile ist laut der Erläuterung im Collabora-Blog die strikte Isolation der Android-Apps durch den Container. Die Nachteile beziehen sich auf den Hardwarezugriff und die Leistung. Alle Hardwarezugriffe, die von Android benötigt werden, müssen an den Container übergeben werden. Neben dem Aufwand der manuellen Konfiguration eines solchen Zugriffs über systemd-nspawn kann sich die doppelte Belastung der Hardware durch zwei Betriebssysteme nachteilig auf die Leistung auswirken.
systemd-nspawn wird hier ja als echtes Schwergewicht im Containerbereich dargestellt. ;) Aber eigentlich ist systemd-nspawn nichts anderes als ein aufgepumptes chroot mit ein bisschen Isolation und mehr sollte es laut Lennart Poettering auch nie sein/werden (sagte er mehrfach in Interviews und Vorträgen). z. B. Systemd-Nspawn is Chroot on Steroids - Lennart Poettering, Red Hat
Wenn hier also etwas als Performance-Bremse unterwegs ist dann wohl eher die im "Container" enthaltenen Abstraktionsschichten.
Das Anbox Projekt bietet das auch schon recht lange. https://github.com/anbox/anbox
Würde mich wundern wenn man sich daran nicht bedient hätte.
Anbox nutzt LXC anstatt systemd-nspawn, ansonsten machen die schon das Gleiche. SPURV scheint leichtgewichtiger und könnte sich damit etwa für das Librem 5 eignen.
Aber eigentlich ist systemd-nspawn nichts anderes als ein aufgepumptes chroot mit ein bisschen Isolation und mehr sollte es laut Lennart Poettering auch nie sein/werden (sagte er mehrfach in Interviews und Vorträgen).
z. B. Systemd-Nspawn is Chroot on Steroids - Lennart Poettering, Red Hat
Wenn hier also etwas als Performance-Bremse unterwegs ist dann wohl eher die im "Container" enthaltenen Abstraktionsschichten.