Surnia (LTE) [ROM] LineageOS 14.1 Android 7 Nougat (Moto E LTE 2015)

[ooo]

Zum Fire Kernel kann ich nicht viel sagen. - squid2 und Alberto97 sind aber selbst sehr gute Kernel-Devs und kümmern sich um den CM-eigenen Kernel. - Da die Gesten und die LED in der ROM funktionieren, benutze ich aktuell keine fremden Kernel (mehr). - Die Sicherheitspatches für den CM-Kernel (das sind die roten Einträge im Changelog) kommen auch schneller in die aktuelle Nightly bzw. auf das Device. - Das ist mir wichtiger als z. B. 1 Prozent mehr Akku-Laufzeiit oder eine leicht höhere Performance. - Die ROM ist momentan so frisch, dass ich mir auch eher keine neuen Dependencies (Abhängigkeiten) und damit neue, fremde, potenzielle Fehlerquellen zulegen möchte. - Vllt. später ...

 

[ooo]

So, kleiner Zwischenstand:

Die Nightly @ 2016-12-09 (mit aktiviertem CM-Root-Modus und Open GApps pico vom selben Datum) hat sich die letzten 10 Stunden einwandfrei geschlagen. - Ich konnte keinerlei "echte" Fehler finden. Alle Funktionen, die Schnittstellen und die Sensoren verhalten sich erwartungsgemäß. Die SD Card Einbindung funktioniert und die Zugriffe sind performant. Alle Apps mit Zugriff können Dateien lesen, schreiben, löschen. - Die Performance der GUI ist top (mindestens so schnell, wie CM 13). - Übrigens habe ich das Device vollverschlüsselt und keinen nennenswerten Einbruch bemerkt. - Auch positiv: Das TWRP spielt bei der Initial-Verschlüsselung und der Entschlüsselung mit. - Vorher musste ich das Device unter Stock-ROM verschlüsseln, um es mit CM 13 benutzen zu können. - In gut 10 Stunden moderater Nutzung - W-LAN always on - hat das Gerät 5 % oder 0,5 %/h Akku-Kapazität verbraucht (CM 13 hatte hier im Vergleich 0,3 % Verbrauch, war aber komplett de-Google-isiert). - Das bedeutet (hochgerechnet), man verliert ca. 3-4 % bei 8 Stunden Matrazen-Horchdienst. - Ein guter Wert, wie ich finde. - Das TWRP Recovery R5 macht seine Sache ebenfalls gut, wie von squid2 zu erwarten. - Eine kleine Sache stört mich subjektiv: evtl. ist die Touchscreen-Empfindlichkeit reduziert worden. - Damit meine ich nicht die Reaktion der Apps, Widgets oder des Homescreens, sondern die Empfindlichkeit bei leichten Berührungen und die Reaktion darauf generell. - Zu bemerken sowohl am USB-Daten-Kabel als auch "ohne Leine". - Evtl. ist das so eingestellt worden, weil Besitzer anderer Moto-Modelle Probleme mit hochempfindlichen und zu schnell reagierenden Displays haben (z. B. Stock-ROM von Moto G 3 und Moto G 4)?

Heute kam gleich ein OTA-Update Nightly @ 2016-12-10 angeflogen, das ebenfalls im Zusammenspiel mit dem neuen TWRP Recovery sauber durchlief. - Das Changelog dazu quittierte dessen Anforderung im CM Updater allerdings (noch) mit einer "404 - Page not found"-Fehler-Meldung. - Das ist nicht tragisch, weil erst heute das Moto E 2nd Gen. von den CM 13 Changelogs entfernt und bei CM 14.1 hinzugefügt wurde. - Das wird in nächster Zeit wohl hinter den Kulissen korrigiert. - Die Code-Änderungen sind eher marginal, aber die (auf der Webpage) im Changelog oben rechts über das Options-Menü einblendbaren Änderungen zu den Translations sind ca. einen Kilometer lang. - Das heißt, dass "über Nacht" jede Menge fehlender Übersetzungen geliefert wurden, die in der heutigen Nightly die Stimmung weiter heben dürften.

Ich bin jedenfalls sehr zufrieden und das ist bei mir selten der Fall bei einer so frischen ROM.

 

[guenter1]

Auch bei mir alles im grünen Bereich.

Ich kam von der nicht offiziellen Variante, ein dirty flashen führte zu Fehlern. Er ein komplettes wippen inkl. SD-Karte führte dann zu einem stabilen System.

 

[alterbesen]

Hab auch gerade mein erstes Update auf cm-14.1-20161210-NIGHTLY gemacht ,puhhh ging alles gut
Ich bin begeistert da hakt nix mehr wie beim Stock Rom,klar hab auch mehr Speicher jetzt.
Das geht aber zügig weiter mit den Updates wenn man die Log Seite so sieht :

CM14.1 Nightlies Changelog - Surnia

 

[guenter1]

In XDA gibt es nun einen offiziellen Thread:
[ROM][OFFICIAL][surnia] CyanogenMod 14.1 for Moto E LTE

 

[ooo]

Merci, hab' den Link im OP angepasst.

 

[-FuFu-]

Hab mich dann auch mal entschlossen nun wo es die nighlys gibt auf 14.1 zu gehen und bisher scheint alles so zu laufen wie es soll.
SuperSU + viper4android laufen bisher auch ohne probleme

Zur akkulaufzeit kann ich aktuell noch nichts sagen, da ich noch zuviel am rumspielen bin und der verbrauch so doch etwas höher ist ^^
Geflasht ist die nightly vom 10.12 mit den nano open gapps vom 10.12, FireKernel r7.0, SuperSU v2.78-SR5 und viper4android 2.5.0.5 (Link zur Anleitung + Infos)

Mal sehen wie sich das ganze so in den nächsten Tagen verhält und was es so an neuen spielereien zu entdecken gibt

 

[ooo]

Das ist gut, dass du den Fire Kernel, SuperSU SR5 und Viper4Android einsetzt. - Damit haben wir dann einen direkten Vergleich zwischen einer aufgebohrten ROM (deine Konfiguration) und der blanken Basis-ROM.

Bei mir hat sich SuperSU SR5 sauber installieren lassen und ist korrekt in den Homescreen gestartet, danach aber nach dem ersten regulären Neustart meinerseits ausgestiegen. - Das hat sich durch einen schwarzen Screen (mit "Button" Dreieck nach links (Back) ohne eingeblendete Navigations-Buttons/-Leiste bemerkbar gemacht. - Die Benachrichtigungen (Leiste) samt den Quick-Toggles konnte ich zwar benutzen, haben dann aber nirgendwohin geführt (umschalten/aufrufen - z. B. die Einstellungen - ging, die Anzeige blieb aber identisch, also unbenutzbar = Folge: Factory Reset machen). - Eventuell stimmt auch etwas noch nicht so richtig mit den SE Linux Contexts (strict mode ist ja aktiv) im Zusammenhang mit SuperSU und mit dem Fire Kernel macht sich das dann nicht bemerkbar.

 

[alterbesen]

Gleich mal nachgefragt .. wozu installiert ihr SuperSu man hat doch auch so Root ,oder brauchen manche Apps SuperSu sonst laufen sie nicht ?

 

[ooo]

Bestimmte (nicht-konforme bzw. veraltete) Root-Apps sind ein Grund. - Wenn man diese Apps nicht einsetzt bzw. einen Ersatz nimmt, benötigt man SuperSU nicht.

Bei mir kommt als weiterer Grund hinzu, das ich init.d-Shell-Scripte starten möchte, die bereits kurz nach dem Start des Phones aufgerufen werden, noch bevor Android selbst gestartet wird; z. B. um die Firewall-Regeln (iptables) so zu setzen, dass alles geblockt wird, bis die Firewall-App (unter Android) startet und den weiteren Schutz übernimmt. - Davor startende Apps können sonst bereits mit dem Internet kommunizieren und evtl. Daten heraus schmuggeln oder Malware nachladen; nur als extremes Beispiel.

So etwas - diese init.d-Shell-Scripte einrichten - ging früher einfacher. - Heute machen die SE Linux Berechtigungen im "strict mode" einen Strich durch die Rechnung (Scripte werden nicht ausgeführt, da ROM-fremd) und man müsste sich mit den SE Linux-Permissions/-Policies der ROM herumschlagen (komplexes Thema).

Einfacher ist das mit SuperSU (auch in CM 14.1, strict mode), weil man dann eigene ausführbare Start-Scripte nach /su/su.d/ kopieren kann und diese bei installiertem SuperSU ohne Probleme ausgeführt werden.
___

Wenn man das alles nicht benötigt (aktuelle Apps, keine Shell-Start-Scripte), dann kann man den CM-Root-Modus der ROM aktivieren und SuperSU komplett weglassen ...

 

[Lenneth]

Habe die heutige Nightly via OTA (ich weiß, ich weiß ..) direkt übers Device geflasht. Nach ca. 3-4 Minuten Pulsieren des CM-Kopfes beim Reboot erleichtert festgestellt, dass scheinbar alle (?) oder zumindest die meisten noch nicht übersetzten Textstrings nun auf Deutsch sind und auf einmal die Galerie bei mir wieder funzt. Aufgenommene Videos werden anstandslos abgespielt, wobei ich OpenCamera statt der Google Kamera-Software verwende.

Ist vermutlich wohl schon vorher gefixt geworden und ich habe die Changelogs nicht richtig gelesen, das aber nur als Anmerkung.
Sehr cool, wie unser Nischengerät so schön und immer mit Updates versorgt wird und trotz (nur) 1 GB RAM gut funktioniert. Kudos an die CM-Entwickler bzw. Modder. Das nur so am Rande.

 

[alterbesen]

Bei xda hab ich gesehen das ein User eine recht alte TWRP hat ( 2.8.5 ) stand da ..Frage,wie macht man eigentlich ein Update vom TWRP ?
Ich würde einfach mit "fastboot flash recovery.... " die Neue Version drüber flashen
Ist das so richtig ?

 

[guenter1]

Vom Prinzip her ja, wie bei einer Neuinstallation.

 

[N008]

Klasse, dass es mit Nougat für unser Moto E 2015 nun doch so schnell ging.

CM 14.1 habe ich vor kurzem einmal ausprobiert, bin aber wieder zurück zu CM 13.0, um auf den Release einer offiziellen Nightly zu warten, da trotz geringer Qualität der uneingeschränkte Einsatz der Kamera App sehr wichtig für mich ist. Gestern Abend habe ich meine Surnia von Grund auf neu eingerichtet, was nicht ganz unkompliziert war.

Nachdem ich den kompletten internen Speicher gewipet hatte, habe ich die gestern aktuelle Nightly und SuperSU (aus ähnlichen Motiven wie @ooo) installiert. Die Installation ging wirklich flott und das System startete zügig. Das Verschlüsseln anschließend hat jedoch nicht auf Anhieb funktioniert, das Gerät blieb im Bootvorgang hängen. Auch gelang ich nicht mehr ins per Fastboot gestartete TWRP. Über das Stock Recovery System setzte ich das Gerät auf Werkseinstellungen zurück und begann den Vorgang des Verschlüsseln erneut. Diesmal mit Erfolg. Allerdings war nun SuperSU selbstverständlich verschwunden. Zusammen mit @ooo flashbarer ZIP fürs Swipen, was bei mir auch nicht out of the box möglich war, holte ich das nach und konnte die übrigen Einstellungen vornehmen.

Ich kann den Eindruck bestätigen, dass die Bedienung einen flotteren Eindruck macht. Dies kann natürlich mit Änderungen an den Animationen zusammenhängen. Dennoch hakt nach meinem Eindruck das Gerät weniger bzw. gar nicht, wenn man etwas gleichzeitig alle geöffneten Anwendung schließt. Hier habe ich auch einen ersten kleinen Punkt gefunden, der mich stört. Ich hatte mich schon sehr gewöhnt, über das Quadrat rechts in der Navigationsleiste zwischen den geöffneten Apps hin und her zu wechseln. Diese Tastenbelegungen kann man aber leider nicht ändern (die Funktion ist ausgegraut) im Gegensatz zum Homebutton, den ich aufgrund der Position dafür als nicht ganz so komfortabel erachte.

Leider funktioniert die eine oder andere App noch nicht vollständig, aber es gibt bekanntlich für alles Alternativen (kennt jemand einen performanteren und optisch etwas attraktiveren File Manager?). Bezüglich SuperSU, AFWall+ und initd. habe ich zudem eine Frage: Wenn ich in der Firewall unter "Experimentell" die Funktion "Start-Datenleck beheben" aktivieren möchte, erhalte ich die Fehlermeldung: "Installieren des Startup-Skripts nicht möglich. Bitte stellen Sie sicher, dass Ihr ROM/Kernel init.d/su.d unterstützt!", ist diese Funktion unter CM 14.1 obsolet, oder gibt es ein work around?

 

[-FuFu-]

Ich nutze SuperSU aus den von @ooo genannten Gründen, das starten von Scripten. Benötigt nicht jeder aber ist ne feine Sache.
Weiterhin gibt es Apps die nicht immer mit den in CM integrierten Rootverwalter klarkommen. Hinzu kommt, das ich noch "Magisk" nutze und da muss man eben nen anderen Rootmanager nutzen und da ich SuperSU Pro habe, würde ich das auch gerne nutzen
Und @ooo wurde SuperSU Systemless installiert? Notfalls kann man das ja erzwingen, per Terminal einfach folgendes eingeben:

echo SYSTEMLESS=true>>/data/.supersu

Soweit ist das hier sehe, wird durch den FireKernel (oder maybe auch durch Viper4Android) der SELinux Status auf "Moderat" gesetzt, was die "Sicherheit" beeinträchtigen kann, solange man aber nicht Apps aus "den dunklen Ecken des Internets" nutzt und etwas aufpasst, was man so installiert, sollte man auch recht sicher sein, aber Sicherheit ist denke ich mal ein Thema für sich, wo viele Menschen viele verschiedene Ansichten haben

AFWall+ läuft auch bisher ohne Probleme und @N008 wegen dem "Start-Datenleck beheben" funktion habe ich garnicht geschaut aber ich glaube das genau das script, was dort dann erstellt wird in dem "init.d pack for stock rom" von ooo mit drin ist, das kann man notfalls dann per Hand rüber kopieren und die Rechte setzten.
Als Filebrowser nutze ich seit je her den RootExplorer, meiner Meinung nach einer der Besten Dateimanager für Android (jeder hat seinen Favoriten) und meiner Meinung nach ist er sein Geld Wert.


Eine Sache die mir noch aufgefallen ist, ich nutze den Kernel Auditor um ein paar Werte anzupassen und wenn ich nun die CPU Frequenzwerte anpasse, passiert es zu 90% das der Min Wert nicht wirklich übernommen wird, denn wenn man das Display ausschaltet und wieder Aktiviert setzt sich der Wert sogut wie immer auf 800mhz zurück, das selbe hatte ich auch unter CM13 beobachtet und hab nie wirklich eine Lösung dafür gefunden.
Das es am Kernel liegt kann ich ausschliessen, das selbe passiert auch mit dem CM Kernel, oder was nätürlich möglich ist, ist das es ein Kernel Default ist, der nach dem "aufwecken" immer wieder gesetzt wird, was etwas blöd wäre, da dort noch halt etwas potential ist Akku zu sparen.


Akku Laufzeit scheint ganz gut zu sein, über die letzte Nacht (9 Stunden) waren 4% Akku weg und aktuell bin ich bei 86% nach moderater nutzung (etwas Whatsapp, paar kleinere Videos und bisschen rumspielen in ein paar Einstellungen.
Mal sehen wann ich zum updaten auf die neuste nightly komme aber solange ich keine größeren Probleme/Fehler habe und es keine "gravirenden" Änderungen gibt, kann ich da auch etwas warten.

 

[ooo]

Allerdings war nun SuperSU selbstverständlich verschwunden. Zusammen mit @ooo flashbarer ZIP fürs Swipen, was bei mir auch nicht out of the box möglich war, holte ich das nach und konnte die übrigen Einstellungen vornehmen.

Fragen:
1. Mein swipe-Zip für CM 13, der die Wischfunktionalität zum Schreiben mit der Standard AOSP-Tastatur nachrüstet, funktioniert auch in der CM 14.1 ROM?

2. Nachdem du SuperSU verloren hast: Hast du (es klingt in deinem Text so) die SuperSU *nochmal* nachinstalliert und es funktioniert jetzt? - Oder bezog sich das auf die Wisch-Funktionalität der Tastatur (ohne Google Apps installiert zu haben)?

3. Wenn ja (SuperSU nochmal installiert und funktioniert), welche SuperSU Version war das *exakt*?​

___

Hier habe ich auch einen ersten kleinen Punkt gefunden, der mich stört. Ich hatte mich schon sehr gewöhnt, über das Quadrat rechts in der Navigationsleiste zwischen den geöffneten Apps hin und her zu wechseln

Wenn du meinst, zwischen der gerade aktiven App und der davor umschalten zu können, dann geht das, wenn man zwei Mal das Quadrat hintereinander antippt.

Wenn man das Quadrat laaaaange drückt, kommt man in den Split-Screen-Modus (Multiple Windows Modus). - Das ist manchmal ganz praktisch, um z. B. via Copy&Paste etwas (markierter Text) von einer App in die andere übertragen zu können oder Inhalte zu dokumentieren (Screenshot) oder parallel zu lesen (vergleichen). - Die schwarze Linie in diesem Modus kann man anfassen und verschieben, um die Fenstergrößen zu verändern.​

___

Bezüglich SuperSU, AFWall+ und initd. habe ich zudem eine Frage: Wenn ich in der Firewall unter "Experimentell" die Funktion "Start-Datenleck beheben" aktivieren möchte, erhalte ich die Fehlermeldung: "Installieren des Startup-Skripts nicht möglich. Bitte stellen Sie sicher, dass Ihr ROM/Kernel init.d/su.d unterstützt!", ist diese Funktion unter CM 14.1 obsolet, oder gibt es ein work around?

Das kommt daher, dass SuperSU evtl. nicht / nicht mehr / fehlerhaft installiert wurde. - Gibt es denn ein Verzeichnis /system/etc/init.d/ bzw. ein Verzeichnis /su/su.d/ bei dir? - Dort möchte AFWall+ v2.9.0 (aktuell neueste Release) die Datei afwallstart anlegen. Hat man das geschafft, funktioniert /system/etc/init.d/afwallstart übrigens nicht, wegen den SE Linux Contexts. - AFWall+ weiß das und legt die Datei normalerweise in /su/su.d/ an. Vorausgesetzt, SuperSU wurde fehlerfrei system-less installiert. - SR5-SuperSU.zip macht das (in dieser ROM) inzwischen automatisch. - Aber, wie geschrieben, momentan geht es - bei mir - nicht. - Ohne /su/su.d/ kann man den Datenleck-Fix von AFWall+ *nicht* korrekt aktivieren.​

___

Und @ooo wurde SuperSU Systemless installiert?

@-FuFu- , wenn du mich meinst - ja, bzw. s. o. bzw. siehe (inzwischen) Tipp dazu im Start-Posting (hab' ich nachträglich "reingeschmuggelt").​

___

echo SYSTEMLESS=true>>/data/.supersu

Nicht nötig bei SR5-SuperSU.zip (s. o.)

Kleiner Tipp:

Wenn man ">>" benutzt und z. B. nach einem OTA-Update "nachrooten" muss, dann wird jedes Mal eine neue Zeile "SYSTEMLESS=true" an die Datei /data/.supersu angehängt ... (was schlecht ist).

Besser mit einfacher Klammer (">") arbeiten, zumindest aber den Inhalt von /data/.supersu auf doppelte Einträge überprüfen (doppelte Einträge kann gut gehen, muss aber nicht).​

___

"init.d pack for stock rom" von ooo

Ich habe kein Zip/Pack zu dem Thema? - Was meinst du damit? - Oder habe ich etwas vergessen, was ich mal produziert habe? - Link?

(Evtl. meinst du die Nachrüstung der Swipe-Funktion der AOSP-Standard-Tastatur.)​

___

ich nutze den Kernel Auditor um ein paar Werte anzupassen und wenn ich nun die CPU Frequenzwerte anpasse, passiert es zu 90% das der Min Wert nicht wirklich übernommen wird
[...]
Das es am Kernel liegt kann ich ausschliessen, das selbe passiert auch mit dem CM Kernel

Welchen CM Kernel hast du hier getestet: CM 13 Kernel oder auch schon den CM 14.1 Kernel?

(Evtl. ist Kernel Audiutor als App auch noch nicht soweit, obwohl der Dev gut und schnell ist?)​

[doublepost=1481491565,1481489950][/doublepost]
___

@-FuFu- - Ah, falls du mit "ooo's init.d pack" das hier meinst: Bitte (mit aktuellen SuperSU.zips) *nicht* mehr benutzen, das schafft evtl. Probleme (war für ältere SuperSU und Stock-ROMs gedacht) ...

 

[-FuFu-]

Jap, ich glaub das war das pack ich hab hier nen Ordner wo ich alles mögliche sammel.
Ich hab ja auch nicht gesagt das man das komplette pack nutzen soll, sondern das dadrin das startscript für die AFWall+ ist, was man notfalls dann per Hand kopieren kann, wenn es garnicht anders geht
Ich nutze immer eine selbst zusammen gebaute zip mit scripten und co, die ich auf das jeweilige Rom anpasse, besonders da ich sehr oft den Launcher austausche.

Das verhalten mit der Min Frequenz hatte ich wie gesagt unter CM13 am ende auch beobachtet und dort auch mit 3 verschiedenen Kerneln, squit, FireKernel und original CM Kernel.
Unter CM14 gibt es ja derzeit nur den original CM Kernel und den FireKernel und bei beiden habe ich das verhalten beobachtet.
Ich teste da natürlich noch rum um zu sehen ob es ein "Benutzer Fehler" ist aber selbst wenn ich nur diesen einen Wert anpasse setzt er das oft nach dem aufwachen zurück, nur halt nicht immer...
Aktuell habe ich im Kernel Auditor das ganze mal als "Profil" hinterlegt und dieses aktiviert, das es beim Start ausgeführt wird und bisher ist die Min Frequenz bei 400 geblieben. Ich wüsste auch aktuell nicht wirklich wie ich das ganze genauer beobachten sollt oder was das problem sein könnte.
Eventuell werde ich die Werte die Kernel Auditor anwendet mal als Startscript einbinden und Kernel Auditor deaktivieren um zu schauen ob es an der App liegt oder ob Werte nicht richtig gesetzt werden.
Mal sehen was dabei raus kommt.


Und wegen dem "echo" Befehl, den hatte ich kopiert gehabt von einem workaround, wie man SuperSU eben systemless installiert, und soweit ich es beobachten konnte wird die angelegte Datei wieder entfernt nach dem installieren, zumindest ist sie bei mit danach immer weg und bevor ich befehle nutze schaue ich ja auch nach ob die entsprechende Datei da ist oder nicht.

 

[ooo]

Ich hab ja auch nicht gesagt das man das komplette pack nutzen soll, sondern das dadrin das startscript für die AFWall+ ist, was man notfalls dann per Hand kopieren kann, wenn es garnicht anders geht

Bitte nicht (mehr) nehmen. - Das aktuelle afwallstart hat sich seither inhaltlich verändert, um bestimmte Lücken zu schließen.
Hier ein neueres (von AFWall+ v2.9.0 erzeugt):

Inhalt der Datei afwallstart

#!/system/bin/sh

export PATH=/system/bin

startDt="$(head -n 1 /proc/uptime | cut -d . -f 1)"
while :
do
  if [ -d /data/data/com.android.providers.downloads ]
  then
    break
  fi
  sleep 1
done
endDt="$(head -n 1 /proc/uptime | cut -d . -f 1)"

if [ -e /data/data/dev.ukanth.ufirewall/app_bin/iptables ]; then
  path="dev.ukanth.ufirewall"
elif [ -e /data/data/dev.ukanth.ufirewall.donate/app_bin/iptables ]; then
  path="dev.ukanth.ufirewall.donate"
else
  log -p i -t afwall "AFWall does not seem to be installed, waited for $((endDt-startDt)) seconds."
  exit
fi

log -p i -t afwall "Waited $((endDt-startDt)) seconds for /data/data."

doit() {
  for i in "$@"
  do
    if [ -x "$i" ]
    then
      "$i" -wP INPUT DROP
      "$i" -wP OUTPUT DROP
      "$i" -wP FORWARD DROP
      return
    fi
  done
}

doit /system/bin/iptables /data/data/$path/app_bin/iptables
doit /system/bin/ip6tables /data/data/$path/app_bin/ip6tables
log -p i -t afwall "IPv4/6 policy set to DROP"

[doublepost=1481509221,1481507920][/doublepost]

___

Hier mal ein paar Impressionen zum Akku und Google (ich bin überrascht):

1,5 Tage sehr moderate Nutzung, Google Services sind nicht mal ansatzweise zu sehen in der Übersicht (trotz 39 Stunden Laufzeit im Background).

 

[guenter1]

@ooo: Nur um sicher zu gehen: mit der aktuellen Beta von SuperSU wird automatisch / immer "systemless" installiert? Ist dem so oder gibt es eine Schraube

 

[ooo]

Nein. - Die "Zwangs-Schraube" ist bei Marshmallow/Nougat ROMs allgemein das Flag SYSTEMLESS=true in /data/.supersu zu setzen, um system-less zu erreichen. - system-less bedeutet, dass nur das boot-Image (die boot-Partition) gepatcht/verändert wird, aber die system-Partition wird nicht angefasst. - Das Gegenteil ist system-mode (bzw. SYSTEMLESS=false).

(Eine Lollipop-ROM wird i. d. R. immer im system-mode gerootet, hat also eine veränderte system-Partition, der Schalter wird nicht beachtet.)

In der CM 14.1 ROM des Moto E (XT1524, surnia) wird aber auch ohne den Eintrag in /data/.supersu bzw. ganz ohne die Datei /data/.supersu vom SR5-SuperSU.zip system-less gerootet.

Beim Rooten anderer ROMs (Stock-ROM) muss man die Datei evtl. anlegen, bevor man rootet, um system-less zu erreichen.
Also zu rooten ohne die system-Partition zu verändern.

Nicht machen:
Beim Moto E führt ein Rooten im system-mode (explizites SYSTEMLESS=false) zu einem nicht mehr startenden Device.
(Folge: Stock boot- und system-Images via fastboot flashen bzw. via TWRP wipen und <CM ROM>.zip installieren.)
___

Es gibt folgende generische Download-Links bei Chainfire (generisch = jeweils aktuellste Version):

http://download.chainfire.eu/supersu
http://download.chainfire.eu/supersu-stable
http://download.chainfire.eu/supersu-beta​

___

Diese Schalter | Flags | Switches gibt es, soweit ich weiß:

# Overridable variables (shell, /system/.supersu, /cache/.supersu, /data/.supersu):
#   SYSTEMLESS - Do a system-less install? (true/false, 6.0+ only)
#   PATCHBOOTIMAGE - Automatically patch boot image? (true/false, SYSTEMLESS only)
#   BOOTIMAGE - Boot image location (PATCHBOOTIMAGE only)
#   STOCKBOOTIMAGE - Stock boot image location (PATCHBOOTIMAGE only)
#   BINDSYSTEMXBIN - Poor man's overlay on /system/xbin (true/false, SYSTEMLESS only)
#   PERMISSIVE - Set sepolicy to fake-permissive (true/false, PATCHBOOTIMAGE only)
#   KEEPVERITY - Do not remove dm-verity (true/false, PATCHBOOTIMAGE only)
#   KEEPFORCEENCRYPT - Do not replace forceencrypt with encryptable (true/false, PATCHBOOTIMAGE only)
# Shell overrides all, /data/.supersu overrides /cache/.supersu overrides /system/.supersu