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

[-FuFu-]

Ich hab die Dateien der AFWall+ nie wirklich verglichen, da es bei mir immer so klappte aber ja, man sollte immer versuchen an die neusten Versionen zu kommen und hier im Forum findet sich ja immer jemand der sie Teilen kann

Und ja, Akkuverbrauch ist ganz ordentlich bei cm14.1, nach 8 Stunden bin ich noch bei 83%, wobei bei mir aber die Google Dienste an 2 Stelle stehen aber mein Musik Player wird erst garnicht angezeigt obwohl er 2 Stunden lief... Naja mal weiter beobachten ^^ Top Verbraucher ist Whatsapp und Platz 3 geht an das Display. Viel mehr wie Whatsapp und Musik hören mache ich auch kaum in der Woche (und bisschen Sudoku spielen ) und da sollte der Akku 2 Tage schaffen.

Im großen und ganzen läuft das Rom stabil, bisher keine Fehler gefunden, bis auf das ein oder andere was noch nicht ganz eingedeutscht ist, wo ich gut mit leben kann

 

[N008]

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?

Korrekt. Deine ZIP-Datei aus der Anleitung zum Flashen von CM 13.0 funktioniert und überlebt auch den dirty flash einer neuen nightly.

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)?

Ja, ich habe SuperSU dann noch einmal installiert und es funktioniert ansonsten problemlos. Ich habe keinerlei GAPPS installiert.

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

Das erneute Flashen der Datei SR5-SuperSU-v2.78-SR5-20161130091551.zip war nicht erfolgreich, die angesprochene Einstellung unter AFWall+ lässt sich weiterhin nicht installieren. Die beiden Verzeichnisse /system/etc/init.d/ (enthält die beiden Dateien 00banner und 90userinit) und /su/su.d/ (leer) wurden angelegt.
Ich werde mir heute Abend einmal in Ruhe mit dem manuellen Einfügen des Scripts in das Verzeichnis /su/su.d/ beschäftigen und es ausprobieren.

Vielen Dank übrigens noch für den Hinweis mit dem Doppelklick auf das Quadrat, @ooo.

Beim Herumspielen sind mir noch ein paar weitere Kleinigkeiten aufgefallen. UnifiedNlp (com.google.android.gms) aus dem F-Droid-Store kann mit dem Hinweis, es sei nicht im System eingebunden/registriert, mein Gerät nicht dabei unterstützen, anhand einer lokal auf meiner SD-Karte abgelegten SQLite-Datei einen GPS-Fix zu finden. Der von der App empfohlene Neustart hat den Fehler nicht behoben.
Ferner funktioniert das Einbinden meiner frisch formatierten SD-Karte als mobiler Speicher nicht vollständig. Der FX File Explorer (nextapp.fx) stürzt ab, wenn ich Schreibrechte eintragen möchte. Die Cyanogenmod-Systemeinstellungen stürzen ebenfalls ab, wenn ich unter Gerätespeicher auf mobiler Speicher klicke. Mit dem Dateimanager von Cyanogenmod selbst habe ich jedoch Zugriff auf die Karte. Insofern ist das eher ein Problemchen.

Ach, ja… Mir ist außerdem aufgefallen, dass die Funktion geschützte Apps derzeit nicht funktioniert. Die dort eingetragenen Apps verschwinden zwar aus dem App-Drawer, werden sie aber bspw. durch das Öffnen einer Datei oder von einer anderen App gestartet, erscheint keine Aufforderung zum Entsperren per Geste o.ä. Ich glaube, das ist ein Bug und kein Feature.

So viel erst einmal vom Ausprobieren der letzten Tage meinerseits. ​

 

[alterbesen]

Wenn ich in das Benachrichtigungs - LED Menü gehe kann ich dort apps hinzufügen,rechts oben + ,das klappt auch.
Nur so wie ich mir das vorstelle soll wohl die LED blinken wenn diese Apps gestartet werden oder Nachrichten über diese apps kommen,das klappt nicht.
Ich hab mal von dem Menü ein Screenshot gemacht

 

[-FuFu-]

Ich hab nochmal wegen dem AFWall+ geschaut, bei mir installierte er das startscript über die Einstellungen "Expermimentel", nicht beim ersten mal, und der Grund war, das AFWall+ aus welchen Gründen auch immer keine richtige rootanfrage sendete und SuperSU nicht aufpopte.
Nach einem Blick in die SuperSU App hab ich gesehene, das AFWall+ weiterhin auf "anfrage" stand, dort auf erlaubt gestellt, reboot und dann ging es.
Allerdings wird das script dann nach /system/etc/init.d kopiert, hab es dann per hand nach /su/su.d kopiert.

Hab auch auf die nightly vom 12.12 geupdatet, soweit alles gut und wieso auch immer, scheint die Min cpu frequenz nun auch bei 400 zu bleiben (war aber schon vor dem update so) seit ich es im Kernel Auditor aus Profil gespeichert habe, was beim start gesetzt wird, werd das aber weiter beobachten.

Das mit der Benachrichtigungs LED ist eine komische sache irgendwie, mal gehts, mal nicht. Ich hab da schon vor längerem die App "Light Manager" genutzt, die auch unter Stock Roms helfen kann. Ist zwar unschön auf eine andere App auszuweichen, aber naja, immer in einstellungen rumspielen und fehler suchen ist dann irgendwann zu aufwendig für mich.

 

[Moto_Karl]

Eine Frage zur Installation !??

Ich habe zurzeit die CM12.1 installiert, benötige ich zwingend das Original Marshmallow vor dem Update auf CM14.1 oder kann ich direkt von 12.1 auf 14.1

Vielen Dank !

 

[ooo]

Nein, man kann sein CM 12 nicht behalten und auf CM 14 aktualisieren.
___

Spoiler

Für CM 13 benötigte man bereits mindestens die originale Modem-Firmware von Motorola Android 5.1
Die europäischen Motos hatten aber maximal Lollipop 5.0.2.
Erst nach der Upgrade-Verteilung von Marshmallow 6.0 konnte man CM 13 ohne Probleme benutzen.

Der aktuelle Nachfolger CM 14.1 erfordert also mindestens Marshmallow seitens Motorola Firmware.

Modem Firmware und Anleitung gibt es z. B. hier bei @-FuFu-

[Sammlung] Firmware, Tools & Co

Anleitung​

___

Da man die CM 14.1 sowieso "clean" installieren muss (= alles löschen), kann man vorher auch zunächst eine originale Motorola Marshmallow Firmware (Android 6.0) komplett flashen.

Flash-Anleitung für originale Motorola ROM zu Marshmallow 6.0:
Nur "SPOILER Teil 1 - Marshmallow ROM installieren - Bootloader noch entsperrt" abarbeiten!
Den Rest nicht!
Surnia (LTE) - Sperrung des Bootloaders mit originaler Motorola Firmware Android 6.0 (retde/reteu) [E 2015][XT1524]​

Oder eben "klein" anfangen und nur die Modem Firmware installieren, dann trotzdem Werksreset ...

Evtl. vorher immer ein TWRP Backup machen, klar. - Danach dann CM 14.1 laut Anleitung im Start-Posting installieren.

___

Alter Hinweis vom Entwickler zu CM 13

Installation Instructions - Post #2​

Aktuelle Hinweise vom Entwickler zu CM 14.1

This is our port of CyanogenMod 14.1 to the 2015 Moto E LTE (surnia). This ROM should run reliably, provided you are running a modem from 5.1 or newer.

und

CM14.1 upgrade requires clean install - Post #1463

Please perform a clean install (wipe data and cache) when switching

(Gemeint ist ein Werksreset = alle alten Daten futsch)​

 

[-FuFu-]

Das flashen des Modems hab ich ja so einfach wie möglich gemacht (finde ich zumindest ) und geht auch recht schnell.
Bei fragen dazu findet man hier immer schnell hilfe, falls da noch fragen offen sind.
Und als kleine ergänzung, man sollte die aktuelle TWRP Version nutzen/flashen (Squid TWRP for Styx LTE - xda-developers DevDB) fals dort hilfe benötigt wird, helf ich da auch weiter (oder jemand anders der dann schneller ist )

Ich hab dann heute morgen auch mal auf die nightly vom 13.12 geupdatet, läuft weiterhin wie zuvor alles super ^^
Bin aber auch noch nicht wirklich zum testen gekommen heute.
Solange in den nächstene Tagen keine gravierenden Änderungen kommen, werde ich bis zum WE wohl mal nicht updaten
Aber das problem mit der Min frequenz hab ich weiterhin -.- cpuz sagt 800mhz und ich muss dann per Kernel Auditor erst wieder mein Profil neu anwenden... Ich glaub ich geb es auf da irgendwas einzustellen... immerhin funktioniert "Hot Plug" und er schaltet cpu kerne ab bei geringer nutzung, spart ja auch etwas akku...
Vielleicht komme ich da irgendwann mal zu das genauer zu untersuchen, da es auch nur der 1 Wert ist, der irgendwie nicht übernommen wird.

 

[Lenneth]

Ich hätte eine Frage zur Verschlüsselung unter CM 14.1 für unser geliebtes Surnia, sonst hätte einen Thread woanders aufgemacht..

Schon seit einiger Zeit habe ich mich immer ein wenig eingelesen in das Thema (natürlich nur oberflächlich, da Kryptographie ja nun für uns "Normal-User" abseits von IT-Studierten und -Interessierten schon etwas komplizierter ist)

Wenn ich das Device verschlüsseln möchte, verlangt das OS, dass ich eine PIN setze, was ja auch logisch ist - was bringt einem beste Encryption, wenn da jeder frohlich per ADB oder simpelst übers Gerät an die Daten herankommt?

Ist diese PIN dann zwingend gleichzeitig der Entsperrcode fürs Display oder hat man die Möglichkeit zum Boot ein *zusätzliches* Passwort zu setzen? Ich weiß, dass es sicherheitstechnisch ein Kompromiss wäre, beim Boot ein langes, sicheres Passwort zu nehmen (da man damit auch ein Brute Force via TWRP erschwert würde) und eine simple, vierstellige PIN beim Unlock von Display.
Die Idee wäre eben: Rebioot -> Schön lang und relativ sicher, da ich das Smartphone nur selten neustarte, fürs Display ein semi-langes PW oder Zahlencode.

Aber es würde doch extrem nerven, zwar die Verschlüsselung nutzen zu können, aber jedesmal wenn man das Handy rauskramt, ein ellenlanges Passwort einzutippen (auf Hardware-Tastatur geht es ja noch)?
Dabei gehöre ich NICHT zu den Zombies, die überall alle 2 Minuten ihr Whatsapp oder so öffnet, um zu gucken, wer wann was geschrieben hat

 

[N008]

Du kannst bekanntlich zum Entsperren des Displays zwischen einfachem Wischen (nicht sicher), einem Muster, einer PIN (muss nicht der PIN der SIM entsprechen) und einem Passwort wählen. Selbstverständlich entspricht das gewählte Verfahren auch zum Entschlüsseln. Wenn Du also Zugang zu Deinem Device haben möchtest, um etwa zu telefonieren, Musik zu hören oder zu surfen, musst du bspw. nur eine PIN eingeben und erhältst Zugriff. Die zusätzliche Eingabe etwa eines Passworts ist nicht notwendig. Um dies klarzustellen: Das gewählte Entsperrverfahren ist immer auch das Entsperrverfahren für die Verschlüsselung (etwa beim Booten des Devices oder von TWRP).

 

[Lenneth]

Gut zu wissen. Hatte das nämlich verwechselt mit einer zusätzlichen Sicherheitsschicht (ergo: Bei Boot eine Art "BIOS-Passwort" eingeben, das völlig unabhängig vom gewählten Code für das Gerät gilt. Mit dem Unterschied, dass durch die Verschlüsselung das Smartphone - theoretisch - sicher sein sollte).

Mal gucken, werde mir dann versuchen nen Pass oder PIN zu überlegen, der weder zu kurz ist noch zu kompliziert zu merken/einzugeben ist. Nicht, dass ich jemals ein Handy verloren hätte, theoretisch aber durchaus denkbar. Aber wenn man schon *halbwegs* versucht, datensparsam auf dem Desktop wie auch mobil zu arbeiten, klingt das Thema Verschlüsselung schon interessant.

 

[ooo]

Ist diese PIN dann zwingend gleichzeitig der Entsperrcode fürs Display oder hat man die Möglichkeit zum Boot ein *zusätzliches* Passwort zu setzen?

Das Setzen von zwei unterschiedlichen PINs (Passwörtern, Mustern) ist möglich:

Spoiler

Möglichkeit 1 (geht bei mir nicht):

• Telefon verschlüsseln (wenn noch nicht erfolgt)
  
• Einstellungen > Sicherheit > Displaysperre > PIN > Falls "Sicherer Start" abgefragt wird: "PIN zum Starten des Geräts erforderlich" wählen > Superschwere PIN > einrichten
• Superschwere PIN testen (Bildschirmsperre, Start in das TWRP Recovery, Neustart)
• Einstellungen > Sicherheit > Displaysperre > PIN > Sicherer Start > "Nein danke" wählen (<= Das ist der "Trick") > PIN ändern auf einfache PIN
  (Man kann hier auch abweichend "Passwort" - nicht länger als 16 "normale" Zeichen - oder "Muster" nehmen, die superschwere PIN bleibt beim Start erhalten.)

Dadurch wird die zuvor eingerichtete superschwere PIN bei einem Neustart bzw. Start in das TWRP Recovery beibehalten (also abgefragt), aber die einfache PIN nur beim Entsperren des Bildschirms verwendet.

Auch wenn man danach die Displaysperre wieder auf "Wischen" oder "Keine" umstellt, wird beim Start immer noch die superschwere PIN abgefragt.

Um das auch wieder wegzubekommen, muss man die exakte, ursprüngliche Displaysperre für die superschwere PIN wieder einrichten - diesmal aber mit "PIN zum Starten des Geräts erforderlich" - und (wichtig) dabei die bereits bekannte (beim Start verwendete) superschwere PIN wieder eingeben, einmal neu starten und dann die Displaysperre wieder auf "Wischen" oder "Keine" setzen.
___

Möglichkeit 2 (geht bei mir):

Bei wem das alles nicht funktioniert (es gibt Phones/Recoveries, die nicht so funktionieren), der muss tiefer in die Trickkiste greifen und macht das hier:

• Phone verschlüsseln
• Gewünschte einfache PIN für die Displaysperre setzen (mit "Beim Start fragen")
• Testen (Bildschirmsperre, TWRP Recovery, Neustart, erst jeweils etwas Falsches eingeben)
• Einstellungen > Über das Telefon > 7 x Build-Nummer antippen > Entwickleroptionen werden aktiviert
• Einstellungen > Entwickleroptionen > Root-Zugriff > Root-Modus "Nur Apps" aktivieren
• Einstellungen > Entwickleroptionen > Lokales Terminal > aktivieren
• Terminal App öffnen und Eingabe:
  (nach "su" den Root-Zugriff erlauben)
  

  su
  vdc cryptfs changepw pin <Aktuelle einfache PIN> <Superschwere neue PIN>
  reboot recovery

  (Im TWRP Recovery die <superschwere neue PIN> testen, dann Reboot > System ...)
  ___
  
• Wenn *danach* die Displaysperre geändert wird, kann es sein (muss nicht), dass man das ab Terminal App öffnen (mit der aktiven superschweren PIN) wiederholen muss:

  su
  vdc cryptfs changepw pin <Superschwere aktive PIN> <Superschwere aktive oder auch neue PIN>

  (Das kann man auch jederzeit benutzen, um einfach unabhängig von der Displaysperre die Start-PIN zu ändern.)

___

Tipp:
Vor all den "Spielereien" ins TWRP Recovery starten und ein Voll-Backup machen. - Dabei aber auf eine externe SD Card (eine Adopted SD Card ist in diesem Szenario übrigens auch schlecht, weil verschlüsselt) bzw. einen USB-OTG-Stick (beste Lösung) sichern, weil man sonst nicht mehr an das TWRP-Verzeichnis im (verschlüsselten) Internal Storage kommt, wenn etwas mit der PIN-/Passwort-Setzerei schief geht ...

Falls man überhaupt nicht mehr lebend aus der Nummer heraus kommt, in das TWRP Recovery starten und dort

• TWRP > Passwort-Abfrage > Cancel
  
• TWRP > Wipe > Format Data > [ y ] [ e ] [ s ] und [ Enter ] (die Taste mit dem Haken) antippen
  (Das entfernt die Verschlüsselung, aber löscht auch alle Daten; außer der externen SD Card. - Anders geht es nicht.)
  
• TWRP > Reboot > Recovery
• TWRP > Wipe > Factory Reset ... (Werksreset - die externe SD Card wird nicht gelöscht)
• TWRP > Restore > Auswahl Sicherung (von externer SD Card oder USB-OTG-Stick) > Swipe to restore ...
  
• TWRP > Reboot > System

 

[Lenneth]

Danke für die ausführliche Antwort, ooo.
Dein Post wurde soeben in eine kleine .txt weggesichert, damit im Bedarfsfall eine Notlösung vorhanden ist.
Alles brav befolgt, habe aber eine Kleinigkeit nicht beachtet, weshalb ich mich trotz korrekt gesetztem Passwort ausgesperrt habe. Backup bzw. Neuinstallation (Backup ist wenige Tage alt und extrem wichtige Sachen habe ich ohnehin kaum - Rufnummern sind sogar "offline" auf Papier hinterlegt, falls die SIM mal die Fliege macht usw.).

Neuinstallation ist soeben durch, bin wieder im CM-Willkommensbildschirm!
Habe quasi nichts verloren, da ein paar wenigen Apps aus dem Play Store nichts wirklich weltbewegend auf dem Phone war, was ich nicht extern irgendwo als Backup weggesichert hätte, z. B. Rufnummern, sehr persönliche Dokumente. Fotos sind eh auf der SD und auf mehreren Backupmedien usw.
Das letzte Backup ist sowieso dasjenige, das ich direkt nach der frischen Neuinstallation von CM14.1 gesetzt habe und nur wenige Tage alt.

Hintergrund fürs Aussperren ist ein kleines, aber sehr feines Detail::

Beim verschlüsseltem Android-Start wird ja die Tastatur eingeblendet, sobald das Gerät die Passphrase oder die PIN möchte. Blöderweise hatte ich vor dem Reboot vergessen, in den Sicherheitseinstellungen den Entsperrtyp von "PIN" auf "Passwort" zu ändern, nachdem ich mir in der Android-Shell das einfache und komplexe Passwort gesetzt habe. Denn ich verwende fürs Entsperren des Displays einen simplen Zahlencode, für den Start war mein lange Masterpasswort angedacht, dass ich (lokal am PC) für meine KeePass-Datenbank verwende-

Diese fehlende Umstellung hatte zur Folge, dass Android beim Start logischerweise eine PIN erwartet, also ausschließlich numerische Zeichen. Da ich aber ein Passwort gesetzt habe und Android nicht weiß, dass mehr Zeichen als nur Ziffern nötig sind, konnte ich die Tastatur beim Boot nicht auf andere Zeichen außer Ziffern umstellen, Und da Kleinbuchstaben und andere Sonderzeichen vorkommen, wäre das ohnehin keine Option, irgendwie über Mehrfachdruck auf die Zifferntasten um wie bei handelsüblichen Telefontastaturen Großbuchstaben einzugeben). Alles probiert, keinen Erfolg. Denn ins TWRP konnte ich mit demselben Passwort problemlos rein, da die eingebaute Tastatur dort alphanumerische Zeichen bei Groß-/Kleinschreibung ermöglicht-

Werde es erstmal bei "einem" PIN für die erneut erfolgende Verschlüsselung belassen. Ein Backup zurückzuspielen ist ja kein Problem, aber will halt weitere Dummheiten vermeiden. Dabei wurde es schon zig Male gemacht, natürlich vor dem Hintergrund, dass ich eben nur "User" bin und tiefergehende Android- und Linuxkenntnisse bei mir nicht vorhanden sind. Wenn von kurze Testphasen unter 2-3 Linux-Derivaten als Dual-Boot absieht (wo im Fall von Ubuntu, Fedora und Co. graphische Installer usw. einem ja nahezu alles abnehmen)

 

[ooo]

Danke für dein Feedback zu deinen Erfahrungen mit der Verschlüsselung. - Deine ursprüngliche Frage war ja - so verstand ich das (falsch) - ob man zwei verschiedene PINs verwenden kann, und, wenn ja, wie man das bewerkstelligt. - Darauf habe ich die Lösung (mit 2 PINs) beschrieben, die ich natürlich selbst mehrfach ausprobiert habe.
(Übrigens mit ca. 25-maligem kompletten Neuaufsetzen des Phones, um alle Facetten über viele Stunden auszutesten. - Das Phone hat sich über mich danach bei der Phone-Gewerkschaft beschwert und spricht seitdem nicht mehr mit mir ... joke)

Die Lösung für die Passwort/PIN-Kombination findest du unten.
___

Zu deinem Typisierungs-Problem:

Spoiler

Am Rande habe ich ja erwähnt, dass man das auch für 2 Passphrases bzw. Muster machen kann. wobei Muster heikel ist und - je nach Kombination - bei mir meistens schief ging, was u. a. am verwendeten TWRP Recovery liegen könnte. - Der "Trick" ist ja (ohne root) für den durchschnittlichen Anwender seitens der Android-Macher nicht so vorgesehen und auch nicht benutzbar. - Wir "schleichen" uns ja sozusagen durch die Hintertür ins Haus ...

Auch ist die (funktionierende) Syntax, die ich oben angegeben habe, nicht die, welche im Original-Code dokumentiert ist. - Warum?

Die Syntax geht von zwei (auch unterschiedlichen) Typen für die zwei PINs/Passphrases/Pattern aus, aber der Code enthält an dieser Stelle einen Bug und benutzt die falschen Parameter:

Quelle:
android_system_vold/CryptCommandListener.cpp at cm-14.1 · CyanogenMod/android_system_vold · GitHub​

_

Anstatt (Beispiel-Syntax für den Typ "pin")

(Beabsichtigtes Original laut Syntax im Code; ein weiterer Typ-Parameter für das zweite, neue zu setzende "Passwort" <secret_new>)

vdc cryptfs changepw pin <secret_active> pin <secret_new>

muss man

(So arbeitet der Befehl momentan wirklich; das ist ein Fehler)

vdc cryptfs changepw pin <secret_active> <secret_new>

verwenden.

Das hat zur Folge, dass man nur zum gerade aktiven secret-Typ (PIN/Passphrase/Pattern) ein neues (gleich-typisiertes) Secret setzen kann.
Wäre der Code in Ordnung, könnte man mit dem fehlenden zweiten Typ-Parameter auch z. B. vom Typ "pin" auf "password" oder "pattern" umstellen.

___

Ich habe erfolgreich eine schwierige lange PIN und auch ein entsprechendes Passwort setzen können (mit Möglichkeit 2 von oben) und habe danach den Sperr-Typ der Displaysperre unter Android (von Passwort und auch von PIN) auf z. B. ein einfaches Muster oder gar nur "Wischen" oder "Keine" setzen können, ohne ausgesperrt zu werden und ohne die Start-Abfrage zu verlieren.

Evtl. die Lösung für dein Problem?
Dazu habe ich bei der Abfrage "Beim Start abfragen" die Option "Nein danke" gewählt, um zu vermeiden, dass es zu Fehlern kommt, weil die Typisierung des Start-Secrets nicht mehr zum neuen Typ der Displaysperre passt oder die Start-Sperre komplett auf den einfachen gesicherten neuen Typ umgestellt wird. - Bei bestimmten Kombinationen (mit "Muster") wurde die Start-Sperre sogar komplett deaktiviert, was man überhaupt nicht möchte ...

Kurzfassung - in genau dieser Reihenfolge (sollte auch - für dich - mit "Passwort" als Ausgangs-Typ gehen):

Spoiler

• Phone verschlüsseln (erste "Amtshandlung" nach dem ersten Start nach einem Clean Install)
  (Standard-Displaysperre "Wischen" <<< ohne Änderungen an Sicherheitseinstellungen <<< Standardeinstellungen belassen, Dialog "Protect your phone" bzw. ALLE Dialoge beim ersten Start immer überspringen <<< Clean Install der ROM <<< zuvor Format Data im TWRP)
  
• Erst nach der Verschlüsselung einfaches Display- und Start-Passwort (oder PIN) setzen - Muster nicht
• Die Displaysperre mit "Beim Start fragen" einrichten
  
• vdc cryptfs changepw password <aktuelles_start_password> <neues_schwieriges_start_password>
  (Aufgrund eines Fehlers im Code ist der ursprüngliche Secret-Typ immer beizubehalten.)
  bzw.
  vdc cryptfs changepw pin <aktuelle_start_pin> <neue_schwierige_start_pin>
  
• Kein Neustart, sondern Phone ausschalten, kurz warten, dann Phone wieder einschalten
• Die erste Abfrage ist dann das Start-Passwort <neues_schwieriges_start_password>, die zweite Abfrage ist die (noch alte, einfache) Displaysperre <aktuelles_start_password>
  _
  
• Das hier fehlt en detail oben im Ursprungsposting unter "Möglichkeit 2":
  Erst jetzt die Displaysperre auf z. B. Typ "PIN" setzen (oder auch auf Typ "Muster"), dabei aber immer bei der Abfrage "Beim Start abfragen" die Option "Nein danke" wählen (damit der Typ und das Secret - im Beispiel <neues_schwieriges_start_password> - beim Starten erhalten bleiben)

Das Ergebnis für dich wäre

1. Eine lange schwierige Passphrase (Passwort) für die Starts
2. Eine kurze PIN für die Entsperrung deines Displays (auch jederzeit änderbar - siehe oben "Nein danke" - Übrigens meine Lieblingsantwort im Real Life ... joke)

Geht das nicht?

 

[alterbesen]

Nur mal so am Rande,seid gestern gibt es eine TWRP App mit der man auch eine neue Version flashen kann,also recht komfortabel .
Damit erübrigt sich meine Frage ja weiter oben hier
Official TWRP App – Android-Apps auf Google Play

 

[ooo]

Hier gibt es die TWRP-App als Download für Menschen ohne Google.
(Englische) Dokumentation dazu
___
(Edit: Links wieder entfernt)

Das finde ich jetzt wieder weniger gut ... Ich werde die App nicht einsetzen, sorry.

Spoiler: Warum?

Warum? - Weil Daten (an eine deutsche GmbH) abfließen können (opt-in) bzw. werden.

(Datenanalyse-App mit Root - Internet-Verbindung sowieso - als permanenter Background-Service? - WTF!?) ...​

​

Hier noch ein Auszug, welche Daten das (mindestens) sind:

​

(Ich habe diesmal ganz bewusst keinen Link auf die PDF-Quelle gesetzt.)

Ist die Entwicklung nicht interessant?

• Android wird immer "sperriger" (Sicherheits-Features, User Lock-in etc., Verursacher: Google)
• Die Kontroll-Wünsche der Regierungen (Vertretung der Reichen, die wir uns nicht mehr leisten sollten) steigen ins Uferlose, (Internet-)Konzerne werden nachlässigst besteuert, die einfachen Menschen immer mehr gegängelt. - Das ist als Reaktion nichts weiter als blanke Angst vor den Folgen des eigenen Tuns ... (Motto: Was mich und meine Gier evtl. bedrohen könnte, das mache ich präventiv platt.). - Android ist nur ein Werkzeug von vielen, um gewisse Ziele zu erreichen, aber omnipräsent und vernetzt ...
  
• Android soll überall laufen (Smartphone, IoT, Car, Multimedia, Home Control, Body Control (Wearables) etc. - Totale Vernetzung = Totale Kontrolle - Aber nur 1 zentraler Kontrolleur ... ich denke nicht, dass das Google ist ...)
• Man wird totgeworfen mit für Jeden erschwinglichen Android-Devices (damit auch ja jeder mindestens eines besitzt, natürlich always on ...)
• Gleichzeitig gibt es immer mehr Schad-Software (auch bedingt durch total ungesunde, überbeschleunigte Entwicklungszyklen, ohne Fehlervermeidung/-korrekturen, keine Zeit zum richtig Machen bzw. kein Geld übrig zum Patchen, aber Milliarden-Umsätze auf dem Papier erzeugen ...)
  
• Cyanogen bekommt Schwierigkeiten, nachdem Microsoft eine Abfuhr erhielt bzw. Google angepisst wurde (Kopfschuss-Spruch vom CEO) - Auf Millionen Devices weltweit
  
• SuperSU (zentrale Root-App) wird vorgeblich von Chinesen aufgekauft (auf Millionen Devices weltweit)
  
• Die TWRP-Mädels (hohes Ansehen in der Community) veröffentlichen eine App, die genau Null Nutzen bringt, aber dafür fast schon als Trojaner/Root Kit bezeichnet werden könnte (das Recovery/Boot-Image ist ebenfalls ein neuralgischer Punkt auf dem Phone, dazu die "passende" App; momentan ohne frei einsehbaren Source Code, jedenfalls habe ich noch keinen gefunden)

Es macht langsam keinen Spaß mehr mit diesen neoliberalen, kontroll-süchtigen Paranoiden ...

Aber genug geheult. - Ich werde ab jetzt meine TWRP Recoveries nur noch aus den Sourcen kompilieren und auch SuperSU nicht mehr einsetzen (wurde von einer chinesischen Firma gekauft - ob Chainfire das Konstrukt als juristischen/fiskalischen Schutz benutzt, ist fraglich) ...

[doublepost=1481959331,1481952644][/doublepost]@alterbesen - Bitte nicht falsch verstehen, ich mache dir absolut keinen Vorwurf, dass du die App gefunden hast und hier verlinkst. - Das ist okay. - Aber die Problematik besitzt eine viel größere Dimension und darüber muss man auch sprechen dürfen ...

 

[Lenneth]

@ooo
Wegen der beiden verschiedenen PINs: Exakt das meinte ich! Und genau das hattest du oben treffend beschrieben.
Habe natürlich Möglichkeit zwei gewählt, hatte mich oben wohl unverständlich ausgedrückt.

Aber schon krass, dass du das so häufig ausprobierst hast, nur wegen der einen Frage. Ich probiere deine "neuen" Schritte auch wieder aus (Backup selbstverständlich, Titanium Backup hat bereits einmal alles Wichtige gesichert). Wird nur bißchen dauern, da eben noch bissel privat was zu tun usw.

@Posts von alterbesen und ooo über diesem hier:

Datenschutz ist mir zwar schon wichtig, aber da ich ja bereits ein Smartphone nutze, ich zugegeben Google als Suchmaschine und Maps überaus praktisch finde, würde ich zwar keinen Aluhut tragen. Aber bei Progs, wo wenig bekannt ist, würden auch hier die Alarmglocken läuten.
Auf dem Desktop werden da in Firefox (Telemetrie und dergleichen natürlich deaktiviert) die Erweiterungen RequestPolicy und uBlock eingesetzt, auf meinen Lieblingsseiten ist dafür Werbung gestattet, wenn auch keine Quellen zu Facebook und Konsorten. Adblock Plus' Geschäftspolitik, gegen Bezahlung Werbung auf Whitelists zu setzen, ist für mich ein Grund dagegen (gibt genügend Quellen, u. A. auf heise. Gerade keine Lust, Links herauszusuchen).

Ich disse hier nun keinesfalls gegen ABP und begrüße so etwas in begrenztem Rahmen (wie wir alle wissen, ist "kostenlos" und "werbefrei" in einem Zusammenhang kaum möglich, zumindest gewerblich - außer man verkauft seine Daten wie an Google usw.), weil gerade bei sehr alten Rechnern intensive Flash- und andere Werbung massive CPU-Ressourcen ziehen kann, das ist nur meine persönliche Meinung am Rande.

Das nur am Rand.
Und das mit dem Verkauf der Firma hinter SuperSU ist in der Tat schade.

Aber das sollte imho nicht abdriften bzw. wäre es einen eigenen Thread wert.
Hoffe jedenfalls, dass vielleicht mehr User - gerade wenn es kein allzu teures Smartphone gewesen ist und/oder die Gewährleistung nicht mehr greift, gerade bei älteren Geräten darüber nachdenken, vielleicht den Lebenszyklus verlängern und ein aktuelles, gepatchtes Custom-ROM installieren.

 

[ooo]

Ich bin gerne gründlich und sorgfältig. Es waren ja nicht so viele Versuche und ist (für mich) normal, da gibt es andere Orgien. Das bringt die Materie fachlich einfach mit sich, wenn man etwas genau wissen möchte.

Die Bewertung und Wahl der Sachen nach Nützlichkeit/Schädlichkeit, die man einsetzt, oder die Entscheidung, ob man eine bestimmte Technologie (Smartphone/Internet) überhaupt einsetzt, bleibt einem nicht erspart, aber das gilt für alle Bereiche des Lebens. - Ich sehe das inzwischen völlig leidenschaftslos. - Allerdings gebe ich gerne schon 'mal "Großalarm", wenn ich der Meinung bin, dass ein Gewitter aufziehen könnte ... (und seit geraumer Zeit stehen die Zeichen global auf Sturm, nicht nur politisch) ...

Zum Thema Aluhut: Ich habe gelacht als ich die Meldung las, dass die Russen sich mechanische Schreibmaschinen für hochsensible Bereiche bestellt hatten (kurz nach Snowden), heute finde ich die Idee gar nicht mehr so dumm. - Regierungsvertreter/-Entscheider haben i. d. R. mehr Informationen, also ist es evtl. intelligent zu beobachten, was diese Menschen unternehmen (was sie sagen ist unwichtig und lenkt nur ab). - Russland verbietet Android auf Regierungs-Devices und führt ein eigenes OS nordeuropäischer Provenienz ein. - China und England zensieren alles zu Tode, was ihnen nicht in den Kram passt (andere auch) und China verbietet die Auslieferung der Google Services/des Play Stores auf Android-Devices.- Huawei fliegt aus den USA raus, Huawei-Devices für Netzwerkkommunikation werden geächtet. - IBM, Oracle, Microsoft, Facebook, Apple, Google - alles Internet-relevante US-Konzerne mit entsprechenden Kern-Kompetenzen, die teilweise personal-technisch eng mit der DARPA verbandelt sind - werden (von wem gefördert?) immer mächtiger und haben weltweit bzw. pro-westlich (fast) Narrenfreiheit ... Unsere Telekommunikationskonzerne dürfen von der Außensicht her auch tun und lassen, was sie möchten, Hauptsache, die Internet-Knoten sind leicht zugänglich und die Devices unrootbar ... Bestimmte Ermittlungen gegen Staatsbehörden verlaufen im Treibsand der Geschichte ... Was soll ich also als kleine Amöbe - ohne mich von den Leitmedien (ver-)leiten zu lassen - jetzt politisch oder persönlich für meine (strahlende?) Zukunft folgern? - Es hängt alles zusammen und deswegen passt dieses Thema perfekt in diesen Thread. - Nur bescheidene Gedanken ...

 

[alterbesen]

Genau das Riesen Thema Sicherheit und Datenschutz sollten wir lieber nicht anfassen das passt nicht hier rein
Mal was Anderes,das Heutige NIGHTLY hat keine Änderungen was macht das für ein Sinn ??
Nach welchen Regeln machen die Coder denn solche Pakete ....vielleicht weiß das jemand hier

 

[ooo]

Wenn man oben rechts im Optionen-Menü das Ausblenden der Änderungen zu den Übersetzungen ausschaltet, bekommt man mehr zu sehen.

(Siehe Screenshot)

 

[N008]

Laut squid2 werden bei cmxlog nur diejenigen Änderungen gelistet, die aus dem Gerrit Code Review stammen. Also kein Anspruch auf Vollständigkeit.

Das Thema, das @ooo angesprochen hat, brennt mir auch laufend unter den Nägeln. Die (Software-) Produkte sind immer weniger ausgereift (IoT ist ein Graus). Die Inhalte werden auswechselbar. Standards werden immer weiter ausgehölt, während jeder Driss in einen sog. wallet garden eingesperrt wird, um jedweden Anflug der freien Nutzung von Schnittstellen oder Inhalten zu unterbinden. Aber Hauptsache, Werbung und Tracking funktionieren immer und überall. An manchen Tagen denke ich mir, den ganzen Mist (darunter verstehe ich allgemein alles, was ans Internet angebunden werden kann bzw. mittlerweile muss) einfach wegzuwerfen. Vielfach habe ich mich, ohne etwas zu vermissen, vom Konsum bestimmter Produkte und Webangebote verabschiedet.

Weil es mir gerade wieder einfällt: Warum wird bei AFWall+ im F-Droid-Store eigentlich seit einiger Zeit davor gewarnt, dass die App unfreie Erweiterungen nutzt? Werden da auch "Nutzungsstatistiken" gesammelt?