Kann es daran liegen, dass der Security-Patch-Level von SOS-L 7.0 (2026-01-05) niedriger ist als der von SOS-G 6.4 (2026-02-05)? In dem Fall hättest du wohl besser nicht auf 6.4 upgedated...
SHIFTPHONE_8.SOS.7.0.L.20260122
- Ersteller amartinz
- Erstellt am
- SHIFTphone 8 ShiftOS-L Update
Ich weiß nicht - möglich!
Ja, als ich das Update gemacht hatte, wusste ich noch nichts von dem L-Update. Eigentor
Da das jetzt eine ganze Weile bei 0% hing, hab ich mal abgebrochen und werkel mal weiter unter der Annahme, dass ich es mir erstmal unter OS-G gemütlich mache, bis es dazu eine News oder halt dann ein noch neueres L-Update gibt ^^
Danke auf jeden Fall für eure Ideen!
Ja, als ich das Update gemacht hatte, wusste ich noch nichts von dem L-Update. Eigentor
Da das jetzt eine ganze Weile bei 0% hing, hab ich mal abgebrochen und werkel mal weiter unter der Annahme, dass ich es mir erstmal unter OS-G gemütlich mache, bis es dazu eine News oder halt dann ein noch neueres L-Update gibt ^^
Danke auf jeden Fall für eure Ideen!
In Droid-ify hast du in den Parketquellen ja auch die F-Droid Repo ,daher macht es für die Apps keinen Unterschied ob sie über Droid-ify oder den F-Droid Store aktualisiert werden.
Die Apps und Updates werden ja von den jeweiligen Parketquellen geholt/angeboten.
oder hab ich dich falsch verstanden?
Ich vermute ja, da wird es um die in Android gespeicherte Installationsquelle gehen. Das was man für manche Apps per ADB auf "com.android.vending" setzen muss, damit sie mit microg funktionieren. Ich weiß nicht, was FDroid da rein schreibt, aber Droid-ify müsste das gleiche auch kennen/nutzen um die von FDroid installierten Apps als solche zu erkennen. Das wird wohl das von FDroid sein bis Droid-ify mal ein Update für die App installiert hat.
Möglicherweise spielen auch solche Gedanken eine Rolle...
Ich finde die vorbefüllten Paketquellen durchaus praktisch, auch wenn die Shift-Repo noch manuell hinzugefügt werden muss
Ich finde die vorbefüllten Paketquellen durchaus praktisch, auch wenn die Shift-Repo noch manuell hinzugefügt werden muss
Genau!
Beim PlayStore (damals) wird ne Art Verknüpfung hergestellt. Wenn die weg ist, dann ist die für den scheinbar nicht mehr existent oder bei der Update Prüfung bei.
Hab mal Beispiele angefügt!
Anhänge
Das ist keine Verknüpfung. Es wird einfach geloggt, welcher App-Store die jeweilige App installiert hat. Und das wird in den Einstellungen angezeigt und können alle Apps einsehen. Ist ja aber irrelevant, weil ja auf OS-l ja sowieso die F-Droid-Rechteerweiterung installiert und von den F-Droid-Clients dann standardmäßig verwendet wird. Außerdem ist es für F-Droid-Apps völlig egal, von wo sie installiert wurden. Die Devs stehen mehr auf der Seite „Der User soll wissen, was er tut“ als auf der „Wir wissen alles besser als der User und wenn nicht xyz gemacht/verwendet wird, halten wir das für unsicher“. Gerade das F-Droid-Repository und der originale F-Droid-Client sind übrigens bei manchen Entwicklern äußerst unbeliebt.
Ich weiß nicht - möglich!
Ja, als ich das Update gemacht hatte, wusste ich noch nichts von dem L-Update. Eigentor
Da das jetzt eine ganze Weile bei 0% hing, hab ich mal abgebrochen und werkel mal weiter unter der Annahme, dass ich es mir erstmal unter OS-G gemütlich mache, bis es dazu eine News oder halt dann ein noch neueres L-Update gibt ^^
Danke auf jeden Fall für eure Ideen!
habe das Gleiche verhalten
es bleibt einfach bei 0% und keine Veränderung
nja, zum Glück nur mit dem "daddel"-8.1er....
wär aber nicht bös drum, wenn es da ne Info gibt, woran es liegen könnte oder besser, wie man SHIFT-L zum laufen bekommt, von der 6.4 aus
Das SHIFT-Repo wird automatisch hinzugefügt, da wir es im System hinterlegt haben, Droid-ify das einliest und dann hinzufügt und aktiviert.
Genau, bei der Installation wird festgehalten von welcher anderen APP, die PaketInstallationen durchführen darf, installiert wurde. Das ist aber soweit ich weiß der einzige Unterschied.
Ich bekomme hier eine Warnmeldung wenn ich eine APP aktualisieren will die ursprünglich von einer anderen Quelle kam.
Da ich aber vorhabe die APP ab jetzt mit Droid-ify zu installieren lasse ich das zu und gut.
Der Installer ist "wichtig" um zu erkennen, ob die Datei via einem Store oder "einfach nur so" installiert wurde und je nachdem werden dann gewisse Berechtigungen erlaubt oder nicht, wie z.B SMS versenden.
Manche Apps nutzen es auch als Überprüfung um festzustellen, ob sie von Google Play bezogen wurden um so nicht z.B. von Lucky Patcher, etc. modifiziert worden zu sein (da gibts eine eigene Google Services API dafür).
Der F-Droid Client wird aber zusätzlich laufen wenn installiert? Oder was genau ist mit "entfernen die dann" gemeint?
Im Moment ist es so ,dass jetzt beide Stores vorinstalliert sind. Über kurz oder lang (also nach ein paar Update Zyklen) wird aber dann nur noch Droid-ify vorinstalliert sein (so wie bisher nur F-Droid vorinstalliert war)
Ich nutze Droid-ify jetzt schon eine ganze Weile und habe daher F-Droid einfach deaktiviert.
Wenn dir aber auch künftig F-Droid lieber ist ,kannst du es z. B. jederzeit umgekehrt machen.
Droid-ify ist fein, es gibt nur Dinge, die F-Droid besser oder überhaupt macht, z.B. aus der Repositories Ansicht für ein Repository den QR-Code zeigen (und scannen) oder Link sharen, damit habe ich Droid-ify initial zwei Repositories mitgeteilt, die nicht in der Default-Liste waren. Oder die Nearby Funktion.
Ein Mischbetrieb (Updates mal hier mal dort) ist wohl nicht empfehlenswert wegen der unterschiedlichen Installer-Source? Denke, ich werde in Zukunft Droid-ify standardmäßig nutzen und parallel F-Droid halten.
Ein Mischbetrieb (Updates mal hier mal dort) ist wohl nicht empfehlenswert wegen der unterschiedlichen Installer-Source? Denke, ich werde in Zukunft Droid-ify standardmäßig nutzen und parallel F-Droid halten.
Habs durchgehalten und das Update über den normalen Mechanismus inkl. Benachrichtigung hat einwandfrei funktioniert.Den gleichen Gedanken hatte ich such gerade
Zuletzt bearbeitet:
Mega! ich freu mich, dass die neue Version raus ist.
Ich konnte alles soweit per fastboot aufspielen.
Jetzt hab ich aaaaaber trotzdem noch eine Frage:
Gibt es irgend eine Möglichkeit den Bootloader zu schließen?
Bei meinem 8.1 und auch bei dem 8.1 meiner Frau lässt sich der Bootloader nicht schließen.
Ich hab bei meiner Frau jetzt das OTA-Update gefahren, leider geht es trotzdem nicht und die "OEM-Entsperrung" ist ausgegraut.
Hat den Effekt, dass der Bootloader offen bleibt und Fingerabdrücke nicht funktionieren.
Bin dankbar über Ideen und Expertise.
LG
Ich konnte alles soweit per fastboot aufspielen.
Jetzt hab ich aaaaaber trotzdem noch eine Frage:
Gibt es irgend eine Möglichkeit den Bootloader zu schließen?
Bei meinem 8.1 und auch bei dem 8.1 meiner Frau lässt sich der Bootloader nicht schließen.
Ich hab bei meiner Frau jetzt das OTA-Update gefahren, leider geht es trotzdem nicht und die "OEM-Entsperrung" ist ausgegraut.
Hat den Effekt, dass der Bootloader offen bleibt und Fingerabdrücke nicht funktionieren.
Bin dankbar über Ideen und Expertise.
LG
Geht nur per Fastboot. Entweder mittels UBPorts-Installer, @Lhotzes Fastboot-Methode oder Shifts/amartinzs Fastboot-Methode.
Warum hast du das per Fastboot gemacht? Kamst du von einem CustomOS/ShiftOS-G 6.4 (2026-02-05)? Von ≤ ShiftOS-G 6.3 (2025-12-19) auf ShiftOS-l 7.0 (2026-01-22) wären die einfachen Schritte wie unter https://forum.shiftphones.com/threads/shiftphone_8-sos-7-0-l-20260122.7686/#-installation und https://forum.shiftphones.com/threa...86/#-wechsel-zwischen-shiftos-g-und-shiftos-l beschrieben ausreichend gewesen.
Welche Fastboot-Methode hast du genutzt? Die, die @Lhotze beschrieben (ich hier nochmal ausführlicher erklärt habe) hat oder die, die Shift hier erklärt?
Die OEM-Sperre ist etwas anderes als Bootloader-Lock.
ich hab erst die von @lhotze gemacht - bzw. deine Erkärung. Dabei hab ich mir das System zerschossen und kam nur noch in den Fastboot ohne Recovery. Ehrlicher Weise bin ich danach mit GPT dran gegangen und hab's installiert. anders hats nicht geklappt.
ich meine trotzdem die den Bootloader-Lock. Danke fürs konkretisieren.
Was ich versteh verweigert Shift-OS das schließen um eine Systemintegrität zu gewährleisten. (?)
ich meine trotzdem die den Bootloader-Lock. Danke fürs konkretisieren.
Was ich versteh verweigert Shift-OS das schließen um eine Systemintegrität zu gewährleisten. (?)
Du musst die Systemintegrität haben, damit das Locken des Bootloaders (das machst du über die Konsole) nicht zu einem Hard-Brick führt. wenn der Bootloader geschlossen ist, kannst du im System OEM-Lock tätigen.
Dadurch, dass du schon ein durchgestartes System hast: Lade dir https://downloads.shiftphones.com/p...NE_8.SOS.7.0.L-RELEASE-LIGHT-20260122-OTA.zip auf dein Smartphone. Navigiere nach Einstellungen → System → Systemaktualisierung → Dreipunktmenü → Lokales Update und wähle das File aus. Installiere es und starte neu. Nach dem Nestart wiederhole dies noch einmal. Nun sollte in beiden Boot-Slots dieselbe ShiftOS-l-Version, die korrekte Recovery und der korrekte Bootloader installiert und somit die Systemintegrität vorhanden sein. Starte nun in den Fastboot und gebe
Dadurch, dass du schon ein durchgestartes System hast: Lade dir https://downloads.shiftphones.com/p...NE_8.SOS.7.0.L-RELEASE-LIGHT-20260122-OTA.zip auf dein Smartphone. Navigiere nach Einstellungen → System → Systemaktualisierung → Dreipunktmenü → Lokales Update und wähle das File aus. Installiere es und starte neu. Nach dem Nestart wiederhole dies noch einmal. Nun sollte in beiden Boot-Slots dieselbe ShiftOS-l-Version, die korrekte Recovery und der korrekte Bootloader installiert und somit die Systemintegrität vorhanden sein. Starte nun in den Fastboot und gebe
fastboot flashing lock ein. Nach dem daraus folgenden Werksreset solltest du keinen Backstein haben und nachdem du durch den Einrichtungsassistenten gelaufen bist in den Entwickleroptionen OEM-Lock setzen können. Darauf folgt ein weiterer Werksreset.
Kurze Frage ,damit ich was lerne.
reicht es da jetzt den einzelnen Befehl zum locken zu nehmen?
Bzw. warum bedarf es da nun nicht die beiden aus der Anleitung?
"/fastboot flashing lock_critical
./fastboot flashing lock"
(Antwort auch gern per PN ,falls es zu OT wird)
A) wurde meines Wissens nicht critical unlocked und B) (da bin ich mir jetzt aber nicht ganz sicher) wird beim normalen Locken critical gelockt, wenn es noch offen steht.
Achso danke
ich bin nur nach der Anleitung von Alex gegangen und da klang es für mich so ,dass beim entsperren beides notwendig ist und dann eben für das sperren auch wieder beides gesperrt werden soll.
Hallo Zusammen,
Ich habe auch das neue Update installiert und auf droidify von F-Droid umgestellt, dann alle Apps mal geupdated, dass die auf den neuen Store umstellen. Bei 2 Apps (Signal und Bitwarden) klappt dies jedoch nicht (installierte version hat andere signatur) also hab ich signal einmal neu aus droidify installiert, es besteht aber immer noch dasselbe Problem. Weiß da jemand eine Lösung oder geht das nur wenn es dann eine neue Version zum updaten gibt?
Ich habe auch das neue Update installiert und auf droidify von F-Droid umgestellt, dann alle Apps mal geupdated, dass die auf den neuen Store umstellen. Bei 2 Apps (Signal und Bitwarden) klappt dies jedoch nicht (installierte version hat andere signatur) also hab ich signal einmal neu aus droidify installiert, es besteht aber immer noch dasselbe Problem. Weiß da jemand eine Lösung oder geht das nur wenn es dann eine neue Version zum updaten gibt?
Sollte nicht der Fall sein wenn du die Apps aus derselben Repo installierst. Vielleicht das mal überprüfen.
Bei Bitwarden hab ich es mit Neuinstallieren jetzt hinbekommen. Hm backup kann da aber eventuell bicht zuschlagen, dass seedfault die "alte" apk bereitstellt?
Habs eben nochmal probiert (auch cache von droidify nochmal gecleaned) - er lädt das packet runter (bei signal gibts auch nur eine mögliche quelle) installiert und speckert dann direkt rum.
Zuletzt bearbeitet: