Kann ja gar nicht sein: Du hast ja noch gar keinen schwarzen Bildschirm und kannst dein Gerät noch bedienen – also Chill down.
Ansonsten wurde dir ja schon gut geholfen.
/e/OS U (community; Android 14) fürs SHIFTphone 8.0 ist draußen!
- Ersteller Dwain Zwerg
- Erstellt am
- SHIFTphone 8
-
- Schlagworte
- /e/os custom rom shiftphone 8
Ansonsten wurde dir ja schon gut geholfen.
So, ich habe es auch erfoglreich geschafft e/os (IMG-e-2.9-a14-20250323478433-community-otter.zip) auf dem Shift 8.1 zu installieren. Telefonieren und alles geht super. Mich würden aber noch ein paar Erfahrungsberichte interessiern:
1. Welche Kamera App nehmt ihr? Die vorinstallierte erschlägt mich irgendwie ganz schön mit den ganzen Optionen
2. Ich habe auch mal die Personalausweis App getestet. Es wird zwar der Ausweis per NFC erkannt, aber die Daten werden nicht zu Ende ausgelesen. Hat das mit den hier erwähnten Zertifikaten zu tun, die nicht da sind, weil der Bootloader offen ist?
3. Hat hier mal jemand gefragt, wie es mit dem Zurückschicken des 6m läuft? Irgendwie traue ich mich nicht, komplett auf das 8 umzusteigen, wenn der Bootloader offen ist. Und alles neu muss ich ja dann auch machen, wenn ShiftOS L raus kommt oder?
4. Ist der offenen Bootloader ein Bug von e/os ? Heißt das, mit der nächsten Version geht das es dann vielleicht?
PS: Als Launcher hab ich den von Fossify (https://f-droid.org/en/packages/org.fossify.home/). Kann ich sehr empfehlen.
1. Welche Kamera App nehmt ihr? Die vorinstallierte erschlägt mich irgendwie ganz schön mit den ganzen Optionen
2. Ich habe auch mal die Personalausweis App getestet. Es wird zwar der Ausweis per NFC erkannt, aber die Daten werden nicht zu Ende ausgelesen. Hat das mit den hier erwähnten Zertifikaten zu tun, die nicht da sind, weil der Bootloader offen ist?
3. Hat hier mal jemand gefragt, wie es mit dem Zurückschicken des 6m läuft? Irgendwie traue ich mich nicht, komplett auf das 8 umzusteigen, wenn der Bootloader offen ist. Und alles neu muss ich ja dann auch machen, wenn ShiftOS L raus kommt oder?
4. Ist der offenen Bootloader ein Bug von e/os ? Heißt das, mit der nächsten Version geht das es dann vielleicht?
PS: Als Launcher hab ich den von Fossify (https://f-droid.org/en/packages/org.fossify.home/). Kann ich sehr empfehlen.
Ich kann sinnvoll nur zu 3 sagen, dass die AusweisApp keine Google-Zertifizierung braucht und NFC generell etwas fiddelig ist. Da kommt es sehr auf die Ausrichtung an. Vom Ausweis werden deutlich mehr Daten übertragen als es bei einem Bezahlvorgang nötig ist, die Verbindung muss also länger gut sein.
PS: Fossify hat auch ne Kamera, habe ich aber noch nicht verwendet.
PS: Fossify hat auch ne Kamera, habe ich aber noch nicht verwendet.
Ja, ein ROM Wechsel, egal welches erfordert ein Full Wipe.
Ob das ein Bug ist weiß ich nicht. Aber das es noch Probleme mit /e/OS schon. Außerdem kann dies auch nicht jedes ROM. iodéOS kann dies bspw. ShiftOS L soweit ich weiß noch/nicht. LOS kann es nicht.
Ja, ist wie gesagt ein Sensibelchen. Auch wenn ich es nicht nutze.
Der Bootloader konnte auf den phone 8.0 schon geschlossen werden, Aber mit dem phone 8.1 gab es ein Softwareupdate für Modem und Bootloader, dass /e/ noch nicht eingebaut hatte, weshalb es Probleme mit der Telefonie geben könnte und sich der Bootloader (zumindest beim phone 8.1) nicht schließen lässt. LineageOS kann den Bootloader gar nicht schließen. Bei einem GSI (wie dem iodéGSI) geht dies rein konzeptionell auch nicht.
Meines Verständnisse nach werden beim Bezahlvorgang gar keine Daten ans Smartphone übertragen. Es werden nur Daten vom Smartphone übertragen. Beim Ausweis sieht es genau umgekehrt aus. Und der Ausweis hat keine eigene Energiequelle und muss deshalb erstmal durch NFC elektrisch aufgeladen werden …
@Haihah
1 - Ich nutze die von /E/ - Einmal eingestellt und gut - mir persönlich reicht das soweit.
2 - Perso brauchte ich die Tage... ging einwandfrei, sowohl auf dem 8.1er als auch meinem OnePlus - beide offene Bootloader mit /e/
3 - ?
4 - kein Bug, soweit ich weiß, sondern dem geschuldet, daß das /e/ noch die ältere Versionsnummer (Sicherheitspatches?) hat.
Sollte also beim nächsten oder übernächsten Update von /e/ geschlossen werden können. - Solange man kein Shift Update macht.
1 - Ich nutze die von /E/ - Einmal eingestellt und gut - mir persönlich reicht das soweit.
2 - Perso brauchte ich die Tage... ging einwandfrei, sowohl auf dem 8.1er als auch meinem OnePlus - beide offene Bootloader mit /e/
3 - ?
4 - kein Bug, soweit ich weiß, sondern dem geschuldet, daß das /e/ noch die ältere Versionsnummer (Sicherheitspatches?) hat.
Sollte also beim nächsten oder übernächsten Update von /e/ geschlossen werden können. - Solange man kein Shift Update macht.
Zuletzt bearbeitet:
Jein, grundsätzlich haben Smartphone und Karte/Lesegerät da natürlich gegensätzliche Rollen. Kommunikation an sich findet aber bidirektional statt. Die grundlegende "Informationseinheit" ist da die APDU und tritt immer nur in Paaren aus Command und Response auf. Im Grunde meinte ich aber damit nur, dass während Bezahlvorgänge oft unter 1s dauern, das Ausweislesen mehrere Sekunden dauert und damit das Risiko, dass die Verbindung abbricht vielfach höher ist. Das Problem, dass die Antennenausrichtung kritisch ist gilt für beide Kommunikationsrichtungen und da kann auch ein kleiner Wackler oder Fremdeinfluss das Ende der Kommunikation bedeuten. Gerade beim Ausweis ist der größte Teil der Kommunikation kryptographisch abgesichert und wenn da ein Bit umkippt ist es einfach vorbei und man fängt von vorne an.
Der Ausweis wird übrigens nicht geladen, sondern zieht die Energie für seine Berechnungen direkt aus dem Feld und manipuliert die Feldstärke um die Kommunikation zu kodieren. Stark vereinfacht holt der Energie aus dem Feld und schaltet dann kontrolliert den Widerstand hoch und runter um mehr oder weniger Energie zu ziehen. Das kann das Smartphone/Lesegerät dann messen und so findet die Kommunikation statt.
Ja stimmt, Danke, ich hatte im Endeffekt nur den Bootloader-Trouble. Hätte mir alle vorherigen Kommentare noch besser durchlesen müssen, dann hätte ich mir Panik erspart. Aber jetzt läuft alles und ich bin ziemlich zufrieden mit /e/
AUßER...evtl. hat jm. ein ähnliches Problem...Signal: Frisst einfach sehr viel Akku, im Moment wieder mit 23 % mit Abstand am meisten von allen Apps. Dabei find ich die Hintergrundzeit immer am verdächtigsten: 10 Std. (bei 40 Min. Bildschirmzeit). Ich hab Signal die letzten Stunden wohl schon gut genutzt und auch paar Sachen verschickt, steht aber irgendwie nicht im Verhältnis (WhatsApp z.B. bei Hintergrund 2 h/Bildschirmzeit 10 Min.).
Ich bin da schon total sensibilisiert, weil auf meinem alten 5mu mit ShiftOS-L war Signal derselbe Akkufresser, teilweise hat sich der Akku instant entladen beim Öffnen von Signal. Und das war unabhängig davon, ob ich microG drauf hatte oder nicht.
Hab schon recherchiert, aber kam nicht viel bei rum. Signal muss ohne microG ständig irgendwelche Websockets anpingen oder so, das war mal ein Problem...aber sonst!? Hab dann mal versucht, die mobile Datennutzung für Signal zu unterbinden, aber macht auch keinen Unterschied.
Irgendwelche Ideen dazu?
Ja, auf Molly umsteigen und Mollysocket nutzen. Bei microG muss man die App auch registrieren (lassen), dann müsste das auch gefixt sein.
Danke für den Tipp, hab es mal draufgespielt. Also Molly + MollySocket + ntfy + UnifiedPush. Aber Frage: Wenn ich doch UnifiedPush habe, brauche ich doch microG für Molly nicht mehr!? Falls doch, wie registriere ich Molly dafür?
Genau, das eine oder das andere. Molly kann glaub garkein microG (nicht überprüft auf die Schnelle). (Manche?) Apps registrieren sich glaub bei der Installation bei FCM, wenn microG aktiviert ist. Man müsste also Signal neu installieren, nachdem man microG ein- oder ausgeschaltet hat. Aber recherchiere das besser vorher nochmal. Whatsapp kann das glaub sogar 'on the fly', merkt also wenn es keine Google Services gibt und schaltet auf Websocket um und vice versa.
Für Molly Socket brauchst du noch adminforge. Im Übrigen würde ich Molly-FOSS nutzen. Das nutzt keine propräritären (respektive Google-)Services mehr.
Ich hatte ja Hoffnungen, dass das kommende Release (3.0, kommt angeblich am 3. Juni) auch direkt die neue Firmware enthalten würde, und dann alles ganz einfach wäre...
Tja. Bin extra der Testing-Gruppe beigetreten, und obwohl ich mehrfach gemeldet habe dass ich mit deren images kein Netz habe, ist der neueste build immer noch mit alter firmware. Mir scheint auch niemand glauben zu wollen, dass es überhaupt daran liegt....
@amartinz Falls Du zufällig die Zeit finden würdest, das /e/OS-Team diesbezüglich zu kontaktieren, wäre ich (und vermutlich viele andere hier) Dir sehr dankbar
[Und ja, mir ist bewusst, dass die Entwickler auch nur begrenzt Zeit haben und Prioritäten setzen müssen. Die Lösung in diesem Fall scheint mir zwar einfach zu sein, aber da mag ich mich irren. Ich bin allerdings sehr unzufrieden damit, dass das Problem an sich noch nicht anerkannt wurde]
Tja. Bin extra der Testing-Gruppe beigetreten, und obwohl ich mehrfach gemeldet habe dass ich mit deren images kein Netz habe, ist der neueste build immer noch mit alter firmware. Mir scheint auch niemand glauben zu wollen, dass es überhaupt daran liegt....
@amartinz Falls Du zufällig die Zeit finden würdest, das /e/OS-Team diesbezüglich zu kontaktieren, wäre ich (und vermutlich viele andere hier) Dir sehr dankbar
[Und ja, mir ist bewusst, dass die Entwickler auch nur begrenzt Zeit haben und Prioritäten setzen müssen. Die Lösung in diesem Fall scheint mir zwar einfach zu sein, aber da mag ich mich irren. Ich bin allerdings sehr unzufrieden damit, dass das Problem an sich noch nicht anerkannt wurde]
Hab ein öffentliches Issue erstellt: https://gitlab.e.foundation/e/devices/android_device_shift_otter/-/issues/1@amartinz Falls Du zufällig die Zeit finden würdest, das /e/OS-Team diesbezüglich zu kontaktieren, wäre ich (und vermutlich viele andere hier) Dir sehr dankbar