Vor einem knappen Jahr habe ich eine Großbeichte abgelegt: Ja, ich
nehme an so einem blöden, schnüffelnden Kundenbindungsprogramm teil, und
dann noch an dem von der Bahn, bei dem VielfahrerInnen gemütlich im
Sessel Kakao schlürfen, während gewöhnliche Reisende draußen am
Bahnsteig frieren oder sich um die wenigen Sitzgelegenheiten in den
Bahnhofsgebäuden streiten müssen: Ehemals bahn.comfort, jetzt BahnBonus.
Im zitierten Post habe ich dem Lounge-Zugang hinterhergeweint, denn seit
einem knappen Jahr lässt die Bahn nur noch Menschen in die Lounges, die
ferngewartete Computer („Smartphones“), und dann noch ziemlich neue
davon, verwenden. Statt der alten Plastikkarte brauchte es jetzt eine,
hust, App. Die tut nun (wie ich jetzt weiß und vorher ahnte) nicht
nicht viel mehr als den Login-Bildschirm der Bahn-Webseite anzuzeigen
und dann Links auf QR-Codes zu generieren. Wahrscheinlich etwas naiv
habe damals gehofft, dass die Bahn die paar Zeilen Javascript, die es
dafür braucht, auch auf ihre normale Webseite packt.
Das ist aber nicht passiert. Als die Bahn neulich
BahnBonus-Papierwerbung geschickt hat („Sie haben Gold-Status!”), habe
ich erneut eine Mail an den Bahn-Support geschrieben, wie es denn mit
QR-Codes auf der Webseite stehe. Erneut war die Antwort ein nicht
weiter erklärtes Nein. Dass die Bahn mit der Negativantwort aber
etliche Gutscheine (insbesondere zum Lounge-Zugang) schickte, nahm ich
als „nee, wir machen das nie, auch wenn es einfach ist“. Mag sein, dass
es dabei ums Datensammeln geht, mag sein, dass das einfach
Konzernpolitik ist.
Jedenfalls: Wenn ich wieder im Warmen Kakao schlürfen will, muss ich
irgendwie auf Dauer an die QR-Codes kommen. Ferngewartete Computer
kommen für mich allenfalls in virtuellen Maschinen in Frage, und so
dachte ich mir: Ich probier mal, ob ich die BahnBonus-App nicht auch auf
meinem normalen Rechner zum Laufen kriege.
Stellt sich raus: Das geht, und wenn mensch sich Google in einer VM
austoben lässt, sogar mit vertretbarem Aufwand. Ich schreibe hier mal
auf, was es für mich gebraucht hat; das mag ja bei anderen
Digitalzwängen auch ein wenig helfen.
Android in QEMU aufsetzen
Ich gehe für die folgenden Schritte aus von einem Debian (bullseye) auf
einem Intel- oder AMD-System, das nicht wesentlich älter ist als 15
Jahre. Im Prinzip dürfte aber fast alles auch auf jeder anderen
Plattform gehen, auf der Qemu läuft.
Wenn ihr bei den folgenden Schritten irgendwo ins Schleudern kommt,
lasst es mich bitte wissen – ich erweitere diese Erzählung gerne so,
dass sie auch nicht übermäßig nerdigen Menschen etwas sagt.
(1) Qemu installieren – Qemu ist zunächst ein Emulator von allerlei
Hardware. Da aber Android enorm ressourcenhungrig ist (also: jetzt
für meine Verhältnisse), wäre alles furchtbar lahm, wenn der
Android-Code nicht direkt von der CPU in eurem Rechner ausgeführt würde
– ich werde Qemu also als Virtualisierer verwenden und nur in sehr
zweiter Linie als Emulator. Achtet jedenfalls darauf, dass qemu KVM
machen kann. Zum Ausgleich braucht ihr nur die amd64-Fassung, nicht all
die anderen Architekturen, und insbesondere nicht ARM. In Bullseye
sollte sowas hier reichen:
apt install qemu-system-gui qemu-system-amd64
[ich selbst habe an der Stelle aus Geiz qemu-system-x86 genommen; das
geht auch, und damit ist alles etwas kompakter].
(2) Android-x86 besorgen – ich gestehe ehrlich, dass ich mich nicht
sehr um die Vertrauenswürdigkeit der Leute rund um den Port von
Android auf x86-Prozessoren gekümmert habe. Ich habe einfach ein
passendes ISO-Image von deren FOSSHUB-Seite (Krapizität 10 lässt
hoffen) runtergeladen; wenn ihr die amd64-Qemu installiert habt, wollt
ihr jetzt das „64-bit ISO file“.
(3) Container fürs Android-Filesystem anlegen – euer Android muss
seine Dateien irgendwo hinspeichern, und ihr wollt ihm gewiss keinen
Zugriff auf euer echtes Dateisystem geben. Erzeugt also eine
„virtuelle“ Festplatte für die Qemu-Daten. Dabei kommt ihr mit einem
Gigabyte auch bei i386 nicht aus. Wenn ihr euch um Plattenplatz keine
Sorgen macht: baut lieber gleich eine mit vier Gigabyte (4G am Ende
der Kommandozeile).
Sucht euch auch irgendeinen Platz, wo ein Klops von der Größe nicht
schlimm stört. Ich nehme hier mal ~/containers (was ihr dann wohl
aus eurem Backup rausnehmen solltet):
mkdir -p ~/containers
qemu-img create -f qcow2 ~/containers/android.img 2G
Display-Probleme
Jetzt stellt sich das Problem, dass euer künftiges Android die
Bildschirmausgabe irgendwo hinschicken muss. Qemu kann in ein ordinäres
X-Fenster ausgeben, aber das ist – aus Gründen, die ich nicht untersucht
habe – furchtbar lahm. Was für mich gut funkioniert hat: VNC. Wenn ihr
damit nicht zurechtkommt, probiert unten mal QDISPLAY="-display gtk"
(könnte halt kreuzlahm sein).
(4) Android-Installer starten – das braucht ein paar Optionen,
damit das Ding auch ins Netz kommt und die beiden nötigen Dateien (die
virtuelle Platte und den Android-Installer) findet:
QDISPLAY="-display vnc=localhost:0"
qemu-system-amd64 $QDISPLAY -enable-kvm -m 2000 \
-net nic -net user -drive file=$HOME/containers/android.img,format=qcow2 \
-boot d -cdrom /media/downloads/android-x86-9.0-r2.iso
Den Pfad in der -cdrom-Option müsst ihr ganz sicher anpassen, damit
er auf das ISO zeigt, das ihr gerade runtergeladen habt. Lasst jetzt
einen VNC-Client auf localhost:5600 los; ich empfehle in diesen Tagen
remmina (aus dem gleichnamigen Debian-Paket).
(5) Den Android-Container konfigurieren – wählt Installation
to Hard disk aus, dann Create/Modify Devices. Ihr kommt in einen
guten, alten, textbasierten Partitionierer. Als Disklabel wollt ihr
nicht GPT haben (weil das später Ärger mit dem Bootloader GRUB gibt).
Der Speicher, den ihr da partitioniert, ist der, den ihr in Schritt 3
angelegt habt. Packt die ganze „Platte“ in eine Partition, sagt
Write (keine Sorge, mit den Optionen oben könnt ihr keine Daten von
euch kaputtmachen) und dann Quit.
Ihr kommt dann zurück in den Android-Installer. Nach einem Ok könnt
ihr das Filesystem auswählen – nehmt ext4.
Dann fragt der Installer, ob ihr einen GRUB haben wollt – ja, wollt ihr,
sonst kommt euer Android nachher nur mit viel Mühe hoch.
Das System Directory wollt ihr wahrscheinlich nicht read/write haben
(es sei denn, ihr wollt ernsthaft mit dem Android spielen). Das spart
einiges an Platz.
(6) Android ins Netz lassen – an der Stelle sollte euch der
Installer anbieten, Android-x86 zu starten. Tut das. Wählt eine
Sprache aus – ich habe es bei „English (United States)“ belassen.
Es kann sein (ist bei mir passiert), dass das Ding nach der
Sprachabfrage abstürzt und wieder beim Grub-Prompt vom Installer ist.
Wenn das passiert, beendet die qemu (also: Control-C in deren Fenster)
und schaut unten bei VM starten nach der Kommandozeile, die die Qemu
ohne Installer hochzieht. Wir haben es hier mit kommerzieller Software
zu tun, Gesundbooten ist also durchaus eine legitime Option.
Jedenfalls: nach der Sprachwahl will das Ding ins Netz, und ich fürchte,
es hat keinen Sinn, ihm das zu verbieten. Sucht also nach Netzen.
Ihr solltet genau eines sehen, VirtWifi oder sowas. Wählt das
aus, seufzt und lasst schon mal auf eurem richtigen Rechner ein
tcpdump -n laufen, um zu sehen, womit euer neues Android so alles
plaudert (vgl. Die Wunden lecken).
Das „Checking for Updates“ hat bei mir über Minuten hinweg 100% CPU
verbraten (mensch will gar nicht wissen, was es dabei zu rechnen gibt).
Da ich den „ich tu gerade was“-Feedback im emulierten Android generell
nicht so prall finde, könnt ihr die Zeit ja damit verbringen, eure
CPU-Last-Anzeige am Desktop auf Vordermann zu bringen (mein Tipp:
wmcore).
Dann fragt Android, ob es von irgendwoher eure Daten ziehen kann. Klar:
das hätte Google gerne. Zum Glück gibts einen kleinen „Don't
Copy“-Knopf. Genauso ist auch der Skip-Knopf im nächsten Dialog, dem
Google-Signin, ziemlich klein, und Google nervt extra nochmal, wenn
mensch ihn wählt. Wählt ihn trotzdem. Date and Time sind zur
Abwechslung problemlos abnickbar, dann kommt ein Dialog zu „Google
Services“, die mensch alle manuell ausschalten muss.
Das ist offenbar die Benutzerfreundlichkeit („User Experience“), über
deren Mangel im Free Software-Bereich ich immer so viel höre.
Ums Akzeptieren, dass Google immer und zu jeder Zeit Kram auf die
VM packen kann, kommt mensch glaube ich nicht rum. Aber dafür ist es ja
auch eine VM.
Den folgenden „Protect your Tablet“-Dialog finde ich interessant, weil
die Benutzerführung, die mir gerade noch Vertrauen zu Google überhelfen
wollte, nun Misstrauen gegen andere Menschen sät, und das gleich noch
mit einem zweiten Extra-Mahn-Dialog, wenn ich keine Lust auf Geräte-PINs
habe. Also ehrlich: wenn ich mit Google zu tun habe, mache ich mir doch
über menschliche DiebInnen keine Sorgen…
Die abschließende Frage nach der Home-App verstehe ich auch nicht.
Macht einfach irgendwas. Damit seid ihr im Android-Geschäft.
Apps ohne App-Store
(7) Home-Screen aufräumen – Wenn ihr gleich mal den „Home-Screen“
aufräumen wollt: jeweils lang ein Icon klicken und ziehen. Dann
erscheint ein „Remove“-Feld, auf das ihr das Icon ziehen könnt. Macht
das am besten mit allem außer dem Chrome. Den brauchen wir gleich. Die
widerliche Google-Bar lässt sich, glaube ich, mit diesem Mitteln nicht
entfernen. Wozu auch – der Container gehört ja, wie ihr gerade
abgenickt habt, sowieso Google.
(8) Bahn-App finden – Die Bahn veröffentlicht, so weit ich
weiß, keine APKs (also Pakete) von ihrer App. Insofern müsst ihr …