Die Dateien und eine Anleitung gibt es im xda-Forum. Nicht die ersten Dateien nehmen, sondern die des neusten Build.

Achtung: Bei dieser Installation gehen aufgrund der Änderung der Partitionierung auch die Daten im internen Speicher (Download, Dokumente, Bilder, …) verloren!

  1. die Dateien lineage-18.1-…-UNOFFICIAL-i9100.zip und lineage-18.1-…-UNOFFICIAL-i9100_magisk_boot.img auf die SD-Karte kopieren
  2. Download-Modus (Power+Home+Volume down) starten und heimdall flash --repartition --pit i9100-LOS-16.0-Emulated-Storage.pit --RECOVERY i9100-LOS-16.0-Emulated-Storage-TWRP-3.3.1-1.img --no-reboot aufrufen; laut dem Forumseintrag funktioniert auch TWRP-3.4.0-i9100-Android-10.img von LOS 17
  3. Neu starten und sofort in den Recovery-Modus (Power+Home+Volume up) gehen. Dann »Swipe to Allow Modifications«
  4. Partitionen formatieren:
    • Wipe → Format Data → »yes« eingeben
    • Wipe → Advanced Wipe → folgende Punkte auswählen und danach Swipe to Wipe
    • Davik / ART Cache
    • Cache
    • System
    • Non-emulated Storage
  5. System installieren: Install → lineage-18.1-…-UNOFFICIAL-i9100.zip wählen und Swipe to confirm Flash
  6. Angepassten Kernel mit Magisk für Root-Rechte installieren (wenn nicht gewünscht, dann auslassen): Install → Install Image → lineage-18.1-…-UNOFFICIAL-i9100_magisk_boot.img und Boot wählen und Swipe to confirm Flash
  7. Neustarten, aber nicht TWRP-App installieren und Gerät einrichten
  8. Entwickleroptionen aktivieren: Geräteeinstellungen → Über das Telefon → 7x auf Build-Nummer klicken
  9. F-Droid-App mit adb install installieren oder im Browser auf dem Gerät von f-droid.org herunterladen und installieren.
  10. Aurorastore installieren
  11. Im F-Droid die Quellen für MicroG einrichten, indem man auf microg.org die Adresse anklickt oder den Befehl adb shell am start -a android.intent.action.VIEW -d 'https://microg.org/fdroid/repo?fingerprint=9BD06727E62796C0130EB6DAB39B73157451582CBD138E86C468ACC395D14165' aufruft. Im Anschluss die App microG Services Core installieren und die Befehle adb shell pm grant com.android.vending android.permission.FAKE_PACKAGE_SIGNATURE und adb shell pm grant com.google.android.gms android.permission.FAKE_PACKAGE_SIGNATURE ausführen.
  12. Apps einrichten

Root-Rechte mit Magisk

Bei den alten LineageOS-Versionen konnte man im TWRP immer SuperSU installieren und schon klappte das mit Root. Aber bei dieser neuen Version wird Magisk verwendet, das einerseits den Kernel anpasst (siehe oben bei der Installation) und weiterhin eine App benötigt. Diese App nur von Github herunterladen, da es im Netz viele gut gemachte Seiten mit »Zusatzfunktionen« gibt – ich bin selbst in eine solche Falle getappt und musste das Handy wieder komplett zurücksetzen, um das Ding loszuwerden.

Eine ausführliche Installationsanleitung gibt es auch bei xda-developers, die aber hier nicht notwendig ist, da der angepasste Kernel bereits für LineageOS angeboten wird.

Wenn der Magisk-Manager das erste Mal gestartet wird, muss er feststellen, dass der angepasste Kernel vorliegt und startet das System neu, um Anpassungen vorzunehmen – dies klappte bei der Variante mit Beigabe nicht, wodurch ich recherchieren musste um festgestellt habe, dass ich eine Fälschung hatte. Danach hatte ich dann SU und konnte es wie zuvor auch auf der Kommandozeile und für Apps verwenden.

Verbergen der Root-Rechte

Einige Apps, insbesondere die von Banken, mögen keine Root-Rechte und weigern sich, zu starten. Aber mit Magisk gibt es die Möglichkeit, diese Root-Rechte zu verstecken. Magisk nutzt dafür die Namespaces des Linux-Kernels und präsentiert der App eine angepasste Umgebung, in der sie sich wohlfühlt.

Wenn Magisk aktiviert ist, braucht man auf der Kommandozeile noch noch MagiskHide zu aktivieren und die gewünschte App direkt nach der Installation in die Liste der zu versteckenden Apps aufnehmen. (Ich habe gelesen, dass es einige Apps geben soll, die beim Entdecken eines gerooteten Gerätes die Gerätekennung an einen Server melden, sodass man auch mit MagiskHide danach nichts mehr ausrichten kann, weil das Gerät auf einer Sperrliste steht. Zum Glück ist mir solch eine App noch nicht untergekommen.

% adb shell su -c magiskhide status
MagiskHide is not enabled
% adb shell su -c magiskhide ls
com.google.android.gms|com.google.android.gms.unstable
org.microg.gms.droidguard|com.google.android.gms.unstable
% adb shell pm list packages |grep comdirect
package:com.comdirect.phototan
% adb shell su -c magiskhide add com.comdirect.phototan
% adb shell su -c magiskhide ls
com.comdirect.phototan|com.comdirect.phototan
com.google.android.gms|com.google.android.gms.unstable
org.microg.gms.droidguard|com.google.android.gms.unstable

SafetyNet funktioniert nicht mit microG

SafetyNet ist eine Funktion des Google-Frameworks, mit der das Handy auf Sicherheit geprüft wird. Dabei sind die Anforderungen für die Bestechung der Prüfung, dass die Google-Apps installiert sind, der Bootloader nicht ausgetauscht wurde und kein SU auf dem Gerät installiert ist. Alles drei Punkte, mit denen ein freies Handy durch fällt. Daher haben die Entwickler von microG schon versucht, mit DroidGuard Helper diese Anforderungen zu umgehen. Aber die Chancen stehen schlecht, denn gegenwärtig entspricht die Implementation von microG schon nicht mehr den Anforderungen und es ist abzusehen, dass eine Umgehung nicht mehr möglich seien wird.

Bei mir betrifft es die App der Fidor-Bank, die ich weiterhin auf einem Zweitgerät nutzen muss, welches zwar ein LineageOS nutzt, aber die Google-Apps installiert hat und ohne SU ist. Der einzige Hoffnungsschimmer war der Handelsstreit zwischen den USA und China, womit Huawei keinen Zugang mehr zu den Google Apps bekommen durfte und daher auf den in Deutschland verbreiteten Huawei-Handys die Apps mit SafetyNet-Anforderung nicht laufen.

Abwarten, aber die Menge der Schrottapps, die auf einem freien Smartphone nicht funktionieren, scheint immer größer zu werden.

Partitionsschema bei Android

Bei dem Update wurde das Partitionsschema verändert und die UMS (USB Mass Storage) auf 8 MiB verkleinert und der Speicherplatz der DATAFS zugeordnet. Mit Android 7 lagen in DATAFS die internen App-Daten (Verzeichnis /data im Android) und in UMS die Nutzerdaten (Verzeichnis /sdcard), die als interner Speicher oder interne SD-Karte benannt wurden. Mit Android 10 (vielleicht auch schon mit 8 oder 9) ist der interne Speicher ein Teil von DATAFS und wird als Bind-Mount von /data/media/0 als /sdcard eingeblendet.

Dies hat den riesigen Vorteil, dass der Benutzer jetzt Platz für den internen Speicher der Apps schaffen kann, indem er Bilder und Dokumente im internen Speicher löscht. Mit der Trennung der beiden Speicherorte war es häufig dazu gekommen, dass die Benutzer keine Apps mehr installieren konnte, weil kein Platz mehr unter /data für die Apps verfügbar war, aber keine Möglichkeit diesen irgendwie freizugeben bzw. war unter /sdcard massig frei.

Das neue Partitionsschema sieht nun wie folgt aus. Die Bedeutung einiger Partitionen wird in der Android-Dokumentation erläutert, aber viele der Namen finden sich nicht wieder; boot heißt KERNEL beim Galaxy S2. Die Partitionen SBL1 und SBL2 sind Qualcomm-spezifisch und beinhalten den Secondary stage bootloader. Das Blockschaltbild auf der Webseite verdeutlicht auch sehr anschaulich den Bootprozess.

``` text

sgdisk --print /dev/block/mmcblk0

Number Start (sector) End (sector) Size Code Name 1 8192 49151 20.0 MiB 0700 EFS 2 49152 51711 1.3 MiB 0700 SBL1 3 53248 55807 1.3 MiB 0700 SBL2 4 57344 73727 8.0 MiB 0700 PARAM 5 73728 90111 8.0 MiB 0700 KERNEL 6 90112 106495 8.0 MiB 0700 RECOVERY 7 106496 311295 100.0 MiB 0700 CACHE 8 311296 344063 16.0 MiB 0700 MODEM 9 344064 3489791 1.5 GiB 0700 FACTORYFS 10 3489792 30736383 13.0 GiB 0700 DATAFS 11 30736384 30752767 8.0 MiB 0700 UMS 12 30752768 30769151 8.0 MiB 0700 HIDDEN ```

TWRP aus dem laufenden System aktualisieren

Im XDA-Forum habe ich gelesen, dass man mit Root-Rechten auch aus dem laufenden System heraus das Recovery und Kernel aktualisieren kann:

adb push TWRP-*.img /data/local/tmp
adb shell 'dd if=/data/local/tmp/TWRP-….img of=/dev/block/by-name/RECOVERY'

adb push lineage-17.1-*_boot_magisk.img /data/local/tmp
adb shell 'dd if=/data/local/tmp/lineage-…_boot_magisk.img of=/dev/block/by-name/KERNEL'