(SHIFT6mq) LineageOS 20 (Android 13)

Heisst das mit Calyx hätte ich meine Apps wieder? Bis jetzt sind sie ja noch da. In Calyx funzen die Apps, allerdings ist das heutige Update natürlich neuer als das von Calyx. Werde ich wohl auf ein Calyx Update warten müssen. Mein e/ 6mq ist grade unterwegs.
 
Wegen 32 vs 64 Bit, hier ein Quote von einem anderen (noch unveröffentlichten) Thread:

Wichtiger Hinweis für 32-Bit Anwendungen / Apps​


Wir würden gerne auf die 32-Bit Kompatibilitätsschicht für Apps verzichten.
Das bedeutet, dass Apps, die nur für 32-Bit ausgelegt sind, nichtmehr unterstützt werden.

Betroffen sind Anwendungen, die seit längerer Zeit nichtmehr aktualisiert wurden, da bereits 2017 angekündigt wurde, dass Apps 64-Bit unterstützen müssen.
Diese Anforderung würde im August 2019 eingeführt, mit Ausnahmen für Apps, die eine ältere Version von Unity als 5.6 nutzen, welche im August 2021 aufgehoben wurde.

Theoretisch sollten also nur Apps betroffen sein, welche seit August 2021 nichtmehr aktualisiert wurden.
(Für Entwickler: Support 64-bit architectures)

Falls es Einschränkungen oder Probleme bei eurer Nutzung gibt, meldet euch bitte!
Wir nutzen die Beta-Test Phase um zu evaluieren, ob wir für diesen Schritt schon bereit sind.
 
Das heisst also das alle Bezahlten Apps die nicht 64 Bit supported werden, aber auch ohne liefen kann ich dann getrost in die Tonne treten. Fazit: App weg, und geld zum Fenster raus geworfen.:unsure::eek::cry:
Aber wie soll der Laie denn erkennen wenn er eine App kaufen will ob diese eine 32 oder 64 Bit Anwendung ist. Schliesslich werden bestimmt nicht alle App Entwickler tausende von Apps mal eben so auf 64 Bit umstellen, oder doch???
 
Zuletzt bearbeitet:
Kann man nicht erkennen! Wenn man eine App kauft welche schon mehrere Jahre nicht mehr aktualisiert wurde sollte man sich überlegen sie zu kaufen. Erstens kann sie 32 bit sein, zweitens wenn sie nicht regelmäßig Updates bekommt sollte man sie sowieso nicht kaufen. Doof ist das natürlich bei Apps die man bereits gekauft hat.
 
Woran erkenne ich, ob eine installierte App für 32 oder 64bit erstellt / programmiert wurde?
Das heisst also das alle Bezahlten Apps die nicht 64 Bit supported werden, aber auch ohne liefen kann ich dann getrost in die Tonne treten. Fazit: App weg, und geld zum Fenster raus geworfen.:unsure::eek::cry:
Aber wie soll der Laie denn erkennen wenn er eine App kaufen will ob diese eine 32 oder 64 Bit Anwendung ist. Schliesslich werden bestimmt nicht alle App Entwickler tausende von Apps mal eben so auf 64 Bit umstellen, oder doch???
Wenn sie im Play Store erworben wurde, ist sie mit ziemlicher Sicherheit kompatibel, da seit 2019 64-Bit Unterstützung erzwungen wird.

Heißt, falls auf so eine App gestoßen wird, (meist F-Droid oder Bezugsquellen außerhalb des Play Stores) die Entwickler bitten die 64-Bit Unterstützung einzubauen.
 
Danke für die Korrektur. Bzw. heißt das das Apps die mit 32bit laufen und lange nicht aktualisiert wurden aus dem Store geflogen sind? Oder könnten da noch welche rumlungern?
 
Wenn sie im Play Store erworben wurde, ist sie mit ziemlicher Sicherheit kompatibel, da seit 2019 64-Bit Unterstützung erzwungen wird.

Heißt, falls auf so eine App gestoßen wird, (meist F-Droid oder Bezugsquellen außerhalb des Play Stores) die Entwickler bitten die 64-Bit Unterstützung einzubauen.
Bei mir ist es eine einfach gestrickte ältere Doppelkopf-Aufschreib-App, auf deren weitere Funktion ich hoffe.
 
  • Like
Reaktionen: Mäx2020 und danielp
Heißt, falls auf so eine App gestoßen wird, (meist F-Droid oder Bezugsquellen außerhalb des Play Stores) die Entwickler bitten die 64-Bit Unterstützung einzubauen.
Heißt, dass auch viele (aktuelle) Apps aus meinem Repo betroffen wären. Da ich aus verschiedenen Gründen (ich baue nicht selbst; Repo läuft auf "personal space" und hat daher eine Grenze von 30 MB per App) mich oftmals für einen ABI-Build entscheiden muss, trifft es dabei i.d.R. armeabi-v7a (also den 32bit Build) – da dieser von den meisten Geräten unterstützt wird und ich auch Nachhaltigkeit (hier: die möglichst lange Nutzung von Geräten; bei mir ist z. B. auch noch ein FP2 aus 2015 im regulären Einsatz, mit Android 11) fördern möchte.

Ich kann den Ansatz, bei neuen Geräten die 32bit-Unterstützung wegfallen zu lassen, durchaus verstehen. Aber so lange noch viele 32-Bitter unterwegs sind, werde ich noch armeabi-v7a in meinem Repo bevorzugen. Ein allmählicher Shift (oops) zu armv8 (64bit) wird kaum vor 2024 "Schwung aufnehmen".

@amartinz bitte nicht als "Druck" von meiner Seite verstehen. Sobald mich das Phone8 erreicht, wird es mein 2015er FP2 ersetzen, und ich werde persönlichen Druck fühlen 🙈 Sollte es irgendwo eine aussagekräftige, aktuell gehaltene Statistik geben, wie hoch der Prozentsatz von reinen 32bittern ist, verfolge ich die gern – und mache dann zur passenden Zeit wieder einen Poll im Fediverse ;) Ggf. shifte ich einzelne Apps auch schon früher (z. B. wenn sie aufgrund von Hardware-Anforderungen auf "Altgeräten" ohnehin nicht oder nicht wirklich brauchbar laufen). Hinweise auf solche Kandidaten gern per DM (oder via Issue hier).
 
  • Like
Reaktionen: Mäx2020 und danielp
@Izzy_: nicht super aktuell: android.stackexchange.com/... (Q3 2022), aber die Quote von armeabi-v7a (32bit) steht so bei ~19%. Tendenz sicher sinkend 😉
Nur seltsam: was sind 17% 'Others'?
Verlässlichere Statistiken scheint es nicht zu geben.

Was wäre denn dein persönlicher Grenzwert? Obwohl, du wirst es sicher merken: nämlich dann wenn sich mehr Nutzer mit neueren Geräten/ROMs bei dir beschweren, als jene mit älteren (vorrausgesetzt du bevorzugst schon mal ein paar 64bit builds und testest mal die Reaktionen)... 😉
 
nicht super aktuell: android.stackexchange.com/... (Q3 2022), aber die Quote von armeabi-v7a (32bit) steht so bei ~19%. Tendenz sicher sinkend 😉
Nun ja, ein paar Punkte dazu:
  • wenn schon "damals" arm64 überwogen hat, sollte diese Tendenz sich eher verstärkt haben
  • was fehlt ist die Angabe, wie viele Geräte davon "arm64 only" sind, also keine 32bit mehr unterstützen (die Statistik beschreibt ja eher die verbaute CPU – und die unterstützt i.d.R. auch dann 32bit, wenn sie selbst 64bit ist). Die meisten Fragen, die mich diesbezüglich bislang erreicht haben, kamen von arm64-Gerätenutzern, die lieber eine arm64 Version hätten (armeabi aber verwenden können). Bislang ganze 2 von jenen, die kein 32bit mehr können (Pixel 7+).
  • die Statistiken beziehen sich auf die globale "PlayStore-Welt" – in der "FOSS-Welt" sieht es da scheinbar anders aus. Eine Grafik, die ich kürzlich erhielt, zeigte die Nutzung der 32bit Version leicht über der 64bit an (siehe unten).
  • ich möchte ja insbesondere die lange Nutzung (aka "sustainability") fördern. Klar gibt es arm64 seit ca. 2016. Aber seit wann war der 32bit Anteil von Neugeräten in einem eher "unbedeutenden" Rahmen?
install_base.png
Grafik stammt aus dem Februar diesen Jahres. Obwohl sowohl eine 32bit als auch eine 64bit Version angeboten wurden, wurde die 32bit Version deutlich häufiger installiert.

Was wäre denn dein persönlicher Grenzwert?
Schwer zu sagen, da spielen verschiedene Faktoren mit rein. Ich schaue jetzt bereits wo es sinnvoller ist, die arm64 Builds zu nehmen – und frage auch die jeweiligen Entwickler, welche sie bevorzugen. Aufkommen tut die Frage ohnehin fast nur bei Flutter oder ReactNative (wo man ein "Hello World" ja kaum problemlos unter 5 MB bekommt 🙊) – selten bei Kotlin und so gut wie nie bei Java. Jetzt könnte man nach dem "Kipp-Punkt" fragen, zu dem 32bit-Neugeräte unter 10% fielen, und da dann 5 Jahre drauf legen. Oder einen Poll machen, wer noch auf 32bit angewiesen ist (nicht jeder kann sich alle 2 Jahre, oder überhaupt, ein Neugerät leisten). Wie aussagekräftig das dann ist, weiß ich nicht.
Hundert Prozent Sicherheit wird es nie geben (na ja, 2030 vielleicht 🙊). Es wird also eher ein "allmählicher Übergang".

wenn sich mehr Nutzer mit neueren Geräten/ROMs bei dir beschweren, als jene mit älteren (vorrausgesetzt du bevorzugst schon mal ein paar 64bit builds und testest mal die Reaktionen)...
Das tue ich in der Tat bereits. Allerdings überwiegend bei Apps, die ich entweder für "recht speziell" oder aufgrund ihres vermuteten Ressourcen-Bedarfs für eher nicht "Altgerät-geeignet" halte. Mit der Zeit werde ich diese Tendenz sicher ausbauen, und den 64bit-Anteil erhöhen. Insbesondere, wenn immer mehr 32bitter langsam ihren Geist aufgeben, oder nicht mehr wirklich alltagstauglich sind. Ich habe zwar sogar noch ein Gerät aus 2010 (Motorola Milestone 2) hier im Einsatz – aber ganz ehrlich: taugt noch gut als Nightstand & Wecker, aber ohne Updates etc. hängt es halt auf Kitkat fest (und auch das nur Dank CyanogenMod) und ist somit kein wirklicher Maßstab für dieses Thema :ROFLMAO:.
 
  • Love
Reaktionen: sh^fty
Schade das man die Trennung der Töne und Lautstärke für Klingelton und SMS wieder rausgenommen hat:unsure::(:eek: Warum nur???(n) Ist dann ja wohl auf allen Lineage basierenden OS so. Wenn mal was funktioniert, muss man es gleich wieder entfernen. Immer wieder das selbe.:cry:
 
@NoG....eFan: Ich würde es eher so interpretieren: es wurde durch ein Neues vom 08.04. ersetzt; jenes vom 06.03. ist aber noch verfügbar. Meine Vermutung: So spart Marvin Speicher und kann dennoch zwei aktuelle Releases anbieten, die sich zumindest etwas (mehr) unterscheiden.

PS: Da nur zwei microG releases pro Monat erstellt werden, war es das vermutlich schon für den April (nach dem Release vom 06.03 kam auch erst mal nix bis zum 01.04.) 🤷‍♀️
 
  • Like
Reaktionen: NoG....eFan
Schade das man die Trennung der Töne und Lautstärke für Klingelton und SMS wieder rausgenommen hat:unsure::(:eek: Warum nur???(n) Ist dann ja wohl auf allen Lineage basierenden OS so. Wenn mal was funktioniert, muss man es gleich wieder entfernen. Immer wieder das selbe.:cry:
Weil AOSP das Feature jetzt selbst integriert seit QPR2, aber noch versteckt hat und es Konflikte mit der Lineage Integration ausgelöst hat.

Der Revert stand auch im Changelog und es wird bald wiederkommen.
 
Wir würden gerne auf die 32-Bit Kompatibilitätsschicht für Apps verzichten.
Ich musste zurück auf 32-Bit (lineage-20.0-20230322-nightly-axolotl-signed.zip) wegen der App Silence (https://f-droid.org/de/packages/org.smssecure.smssecure/)
Silence nutze ich gerne als SMS App weil a) verschlüsselte Kommunikation möglich und b) eine sehr praktikable import/export Funktion für SMS.
Issue #848 + #853 im dortigen Tracker weisen bereits auf die Probleme hin. Ich hoffe auf baldigen fix. (https://git.silence.dev/Silence/Silence-Android/-/issues)
Für das lineage-axolotl wünsche ích mir noch etwas mehr Zeit für 32 bit. 🙏
 
Glaub da wird nicht mehr viel passieren. Das Silence Project scheint gestorben zu sein. Ist/War ein Fork von Signal welches ja die Unterstützung verschlüsselter SMS eingestellt hat! Der letzte sinnvolle Commit war vor zwei Jahren.
Würde ich mich eher nach einer anderen SMS App umsehen wobei man dann auf die Verschlüsselung sicher verzichten muss. Kenne keinen vergleichbare SMS App welche Verschlüsselung unterstützt. Import/Export unterstützen alle passablen SMS Apps.
 
  • Like
Reaktionen: amartinz
Hab ihr auch das Problem, das Sachen nur passieren wenn die App offen ist?
Gilt nicht für alle.
Aufgefallen bspw. bei ner Kalender App oder auch Backup Apps, SMS. Tasks und Benachrichtigungen erscheinen/laufen nur wenn diese offen sind.
Akku Optimierung... ist aus und sollte deshalb wie früher laufen.
Ist also kein generelles Problem.
 
Hast du in den Entwicklereinstellungen vll. die Menge an zugelassenen Hintergrundprozessen limitiert? Wäre jetzt (neben einem dauerhaft aktivierten Energiesparmodus oder externen Apps wie "Servicely' die einzige Idee die ich hierzu beisteuern könnte).
Greetz
 
Hallo zusammen
ich bin neu hier im Forum. Bisher hatte ich das Shift 6m mit OS-L Version im Einsatz. Jetzt habe ich neu das Shift 6mq. Das möchte gerne mit Lineage 20 einrichten, da ich microg benötige. Die Umstellung von OS-G auf OS-L 3.9 hat über SD-Card problemlos funktioniert. Beim Versuch das Lineage 20 zu flashen taucht folgendes Problem auf:

Meine Rechner (LENOVO Yoga 710-11IKB /Windows 10 Home) zeigt das Shift 6mq unter "Bluethooth und andere Geräte"an und es erscheint auch im Geräte-Manager.
Allerdings ist eine aktive Verbindung nur mit PTP möglich (dann wird es aber und fastboot nicht erkannte).
Alle anderen Verbindungsmöglichkeiten führen sofort zum Ausgrauen und damit zur Nichterkennung des Gerätes über adb / fastboot deviceses 😓

Im Shift sind folgenden Einstellungen bereits aktiviert:
- Entwicklermodus ist eingeschaltetet
- Bootlocker ist entsperrt (OEM unlocking)
- USB-Debugging ist aktiv

Im PC sind alle Updates installiert. MTP-USB-Gerätetreibe ebenfalls aktualisiert.
Was habe ich vergessen? bzw. wer hat eine Idee was zu tun ist? 🤔
Danke schon mal an alle die sich damit befassen wollen/können.
 
Die Umstellung von OS-G auf OS-L 3.9 hat über SD-Card problemlos funktioniert.
Das ist ja das gute. Das ist auch von Shift so gewollt. Lineage und alle anderen Custom Roms werden nicht von Shift supported, aber Shift arbeitet mit der Custom Community zusammen um dem Nutzer "sein" persönlich beliebtes Rom zu ermöglichen. Ich hoffe ich habe mich einigermaßen korrekt ausgedrückt. Es gibt hier aber Leute die das explizit noch ausführlicher erklären können. Wenn du mit dem UB-Port Installer nicht klar kommst (was ich mir aber nicht vorstellen kann), geh einfach an den Anfang des gesammten Threeds und les dir von @amartinz alles in aller Ruhe durch. Dann wird das auch was werden.(y)
 
Zuletzt bearbeitet: