Linux auf dem Alexa Tablet 12 Pro: warum Termux und AVF scheitern

Ergebnis in Kürze

Ohne Root gibt es auf dem Alexa Tablet 12 Pro derzeit keine lokale Linux-Umgebung. Beide naheliegenden Wege scheitern, und zwar aus unterschiedlichen Gründen:

Weg	Ergebnis	Ursache
Termux (Play Store und GitHub)	Startet nicht: „Unable to install bootstrap“. Auch eine Installation für Benutzer 0 hilft nicht.	Headless System User Mode: Termux läuft nur als Benutzer 0, und Benutzer 0 hat keine Oberfläche.
Linux-Terminal von Android 16 (AVF, Debian-VM)	Lässt sich freischalten, die VM startet, Debian bootet aber nie: „Nicht behebbarer Fehler“ (onVmError).	Die Gast-CPU führt unter Amazons GenieZone-Hypervisor keine Anweisung aus. Android beendet die VM nach 60 Sekunden.

Als Alternative bleibt ein SSH-Client, der sich mit einem eigenen Server verbindet.

Das Gerät

Eigenschaft	Wert
Gerät	Amazon Alexa Tablet 12 Pro (WLAN), Modell ATSPWI
Betriebssystem	Alexa Tablet UI 16.1.10
Android	16 (API 36), Build SL16SHIP2003.1344N
SoC	MediaTek MT8793N (laut Amazon), Kerne und Takte wie beim Dimensity 8400 (MT6899)
RAM	8 GB (Android meldet 6.882 MB), dazu 3 GB Swap
Hypervisor	MediaTek GenieZone (/dev/gzvm), kein KVM
Benutzermodell	Headless System User Mode, Nutzer = Benutzer 10

Headless System User Mode erkennen

Das Tablet läuft im Headless System User Mode (HSUM): Benutzer 0 ist ein Systembenutzer ohne Oberfläche, du selbst bist Benutzer 10. Das prüfst du mit drei Befehlen:

C:\> adb shell pm list users
Users:
        UserInfo{0:null:813} running
        UserInfo{10: :4412} running

C:\> adb shell am get-current-user
10

C:\> adb shell getprop ro.fw.mu.headless_system_user
true

Die Zahlen hinter den Benutzern sind Flags als Hexwerte. UserInfo.toString() gibt sie mit Integer.toHexString() aus:

Benutzer	Flags	Zerlegung	Bedeutung
0	0x813	SYSTEM (0x800) + INITIALIZED (0x10) + ADMIN (0x2) + PRIMARY (0x1)	Systembenutzer ohne FULL: keine Oberfläche, kein Name
10	0x4412	MAIN (0x4000) + FULL (0x400) + INITIALIZED (0x10) + ADMIN (0x2)	Der eigentliche Hauptnutzer

Fehlt bei Benutzer 0 das FULL-Flag (0x400), läuft dein Gerät im Headless-Modus. Das hat Folgen für Debloat-Befehle und, wie sich zeigt, für Termux.

Termux: „Unable to install bootstrap“

Termux startet auf dem Alexa Tablet 12 Pro nicht. Die Version aus dem Play Store und die aktuelle Version von GitHub brechen beide beim ersten Start mit derselben Meldung ab:

Die ausführliche Fassung der Meldung nennt den Grund:

Termux can only be run as the primary user. Bootstrap binaries compiled for Termux have hardcoded $PREFIX path and cannot be installed under any path other than /data/data/com.termux/files/usr.

Warum Termux scheitert

Termux scheitert an einem fest einkompilierten Pfad. Alle Termux-Pakete sind auf den Prefix /data/data/com.termux/files/usr gebaut, und /data/data ist ein Symlink auf /data/user/0, also auf die App-Daten von Benutzer 0.

• Unter Benutzer 10 liegen die App-Daten in /data/user/10/com.termux. Termux prüft beim Start, ob es als Benutzer 0 läuft, und bricht sonst ab.
• Im Headless-Modus hat Benutzer 0 keine Oberfläche. Du kannst nicht zu ihm wechseln, und Benutzer 10 darfst du auf keinen Fall entfernen.
• Ein eigener Termux-Build mit Prefix unter /data/user/10/… wäre theoretisch möglich, setzt aber voraus, das komplette Paket-Repository neu zu kompilieren.

Versuch: Termux als Benutzer 0 installieren und starten

Termux als Benutzer 0 zu starten, funktioniert ebenfalls nicht. Getestet habe ich das mit termux-app_v0.119.0-beta.3+apt-android-7-github-debug_arm64-v8a.apk.

Die Installation für Benutzer 10 klappt, die App scheitert danach wie oben am Bootstrap:

C:\> adb install --user 10 termux-app_v0.119.0-beta.3+apt-android-7-github-debug_arm64-v8a.apk
Performing Streamed Install
Success

Die Installation für Benutzer 0 per adb install --user 0 hängt dagegen ohne weitere Ausgabe. Laut logcat gibt Play Protect die App frei, Android will sie danach aber zusätzlich an den Entwickler-Verifier com.google.android.verifier übergeben. Der ist nur für Benutzer 10 installiert, und Android versucht es für Benutzer 0 mit wachsenden Abständen immer wieder:

Finsky  : VerifyApps: [ADV] No verification policy was set for user 0. Using default policy.
Finsky  : VerifyApps: [ADV] Verifier app is not installed. Passing by default for com.termux (id=2)
Finsky  : VerifyApps: [ADV] Enforced verdict for com.termux: VERIFICATION_ALLOW
12:54:27 ActivityManager: Unable to start service Intent { act=com.google.android.verifier.backport.VERIFY_PACKAGE … } U=0: not found
12:54:28 ActivityManager: Unable to start service Intent { … } U=0: not found
12:54:31 ActivityManager: Unable to start service Intent { … } U=0: not found
12:54:35 ActivityManager: Unable to start service Intent { … } U=0: not found

Auch das ist ein Headless-Effekt: Systemkomponenten, die nur für den echten Nutzer installiert sind, fehlen beim Systembenutzer. Ein Amazon-Konto spielt dabei keine Rolle.

Das schon installierte Paket für Benutzer 0 freizuschalten, umgeht die Prüfung:

C:\> adb shell pm install-existing --user 0 com.termux
Package com.termux installed for user: 0

Der Start für Benutzer 0 wird angenommen, aber nie ausgeführt:

C:\> adb shell am start --user 0 -n com.termux/.app.TermuxActivity
Starting: Intent { cmp=com.termux/.app.TermuxActivity }

C:\> adb shell am start --user 0 -n com.termux/.app.TermuxActivity
Starting: Intent { cmp=com.termux/.app.TermuxActivity }
Warning: Activity not started, its current task has been brought to the front

C:\> adb shell pidof com.termux
(leer)

C:\> adb shell dumpsys activity activities | findstr /i termux
  * Task{652f45b #1000393 type=standard A=10303:com.termux U=0 visible=false visibleRequested=false mode=fullscreen translucent=true sz=1}
    * Hist  #0: ActivityRecord{21272426 u0 com.termux/.app.TermuxActivity t1000393}
      packageName=com.termux processName=com.termux
      dataDir=/data/user/0/com.termux

Android legt für Benutzer 0 einen Task an, zeigt ihn aber nie an (visible=false) und startet nicht einmal einen Prozess. Die Ironie: Für Benutzer 0 läge Termux mit dataDir=/data/user/0/com.termux genau unter dem Pfad, den der Bootstrap braucht. Tippst du auf das Termux-Symbol, startet trotzdem immer die Instanz von Benutzer 10.

Schritt	Ergebnis
Termux für Benutzer 10	Bootstrap-Fehler, der Prefix zeigt fest auf Benutzer 0
adb install --user 0	Hängt, weil der Entwickler-Verifier für Benutzer 0 fehlt
pm install-existing --user 0	Installation gelingt
am start --user 0	Wird angenommen, der Task bleibt unsichtbar, kein Prozess

Aufräumen kannst du mit adb uninstall com.termux. Das entfernt Termux für alle Benutzer.

Nebenbefund: die 16-KB-Warnung

Beim Start der Debug-Version von Termux erscheint zusätzlich ein Kompatibilitätsdialog, der mit dem Bootstrap-Problem nichts zu tun hat:

Das Tablet nutzt 4-KB-Seiten (adb shell getconf PAGESIZE liefert 4096). Android 16 zeigt die Warnung laut Dialogtext, weil es sich um eine debugfähige App handelt, also als Hinweis für Entwickler. Hintergründe zu 16-KB-Seiten stehen in der Android-Dokumentation. Du kannst den Dialog mit „Nicht mehr anzeigen“ schließen.

Das Linux-Terminal von Android 16

Das Linux-Terminal von Android 16 lässt sich auf dem Alexa Tablet 12 Pro freischalten, bootet Debian aber nicht. Die App nutzt das Android Virtualization Framework (AVF) und startet Debian in einer virtuellen Maschine.

Voraussetzungen prüfen

C:\> adb shell getprop ro.boot.hypervisor.vm.supported
1

C:\> adb shell getprop ro.boot.hypervisor.protected_vm.supported
(leer)

C:\> adb shell pm list features | findstr virtual
feature:android.software.virtualization_framework

C:\> adb shell ls -l /dev/kvm /dev/gzvm
ls: /dev/kvm: No such file or directory
crw-rw-rw- 1 root root 10, 266 2026-10-21 10:16 /dev/gzvm

Nicht geschützte VMs werden unterstützt, geschützte (pVM) nicht. Für das Terminal reicht das, es nutzt eine nicht geschützte VM. Hypervisor ist MediaTek GenieZone statt KVM. Die Terminal-App com.android.virtualization.terminal ist ab Werk deaktiviert.

Freischalten

adb shell pm enable --user 10 com.android.virtualization.terminal

Danach erscheint in den Entwickleroptionen der Schalter „Linux-Entwicklungsumgebung (experimentell)“. Nach dem Einschalten taucht die App „Terminal“ im App-Drawer auf und lädt beim ersten Start das Debian-Image herunter.

Fehlerbild: „Nicht behebbarer Fehler“

Nach dem Download erscheint „Terminal wird vorbereitet“. Die Ladeanimation läuft minutenlang, danach kommt „Nicht behebbarer Fehler“. Ein erneuter Start führt zum selben Ablauf.

Weitere Beobachtungen:

• Das Bildschirm-Symbol oben rechts (virtueller VM-Bildschirm) ist ausgegraut und reagiert nicht.
• Die Einstellungen zeigen Portsteuerung und Wiederherstellung, in einem anderen Durchlauf zusätzlich Disk resize für die Größe der virtuellen Festplatte (bei mir 97,3 von maximal 165 GB). Die Portsteuerung hilft nicht, solange Debian nicht bootet. Ich habe das Terminal auch über Wiederherstellung zurückgesetzt: Der nächste Start endete mit demselben Fehler.
• Während die VM läuft, hat die Musikwiedergabe über Bluetooth kurze Aussetzer.

Was die Logs zeigen

Die VM wird erzeugt und gestartet, und zwar unter Benutzer 10. Der Headless-Modus blockiert die VM also nicht, anders als bei Termux:

virtmgr : Non-protected virtual machine "debian" (owner: u10_a252, cid: 2051) created
virtmgr : Non-protected virtual machine "debian" (owner: u10_a252, cid: 2051) started
crosvm  : creating hypervisor: Geniezone { device: Some("/dev/gzvm") }
crosvm  : Trying to attach block device: /proc/self/fd/50
crosvm  : Trying to attach block device: /proc/self/fd/46

Die wichtigsten Parameter aus dem Aufruf von crosvm (dem Virtual Machine Monitor von AVF):

Parameter	Wert
Kernel-Kommandozeile	root=/dev/vda1 ds=nocloud arm64.nompam 8250.nr_uarts=4 console=ttyS0
Arbeitsspeicher	--mem 4096 (4 GB), kein Memory Balloon
CPU	--host-cpu-topology, sve=[auto=true], --no-pmu
Grafik	--gpu=backend=2d, Fenster 1280×720
Sound	--virtio-snd backend=aaudio
Netzwerk	TAP-Interface avf_tap_fixed

Android richtet das Netzwerk für den Gast ein und startet einen DHCP-Server. Die Terminal-App wartet per mDNS darauf, dass das Web-Terminal im Debian-Gast erscheint. Danach kommt nichts mehr: keine DHCP-Vergabe an den Gast, keine mDNS-Meldung, aber auch kein Absturz von crosvm.

Außerdem auffällig: Der Logger der App bricht direkt beim Start ab (Failed to log VM log output), deshalb fehlt die Konsolenausgabe des Gastes im logcat. SELinux verweigert dem VM-Manager den Zugriff auf Grafik-Ressourcen (avc: denied { use } … tcontext=u:r:surfaceflinger:s0), was vermutlich das ausgegraute Bildschirm-Symbol erklärt.

Nach etwa 16 Minuten Laufzeit sah es so aus:

C:\> adb shell top -b -n 1 -m 8
  Mem:  7047680K total,  6877496K used,   170184K free
 Swap:  3143860K total,  2918104K used,   225756K free
800%cpu  32%user   4%nice 100%sys 629%idle   0%iow  32%irq   4%sirq   0%host
  PID USER      PR  NI VIRT  RES  SHR S[%CPU] %MEM     TIME+ ARGS
24968 u10_a252  20   0  15G 133M 133M S 46.4   1.9  23:42.02 crosvm_debian …
24860 u10_a252  10 -10  41G 195M 120M S 32.1   2.8   2:25.96 com.android.virtualization.terminal

C:\> adb shell ip neigh show dev avf_tap_fixed
(leer)

• crosvm hat rund 24 Minuten CPU-Zeit verbraucht, die Last steht bei 100 % „sys“. Die Arbeit passiert also im Host-Kernel, nicht im Gast.
• crosvm belegt nur 133 MB RAM, ungefähr die Größe von Kernel und Initrd. Ein bootendes Debian würde deutlich mehr Speicher anfassen.
• ip neigh ist leer: Der Gast hat nie ein Netzwerkpaket an den Host geschickt.
• Der Swap ist zu 93 % belegt, was sehr wahrscheinlich die Bluetooth-Aussetzer erklärt.

Zur Gegenprobe habe ich das Terminal direkt nach einem Neustart mit leerem Swap gestartet. Das Ergebnis war dasselbe. Bemerkenswert: Direkt nach dem Booten sind nur 2,2 GB RAM verfügbar (MemAvailable), die VM fordert aber 4 GB an.

Der entscheidende Log: Watchdog nach 60 Sekunden

Genau 60 Sekunden nach dem Start prüft der VM-Manager die Rechenzeit des Gastes. Sie liegt bei null, also stuft er die VM als hängend ein und beendet sie per SIGKILL:

12:17:17.180 virtmgr : Non-protected virtual machine "debian" (owner: u10_a252, cid: 2048) started
12:17:17.219 crosvm  : creating hypervisor: Geniezone { device: Some("/dev/gzvm") }
12:18:17.218 virtmgr : Failed to get guest CPU time: zero value is measured on elapsed CPU guest_time
12:18:17.218 virtmgr : Killing VM (name: debian, cid: 2048) forcibly. Data might be corrupted!!!
12:18:17.248 virtmgr : Failed to get guest RSS: can't find VmHWM in the status file
12:18:17.250 virtmgr : crosvm(10189) exited with status signal: 9 (SIGKILL)
12:18:17.361 virtmgr : Non-protected virtual machine "debian" (owner: u10_a252, cid: 2048) exited

Die gefilterten Log-Auszüge (nur VM-relevante Zeilen) kannst du selbst ansehen: erster Start und Neustart mit Watchdog-Abbruch.

Bewertung

Die virtuellen CPUs führen unter Amazons GenieZone-Umsetzung keinen Gastcode aus. Debian kommt nicht einmal bis zur ersten Kernel-Meldung. Dafür sprechen fünf Belege:

1. Die Gast-CPU-Zeit nach 60 Sekunden liegt bei null (Watchdog-Log).
2. Hohe CPU-Last gibt es nur auf der Host-Seite (100 % „sys“), 24 Minuten crosvm-CPU-Zeit ohne Ergebnis.
3. Der Gast belegt nur 133 MB Speicher.
4. Der Gast zeigt keinerlei Netzwerkaktivität, weder DHCP noch mDNS noch einen ARP-Eintrag.
5. Amazon hat die Terminal-App ab Werk deaktiviert, möglicherweise genau deshalb.

Ausgeschlossen bzw. unwahrscheinlich sind:

• Headless-Modus: Die VM wird korrekt unter Benutzer 10 erzeugt und gestartet.
• Speichermangel: Er kann den Gast verlangsamen, erklärt aber keine Gast-CPU-Zeit von exakt null. Der Test mit leerem Swap änderte nichts.
• Beschädigtes Image: Die Blockgeräte werden angehängt, der Fehler tritt auf, bevor der Gast überhaupt Code ausführt. Das Zurücksetzen über Wiederherstellung in der Terminal-App änderte nichts.
• Deaktivierte Amazon-Apps: Sie haben keinen Einfluss auf den Hypervisor.

Ohne Root ist das nicht lösbar. Die VM-Konfiguration (4 GB RAM, Kernel-Parameter) liegt im geschützten App-Verzeichnis /data/user/10/com.android.virtualization.terminal/, Hypervisor und SELinux-Regeln sind Teil der Firmware.

Aufräumen

1. Schalte in den Entwickleroptionen die Linux-Entwicklungsumgebung aus. Das löscht das Debian-Image (mehrere GB).
2. Versetze die App wieder in den Werkszustand:

adb shell pm disable-user --user 10 com.android.virtualization.terminal

Alternativen

Weg	Status
SSH-Client (Termius, ConnectBot) zu einem eigenen Server	Funktioniert, mit Tastaturhülle alltagstauglich
UserLAnd (proot, keine fest kodierten Pfade)	Nicht getestet, könnte im Headless-Modus funktionieren
LADB (lokale adb shell über kabelloses Debugging)	Nicht getestet. Nur Android-Toolbox, kein apt, aber ohne PC nutzbar
Eigener Termux-Build mit Prefix unter /data/user/10	Theoretisch möglich, praktisch zu aufwendig
Linux-Terminal nach künftigen Alexa-Tablet-UI-Updates erneut testen	Offen

Befehlsübersicht

Zweck	Befehl
Benutzer anzeigen	adb shell pm list users
Aktiver Benutzer	adb shell am get-current-user
Headless-Modus prüfen	adb shell getprop ro.fw.mu.headless_system_user
VM-Unterstützung	adb shell getprop ro.boot.hypervisor.vm.supported
Geschützte VMs	adb shell getprop ro.boot.hypervisor.protected_vm.supported
Hypervisor-Gerät	adb shell ls -l /dev/kvm /dev/gzvm
App für Benutzer 0 freischalten	adb shell pm install-existing --user 0 <paket>
Läuft ein Prozess?	adb shell pidof com.termux
Seitengröße	adb shell getconf PAGESIZE
Terminal-App freischalten	adb shell pm enable --user 10 com.android.virtualization.terminal
Gast im Netzwerk?	adb shell ip neigh show dev avf_tap_fixed
VM-Log nach Fehler	adb logcat -d -s crosvm virtmgr VirtualizationService
Verfügbarer RAM	adb shell cat /proc/meminfo (Zeile MemAvailable)

Fazit

Linux lokal auf dem Alexa Tablet 12 Pro geht ohne Root derzeit nicht. Termux scheitert am Headless System User Mode, das Linux-Terminal von Android 16 an der GenieZone-Umsetzung von Amazon. Für die Kommandozeile bleibt ein SSH-Client, der sich mit einem eigenen Server verbindet. Stand 23. Oktober 2026 habe ich keine weiteren Berichte zu Termux oder dem Linux-Terminal auf dem Alexa Tablet 12 Pro gefunden und kein Alexa-Tablet-UI-Update nach 16.1.10. Ich teste das Terminal nach den nächsten Alexa-Tablet-UI-Updates erneut und ergänze das Ergebnis hier.

Wie du das Tablet vorher von Amazon-Apps, Werbung und Telemetrie befreist, steht in Alexa Tablet 12 Pro debloaten. Umgekehrt klappt es übrigens oft: Mit Waydroid läuft Android als LineageOS in einem Container auf Linux-PCs. Laut offizieller Statistik ist das sogar das häufigste „Gerät“ mit LineageOS, siehe LineageOS Nutzerzahlen.