Installieren von APP-Hardboots, Telefonen und Bootloops

Ich habe ein Oneplus 1 mit CM11 44s Kitkat 4.4.4

Ich habe CM11 sauber geflasht und kann jetzt keine App aus dem Playstore installieren. Sobald die Installation einer App abgeschlossen ist, startet das Telefon hart und tritt in den Bootloop ein oder ich erhalte kontinuierliche Fehlermeldungen Trebuchet funktioniert nicht mehr, Play Store funktioniert nicht mehr

Ich muss in den abgesicherten Modus gehen und die App deinstallieren, um das Telefon wiederherzustellen.

Apps, die ich versucht habe zu installieren und die nicht erfolgreich waren Greenify Nova Launcher Facebook Gboard Microsoft SMS Organizer

Grundsätzlich kann ich überhaupt nichts installieren! All dies lief vorher gut, jetzt verstehe ich nicht, was falsch ist!

Ich habe das ganze Telefon gereinigt, alles mit Fastboot formatiert und CM11 neu installiert, aber das Problem bleibt bestehen.

Bitte helft!!

Antworten (2)

Für mich ist es die FaceBook-App, die den Bootloop verursacht. Ich habe CM11 auf einem Nexus 7. Ich habe den Play Store verwendet, um letzte Woche ein paar Apps zu aktualisieren, und als ich darauf zurückkam, war es eine Schleife. Ich habe mehrere Werkseinstellungen zurückgesetzt und festgestellt, dass es die neueste FB-App war. Ich erhalte einen sofortigen Bootloop bei der Installation. Ich habe mich einfach entschieden, es nicht zu verwenden :) Was auch immer das Problem ist (vielleicht gibt es ein Problem, das Android Studio einführt, das CM11 nicht mag) kann sich auf andere Apps auswirken.

Es ist, weil appt2 jemand darüber im Google Issue Tracker hier gepostet hat: https://issuetracker.google.com/issues/64434571#comment22 und sie sagen, dass sie ein Update für appt2 veröffentlichen würden, um das Problem zu beheben, das bei allen CyanogenMod/LineageOS Rom auftritt und sie haben den Fehler auch im Detail beschrieben, hier ist er: - CyanogenMod hat diese Funktion getPkgName ( https://github.com/CyanogenMod/android_frameworks_base/blob/cm-13.0/libs/androidfw/AssetManager.cpp ). Es erstellt einen ResXMLTree auf dem Stack und verweist ihn auf einen Puffer aus einem Asset, ohne eine Kopie zu erstellen. Dann wird das Asset geschlossen, bevor der ResXMLTree zerstört wird.

Für Apps, die von aapt erstellt wurden, ist dies harmlos. aapt2 erzeugt jedoch UTF-8-String-Pools, die dazu führen, dass der mCache des ResStringPool(mStrings) von ResXMLTree in ResStringPool::stringAt ( https://github.com/CyanogenMod/android_frameworks_base/blob/cm-13.0/ ) nicht null wird. libs/androidfw/ResourceTypes.cpp ). Dann dereferenziert ResStringPool::uninit mHeader (das jetzt baumelt), und es kommt zu einem Absturz.

Dieser Absturz zeigt sich auf unterschiedliche Weise. Auf einem Cyanogen OS-Gerät stürzt der Launcher ab, wenn eine mit aapt2 erstellte App installiert wurde, aber nur, wenn das Manifest groß ist (wahrscheinlich aufgrund der Art und Weise, wie die Zuordnung zwischen kleinen und großen Blobs erfolgt). Auf einem anderen Gerät stürzt system_server beim Booten ab, wenn eine von aapt2 erstellte App installiert ist.

Wir versuchen, dies mit einem benutzerdefinierten Build von aapt2 zu umgehen, der immer einen UTF-16-String-Pool für das Manifest erstellt. Die bisherigen Ergebnisse sind vielversprechend.