Lenovo Tab 2 A10-70F Linksammlung (Firmware, Recovery, Root)

  • 299 Antworten
  • Neuester Beitrag
Diskutiere Lenovo Tab 2 A10-70F Linksammlung (Firmware, Recovery, Root) im Lenovo TAB2 A10-70 Forum im Bereich Lenovo Forum.
N

newbietux

Neues Mitglied
Leider blieb es bis heute morgen beim Anzeigen des Startbildes "Lenovo - powered by android". >:-<<
 
A

AndyFx

Neues Mitglied
Hallo newbietux,

ich habe das folgendermaßen gemacht:
- per SPFT das letzte Image für Lollipop geflasht
- Tablet einmal "normal starten" lassen und den Assistenten "abwürgen" (überspringen,überspringen etc.)
- das Update auf MM auf den internen Speicher (per USB-Kabel) kopiert
- im Stock-Recovery das Update auf MM per Zip installieren
- wieder neu starten lassen (hier bekommt man wenigstens einen Fortschrittsbalken)
- das Boot-Image und die aktuelle SuperSU wieder auf den internen Speicher kopiert
- TWRP per SPFT installieren
- das Boot-Image per TWRP installieren
- Data per TWRP wipen
- SuperSU nach Neustart ins TWRP installiert
- Tablet gestartet -> alles läuft.
Dauer der Prozedur ca. 1,5 Stunden.

Wie man allerdings die SPFT-Teile in Linux erledigt, weiß ich leider nicht ....
Die SD-Karte brauchte ich jedenfalls nicht.

vg.

Andy
 
N

newbietux

Neues Mitglied
@AndyFx
Danke für Deine Antwort. Ich habe jetzt erst einmal mit adb sideload (da bei mir SPFT nicht funktioniert) das OTA Update MM installiert. Jetzt startet gerade das System mit dem Fortschrittsbalken.
Anschließend werde ich Stück für Stück probieren an welcher Stelle der "Anpassungsprozess" klemmt:
- beim flashen des angepassten Boot-Images?
- beim wipen von Data?
- beim Installieren der exFAT-Treiber?

Ich benötige die exFAT-Treiber aber unbedingt, da ich sonst auf die Daten auf meiner 128 GB großen SD-Karte nicht zugreifen kann.
Es ist aber auch ärgerlich, dass Lenovo mit MM nicht auch gleich Treiber für exFAT mitbringt! Oder habe ich da was verpasst? Jedenfalls hatte mein MM System immer behauptet, dass die SD-Karte beschädigt wär und gefragt ob ich sie reparieren möchte. Das habe ich natürlich immer abgelehnt.

Jetzt frage ich mich gerade ob im alten System beim Verschlüsseln des Systems auch die SD-Karte mit verschlüsselt wurde???
Wenn dem so wäre wüsste doch das neue System nichts mehr von den Schlüsseln für die Verschlüsselung!?
Da wären doch meine Daten auf der SD-Karte jetzt sowieso futsch - oder?

Jetzt steht der Fortschrittsbalken schon ca. 1 h bei ca. 5 Prozent!?
Ich warte mal noch 1 bis 2 h (bevor ich als nächsten Versuch ein OTA von Android 5 installiere).

Eeeeeendlich! Reichlich 3,5 Stunden hat sich Android Zeit genommen um den Fortschrittsbalken zu beenden. Danach hat es auch gleich das System neu gestartet.
 
Zuletzt bearbeitet:
T

Tzul

Stammgast
newbietux schrieb:
Ich hatte das Problem gehabt, dass nach dem Update mein TWRP und auch die Treiber für meine exFAT formatierte SD-Karte weg waren.
Ja, das Problem hatte ich auch, aber das war zu erwarten. In Android 6 wurde mal wieder das Storage-System umgekrempelt, was dazu führt, dass der alte NTFS/exFAT-Patch leider nicht funktionieren wird! :(
Aber ich habe NTFS zum Laufen gebracht, sogar besser als vorher!

newbietux schrieb:
Leider bin ich auch der, der mit Linux arbeitet und bei dem SPFT das Gerät nicht findet. So muss ich immer alles zuerst mit fastboot zum Funktionieren bringen.
Wenn du schon vor dem Update TWRP installiert hattest, dann hättest du es behalten können und der Weg über Fastboot wäre unnötig gewesen. Der Bootloader des Tablets ist gar nicht gesperrt (sonst würde das unsignierte TWRP gar nicht starten). Alles was dann "fastboot oem unlock" noch macht, ist das Flashen per fastboot freizuschalten. Dafür kann ich auch lk.bin patchen - aber dann ist wieder die Frage, wie du das bei dir installierst ohne TWRP und SPFT.
Hast du schon Miss Montages Tutorial für SPFT unter Linux probiert? Ich habe das SPFT mal in einer Ubuntu VM installiert und zum Laufen bekommen.

AndyFx schrieb:
ich habe das folgendermaßen gemacht:
- per SPFT das letzte Image für Lollipop geflasht
- Tablet einmal "normal starten" lassen und den Assistenten "abwürgen" (überspringen,überspringen etc.)
Das ist natürlich sehr gründlich, aber in diesem Fall absolut unnötig. Das neue Update überschreibt von sich aus fast alles: Preloader, Bootloader (LK), Boot-Image, Logo, Trustzone (tee1&tee2), System-Image, Userdata. Also praktisch nur Secro nicht und das Recovery, das dann wie üblich beim nächsten Android-Boot automatisch erzeugt und geflasht wird.
Deswegen kann man das Update einfach mit TWRP 3.0.0 installieren, egal welche alte Firmware gerade installiert ist. TWRP sorgt dann auch dafür, dass es nicht vom Stock Recovery überschrieben wird (wenn man TWRP Änderungen der Systempartition erlaubt hat). Danach, noch vor dem ersten Start von Android, kann man mit der Anleitung für Root weitermachen, wenn man möchte.

newbietux schrieb:
Ich benötige die exFAT-Treiber aber unbedingt, da ich sonst auf die Daten auf meiner 128 GB großen SD-Karte nicht zugreifen kann.
Es ist aber auch ärgerlich, dass Lenovo mit MM nicht auch gleich Treiber für exFAT mitbringt! Oder habe ich da was verpasst? Jedenfalls hatte mein MM System immer behauptet, dass die SD-Karte beschädigt wär und gefragt ob ich sie reparieren möchte. Das habe ich natürlich immer abgelehnt.
War bei mir genauso. Ich habe auch eine 128 GB Karte und transferiere öfter mal sehr große Dateien, per Kartenleser am PC, denn USB-MTP und WLAN sind zu lahm. Adopted Storage ist deswegen auch keine Lösung für mich. Wie gesagt funktioniert der alte exFAT/NTFS-Patch leider nicht mehr in Android 6. Man könnte ihn mit einiger Arbeit wahrscheinlich anpassen, aber ich habe mich für einen anderen Weg entschieden. Ich habe gemerkt, dass der Storage Volume Daemon (vold) im Prinzip Unterstützung für NTFS eingebaut hat, aber die externen NTFS-Tools fehlen (ntfsfix, ntfs-3g). Ich habe die Dateien an den richtigen Ort kopiert, aber das allein hat noch nicht funktioniert, es gab noch ein paar weitere Probleme zu beheben. Jetzt schein es zu funktionieren. Das Gute daran ist, dass es nahtlos ins Android-System eingebunden ist, d.h. man kann NTFS-Karten über die Einstellungs-App einbinden und auswerfen, ohne wie beim alten Patch das Tablet neustarten oder Shellbefehle eingeben zu müssen. Für exFAT ist das leider nicht so möglich, da gibt es weitere Hürden zu überwinden. Aber solange wenigstens eines von beiden (NTFS oder exFAT) funktioniert, bin ich zufrieden.

Ich hatte natürlich noch nicht viel Zeit es zu testen, daher Benutzung auf eigene Gefahr!
Diese Zip-Datei mit TWRP installieren. Benötigt SuperSU für schreibbares NTFS. Wer sich für Details interessiert wie das ganze funktioniert, kann die enthaltene readme lesen. ;)
 
Zuletzt bearbeitet:
N

newbietux

Neues Mitglied
@Tzul
Vielen Dank für Deine ausführliche Antwort.

Den Link mit dem auf Linux zugeschnittenen Hinweisen für die Nutzung des SPFT hatte ich so nicht gefunden - Danke dafür. Bei meinem nächsten Upgrade werde ich die Infos einsetzen.

Jetzt zum aktuellen Stand in meinen Aktionen:
- ich habe die Schritte zum direkten Flashen des OTA-Updates auf MM und dem darauf folgenden flashen des angepassten boot-images nacheinander ausgeführt und zwischendrin auch probiert, dass das System noch korrekt arbeitet/startet

- nachdem ich dann die data-Partitiion neu partitioniert und nach dem Neustart ins Recovery mit TWRP SU installiert hatte blieb der Neustart wieder im Startbildschirm hängen (jetzt schon über 4 Stunden)
=> was mache ich oder läuft bei mir falsch?

Die Daten der SD-Karte waren nicht verschlüsselt und ich konnte sie Sichern und nach Umformatierung der SD-Karte auf NTFS auch wieder auf sie aufspielen. Jetzt warte ich nur noch, dass ich ein startbares und gerootetes System bekomme um den NTFS Patch einspielen zu können.
 
T

Tzul

Stammgast
@newbietux Also nach dem Flashen des Boot-Image und vor der Installation von SuperSU funktioniert es noch?
Dann liegt es wohl an SuperSU. Welche Version installierst du und bist du sicher, dass im Systemless-Modus installiert wird? Siehe Log-Ausgabe. Zur Sicherheit könntest du auch mit TWRP die Cache-Partition vor der Installation formatieren, falls da eine ".supersu"-Datei existieren sollte, die Systemless-Installation verhindert.
4 Stunden sollte das absolut nicht dauern, höchstens 15-30 Minuten.
 
N

newbietux

Neues Mitglied
@Tzul
nach dem Flashen des Boot-Image und vor der Installation von SuperSU funktioniert es noch?
Ja - danach funktioniert es noch.
Dann liegt es wohl an SuperSU. Welche Version installierst du
Ich installiere das SuperSU das in TWRP angeboten wird direkt mit TWRP.
bist du sicher, dass im Systemless-Modus installiert wird?
Dazu weiß ich nicht was damit gemeint ist bzw. wie man dazu vorgehen muss.
Bei TWRP kam immer die Abfrage ob Änderungen an der Systempartition zugelassen werden sollen. Das habe ich bejaht. War das falsch?
Ich habe mir erst jetzt das aktuelle UPDATE SuperSU (Link von Seite 1 dieses Threads geholt).
4 Stunden sollte das absolut nicht dauern, höchstens 15-30 Minuten.
Es ist auch nie fertig geworden sondern blieb die ganze Zeit mit dem Startbildschirm stehen.

So - jetzt mit dem aktuellen SuperSU 2.82 hat es endlich geklappt. Das System ist gerade neu gestartet und will angepasst werden. Als nächstes werde ich den NTFS-Patch installieren.
Erst einmal vielen Dank für Deine Hilfe.
 
Zuletzt bearbeitet:
T

Tzul

Stammgast
newbietux schrieb:
Ich installiere das SuperSU das in TWRP angeboten wird direkt mit TWRP.
Das war dann wohl der Fehler. In der Anleitung habe ich geschrieben "Aktuelles SuperSU-Zip flashen". ;)
Die Version, die im TWRP integriert ist, ist veraltet und kann noch kein Systemless.
 
KyleRiemen

KyleRiemen

Ehrenmitglied
@Tzul
Kann ich als Alternative zu SuperSu auch Magisk V13.3 flashen?

Nochmal kurz mein geplanter Weg:

Update runterladen.
Ins TWRP booten.
NANDroid Backup machen.
Das Update im TWRP flashen.
Data, Cache und Dalvik/Art Cache wipen.
Dein Bootimage per TWRP in die Bootpartition flashen.
Reboot ins Recovery.
Magisk V.13.3 flashen.
Reboot ins System.
Hoffen das alles klappt :)

Nochmal danke für deine Mühe.
Gruß
CyPress1988
 
T

Tzul

Stammgast
@CyPress1988 Mit Magisk habe ich bisher nur wenig Erfahrung, aber ich denke es wird funktionieren.
Dein Weg sieht richtig aus. "Data, Cache und Dalvik/Art Cache wipen" kannst du dir sparen, da das Update die Data-Partition formatiert (löscht auch Dalvik/Art). Aber die Cache-Partition kannst du wipen, auch wenn das wahrscheinlich unnötig ist.
 
A

AndyFx

Neues Mitglied
@Tzul
Kann man eigentlich erkennen, ob die MM-Firmware immer noch AAL einsetzt? Auch hier gibt es im Engineer Mode keine Schalter...

vg.

Andy
 
KyleRiemen

KyleRiemen

Ehrenmitglied
Kurze Rückmeldung:
Hat so wie von mir beschrieben geklappt.
Magisk läuft auch und besteht SafetyNet.
Screenshot_20170725-121035.png
 
T

Tzul

Stammgast
@AndyFx Nein, AAL gibt's in der neuen Firmware zum Glück nicht mehr.
 
A

AndyFx

Neues Mitglied
@Tzul
Seit MM zeigt Chrome / Google-Suche offenbar verstärkt Subpixel-Antialiasing (was ich nicht ausstehen kann). Speziell bei eingefügten Anzeigen ist die Schrift oft seltsam unscharf. Zumindest ist mir das in KitKat vorher nie aufgefallen. Firefox macht das nicht. Kann man das irgendwie ausschalten (Vielleicht hat ja der Mediatek-Chip noch eine Überraschung parat?)?

Ansonsten bin ich mit dem neuen Update sehr zufrieden. Auch meine Fritzbox läuft nun mit der neuen Firmware auch mit dem Tablet (was bei Kitkat unterträgliche Aussetzer verursacht hatte).

Edit: Die Lösung ist Chrome Dev - der bringt ein Suchwidget als Google Alternative mit. Die Einstellung "enable blink's scale factor" zaubert knackscharfe Schriften auf den Schirm.

vg.

Andy
 
Zuletzt bearbeitet:
N

newbietux

Neues Mitglied
Ich habe auf meinem gerooteten Tablet Probleme beim Zugriff mit Xodo und Acrobat Reader auf PDF-Dateien auf der externen SD-Karte (mit NTFS-Format und dem Patch von @Tzul).
Wenn die Berechtigung zum Zugriff auf die Daten abgefragt wird und ich diese erteilen möchte kommt die Meldung: "System Overlay erkannt". Nachdem ich wie vorgeschlagen die Einstellung für alle Apps und System-Apps auf "Nein" gestellt habe kommt die Meldung weiterhin.
Nur mit dem X-Plore PDF-Viewer (aufgerufen aus dem X-Plore Dateimanager) lassen sich die Dateien anzeigen.
Wo könnte das Problem liegen?
 
T

Tzul

Stammgast
@newbietux Das ist ein Fehler oder eher Feature in Android 6. Mehr Infos und Lösung in diesem englischen Artikel. Android verbietet das Erteilen von Berechtigungen, wenn ein Overlay aktiv ist.

Es sollte reichen, wenn du dem Acrobat Reader und anderen betroffenen Apps manuell die "Speicher"-Berechtigung (und eventuell andere auch) erteilst, indem du in die Systemeinstellungen gehst, dann Apps, App auswählen, Berechtigungen.
 
Zuletzt bearbeitet:
A

AndyFx

Neues Mitglied
Die Suchleiste gibt es jetzt auch für Chrome-Beta - im Vergleich zu Google kann man hier die Suchmaschine einstellen und es wird gleich ein Tab mit den Ergebnissen geöffnet.

Zu den unscharfen Schriften ein Beispiel:
Screenshot_20170728-084842.png Screenshot_20170728-085611.png
Die genannte Einstellung gibt es auch beim ChromeBeta

vg.

Andy
 
Zuletzt bearbeitet:
N

newbietux

Neues Mitglied
@Tzul
Ich hatte in den App-Einstellungen für das "Anzeigen über anderen" bei allen aufgeführten Apps (auch den System-Apps) die Einstellung auf "Nein" gestellt. Dort wurden aber meiner Meinung nach nicht alle aufgeführt. Immer wenn ich einer App Zugriff auf "Speicher" erteilen wollte kam die "System-Overlay"-Warnung mit dem Verweis zu den Systemeinstellungen zu "über anderen Anzeigen".

Das Auswerten des extra angelegten Logfiles brachte auch keine Klarheit da "Overlay" sehr oft vorkam und auch bei den "Warning"s keine App klar als Ursache benannt wurde. Einige der dort aufgeführten hatte ich deinstalliert, was aber nicht half (darunter "Weather" und TSF-Launcher).

Erst das Deinstallieren von "Gravity-Box" führte zum Erfolg. Jetzt weiß ich aber noch nicht welches der Module das "Schuldige" war.
 
T

Tzul

Stammgast
@newbietux Ich habe unter "Anzeigen über anderen" gar nichts geändert. GravityBox habe ich auch installiert. Funktioniert trotzdem alles. Ich habe die App-Berechtigungen wie gesagt in den App-Einstellungen gewährt, nicht in den Popup-Dialogen, die beim Starten einer App angezeigt werden.
 
N

newbietux

Neues Mitglied
@Tzul Ich habe dann natürlich auch versucht den Zugriff auf die SD-Karte über die App-Einstellungen direkt einzurichten. Dort bekam ich aber trotzdem nur die Warnmeldung zum erkannten SystemOverlay (ohne Nennung des "Missetäters" :-() mit dem Link zu den System-Einstellungen "Über anderen Apps einblenden" und dem Hinweis diese doch anzupassen.

Wenn es bei Dir mit installiertem "GravityBox" geht könnte doch ein Modul welches Du nicht verwendest - ich aber schon - der Verursacher sein! Oder???