SHIFTPHONE_8.SOS.7.0.L.20250916

Auch verstanden?
Es ist hier genau umgekehrt.
Shift versucht meines Wissens nach jedes Quartal ein Update für OS-G bereitzustellen.
Wie @halemmerich geschrieben hat kann es auch länger dauern, da es externe Abhängigkeiten gibt die nicht beeinflussbar sind. Für ShiftOS-L gilt das nicht im selben Maße, deswegen sind häufigere Updates möglich.
Nur weil man einen Finger bekommt muss man nicht immer gleich die ganze Hand ausreißen.
Ich hab es schon verstanden.
Auch wenn das eine leichte Kritik an einer von dir geliebten Firma war, bin ich nicht gleich zu dumm zum lesen...

Ich glaube mit den eingeschränkten Mitarbeiter Zahlen sollte man auf den Luxus eines eigenen OS verzichten.
Wenn man sowieso G pflegen muss, dann sich darauf konzentrieren und ein Google freies OS gleich von Murena nehmen, wenn man jetzt endlich zusammen arbeitet. Oder eben konsequent weg von Google.
Beides scheint nicht gleichzeitig zuverlässig machbar wenn man auch noch die Vorgänger wie zum Beispiel 6mq zuverlässig unterstützen möchte.
 
Ich hab es schon verstanden.
Auch wenn das eine leichte Kritik an einer von dir geliebten Firma war, bin ich nicht gleich zu dumm zum lesen...

Ich glaube mit den eingeschränkten Mitarbeiter Zahlen sollte man auf den Luxus eines eigenen OS verzichten.
Wenn man sowieso G pflegen muss, dann sich darauf konzentrieren und ein Google freies OS gleich von Murena nehmen, wenn man jetzt endlich zusammen arbeitet. Oder eben konsequent weg von Google.
Beides scheint nicht gleichzeitig zuverlässig machbar wenn man auch noch die Vorgänger wie zum Beispiel 6mq zuverlässig unterstützen möchte.
Gemessen an der gesamten Entwicklungszeit, fließen höchstens 10% in die L Version mit ein.

Jeglich Hardware- und gerätespezifischen Entwicklungen werden in der G Version integriert, getestet, verifiziert und erst danach in die L Version übernommen.
Hier liegt es wirklich nur an den Hürden bei der finalen Zertifizierung, wo wir auf unsere Partner warten müssen.

Im diesem Falle können wir nicht zertifizieren, weil Google bei neueren Test Suites die Enkodierer-Tests verschärft hat und diese bei der Kombination von Android 14 + Qualcomm + C2 + HEVC fehlschlagen.
Es gibt dafür keine Waiver (also keine Ausnahmen), da es ein echtes Problem ist.
Somit müssen wir darauf warten, dass Qualcomm einen Fix liefert.

Wir sind seit Wochen im Gespräch deswegen, es ist aber noch kein Ende in Sicht.
Deswegen haben wir parallel an einem Workaround gearbeitet, welcher uns wahrscheinlich durch die Zertifizierung lässt (dafür gibt es keine Hardwarebeschleunigung beim Enkodieren von HEVC/H.265).
 
Gemessen an der gesamten Entwicklungszeit, fließen höchstens 10% in die L Version mit ein.

Jeglich Hardware- und gerätespezifischen Entwicklungen werden in der G Version integriert, getestet, verifiziert und erst danach in die L Version übernommen.
Hier liegt es wirklich nur an den Hürden bei der finalen Zertifizierung, wo wir auf unsere Partner warten müssen.

Im diesem Falle können wir nicht zertifizieren, weil Google bei neueren Test Suites die Enkodierer-Tests verschärft hat und diese bei der Kombination von Android 14 + Qualcomm + C2 + HEVC fehlschlagen.
Es gibt dafür keine Waiver (also keine Ausnahmen), da es ein echtes Problem ist.
Somit müssen wir darauf warten, dass Qualcomm einen Fix liefert.

Wir sind seit Wochen im Gespräch deswegen, es ist aber noch kein Ende in Sicht.
Deswegen haben wir parallel an einem Workaround gearbeitet, welcher uns wahrscheinlich durch die Zertifizierung lässt (dafür gibt es keine Hardwarebeschleunigung beim Enkodieren von HEVC/H.265).
Interessanter Einblick, Danke.
 
  • Like
Reaktionen: flrno
Gemessen an der gesamten Entwicklungszeit, fließen höchstens 10% in die L Version mit ein.

Jeglich Hardware- und gerätespezifischen Entwicklungen werden in der G Version integriert, getestet, verifiziert und erst danach in die L Version übernommen.
Hier liegt es wirklich nur an den Hürden bei der finalen Zertifizierung, wo wir auf unsere Partner warten müssen.

Im diesem Falle können wir nicht zertifizieren, weil Google bei neueren Test Suites die Enkodierer-Tests verschärft hat und diese bei der Kombination von Android 14 + Qualcomm + C2 + HEVC fehlschlagen.
Es gibt dafür keine Waiver (also keine Ausnahmen), da es ein echtes Problem ist.
Somit müssen wir darauf warten, dass Qualcomm einen Fix liefert.

Wir sind seit Wochen im Gespräch deswegen, es ist aber noch kein Ende in Sicht.
Deswegen haben wir parallel an einem Workaround gearbeitet, welcher uns wahrscheinlich durch die Zertifizierung lässt (dafür gibt es keine Hardwarebeschleunigung beim Enkodieren von HEVC/H.265).
Heißt das, ihr werdet nun die Version mit dem Workaround einreichen?
 
Gemessen an der gesamten Entwicklungszeit, fließen höchstens 10% in die L Version mit ein.

Jeglich Hardware- und gerätespezifischen Entwicklungen werden in der G Version integriert, getestet, verifiziert und erst danach in die L Version übernommen.
Hier liegt es wirklich nur an den Hürden bei der finalen Zertifizierung, wo wir auf unsere Partner warten müssen.

Im diesem Falle können wir nicht zertifizieren, weil Google bei neueren Test Suites die Enkodierer-Tests verschärft hat und diese bei der Kombination von Android 14 + Qualcomm + C2 + HEVC fehlschlagen.
Es gibt dafür keine Waiver (also keine Ausnahmen), da es ein echtes Problem ist.
Somit müssen wir darauf warten, dass Qualcomm einen Fix liefert.

Wir sind seit Wochen im Gespräch deswegen, es ist aber noch kein Ende in Sicht.
Deswegen haben wir parallel an einem Workaround gearbeitet, welcher uns wahrscheinlich durch die Zertifizierung lässt (dafür gibt es keine Hardwarebeschleunigung beim Enkodieren von HEVC/H.265).
Zumindest liegt es also auch daran das die G Version noch auf Android 14 anstatt wie bei L auf 15 läuft?
 
Nein. Das Qualcomm eine veraltete Basis liefert, weshalb man nicht vernünftig Android 16, sondern maximal Android 15 unterstützen kann. Sowohl Fairphone fürs Fairphone 5 als auch Shift warten sehnsüchtig auf die neue Codebasis, bei der das ganze Zertifizierungstheater beim Release des phone 8.1 nicht nötig gewesen wäre, weil bei einer neuere Codebasis nicht dauernd die Zertifizierung fehlschlägt.
 
Nun bin ich auch mal zu OS L gewechselt.
Was mir sofort aufgefallen ist das die Display Helligkeit bzw. Farbe beim Tippen mit der Tastatur sich ständig ändert. Das ist schon etwas störend.
Gibt auch paar Apps die leider nicht funktionieren bzw sind auch über Aurora Store nicht installierbar.
Fluid Meteo
Proton Lumo
 
Das Ändern kannst du unterbinden. Entweder in den Entwicklungsoptionen forcieren, dass immer die höhere Bildfrequenz erzwungen wird, oder generell Smooth Display abschalten, so dass immer 60Hz anliegen. Die Farbdarstellung braucht wohl noch weiteres Feintuning, damit der Wechsel nicht so auffällt. Beim OS-G fällt das nicht auf, weil das gar nicht dynamisch zwischen Bildfrequenzen wechselt soweit ich weiß.
 
  • Like
Reaktionen: R.E.D.
Nun bin ich auch mal zu OS L gewechselt.
Was mir sofort aufgefallen ist das die Display Helligkeit bzw. Farbe beim Tippen mit der Tastatur sich ständig ändert. Das ist schon etwas störend.
Gibt auch paar Apps die leider nicht funktionieren bzw sind auch über Aurora Store nicht installierbar.
Fluid Meteo
Proton Lumo
Lumo hab ich grade insalliert, kannte ich noch garnicht. Also liegt nicht an shift os, vllt "fehler 40"? ;)
 
  • Like
Reaktionen: R.E.D.
Gibt auch paar Apps die leider nicht funktionieren bzw sind auch über Aurora Store nicht installierbar.
Fluid Meteo
Proton Lumo
Lassen sich beide installieren gerade getestet.

1000017537.png 1000017536.png

Melde dich mal bei Aurora ab ,schließ die APP und starte sie neu und melde dich wieder an. Manchmal spinnt der Store und kriegt sich dann wieder ein.

Ansonsten kannst du im Store bei Vortäuschung auch einfach mal das Gerät wechseln ,das hilft auch manchmal.

Final wäre noch den Speicher Cache vom Store löschen ,das hilft eigentlich immer ,wenn sich der Store anders nicht mehr einkriegt.
 
  • Like
Reaktionen: Dwain Zwerg