CalyxOS auf dem Shift8(.1)
- Ersteller tkopq
- Erstellt am
- SHIFT6mq SHIFTphone 8
Ich schätze, es liegt am Bootloader. Und der sollte imho bei Nutzung einer sensiblen App sowieso geschlossen sein.
Ein Calyx-Test-Build ist draußen. Aber leider noch nicht für Shift:
calyxos.org
Aber immerhin:
CalyxOS progress report - our test build with Android 16 is here
CalyxOS progress report - our test build with Android 16 is here
calyxos.org
Aber immerhin:
Die werden vorerst nur mit ausgewählten Testern geteilt, bis sie für alle veröffentlicht werden.
Die für SHIFT.
Die URL wurde halt nicht direkt gepostet, kann aber selbst abgeleitet werden, wie mit vorherigen Versionen.
Wenn man weiß, dass das Shiftphone 8 ein "Wassermarder" ist...
.Das Pixel 7, wie man hier sieht, ist Beispielsweis eine schwarzgefärbte "Großkatze"
Greetz
Ich werde den Built frühestens am Donnerstag installieren. Änderungen abgesehen von Android 16 QPR2:
Für das Shift8 wurde nicht offen gepostet, weil bisher nur ein Testgerät, vermutlich 8.0 vorliegt.
- Switch Automatische Helligkeit neben der Helligkeitsleiste gibt es nicht mehr (aufwendig zu implementieren in der neuen Version (it's now way more complicated to maintain and as such we dropped it))
- Android Auto should work, enable its support in Settings -> Connected devices -> Connection preferences, then install Android Auto from Aurora and the stuff it asks for
- https://github.com/seedvault-app/seedvault/wiki/Known-Issues
- beta on Pixel 5, minor issues encountered:
- hiccups with mobile data: the default APN was wrong for my carrier and I had to fix it manually (but it could be their fault I suppose); mobile data was disabled by default (it wasn't very intuitive to figure out)
- I have an eSTK.me "physical e-SIM" set up to send a notification on startup; it did not show up (but the SIM works, including receiving calls)
- The time in the status bar is black for some reason, while the icons are white. I think they should both be white with the stock wallpaper
- a moto g84 with esim support, and I configured it for my phone in another country. If I reinstall CalyxOS, what will happen with the esim number, it will be detected again?
- It should stay there so long as you don't wipe it explictly, is my understanding.
- Signal - Einstellung Nutzung im Hintergrund erlauben nicht bleibend - Einzelfall, anderer Nutzer hat das Problem nicht
Für das Shift8 wurde nicht offen gepostet, weil bisher nur ein Testgerät, vermutlich 8.0 vorliegt.
Zuletzt bearbeitet:
Ich habe auch gerade mit Mike geschrieben, er meinte es ist in Ordnung die Links hier zu posten.
Also vollständigkeitshalber, die Lösung auf @@Lhotze's Rätsel lautete otter:
Die existierenden waren alle für Vorbesteller reserviert, weswegen sich das ein wenig verzögert hatte.
Also vollständigkeitshalber, die Lösung auf @@Lhotze's Rätsel lautete otter:
- https://release.calyxos.org/factory/otter/16/otter-factory-260720100.zip
- https://release.calyxos.org/factory/otter/16/otter-factory-260720100.zip.sha256sum
Genau, schicken jetzt bald frisch produzierte 8.1 los.
Die existierenden waren alle für Vorbesteller reserviert, weswegen sich das ein wenig verzögert hatte.
Wenn das jemand mal drauf hat, wäre es interessant zu wissen, ob der FP-Sensor(mit/ohne Re-Lock, mit/ohne Root) darauf funktioniert.
Nur kurz die Bestätigung, dass der Guide weiterhin funktionieren sollte, weil Device-Flasher 1.1.1 verwendet werden soll. Ich hab das neue CalyxOS noch nicht installiert. Auf Matrix gibt es wen der es schon erfolgreich unter Linux gemacht hat. Kleinere Aktualisierungen in den 1. beiden Nachrichten
Zuletzt bearbeitet:
Von CalyxOS (Android 15), closed bootloader, vermutlich Status grün (keine Warnung beim Start?? kann mich an keine erinnern, passt auch hierzu) zu CalyxOS 16 Q..2, closed bootloader bin ich jetzt im Status gelb (Hintergrund) und der Fingerprint geht nicht mehr. Evtl. hätte ich beim Installationsprozess etwas anderes machen müssen. Beim Start erhalte ich die niedrigste Stufe der Warnung:
"
Secure Boot, ja!
Geschlossener Bootloader, ja!
Fingerprint-Kalibrierung verloren
Ich kann keinen Fingerabdruck hinterlegen (@jackspeed und die anderen)
"
Your device has loaded a different operating system"Secure Boot, ja!
Geschlossener Bootloader, ja!
Fingerprint-Kalibrierung verloren
Ich kann keinen Fingerabdruck hinterlegen (@jackspeed und die anderen)
Zuletzt bearbeitet:
Liegt es also an Android 16, das der Fp-Sensor nicht funktioniert?Von CalyxOS (Android 15) ... zu CalyxOS 16 Q..2, ...
Fingerprint-Kalibrierung verloren
Vielleicht könnte @amartinz das Problem nochmal etwas genauer erklären?
Was genau hat sich zwischen A15 ->A16 geändert, das solche Probleme mit Kernkomponenten auftauchen?
(Falls ich eine Erklärung überlesen haben sollte, möge man mir vergeben.)
Nein, jedenfalls soweit ich das verstanden hab. Der Sensor brauch abseits entsprechender Treiber, Firmware, ... auch ein für ihn sicheres/verifiziertes System. Also die genannte Kette aus passenden und signierten geschlossenen Bootloader, OS, ... nicht unterbrochener Patchkette, ...
Falls Google die Anforderungen in einer Version hochschraubt um die höchste Verifizierungsstufe zu bekommen ist man natürlich Machtlos wie bspw. beim 6mq, weil alles kann man nicht nachrüsten.
Ich bin ja nur Laie und verfolge das ganze hier recht gespannt und neugierig.
Nebenbei bin ich dazu dann auch mal über ein Video (von The Morpheus) gestolpert ,wo gerade auch die Veränderungen von Android 15 zu Android 16 zur Sprache kommen und was das für die Custom Roms bedeutet.
(also nicht Feature Änderungen ,sondern Änderungen bezgl. G..gle's Umgang mit AOSP und was für die Communitiys schwieriger geworden ist)
Wen es interessiert der kann es sich unter folgendem Link anschauen/hören. (ab Minute 8:00 ca wird es langsam richtig interessant ,finde ich zumindest)
Android jetzt Closed Source? Die bittere Wahrheit
(Der Titel ist allerdings etwas reißerisch, den Inhalt finde ich aber sehr interessant)
Gerade das "Reverse Engineering des Device Trees" scheint ja nun seit Android 16 deutlich komplexer und zeitaufwendiger zu sein und eventuell fällt das "Fingerprintsensor - Problem" da mit rein und macht den Custom Roms so zu schaffen (ist aber nur so ein Laien Gedanke)
Nebenbei bin ich dazu dann auch mal über ein Video (von The Morpheus) gestolpert ,wo gerade auch die Veränderungen von Android 15 zu Android 16 zur Sprache kommen und was das für die Custom Roms bedeutet.
(also nicht Feature Änderungen ,sondern Änderungen bezgl. G..gle's Umgang mit AOSP und was für die Communitiys schwieriger geworden ist)
Wen es interessiert der kann es sich unter folgendem Link anschauen/hören. (ab Minute 8:00 ca wird es langsam richtig interessant ,finde ich zumindest)
Android jetzt Closed Source? Die bittere Wahrheit
(Der Titel ist allerdings etwas reißerisch, den Inhalt finde ich aber sehr interessant)
Gerade das "Reverse Engineering des Device Trees" scheint ja nun seit Android 16 deutlich komplexer und zeitaufwendiger zu sein und eventuell fällt das "Fingerprintsensor - Problem" da mit rein und macht den Custom Roms so zu schaffen (ist aber nur so ein Laien Gedanke)
So ist es. Die Sache ist folgende. CalyxOS & iode bauen auf LOS auf. LOS für das shift8 wird direkt von shiftphone maintained. Leider bekommen sie es derzeit nicht hin das in LOS die Verifizierungskette durchgehend läuft.
Und nun der Ablauf: Nach Manipulation des Bootloaders, und da fällt das Unlock rein welches wiederum benötigt wird um ein Custom Rom aufzuspielen, verliert korrekterweise der FP-Sensor die Kalibrierung.
Das sollte jedoch wieder rückgängig gemacht werden wenn:
A.) die Zertifizierungskette durchgehend korrekt ist UND
B.) der Bootloader geschloßen ist
Leider ist eben die Kette derzeit das Problem. Shift ist dran. Nun können Calyx & andere da nur warten. Da die Verifizierung mit der HW zusammen hängt, und das kann nur shift.
Es gibt einen Patch der aber auch nicht immer funkt. Hat aber den Nachteil das der Bootloader offen sein muß und man muß mit Magisk rum pfuschen. Also eher abzuraten.
Nein. Das ist Normal. Auch wenn der Bootloader wieder locked ist kommt diese Warnung. Sobald kein Original OS vom Hersteller drauf ist wird korrekterweise gewarnt. Das bekommt man auch nicht weg. Ist tief in Android verwurzelt und von Google so implementiert. Auch wenn du das Gerät Original von zB Murena oder iode kaufen würdest, wäre diese Warnung.
Das war dann wohl ich ^^
Bin gerade dabei eine Bugliste zusammen zu schreiben und bei Calyx & auch hier zu hinterlegen. Sind viele Kleinigkeiten.
Außer dem bisherig bereits erwähntem FP-Sensor kommt noch hinzu: Wireless Charging, Custom Key, Camera Glitches, SMS Empfang (vor allem bei zusätzlichen Usern), Notifications etc. Also da ist noch einiges zu tun. Spezielle Government Apps wie die Österreichische eID streiken. Banking Apps wiederum OK.
Aktueller Patchstand: CalyxOS 7.2.1.0
@R.E.D. danke für den Link, genau diese Informationen fehlten mir, um das ganze nachvollziehen zu können. 
Naja. Das Verständnis was mir hier fehlt ist folgendes:@R.E.D. danke für den Link, genau diese Informationen fehlten mir, um das ganze nachvollziehen zu können.
Calyx & iode bauen auf LOS auf. LOS für das shift8 wird von shiftphone selber maintained.
Warum bekommen es die eigenen Devs nicht hin?
Im Video wird erklärt welche Herausforderungen OEM Fremde haben (werden). Aber shiftphone ist ja selber OEM.
Wie dem auch sei. Nach über einem Jahr Calyx down werde ich die paar Wochen auch ohne FP-Sensor und den restlichen Kinderkrankheiten leben können.
Bisher sehr zufrieden mit beidem.
Dem neuem Shift8 und auch mit dem noch kränklichen Calyx.
Ne, das ist nur der gespoofte OS-G 6.2 Fingerprint, soweit ich das sehe. Die CalyxOS Basis ist ja eine völlig andere als die von OS-G, sagt also nix aus.
Ich habe noch nie ein geflashtes Handy, selbst mit Locked BL gesehen ohne dieser Warnung. Calyx, GOS, /e/, iode alle haben das. Kann aber auch sein das ich immer die falschen Handies hatte. FP3 direkt von Murena, FP4 mit iode & Calyx, Pixel 8 & GOS...
Ist aber im Endeffekt irrelevant. Ist nur Optik.
Wichtig ist das die Signaturen intern richtig verarbeitet werden sonst wird das nie was mit dem FP-Sensor.
Ist aber im Endeffekt irrelevant. Ist nur Optik.
Wichtig ist das die Signaturen intern richtig verarbeitet werden sonst wird das nie was mit dem FP-Sensor.
Da gibt es nichts zu Whitelisten. Wie sollte das funkt.?
Während das Bootvorganges gibt es keine Netzwerkverbindung und die Keys werden generell nicht Online verifiziert. Das was zum locken des Bootloaders sein muß, ist das im Calyx Build Keys vom OEM verwendet werden.
Das ist ja der Fall, sonst gäbe es keinen locked BL.
Die Warnung beim booten ist rein Optisch, spielt für den Betrieb keine Rolle.
Warum es aber dennoch die Signaturkette zerreißt und somit der FP-Sensor sich nicht mehr kalibriert...
Maybe ein neues Prüfverfahren in 16 das hart die OEM Keys prüft, und sobald da nicht die Originalen verwendet werden...
Idk
Ich glaube, man muss hier zwei Ebenen trennen:
Wer darf booten?
und wann wird es „grün“ ohne Warnung?
„Grün“ (keine Warnung) ist nur mit originalem OS möglich.
Die Hardware ist intern mit den OEM‑Keys verdrahtet. Nur wenn
das originale ShiftOS läuft, es mit den dazugehörigen OEM‑Keys signiert ist und der Bootloader locked ist,
kann Verified Boot vollständig „grün“ werden – genau das beschreibt @amartinz in seinem Beitrag.
Diese privaten OEM‑Keys gibt SHIFT natürlich nicht raus, das dürfen sie auch gar nicht. Sonst könnte zB Calyx behaupten das ihr Rom SOS ist.
Was SHIFT für Calyx tun kann – und getan hat:
SHIFT kann (und hat) Calyx einen Public Key geben, der im Bootloader hinterlegt wird (siehe OEMPublicKey.h).
Damit kann CalyxOS mit locked Bootloader gebootet werden, weil der Bootloader Calyx‑signierte Images als „gültig“ akzeptiert.
Das ersetzt aber nicht die originalen OEM‑Keys und macht den Bootpfad nicht wieder „grün“ im Sinne von „Originalzustand wie ab Werk“.
Konsequenz für CalyxOS auf dem Shift 8:
Bootloader kann sauber locked sein.
CalyxOS ist korrekt signiert und wird vom Bootloader akzeptiert.
Trotzdem bleibt die Warnung, weil es eben nicht das originale ShiftOS + OEM‑Key‑Kette ist.
Anders gesagt: Der Calyx‑Key sorgt dafür, dass das Gerät mit locked BL startet – aber er kann nicht dafür sorgen, dass das Gerät so tut, als würde noch das originale OEM‑OS laufen.
Deshalb wird es mit CalyxOS auf dem Shift 8 nie „grün wie mit Stock‑ShiftOS“, selbst wenn alles sauber signiert ist und der Bootloader gesperrt ist. Dafür bräuchte man die vollständige OEM‑Key‑Kette, und die liegt (zu Recht) ausschließlich bei SHIFT.
Einzige Möglichkeit wäre wenn Calyx die Hardware bauen liese, mit Ihren OEM Keys.
Und nun sind wir wieder bei dem Punkt.
Vollständige Key-Kette und FP-Sensor:
Wenn nun seit a16 für zB die FP-Sensor Funktionalität, die volle Key-Kette abgefragt wird, schaut es traurig aus.
Aber, ich gehe (noch nicht) davon aus und hoffe das es andere Gründe hat. Denn wir wissen, auch aus dem Calyx Chat, das andere Geräte mit aktuellem a16 Calyx Test Builds, die FP-Sensoren funkt. Also ist es eher (noch nicht) ein generelles a16 Thema.
Wer darf booten?
und wann wird es „grün“ ohne Warnung?
„Grün“ (keine Warnung) ist nur mit originalem OS möglich.
Die Hardware ist intern mit den OEM‑Keys verdrahtet. Nur wenn
das originale ShiftOS läuft, es mit den dazugehörigen OEM‑Keys signiert ist und der Bootloader locked ist,
kann Verified Boot vollständig „grün“ werden – genau das beschreibt @amartinz in seinem Beitrag.
Diese privaten OEM‑Keys gibt SHIFT natürlich nicht raus, das dürfen sie auch gar nicht. Sonst könnte zB Calyx behaupten das ihr Rom SOS ist.
Was SHIFT für Calyx tun kann – und getan hat:
SHIFT kann (und hat) Calyx einen Public Key geben, der im Bootloader hinterlegt wird (siehe OEMPublicKey.h).
Damit kann CalyxOS mit locked Bootloader gebootet werden, weil der Bootloader Calyx‑signierte Images als „gültig“ akzeptiert.
Das ersetzt aber nicht die originalen OEM‑Keys und macht den Bootpfad nicht wieder „grün“ im Sinne von „Originalzustand wie ab Werk“.
Konsequenz für CalyxOS auf dem Shift 8:
Bootloader kann sauber locked sein.
CalyxOS ist korrekt signiert und wird vom Bootloader akzeptiert.
Trotzdem bleibt die Warnung, weil es eben nicht das originale ShiftOS + OEM‑Key‑Kette ist.
Anders gesagt: Der Calyx‑Key sorgt dafür, dass das Gerät mit locked BL startet – aber er kann nicht dafür sorgen, dass das Gerät so tut, als würde noch das originale OEM‑OS laufen.
Deshalb wird es mit CalyxOS auf dem Shift 8 nie „grün wie mit Stock‑ShiftOS“, selbst wenn alles sauber signiert ist und der Bootloader gesperrt ist. Dafür bräuchte man die vollständige OEM‑Key‑Kette, und die liegt (zu Recht) ausschließlich bei SHIFT.
Einzige Möglichkeit wäre wenn Calyx die Hardware bauen liese, mit Ihren OEM Keys.
Und nun sind wir wieder bei dem Punkt.
Vollständige Key-Kette und FP-Sensor:
Wenn nun seit a16 für zB die FP-Sensor Funktionalität, die volle Key-Kette abgefragt wird, schaut es traurig aus.
Aber, ich gehe (noch nicht) davon aus und hoffe das es andere Gründe hat. Denn wir wissen, auch aus dem Calyx Chat, das andere Geräte mit aktuellem a16 Calyx Test Builds, die FP-Sensoren funkt. Also ist es eher (noch nicht) ein generelles a16 Thema.
Nein.
"Wenn der Bootloader bei /e/ OS oder CalyxOS gesperrt wird, ist der Bootzustand "grün", also keine Warnung, weil sie einen eigenen Bootloader haben, wo ihre Signatur hinterlegt ist."
Der neue öffentliche Calyx Schlüssel ist im Bootloader hinterlegt. Damit können mit dem zugehörigen privaten Calyx Schlüssel signierte Builds verifiziert werden. Der Bootzustand ist dann bei gelocktem Bootloader auch "grün."
"Wenn der Bootloader bei /e/ OS oder CalyxOS gesperrt wird, ist der Bootzustand "grün", also keine Warnung, weil sie einen eigenen Bootloader haben, wo ihre Signatur hinterlegt ist."
Der neue öffentliche Calyx Schlüssel ist im Bootloader hinterlegt. Damit können mit dem zugehörigen privaten Calyx Schlüssel signierte Builds verifiziert werden. Der Bootzustand ist dann bei gelocktem Bootloader auch "grün."
Ich glaube, wir benutzen „grün“ gerade in zwei unterschiedlichen Bedeutungen:
- AVB-State „green“ heißt nur: Die aktuell gebootete Partition ist mit einem Schlüssel signiert, den der Bootloader akzeptiert und der BL ist locked.
Das kann auch ein Calyx‑Key sein – genau dafür ist der OEMPublicKey da. In diesem Sinn hast du recht: Calyx‑Build + gelockter BL kann intern „green“ sein.
- Keine Warnung auf dem Bildschirm (so wie bei original ShiftOS) bekommst du aber nur, wenn die komplette Kette „Original‑OS + originaler OEM‑Key + locked BL“ anliegt.
Calyx hat den eigenen Schlüssel im Bootloader hinterlegt bekommen, aber nicht die Shift‑OEM‑Keys – die bleiben bei Shift.
Heißt:
Ja: Calyx kann auf dem Shift 8 mit gelocktem Bootloader in einem validen/verifizierten AVB‑State booten, weil der Calyx‑Key im Bootloader steckt.
Nein: Calyx kann damit nicht die gleiche „kein Hinweis wie ab Werk“-Darstellung erzwingen wie Stock‑ShiftOS, weil es eben nicht mit den originalen OEM‑Keys signiert ist.
Das geht technisch nicht! Dazu müßten die Calyx Keys in die Hardware gebrannt werden.
- AVB-State „green“ heißt nur: Die aktuell gebootete Partition ist mit einem Schlüssel signiert, den der Bootloader akzeptiert und der BL ist locked.
Das kann auch ein Calyx‑Key sein – genau dafür ist der OEMPublicKey da. In diesem Sinn hast du recht: Calyx‑Build + gelockter BL kann intern „green“ sein.
- Keine Warnung auf dem Bildschirm (so wie bei original ShiftOS) bekommst du aber nur, wenn die komplette Kette „Original‑OS + originaler OEM‑Key + locked BL“ anliegt.
Calyx hat den eigenen Schlüssel im Bootloader hinterlegt bekommen, aber nicht die Shift‑OEM‑Keys – die bleiben bei Shift.
Heißt:
Ja: Calyx kann auf dem Shift 8 mit gelocktem Bootloader in einem validen/verifizierten AVB‑State booten, weil der Calyx‑Key im Bootloader steckt.
Nein: Calyx kann damit nicht die gleiche „kein Hinweis wie ab Werk“-Darstellung erzwingen wie Stock‑ShiftOS, weil es eben nicht mit den originalen OEM‑Keys signiert ist.
Das geht technisch nicht! Dazu müßten die Calyx Keys in die Hardware gebrannt werden.
Steht auch hier explizit:
source.android.com
Der Verified‑Boot‑Zustand grün, ist nur für den Fall gedacht, dass das Gerät locked ist und keine eigene / zusätzliche Root of Trust verwendet wird – also genau der Originalzustand mit OEM‑Keys und Stock‑OS.
Sobald ein eigener Key (user‑settable root of trust, z.B. Calyx‑Key) im Spiel ist, ist der Zustand bei locked Bootloader nur noch gelb – und es gibt eine Warnung, selbst wenn alles korrekt signiert ist.
Wobei der AVB State ist aber dennoch grün, dieser bedeudet aber 'nur' das gelocked gebootet werden darf.
Und Calyx muß seine Keys mit einbringen da sie die Private Keys von SHIFT nicht erhalten werden.
Bootvorgang | Android Open Source Project
source.android.com
Der Verified‑Boot‑Zustand grün, ist nur für den Fall gedacht, dass das Gerät locked ist und keine eigene / zusätzliche Root of Trust verwendet wird – also genau der Originalzustand mit OEM‑Keys und Stock‑OS.
Sobald ein eigener Key (user‑settable root of trust, z.B. Calyx‑Key) im Spiel ist, ist der Zustand bei locked Bootloader nur noch gelb – und es gibt eine Warnung, selbst wenn alles korrekt signiert ist.
Wobei der AVB State ist aber dennoch grün, dieser bedeudet aber 'nur' das gelocked gebootet werden darf.
Und Calyx muß seine Keys mit einbringen da sie die Private Keys von SHIFT nicht erhalten werden.
Zuletzt bearbeitet:
Steht auch hier explizit:
Bootvorgang | Android Open Source Project
Der Verified‑Boot‑Zustand grün, ist nur für den Fall gedacht, dass das Gerät locked ist und keine eigene / zusätzliche Root of Trust verwendet wird – also genau der Originalzustand mit OEM‑Keys und Stock‑OS.
Sobald ein eigener Key (user‑settable root of trust, z.B. Calyx‑Key) im Spiel ist, ist der Zustand bei locked Bootloader nur noch gelb – und es gibt eine Warnung, selbst wenn alles korrekt signiert ist.
Wobei der AVB State ist aber dennoch grün, dieser bedeudet aber 'nur' das gelocked gebootet werden darf.
Und Calyx muß seine Keys mit einbringen da sie die Private Keys von SHIFT nicht erhalten werden.
Nochmal: