Wenn das S22 schon auf 13 geupdated wurde geht kein Downgrade auf 12 mehr.
Doch das geht. Man flasht mit Odin ein originales Samsung 12er Rom. Ich würde dann das letzte vom September nehmen. Dafür muss auch nicht der Bootloader entsperrt werden.
Android 13!
-
-
Doch das geht. Man flasht mit Odin ein originales Samsung 12er Rom. Ich würde dann das letzte vom September nehmen. Dafür muss auch nicht der Bootloader entsperrt werden.
Dachte das geht nicht weil Samsung einen Schutz gegen Rollback eingebaut hat..?
-
Das machen eigentlich alle Hersteller gleich, dass man direkt in Android nur Updates aufspielen kann.
Daher ja der Weg über Odin mit einem PC und USB Kabel.
-
Der Schutz gegen Rollback ist wohl doch nicht beim OS, sondern beim Bootloader.
Und die letzte Android 12 Version hat den S2 Bootloader, die aktuellste Android 13 Version aber auch S2. Damit sind sie noch kompatibel.
Hätte das aktuelle A13 allerdings schon S3 oder so (ich denke so werden die den hoch versionieren) ginge es eben nicht mehr.
Die aktuelle Android 13 ist S908BXXS2BWA2, die letzte Android 12 ist S908BXXS2AVI7. Beide haben S2 im Namen (die 2 Stellen stehen für den Bootloader, die letzten 4 Stellen stehen jeweils für Android-Version, Jahr, Monat und eine Folgenummer)
-
Genau, die Nummer muss identisch sein. Dann ist das flashen kein Problem.
-
-
Seit ich für die Bluetooth-App die Akku-Optimierungen deaktiviert habe, sind die Signalverluste um einiges seltener geworden.
Direkt nach Deaktivierung hatte ich (wie zu lesen) direkt wieder einen Signalverlust, aber seit dem - bis jetzt, spürbar seltener.
Vor Deaktivierung: ca. 3-5 Signalverluste/Tag.
Nach Deaktivierung: ca. 1x alle 1-3 Tage.
Smartphone: Samsung S20 FE 5G mit Android 13
-
Genau, die Nummer muss identisch sein. Dann ist das flashen kein Problem.
Das one ui 5.1 Update für S22 ist jetzt draußen und es erhöht die Bootloader Version auf 3. Wenn man die drauf macht ists vorbei mit downgrade
-
Genau. Bei mir ebenfalls. Allerdings heisst es: "Unsere Datensätze zeigen, dass Sie unsere Android-Apps FreeStyle LibreLink oder FreeStyle Libre 3 auf einem Smartphone mit dem Betriebssystem Android 12 oder darunter verwenden."
Ich hab wie üblich die Datenschutzhinweise nicht gelesen, aber warum "dürfen" die sowas speichern? Stichwort Datensparsamkeit bzw. Datenvermeidung.
Das wird mit jedem Datensatz mit übermittelt.
-
Ja, ich vermute es. Nur: warum ist das notwendig und damit legal?
So langsam wie die Libre 3 App auf "berührungen" reagiert könnte man meinen, die schicken ein komplettes Image des Handys mit.
-
Ja, ich vermute es. Nur: warum ist das notwendig und damit legal?
So langsam wie die Libre 3 App auf "berührungen" reagiert könnte man meinen, die schicken ein komplettes Image des Handys mit.
Das die App sehr sehr träge ist wenn man einen Eintrag hinzufügen will ist sicher nicht schön. Aber da sehe ich keinen Bezug zum BT Problem.
Weil manchmal geht das auch sehr schnell.
Wenn man sich LIbreview ansieht, bzw. einen CSV Export der Daten aus Liebreview, kann man da ja klar erkennen welcher Wert von welchem Handy bzw. Lesegerät kommt. Da wird einfach die Quelle mit identifiziert um damit zu verhindern das zwei Quellen gleichzeitig aktiv Daten nach LiebreView schreiben. Bzw. das als zusätzliche Funktion mit zu einer Auswertung verwenden.
Deshalb werden die wohl jedes mal mit übermittelt. Könnte man sicher über auch anders lösen in dem man einen eindeutigen Key pro Gerät erzeugt pro Handy. Ob das mit dem Lesegerät auch geht bin ich mir nicht sicher. -
-
Wir wollen bitte mal beim Android13-BT-Thema bleiben.
Ich hab da mal was gefunden:
https://www.br.de/nachrichten/…efaehrlich-werden,TVS6uK7
Wobei ich fest davon überzeugt bin, dass es eben nicht nur den dort beschriebenen FSL/DEXCOM betrifft.
Was mich jedoch erstaunt, DEXCOM zieht sich insofern aus dem Thema raus, als es angibt, Android13 sei nicht kompatibel.
Ich gehöre eher zu den Nutzern, die ein möglichst aktuelles OS bevorzugen. Egal ob Linux, Windows oder Android.
Es ist ja nicht so, als würde Android 13 plötzlich seit neuestem am Horizont aufgetaucht sein.
Hier haben Abbott und DEXCOM schlichtweg ihre Hausaufgaben nicht gemacht. Auch Google, die hier mit im Boot sind, haben wohl nicht alles sauber getestet.
-
Und soviel zur "Risikoanalyse", die ich bei Abbott gerne mal lesen würde. Die allererste FSL1 Software fürn PC war ja schon grausig und wurde glaub ich einmal aktualisiert als das Libre-2 rausgekommen ist.
Mir scheint, die machen mit einem Höllenaufwand ne Software samt "Zulassung gemäß CE/Medizinprodukt" und definieren diese sobald zertifiziert als "fertig". Ich hab mal gelernt, dass Software nie wirklich fertig ist. Edit - außer die Software wird obsolet und nicht mehr genutzt. Jedenfalls gings "meiner" Software vor knapp 20 Jahren so. Man hat immer noch aus den Erfahrungen bei Anwendung dieser was gefunden, was besser geht.
-
"Zulassung gemäß CE/Medizinprodukt"
Ich hab mir sofort folgendes gedacht:
Kann ein medizinisches Produkt, das zertifiziert sein muss, auf einem Gerät betrieben werden, das nicht im Ansatz einer medizinischen Prüfung standhalten würde?Oder auf die Softwarewelt übertragen ...
Kann ich einen Datenbankservice mit 99,99% Verfügbarkeit dem Kunden anbieten, wenn das OS drunter 'nur' 99% Verfügbarkeit hat? -
Ich hab mal gelernt, dass Software nie wirklich fertig ist.
Das unterschreibe ich Dir sofort!
Aus meinem verlinkten Artikel gibt es ganz unten noch einen recht schönen Absatz.
ZITAT:
>>Benjamin Böhm vom Deutschen Diabetikerbund fordert, die Geräte- und Softwarehersteller sollten Patienten mit in die Produktentwicklung einbeziehen. "Damit Fehler und Probleme, die sich auf die Behandlung auswirken können, frühzeitig bekannt und Patienten informiert werden." Wenn solche Fehler passierten, sei es wichtig, dass sie ernst genommen und schnell behoben würden.<<
Und da muss ich sagen, versagt Abbott auf ganzer Linie.
-
Klar kanns das.
Du musst eben deinen Scope bzw. die "Battery Limits" sauber definieren und begründen, warum daraus kein Risiko erwächst. Das "Risiko" wäre zum Beispiel dass ein völlig falscher Wert angezeigt wird, Patient spritzt falsch und löst einen Notarzt-Einsatz aus. Beispiel: 5.5 zu 15.5 mmol oder 50/500 bei mg/l. Leicht unterschiedliche Dosen....
Wenn das Risiko aber "nur" darin besteht, dass die Software nicht mehr läuft, also gar kein Wert angezeigt wird oder die Übermittlung in die Cloud scheitert - das ist so "gefährlich" wie ein Sensorausfall. Wo erwartet wird dass der Patient eigenverantwortlich blutig misst. Unkomfortabel, aber eben nichts dramatisches.
Daher würd ich gerne verstehen, welche teile der Libre-Software (ich tippe auf "alle") als Medizinprodukt unter GMP stehen. Und meine Vermutung ist, dass nahezu das gesamte Userinterface unter GMP steht. Man könnte auch eine Kernsoftware machen, die den aktuellen Wert plus die letzten 5-8h als Diagramm anzeigt - z.B. als aktive "Notification", die sogar auf dem Sperrschirm angezeigt wird. Und dafür sorgen, dass eben das eigentliche UI über diese Notification aufgerufen wird.
Dieser Wert ist dann "verbindlich, daher unter GMP". Weil der Patient sehen kann, dass dort eben "5.5" steht. Der Rest wie die Tagebuchfunktion, was hast du gepritzt ist hingegen dann nicht mehr GMP. Verlierst du formal was wenn du den Eintrag wegen "Syntax Error" nicht schreiben kannst? Eher nicht. Das Risiko für den Patienten ist gering bis nicht vorhanden. Du kannst sogar so weit gehen, dass das Kernprogramm quasi nur die Notification samt Bereitstellung eines "Android Health Devices" unter GMP stellt und ab diesem wars das. Du stellst sicher, dass eben eine 48 statt 480 oder 5.5 statt 15.5 angezeigt wird. Was "das Tagebuch" und der Rest damit macht ist dann egal. Du siehst ja, was du laut Notification als aktuellen BZ hast. Der "Safety" ist, dass der Patient das sieht und somit den Fehler bemerken kann. Dafür kann dieser Teil ohne großen formalen Heckmeck "gepflegt" und "korrigiert" werden bis hin zu Features werden nachimplementiert. Siehe zum Beispiel die Einbindung von Bluetooth-fähigen Insulinpens bzw. Schnittstellen zu diesen.
Ziehst du dich bei der Einstufung der Risiken zu warm an, dann kostet das wegen GMP, Doku des Codes (Funktionsbeschreibungen), dazugehöriger Qualitätskontrolle einfach ein Höllengeld. Und das User-Interface frisst meist die Masse des Codes. Ich habs vor fast 15 Jahren erlebt, was eine zu frühe "Hochstufung" eines Pharma-Leitsystems von "Inbetriebnahme, kein GMP" auf "GMP" und dann "debuggen unter GMP" an Folgekosten verursacht hat. Wir reden über zweistellige Millionensummen und mehrere dutzend Mannjahre zusätzlicher Arbeit. Weil jede zu ändernde Zeile Code einen "Change" samt "Begründung" und "Risikoanalyse nebst Bewertung" braucht. Dann die Funktionsbeschreibung aktualisieren, dann programmieren, dann formal prüfen, dann aufspielen und Testen. Alles übrigens auditsicher dokumentiert und im Vier-Augen Prinzip. Das ist nicht der Zeitpunkt, wo man mal eben ein "Quality of Life" Improvement macht.
Edit: Was auch denkbar wäre - wie beim FSL1 und 2 ein separates "Lesegerät" mitzuliefern, was den verbindlichen Wert anzeigt. Das Handy parallel ist "Zugabe". Somit besteht faktisch kein Risiko einer Fehlanzeige, es ist ne normale App wie z.B. xDrip/Juggluco. Und dass so ein Gerät auch Teststreifen für blutige Kontrollen nimmt versteht sich von selbst.
-
-
AndiHeitzer danke für den Artikel, ich bin froh, dass ich Dexcom angeschrieben habe, im Vorfeld - allerdings noch ohne Antwort (ok, war auch Wochenende
) -
Das das bei Abbott in der Zwischenzeit sehr hoch gehandelt wird sieht man auch aus der Email welche geschickt worden ist.
Die Beteiligung bzw. Meldung an das Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) ist sicher etwas was Abbott weh tut.
Ich bin froh das ich wohl mit meinem Android 13 Smartphone nicht betroffen bin von dem Problem. (Pixel 6). -
Die Beteiligung bzw. Meldung an das Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) ist sicher etwas was Abbott weh tut.
Ja, denke ich auch. Was wohl viel mehr schmerzt, ist eben ein Medienbericht, der sich durchaus auf die Nutzer auswirkt.
Da muss nun eine Umdenken stattfinden, um das Vertrauen der Kunden wieder aufzubauen.
Ich möchte derzeit nicht am Support-Telefon sitzen und mich 'zur Sau machen lassen'.
-
Ja, denke ich auch. Was wohl viel mehr schmerzt, ist eben ein Medienbericht, der sich durchaus auf die Nutzer auswirkt.
Da muss nun eine Umdenken stattfinden, um das Vertrauen der Kunden wieder aufzubauen.
Ich möchte derzeit nicht am Support-Telefon sitzen und mich 'zur Sau machen lassen'.
Der Support ist ein ausgelagertes Call Center. Und ja auch an denen sollte sich der Benutzer nicht abreagieren.
Ich hab mir sofort folgendes gedacht:
Kann ein medizinisches Produkt, das zertifiziert sein muss, auf einem Gerät betrieben werden, das nicht im Ansatz einer medizinischen Prüfung standhalten würde?Oder auf die Softwarewelt übertragen ...
Kann ich einen Datenbankservice mit 99,99% Verfügbarkeit dem Kunden anbieten, wenn das OS drunter 'nur' 99% Verfügbarkeit hat?Ja das kann man. Kostet dann halt Geld wenn der Kunde die Strafe für die fehlende Verfügbarkeit haben will. Wobei ja 99% Verfügbarkeit auch immer mehr sein kann. Also auch 99,99% wenn es keine Probleme gibt.
-
Nochmal - was passiert wenn das Ding die Verbindung verliert? Es ist ärgerlich, aber eben KEIN gesundheitliches Problem. Selbst wenn dadurch die Batterien alle Nase lang zu früh "durch" sind und Sensoren ausfallen bzw. getauscht werden (welche ggf. ersetzt werden) - auch dann passiert nichts im Sinne der Patientensicherheit. Du riskierst halt zivilrechtliche Konsequenzen ggf. mangels Sensorenkapazität (Herstellung) und "Unterversorgung" einzelner. Das gibt ggf. Regressansprüche, aber das wars - weil es kippt keiner aus den Latschen. Und selbst da ist als GKV Mitglied die Frage ob DU klagen kannst oder die Kasse der Vertragspartner ist. Welche ggf. auf Mehrkosten durch Teststreifenverbrauch Abbott in Regress nehmen kann. Bzw. sich mit denen pauschal einigen könnte....
-
