Exécuter un véritable Linux avec systemd sur un smartphone via Droidspaces

Les anciens smartphones Android sont souvent transformés en serveurs domestiques, bots Telegram ou bancs de test locaux. Habituellement, cela se fait avec Termux et PRoot ou en bidouillant avec chroot. Mais ces approches présentent de sérieux inconvénients. PRoot intercepte chaque appel système via ptrace, ce qui ralentit les performances. Le chroot classique n'isole que le système de fichiers, laissant l'arborescence des processus et les réseaux partagés avec l'hôte. Et surtout, faire tourner un systemd complet comme PID 1 sur Android a toujours été une tâche ardue en raison des cgroups, SELinux et du tueur de mémoire LMK d'Android.

Le projet Droidspaces du développeur ravindu644 offre une solution différente. C'est un binaire d'environ 400 Ko, compilé avec musl libc. Il utilise les namespaces du noyau Linux standard et lance des conteneurs isolés avec une véritable initialisation, une accélération graphique et du réseau.

En quoi Droidspaces diffère des alternatives

Contrairement aux piles LXC ou Docker lourdes fonctionnant au-dessus de Termux, Droidspaces fonctionne directement avec le noyau. Il n'a aucune dépendance externe. Si le noyau du système prend en charge les namespaces, l'outil fonctionnera même dans l'environnement de récupération Android (Recovery ou Ramdisk).

Comparons Droidspaces avec les outils familiers :

• Dans PRoot, chaque appel système subit un délai. Ici, le conteneur s'exécute nativement.
• Le chroot classique échoue sur une simple commande de visualisation des processus. Droidspaces fournit une isolation honnête de PID, MNT, UTS, IPC et Cgroup.
• Le tueur de processus d'arrière-plan d'Android ferme souvent Termux avec tous les services. Droidspaces se détache de la session d'application via setsid et vit dans un démon d'arrière-plan.
• Si vous supprimez l'application Android, les conteneurs en cours d'exécution dans /data/local/Droidspaces continueront à fonctionner, les données ne seront pas perdues.

Graphisme, son et réseau sans configuration manuelle

Depuis la version 6.x, l'utilitaire peut transmettre lui-même les graphiques et l'audio. Si vous avez besoin de XFCE ou d'un autre environnement de bureau, vous n'aurez pas à configurer manuellement les variables d'environnement et à démarrer des serveurs dans Termux.

Lorsque les commutateurs correspondants sont activés, l'utilitaire démarre automatiquement Termux:X11, VirGL et PulseAudio. À l'intérieur du conteneur, les variables DISPLAY=:5 et GALLIUM_DRIVER=virpipe sont automatiquement définies. Pour les GPU Qualcomm Adreno, le pilote Turnip avec le pass-through GPU direct est disponible.

Quatre modes réseau sont pris en charge :

• Host (réseau partagé avec l'appareil)
• NAT (réseau isolé avec détection automatique de l'interface et transfert de port)
• None (isolation réseau complète)
• Gateway (délégation du routage vers un autre conteneur, par exemple avec OpenWRT)

Gestion et travail avec le code

Une interface graphique pratique a été créée pour Android en Kotlin. Elle configure les points de montage, alloue les ressources matérielles, transfère les ports et affiche les journaux de démarrage systemd.

Sur un Linux de bureau ou via SSH, l'appareil est géré via un utilitaire en ligne de commande :

# Проверка готовности ядра
sudo ./droidspaces check

# Запуск контейнера с файлом конфигурации
sudo ./droidspaces start ubuntu --conf /path/to/ubuntu.config

# Вход в консоль запущенного контейнера
sudo ./droidspaces enter ubuntu

Si vous avez besoin de tester des logiciels sans risquer d'endommager le système de fichiers, le mode Volatile est utile. Il utilise OverlayFS, stocke toutes les modifications en RAM et les supprime immédiatement après l'arrêt.

Exigences du noyau et nuances de sécurité

Sans droits root, aucune magie ne se produira. L'outil a besoin de Root (KernelSU, Magisk ou APatch) et d'un noyau version 3.10 ou supérieure.

Sur les anciens noyaux (3.10–4.19), vous devez dealt with Android specifics. En raison des conflits de chiffrement FBE et des particularités du VFS, des blocages du noyau se produisent parfois. L'auteur a fourni un commutateur Deadlock Shield et des filtres BPF. Si vous désactivez la protection, vous pouvez même exécuter Docker à l'intérieur de Droidspaces (conteneurs imbriqués). Sur les noyaux GKI modernes (5.4+), toutes les fonctions sont disponibles prête à l'emploi.

Une note de sécurité importante : Droidspaces a été créé pour les passionnés et ne fonctionne pas comme un bac à sable strict. Les processus à l'intérieur du conteneur avec des privilèges root ont accès aux appels du noyau, et le drapeau --privileged désactive la plupart des capacités et des restrictions seccomp. L'exécution de code douteux sur votre appareil personnel n'est certainement pas recommandée.

Qui trouvera ce projet utile

L'outil plaira à ceux qui transforment une ancienne tablette ou un ancien smartphone en serveur local. C'est pratique pour créer des conteneurs Docker, une instance Home Assistant à domicile, des bases de données ou un environnement de bureau complet avec rendu via GPU.

Des binaires prêts à l'emploi pour les architectures aarch64, armhf, x86_64, x86 et riscv64 sont disponibles dans les versions sur GitHub.