zur Startseite

Druckausgabe von https://privat.albicker.org
Iveco Daily 4x4, Hunde und multithematisches Blog

Ein eingesperrtes Android auf dem Desktop

veröffentlicht am 15.07.2020 mit 2334 Worten - Lesezeit: 11 Minute(n) in * GEBRABBEL * SOFTWARE *

Inhaltsverzeichnis

 

Ein gutes Smartphone ist teuer. Und ein Wegwerfartikel. Sicherheitsupdates gibt es nur für begrenzte Zeit. Akkus sind nicht auswechselbar.
Einige der guten Gründe, die gegen den Erwerb sprechen.
Und dann gibt es da noch die Datenschutz-Aspekte.
All das scheint aber niemanden zu interessieren - und die Entscheidungsträger lernen: immer weiter so. Und die App wird zur Voraussetzung zur Teilnahme am Leben …
Zeit, nach einem “Notausgang” zu suchen.

Warum das Ganze?

Die große Überwachung

In keinem Zeitalter wurden wir so intensiv freiwillig überwacht wie heute.

Wie gesagt: alle tun dies freiwillig und zahlen auch noch kräftig Geld dafür … so ein Verhalten kann ich nur noch mit dem der Lemminge vergleichen …

(P.S.: Für alle “ich habe ja nix zu verbergen”-Propheten sei dieses Editorial als Lektüre empfohlen).

Wie kann ich dem entgehen?

Nun, ich nutze auf meinen privaten Rechnern konsequent Linux als quelloffenes und freies Betriebssystem, und auch bei der Software, die ich darauf verwende, achte ich auf diese Kriterien.

Nun beobachte ich aber zunehmend Bestrebungen, Leute zur Nutzung von Apps zu zwingen für bestimmte Dinge, z. B. beim Online-Banking.

Laden Sie die App kostenlos aus dem Apple Store oder dem Google Play Store herunter – je nachdem, welches Endgerät Sie nutzen.

Ganz selbstverständlich wird davon ausgegangen, daß “jeder” so’n Teil hat, aber: hab ich nicht, will ich nicht - aus den oben genannten Gründen. Ich erledige außerdem meinen Schriftkram lieber an einem sinnvoll großen Monitor - meine Augen danken’s mir (und ich laufe nicht wie so’n Smartphone-Zombie mit gesenktem Blick gegen Laternenmasten oder vor fahrende Autos - das erhöht die Lebenserwartung).

Und so ist also so ein Taschenspion, genannt Smartphone, keine Option für mich. Es muß eine sinnvolle Alternative her.

Die Alternative zum Überwachungs-Telefon, genannt Smartphone

Vorüberlegungen

Von den beiden beherrschenden Smartphone/Tablet-Betriebssystemen Android und iOS beruht ersteres auf einem quelloffenen Basissystem - allerdings ergänzt um eine Menge Google-“Erweiterungen” und geräteherstellerspezifische Software, die man allesamt zumindest mit Mißtrauen betrachten sollte. Die Basis selbst könnte aber dazu dienen, hier “was eigenes” aufzubauen …

  1. Seit Jahren werden sog. “Single-Board-Computer” immer populärer, kleine Computer-Boards, die tlw. gerade mal scheckkartengroß sind. Der bekannteste Vertreter ist der Raspberry Pi. Auf Basis eines solchen Boards könnte man einen Mini-Rechner aufbauen und darauf ein Android installieren.

    TouchPi Prototyp - Frontseiten-Ansicht
    Diesen Ansatz habe ich nach einigen Recherchen aber wieder - zumindest vorläufig - verworfen: Gerade für den Raspberry gibt es bis heute kein stabil lauffähiges Android, und bei den anderen im Markt befindlichen Kleincomputern ist es immer eine Frage der Community, ob und wie lange (oder auch wie akutell) ein Android für den entsprechenden Chipsatz zur Verfügung steht.
  2. Ganz ohne Hardware kommt der zweite Ansatz aus: Auf einem PC oder Laptop kann man eine sog. “Virtuelle Maschine” installieren. Die bekanntesten hier sind VMWare, Oracle Virutualbox und KVM/Qemu.

    Das Prinzip beruht darauf, daß eine Software auf dem Rechner einen zweiten “virtuellen” Rechner simuliert, der dann in einem Fenster des Betriebssystems des Hauptrechners, des host, zur Verfügung steht. Hier kann dann ein unabhängiges (beliebiges anderes) Betriebssystem installiert und als Gast betrieben werden.

  3. Der Vollständigkeit halber sei noch ein Ansatz erwähnt, den ich aus Kostengründen aber erstmal verworfen habe: Es lassen sich auf bestimmte vorhandene Smartphones auch nachträglich datenschutzfreundliche Betriebssysteme aufspielen, wie z. B. GrapheneOS auf eine ganze Reihe von Google-Smartphones, oder auch LineageOS für Geräte vieler Hersteller.

Umsetzung

Aufgrund der beschriebenen Hardware-Probleme habe ich mich zunächst für die 2. Vorgehensweise entschieden: Ein “Android in der Box” (also ein virtuelles Android in einem Fenster meines Linux-Rechners). Als virtuelle Maschine soll KVM/Qemu dienen.

Ein Vorteil von KVM ist, dass die Gastsysteme fast mit nativer Geschwindigkeit laufen, d.h. das Gastsystem reagiert nahezu so schnell wie ein natives System.

Ein weiterer Vorteil von KVM ist, daß quasi beliebige Hardware-Rechner-Architekturen simuliert werden können, also auch die in den Smartphones und Tablets häufig verbauten ARM-Prozessoren. Damit sollte es leichter möglich sein, ein lauffähiges Android zustande zu bekommen.

Ein offensichtlich vergoogeltes Android für PC-Plattformen findet sich hier.

Installation der virtuellen Umgebung

Die Virtualisierung mittels KVM geschieht in 3 Ebenen:

Die Beschreibung im Folgenden bezieht sich auf Debian 10 (Buster).

Vorab-Prüfungen

  1. Ist die im Rechner verbaute CPU geeignet:

    {benutzername}@{rechnername}:~$ egrep -c '(vmx|svm)' /proc/cpuinfo
    4
    

    Eine Zahl größer als Null ist ein gutes Zeichen … das ist die ausführliche Version von

    {benutzername}@{rechnername}:~$ grep -E '^flags.*\b(vmx|svm)\b' /proc/cpuinfo 
    

    Dieser Befehl bringt eine lange Ausgabe, interessant ist hier nur, ob darin vmx oder svm auftauchen (und wie oft).

  2. Werden die Kernel-Module geladen?

    {benutzername}@{rechnername}:~$ lsmod | grep kvm
    kvm                   757760  0
    irqbypass              16384  1 kvm
    

    kvm xyz 0 ist nicht gut, die Frage ist: warum nicht? Für meinen Intel-Prozessor ergeben die Versuche, die Kernel-Module händisch zu laden, Aufschluss:

    root@{rechnername}:~# modprobe kvm
    root@{rechnername}:~# modprobe kvm_intel
    modprobe: ERROR: could not insert 'kvm_intel': Operation not supported
    

    Für AMD-Prozessoren lautet der 2. Befehl modprobe kvm_amd.

    Hinweise auf den ausgegebenen Fehler bzw. dessen Ursache ergibt:

    root@{rechnername}:~# dmesg | grep kvm
    [    7.613131] kvm: disabled by bios
    [    7.650947] kvm: disabled by bios
    [    7.699649] kvm: disabled by bios
    [    7.750248] kvm: disabled by bios
    [ 8828.356016] kvm: disabled by bios
    
  3. Rechner runterfahren und ins BIOS: Kernel-Virtualisierung aktivieren =Bildbeschreibung=

  4. nachprüfen
    Die beiden modprobe-Befehle von oben verlaufen ohne Fehlermeldung und eine Kontrolle ergibt:

    {benutzername}@{rechnername}:~$ lsmod | grep kvm
    kvm_intel             233472  0
    kvm                   757760  1 kvm_intel
    irqbypass              16384  1 kvm
    

QEMU installieren

Nachdem jetzt also die Hardware und der Kernel der Linux-Basis (hier: Debian 10 (Buster)) vorbereitet sind, kann die notwendige Software installiert werden.

root@{rechnername}:~# apt-get install qemu-system-x86
root@{rechnername}:~# apt-get install qemu-kvm

Zusätzlich muß der aktive Benutzer in die Gruppe kvm aufgenommen werden.

root@{rechnername}:~# adduser {benutzername} kvm 

(danach Rechner neu starten)

Grafische Oberfläche VirtManager installieren

root@{rechnername}:~# apt-get install virt-manager 

und den Benutzer den Gruppen libvirt und libvirt-qemu hinzufügen.

root@{rechnername}:~# adduser {benutzername} libvirt
root@{rechnername}:~# adduser {benutzername} libvirt-qemu

Android installieren

Android besorgen

Der erste Schritt besteht darin, von der bereits oben genannten Adresse ein ISO-Image eines Android für PC herunterzuladen, diese .iso-Dateien sind im Bereich zwischen 700 und 900MB groß.

“Hardware” vorbereiten - Virtuelle Umgebung einrichten

Der Starter für die grafische Oberfläche für virtuelle Maschinen ist im Menü unter der Rubrik Systemverwaltung zu finden:

=Bildbeschreibung=

Im sich öffnenden Fenster gibt der erste Button in der Toolbar die Möglichkeit, eine neue virtuelle Maschine einzurichten:

=Bildbeschreibung=

Die Einrichtung kann dann einfach in mehreren Schritten mithilfe des gestarteten Assistenten erfolgen.

Als erstes wird abgefragt, wo das Installationsmedium zu finden ist - wir verwenden hier das heruntergeladene ISO-Abbild des Android-Installers, also ist die erste Option die richtige:

=Bildbeschreibung=

Im nächsten Schritt ist dann der Speicherort dieses ISO-Abbildes anzugeben:

=Bildbeschreibung=

Virt-Manager bzw. Qemu brauchen einen Hinweis auf die Art des zu installierenden Betriebssystems, die automatische Ermittlung (standardmäßig ausgewählt, kl. roter Kreis) schlägt aber fehl:

=Bildbeschreibung=

Deshalb muß hier manuell “nachgeholfen” werden:

=Bildbeschreibung=

Automatische Detektion abschalten und in die Suchzeile anfangen zu tippen: Android wird nicht erkannt und der Assistent schlägt eine “generische Standardeinstellung” vor.

=Bildbeschreibung=

Diese kann man bestätigen und damit fortfahren und im nächsten Schritt die “Hardware-Ausstattung” festlegen, die man der virtuellen Maschine zur Verfügung stellen will.

=Bildbeschreibung=

Im folgenden Schritt 4 geht es darum, der virtuellen Maschine eine “Festplatte” zur Verfügung zu stellen. Diese wird durch eine Datei auf dem Rechner dargestellt, die dem Virt-Manager mitgeteilt und der erstellten virtuellen Maschine zugeordnet wird.

=Bildbeschreibung=

Ich wähle hier die benutzerdefinierte Option, damit kann ich den Speicherort auf eine Partition legen, in der genügend freier Platz zur Verfügung steht. Im 1. Unterschritt wird der Name und der Typ festgelegt,

=Bildbeschreibung=

im nächsten Unterschritt kann dann der Speicherort definiert werden.

=Bildbeschreibung=

Der virtuelle Datenträger ist damit definiert und kann mit der Bestätigung Fertig erstellt werden.

=Bildbeschreibung=

Damit sind die nötigen Informationen für den virtuellen Datenträger vollständig.

=Bildbeschreibung=

Im letzten Schritt werden die Angaben zusammengefaßt und der virtuellen Maschine kann noch ein Name gegeben werden, unter dem diese dann in der Auflistung im Virt-Manager eindeutig erkannt werden kann:

=Bildbeschreibung=

Um der virtuellen Maschine Zugang zum Internet zu gewähren, muß das sog. virtuelle Netzwerk aktiviert werden:

=Bildbeschreibung=

Android-Installer

In der virtuellen Maschinenverwaltung wird nun die eben erstellte virtuelle Maschine Android9 aufgelistet und kann mit dem Pfeilsymbol gestartet werden.
Dabei wird - wie in Schritt 1 und 2 des Einrichtungsassistenten angegeben, der Installer von der “CD”, also dem heruntergeladenen ISO-Image, gestartet.

=Bildbeschreibung=

Um am schnellsten ans Ziel zu kommen, wähle man auf dem ersten Bildschirm die Advanced options:

=Bildbeschreibung=

Dort geht es dann weiter mit der Auto-Installation, es wird automatisch auf die gefundene (hier virtuelle) Festplatte installiert:

=Bildbeschreibung=

Demzufolge muß die nächste Abfrage bestätigt werden

=Bildbeschreibung=

und nach einiger Zeit

=Bildbeschreibung=

meldet der Installer den erfolgreichen Abschluss:

=Bildbeschreibung=

Die erste gezeigte Option startet dann in das neu installierte Android - brav im Fenster des Virt-Managers:

=Bildbeschreibung=

und man landet im Einrichtungsmanager, mit dem man sich dann einige Zeit beschäftigen kann, um die ganzen Google-Übermittlungseinstellungen erstmal soweit abzuschalten, wie es die Oberfläche überhaupt hergibt:

=Bildbeschreibung=

Bootvorgang: installiertes Android starten

Das neue virtuelle Android ist nun eingerichtet. Damit dieses nunmehr direkt beim Start dieser virtuellen Maschine bootet - und nicht der Installer erneut angezeigt wird - muß das virtuelle CD-ROM-Laufwerk aus der Liste der Boot-Geräte entfernt werden:

=Bildbeschreibung=

 

und zu guter Letzt:

Nicht vergessen!

=Bildbeschreibung=

Google weiß alles … 😬

Und wie bringt mich das jetzt weiter?

Ist so’n Android im Fenster wirklich ein Ersatz? Wofür?

Im ersten Abschnitt dieses Artikels ging es um die Dauerüberwachung, der sich (zu) viele von uns “freiwillig” aussetzen.

Nun ist dieses “Android in der Box” auch nur ein gewöhnliches Google-Android - wie bringt mich das jetzt hinsichtlich informationeller Selbstbestimmung weiter?

Das ist eine Frage der Lebensumstände:

Letztlich bleibt für dieses Android also die Aufgabe, irgendwelche TANs zu generieren, die partout nicht anders zu erhalten sind, oder DHL-Pakete über deren App zu verwalten.

Soll ich dazu ’n teures Smartphone rumtragen, das mich auf Schritt und Tritt ausspioniert? Da schalte ich lieber dieses Android in der Box alle paar Tage oder Wochen mal für’n paar Minuten ein - und dann wieder aus … 😜 …

Und wie weiter?

So ein simuliertes Android kann auch eine brauchbare Testplattform sein um herauszufinden, bis zu welchem Grad sich ein Smartphone oder Tablet “entgoogeln” läßt. Eine ganze Reihe Apps scheint nur zu laufen, wenn ein Google-Account aktiv ist - und genau das geht ja gar nicht.

Und wenn denn klar ist, was ich wirklich “brauche” und wie das datensparsam zum Laufen zu bringen ist, dann kann die Entscheidung zum Kauf einer Hardware immer noch fallen - wegen des größeren Bildschirms dürfte das dann am ehesten ein Tablet sein. Und dann wird die erste Entscheidung sein:

Mal sehen, welche Erkenntnisse meine Spielereien im Fenster so bringen …

 


weitere Artikel