À propos de daddle

@TheDoctor oder den Thread-Admin!   Zur Zeit ist die Zip im Download für das Android_4.4.4_Recovery_Package_V2.1.zip korrupt. Statt 1083 M des funktionierenden Android_4.4.4_Recovery_Packages endet der Download konstant in drei Versuchen bei 1029 M als Zip, und diese lässt sich nicht öffnen.   daddle   ... Afficher plus

@TheDoctor   I hope I made your day (Weekend)!  ... Afficher plus

TheDoctor schrieb: daddle schrieb: 2. Frage:  Beim Rückflash auf Ota #2 mit der älteren passenden capsule.bin verhält sich der Flash-Vorgang anders.....   Antwort @TheDoctor: 2) Kann ich nicht 100% beantworten. Das BIOS ist für uns leider eine Black Box, in die wir selbst keinen Einblick haben. Generell würde ich davon abraten, auf die ältere BIOS-Version von OTA#2 zurückzuflashen, weil die Daten des BIOS nur in eine Richtung kompatibel sind. Bei diesen Experimenten können Dir Sachen wie die Seriennummer und der DRM-Schlüssel des Geräts verloren gehen, und dann musst Du es einschicken. >>>> Generell ja. ist aber bei mir nicht so gewesen; mittlerweile 3x den Rückflash gemacht, beim ersten Mal dirty, aber zweimal mit kompletten Erase. >>>> Flashen mit dem Recovery-Paket mit den bis auf das system.img darin ersetzten ota #2-Images (boot und recovery.img's aus CWM-Backup, esp.img und Bios aus Update-OTA #2 und fastboot (droidboot).img von einem zweiten Ota #2-Tab per dd gezogen), und nach dem Recovery-Paket-Flash Wiederherstellung und Austausch der geflashten "falschen" ota3-system.img mit CWM-Backup mit advanced restore nur der ota2-system, und alles funktioniert einwandfrei !  DRM-Schlüssel und Seriennummer sind unverändert vorhanden. Antwort@TheDoctor: 3) Der Parameter "-S 200M" weist Fastboot an, Partitionen in Häppchen maximal dieser Größe zu übertragen. War bei einer älteren Version nötig. Die neuere erkennt automatisch, was die Gegenstelle auf dem Gerät verträgt. >>>>Hatte ich mittlerweile auch nachgelesen. Trotzdem vielen Dank für die Beantworung dieser Anfänger-Frage. Zitat @TheDoctor: So, und jetzt bitte Ende der Detaildiskussionen zu unseren Flashscripten. Könnte bitte irgendwer von den ganzen Leuten, die hier vorher über das katastrophale WLAN geklagt haben, mal Feedback zu diesem Thema geben? 🙂 Grüße & ein schönes Wochenende,  Der Doktor _________________________________________ Hallo und guten Morgen Doktor!   Keine Flash-und Skript-Diskussionen mehr, damit es nicht verwirrt. Versprochen. Andererseits hatte ich dadurch frühzeitig entdecken können, dass ein Unterschied zwischen dem Bios in Ota #3 und im Recovery-Paket v1 bestand, und dass in Paket v2 der flash-Befehl für das neue Bios fehlte! Hatte also auch was Gutes, diese jetzt im Thread verpönte Skript-Diskussion!   Zu dem Wlan-Verhalten nach Ota 3 #v2 und Flashen des Recovery-Paketes v2.1:   Es ist gerade mal 24 Stunden voll funktionsfähig im Download, und seriöse oder belastbare Angaben kann man beim besten Willen nach so kurzer Zeit nicht erwarten; inbesondere in Anbetracht der Tatsache, dass bei den Vorgänger-Versionen die Wlan-Problematik in den verschiedensten Ausprägungen bei vielen Usern erst nach längerer Nutzungsdauer des Tablets auftrat.   Hier also meine ersten Erfahrungen aus 36-Stunden Dauerbetrieb des Tabs nach Recovery-Paket v2.1 (hatte vorgestern selber die fehlende Bios-flash Zeile eingefügt, daher v2.1 und 36-Stunden-Zeitraum):   Ein Fehler ist im Wlan-Betrieb bisher nicht aufgetreten; Wlan mit Zugang zum i-net ist direkt nach WakeUp voll verfügbar, auch im StandBy werden Push-Nachrichten jeder Art empfangen und akustisch gemeldet. Geschwindigkeit des Wlans unverändert gut.    Alle diese Funktionen an drei verschiedenen Access-Points und Router getestet mit den gleichen guten Ergebnissen.   Durch den veränderten Kernel sind keinerlei  andere Fehler oder Funktions-Einschränkungen  aufgetreten.   Der System-Software-Stand ist 100% gleich zwischen Ota-Update #3v2 und Android-Recovery-Paket V2.1. Beide getesteten Varianten funktionieren gleich gut; die meiste Zeit verbracht mit dem an der Ota-Update-Kette entlanggehangeltem Update Ota #3v2.      Soweit mein vorläufiges Resumee: es funktioniert alles! Und der positive Ausblick auf das weitere Verhalten ist, dass nach Flashen des Recovery-Paketes v1, also komplettes Neu-Aufsetzen des Tabs, der Wlan-Fehler sofort auftrat. Jetzt nach dem Android-Recovery-Paket v2-Flash sind bisher nach 36 Std.-Dauerbetrieb keinerlei Fehler feststellbar.   Grüsse, daddle   Edit: Kleine Korrektur im Resumee:   "Soweit mein vorläufiges Resumee: es funktioniert alles! Und der positive Ausblick auf das weitere Verhalten ist, dass nach Flashen des alten Recovery-Paketes v1, also dem komplettem Neu-Aufsetzen des Tabs, der Wlan-Fehler sofort auftrat, und nach Recovery-Paket V2.1 nicht! Jetzt nach dem  Android-Recovery-Paket v2-Flash, bzw. zeitlich überwiegend auch nach dem OTA-Update #3v2 sind bisher nach 36 Std.-Dauerbetrieb keinerlei Fehler feststellbar." (Mittlerweile über  44 Stunden) ... Afficher plus

@TheDoctor   Vielleicht kann man ja diesen Thread anpinnen, und den alten "LIFETAB S1034X Updates #3 und #4 (Lollipop)", der eh geschlossen ist,  und den "LIFETAB S1034X Update #2" ent-pinnen?    Würde der Anfang des Forums wieder etwas übersichtlicher werden und die aktuellen Update-Threads könnten dadurch leichter gefunden werden.   Wenn die neue Lollipop-Version kommt müsste dafür sowieso  ein neuer Thread geöffnet werden.   Gruss, daddle ... Afficher plus

War kein copy&paste Fehler soweit ich erkennen kann. Habe aber den Satzbau extra für dich nochmal umgestellt, damit auch jeder den Satzinhalt verstehen kann.     Aber wenn jeder eine xml lesen kann, dann hättest du doch nicht danach gefragt?  Wie gesagt die fastboot-Befehls-Syntax in der flash.bat macht das m.E. im  Recover-Paket.   Ich glaube die xml kommt nur zum Zuge wenn man das über einen Installer macht; jener der auf der Droidboot-Maske u.a mit nachfolgender Meldung immer für Irritationen sorgt:   "E: No valid installer medium found"   Aber genug OT, sonst wird hier nur noch mehr "gespammt".  grüsse, daddle     Edit:  Im neuen Paket V2.1 wurde die flash.xml weggelassen. Das beantwortet doch deine Frage!   Allerdings ist die installer.cmd verblieben, braucht man doch auch nicht soweit ich das überblicke!  Aber ich bin kurzsichtig!  ... Afficher plus

TheDoctor schrieb:  Nein, geht auch unter Linux nicht. Erklärung, vermutlich (müsste Intel uns beantworten): Wird zwar geflasht wie eine Flash-Partition, geht aber tatsächlich nicht ins Flash, sondern ins EEPROM des BIOS. Ist also eine Besonderheit des Intel-Systems. Wir haben das BIOS erstmalig für Euer Recovery Package in unser normales Flash-Script aufgenommen, die Fehlermeldung aber offenbar ignoriert, weil das eigentliche Flashen des BIOS ja geklappt hat.   Grüße Der Doktor   @TheDoctor    Danke für die Erklärung. Es könnte auch noch einen weiteren Grund geben; liest man während des Bios-flash die kleinen Mitteilungszeilen, steht da dass Anteile des alten Bios in mehreren Schritten zwischengespeichert werden, damit der nächste Flash-Abschnitt weitergehen könne. Würde es vorher erased, würde das Update vermutlich stoppen. Dazu die Zeile aus dem Biosflash-Verlauf zu Anfang:    > "Backed up Bios Image for seamless recovery" , und noch andere Zwischen-Backups im weiteren Verlauf Danach erased das capsule.bin oder im Bios eingebaute Routinen diese Abschnitte selbstständig. (Meldung: xxx destroyed)   2. Frage:  Beim Rückflash auf Ota #2 mit der älteren passenden capsule.bin verhält sich der Flash-Vorgang anders als beim Flashen auf eine höhere Version; vor allem zum Schluss wenn die SEC-Firmware  geflasht werden soll, sagt es   All Bios ingredients updated - continue with SEC firmware update... NewVersion 1.1.0. 1013 (zu flashende) OldVersion 1.1.0. 1030 (vorhandene) und dann laufen jede Menge immer gleichlautende Zeilen durch: . Fw Update in progress - Percentage 20%, Stage: 6/17, Last Update Status 572, . . gefühlt ca. 100 Male, und zum Schluss 'Updating ESRT table', und 'press any key to ...`' Flashe ich dann das neuere Bios mit dem RecoverPaket V2 (oder auch nur die neuere capsule.bin, sicherheitshalber im Verbund  mit esp.- u. droidboot.-img ), sieht man das die SEC-Firmware den neueren Stand 1.1.0.1030 beibehalten hat, und jetzt, da gleicher SEC-FW-Stand, nicht neu geflasht wird.   Das  bedeutet die SEC-Firmware wird nicht auf 1.1.0.1013 zurück geflasht, es bleibt immer SEC-firmware Version 1.1.0.1030 drauf!     3.Frage:  Was bewirken die Parameter "-S 200M"?  Diese wurden ja bei Paket V1 in der Linux flash.sh nicht benutzt, wohl in der flash.bat,  und im neuen Paket V2 weder in der flash.sh noch in der flash..bat  benutzt?   Bitte beantworte mir Unwissendem diese Fragen, kurz und knapp genügt mir!    Grüsse, daddle     @McB   Die flash.xml  hat mir auf jeden Fall geholfen den Flashvorgang zu verstehen, besonders da das Bios sonst in den OTA-Updates  "capsule.bin", im Recover-Paket V1 aber BIOSUPDATE.fv heisst, im Paket V2 wieder capsule.bin. Folgender Auschnitt aus der xml erklärt wieso:   </code_group> <code_group name="capsule"> <file TYPE="capsule"> <name>BIOSUPDATE.fv</name> <version>eng.bios</version> </file> die file TYPE "capsule" hat also den <name> BIOSUPDATE.fv, eine Art Platzhalter-Funktion.   und in der >command> Anweisung steht:   <command> <string>fastboot flash capsule $capsule_file</string> <timeout>1800000</timeout> <retry>2</retry> <description>Flashing 'capsule' image.</description> <mandatory>1</mandatory> </command>  In der Zeile <command string> fastboot flash capsule... wird dann für "$capsule_file" aus der <code_group> für file TYPE"capsule" der angegebene <"name"> <BIOSUPDATE.fv> genommen. Im Recover-Paket V2 ist wieder eine abgeänderte xml, in der dieser Umweg über das Namen-Wechsel-Dich-Spiel nicht mehr nötig ist. Ich glaube die xml braucht man hier sowieso nicht, da ja in der flash.bat die Zeile: "fastboot.exe flash capsule BIOSUPDATE.fv"  genau diese Anweisung, die BIOSUPDATE.fv in den Bereich "capsule" zu flashen, direkt an fastboot gibt!,   Schema: fastboot.exe flash <Bereich od.Partitionsname> <Name des zu flashenden Image od. zu flashender Bin-Datei>   Grüsse, daddle ... Afficher plus

Hi, guten Morgen!   Ist noch zu kurz zum beurteilen.   Die Flash-Orgien kosten immer viel Zeit, besonders da ich von jedem Zwischenschritt jeweils ein CWM-Backup mache, alles bisher ohne Root, versteht sich!   Besonders das letzte CWM-Backup nach zig App-Updates hat Stunden gedauert, so dass ich darüber eingeschlafen bin, und ich erst ab heute morgen rebooten und das WakeUp-Verhalten testen kann. (Kein Wunder dass es so lange dauerte, hat 3x hintereinander das Backup gezogen???)   Habe daher nur kurze Sleep -Phasen von nicht mehr als einer viertel Stunde! Da funktioniert es bisher insoweit dass Wlan nach WakeUp immer sofort aktiv war.  Push-Verhalten im StandBy habe ich noch nicht testen können. Sobald ich sicherere Erkenntnisse habe melde ich mich wieder.   Eine Frage noch, warum funktionierte in der flash.bat das "fastboot.exe erase capsule " nicht, wenn es doch in der flash.sh so von Euch angegeben (benutzt) war? Oder kann das nur die fastboot Linux-Version?   Hatte ich genau wie in der flash.sh zwischen oem partition und oem stop partitioning nach erase factory eingefügt..   Grüsse, daddle ... Afficher plus

Hallo!   Doch, erst kommt Ota #3, danach kommt Ota #3v2! Bin gestern abend nochmal mit einem Clean Flash von Lollipop zurück auf Stand Ota #2,. Dann wird zuerst das Update Ota #3, danach Ota #3v2 zum Download angeboten. Ota #3v2 ist auch mit ca 10MB nur halb so gross wie Ota #3 mit ~24MB!   Und die Images in Ota #3R2 und im RecoveryPackage V2 (esp.img und capsule.bin) sind diesmal nach Grösse und Inhalt identisch.    daddle ... Afficher plus

@TheDoctor              - W I C H T I G  -   Hallo, und danke für das neue Recovery-Paket V2 und das Update Ota #3R2.   Habe das Recovery-Paket runtergeladen, und mir fällt auf, dass in der flash.bat die Zeilen: fastboot.exe erase capsule (?) (in der flash.sh "fastboot erase capsule") . . fastboot.exe flash capsule capsule.bin nicht enthalten sind. Sie stehen aber wohl in der flash.sh.    Da die capsule.bin im KK-Recover-Paket 2 enthalten ist, müsste sie auch wie in der flash.sh mit Flash-Befehlen in der flash.bat für Win-User enthalten sein; sonst bliebe ja das "alte" Bios und gäbe es wieder Verwirrung und Reklamationen und der Thread liefe erneut über!     Sollte ich mich irren, dann korrigiere mich bitte.   lg, daddle   Edit: Ergänzung der fehlenden "fastboot.exe erase capsule"- Zeile   Edit2: Dieser Befehl funktioniert in der Windows  flash,bat nicht  >  geht das vielleicht nur mit der Linux-Version? Andererseits  kommt beim Flashen eine Zeile > "erase capsule failure no such device" (oder so ähnlich!), vielleicht ist ja die  Ziel- Bezeichnung nicht korrekt, bzw. nicht erreichbar?   ... Afficher plus

Hallo Luke,   Ich hoffe du musstest zumindest schmunzeln als du deinen Post mit den neuen Wortschöpfungen geschrieben hattest!   Aber wenn einem so ein "dämlicher" Spruch (wie der von dem freien Land....., der Spruch ist gemeint, nicht der User der ihn verwendet!) in einer Diskussion um Sachthemen als Argument pro oder kontra zum wiederholten Male vorgesetzt wird statt die Sachargumente zu be- oder ent-kräften, na ja....   Grüsse, daddle ... Afficher plus

Hi payer,   Du solltest Sachkritik mal von persönlichen Angriffen unterscheiden, eine  abweichende Meinung von deiner ist kein Angriff. Und der Autor Bounce hat genau meine Interpretation seiner Aussage bestätigt. Was sagst du jetzt?     Du zitierst immer wieder deinen eigenen Spruch, in den du sehr verliebt zu sein scheinst:    "Denn das ist ein freies Land, es ist nicht Dein Board und nicht Dein Thread und Du bist nur ein einfacher User"     Genauso ist es, und deswegen werde ich weiter meine Meinung hier äussern!  daddle ... Afficher plus

payer schrieb: Es ist nicht an Dir zu bestimmen was die zentralen Aussagen in einem Posting sind, auf die ich einzugehen habe. Fakt ist, dass er das geschrieben hat und dass ich etwas dazu angemerkt habe.   >>>> eben nicht ganz, sondern haarscharf daneben!    Ja, WLAN funktioniert mit dem 4.4.4 Recovery-Package, Factory-reset und allen wipes (ja, ich weiß, es gibt nicht so viele, dass ich Deiner Meinung nach das Wort "alle" verwenden darf - ich tue es aber trotzdem) einwandfrei. Deshalb habe ich ja auch keine Eile mit einem neuen, gefixten Recovery-Package und deshalb schreibe ich ja auch, dass sie sich gerne dafür noch Zeit lassen würfen.   >>> >Du liegst du schon wieder falsch; nur in Lollipop ist das Wlan -Prob weg, in Kit Kat auch nach dem 4.4.4 Recovery-Package und factory-reset und allen Wipes nicht! Nur wenn du nach dem Recovery-Paket Lollipop-Update machst, erst dann das factory-reset, ist es weg. Ein factory-reset nach dem Recovery-Paket in Kit Kat bringt nichts!   >>>>Und du kannst ja nicht für andere hier sprechen und sagen sie dürften sich ruhig Zeit mit der Fehlerbehebung lassen, es hätte keine Eile! Wie abgefahren ist das denn? 8-9 Monate sind schon sehr lange, oder? Hast du die anderen User überhaupt gefragt?   Ich gebe dir Recht, dass das schrottige Update #3 dazu verleitet einen gleich weiter zur Beta zu gehen. Das ging mir auch so. Allerdings konnte ich das einen Tag später mit dem Recovery gleich wieder korrigieren, ohne irgend wen um Erlaubnis fragen zu müssen.   >>>>Du hast doch ein paar Probleme, oder???   ... Afficher plus

payer schrieb:   Es hat Dich niemand gezwungen am Beta-Test für Lollipop teilzunehmen. Also brauchst Du Dich deshalb nicht heiß zu laufen.   Hi payer, wie meistens die zentrale Aussage von @bounce nicht erkannt oder überlesen, es geht ihm nicht primär um das Beta-Testen von Lollipop. Zitat:   ----------------------------   ... Wenn er sich entschließt, das zentrale Kommunikationsinterface (WLAN) abzuschießen, um im Gegenzug die Kundschaft als Lollipop-Betatester für das neue ALDI-Weihnachtstablet gebrauchen zu können, dann läuft da ganz grundsätzlich was schief. _________________   Gemeint ist, dass wir das Update #3 einspielen sollten, da es  die Wlan-Problematik verbessern würde, gleichzeitig den Bug, dass beim Anstecken der In-Ear-Phones die Google-Suche startete, beheben. Aber gleichzeitig ein Lockvogel zum gleichzeitigen Flashen des neuen Bios, dass Vorbedingung zum Beta-Testen des Lollipop war und für KitKat keine Vorteile brachte.   Denn tatsächlich hat sich die Wlan-Problematik mit dem KK-Update #3 nicht verbessert, sondern so verschärft, dass mehr bisher davon verschonte User diese auch bekamen, und bei anderen sich die Vielfältigkeit der möglichen Wlan-Probleme beim WakeUp aus dem Standby zeigten. Welche Varianten dabei möglich sind, hatte ich in einem früheren Post gelistet!   Also geht es nicht darum, ob man Lollipop Beta testet oder nicht, es geht darum, dass die versprochene Abhilfe des Wlan-Probs, das sich leider ins Gegenteil verkehrte, und die Option auf einen Lollipop-Beta-Test die User veranlasste KitKat Update #3 zu installieren.   Und psychologisch zu erwarten war natürlich, dass viele davon Gebrauch machen würden und dann auch die Beta-Option für Lolli nutzen würden!  Nicht zu erwarten war (für Eingeweihte jedoch wohl !), dass das Lollipop-Update solche vielfältigen neuen Probleme machte.   Und dabei zeigte sich als "running gag": die Wlan-Problematik löste sich in Lollipop nach einem Factory-reset  in Wohlgefallen auf, und wurde nicht mehr gesehen!    Allerdings erst nach Updaten, nein, nicht von dem regulärem Ota #3,  sondern erst nach vorherigem Flashen des etwas vom Ota#3 abweichendem KitKat-Recovery-Paketes (theoretisch Stand Update#3), dann Beta-Update Lollipop, dann einmal Einrichten und dann factory-reset! Schon sehr viel Arbeit für den Käufer eines Consumer-Productes, dass ja auch manche überforderte.   Danach ist das Wlan-StandBy-WakeUp Problem in Lollpop wie weggezaubert, bei mir jetzt seit über 10 Tagen! In KitKat blieben sie!   Und all das bezeichnet @bounce liebevoll als ein "wenig" unprofessionell, die User als Tester zu benutzen,auch für die Wlan-Probs, was einen gewissen Wahrheitsgehalt hat. Und er meint eben nicht nur für Lollipop, sondern auch übers "try and error" für die Wlan-Probleme; und sich selber allerdings 9 Monate Zeit gelassen zu haben für die Wlan-Fehlerbehebung. (Die bisher immer noch nicht veröffentlicht ist) Denn seit Verkaufsstart im November 2014 leidet das Tab unter KitKat an Wlan-Problemen, nach jedem OTA-Up bzw. mit mehr Nutzungszeit verstrichen sind immer mehr Tabs davon betroffen.   daddle   ... Afficher plus

@TheDoctor   Noch einen Punkt für die ToDo-Liste Lollipop: Schreibdaten-Träger wählen   Auf anderen Lollipop-Geräten kann man unter Einstellungen > Speicher den Schreibdatenträger auswählen, zwischen internem Speicher und  ext. SD-Karte; damit kann ich zumindest festlegen, dass auf der gewählten SD-Karte die Daten auch von System-Apps gespeichert werden, z.B. in DCIM die Fotos und Videos der Kamera-App. Das fehlt leider im S10346.   Aber bin erstmal gespannt auf das korrigierte Recovery-Paket (Stand OTA #3R2). Macht sicher Sinn mit dem  neuen Bios, den Realtek-Treibern und anderen Korrekturen, mit einem Recovery-Paket das Tab  komplett neu aufzusetzen, und alle Altlasten sicher auszumerzen.   Wobei mit dem Bios aus dem KK-Recovery-Paket der Droidboot-Modus (und Booten über Droidboot ins Recovery) wieder in KitKat funktioniert; auch ein Akku-Ladesymbol kommt beim Herunterfahren bei an Strom angeschlossenem Tab, und dann beim Wiederanstecken, oder mit dem Drücken der Powertaste. Lässt man das Kabel aber länger ab, oder fährt das Tab ohne Strom angeschlossen runter, zeigt sich das  Akku-Ladesymbol nicht mehr! Und das setzt sich in Lollipop genauso fort.   Schönes WE, daddle ... Afficher plus

Hi björnp, danke!   Welchen Proc hast du denn in deinem Gerät mit SDK 22, kein Intel (?) und genau welche Lolli-Versionm 5.1 oder 5.1.1? Oder noch kleiner?  daddle ... Afficher plus

Welch ein Kuddel-Muddel, du schriebst: McB schrieb: @mike64 wer sagt denn das 5.0 zum laufen gebracht werden soll¿ wenn du etwas mehr mitgelesen hättest: (das dachte ich)   >>>>  Zur Zeit soll 5.0 zum Laufen gebracht werden, lt. The Doctors Aussage, 5.1 beim nächsten Schritt, wenn sie das neue SDK hätten!   @TheDoctor hatte schon gesagt: das neue SDK wird 5.1 sein.   >>> für 5.1; aber solange wird an 5.0 für unser Update weitergearbeitet! Er hatte nicht gesagt sie stellen die Arbeit an 5.0 ein bis dahin, sondern sie würden, wenn...neues SDK verfügbar, dann eine 5.1- Version entwickeln/anbieten.     Und mich wundert es ein bisschen, dass 5.02 mit SDK 21 läuft, aber 5.1 ein komplett neues SDK bräuchte? Daher will ich es im Nexus 4 oder anderem  Lollipop 5.1 - Gerät testen. Daher ging es nicht um deine Formulierung!   Grüsse, daddle         ... Afficher plus

O McB schrieb: @daddle richtig (wie ich schrieb) das neue SDK.   Deswegen fragte ich nach der sdk-nummer eines Lollipop-5.1-Users; müsste ich doch mein Nexus 4 auf Lollipop 5.1.0 wieder updaten, um die SDK-Nummer auszulesen! daddle ... Afficher plus

mike64 schrieb:..... Ich habe es gelesen, das das 5.1 genannt wurde, was aber keinen Sinn ergibt, das man die 5.0 beta immer noch zum download anbietet, ...... Hi Mike,    da hast du leider was Falsches  gelesen oder in der Erinnerung; es ging hier immer um die 5.0 Beta Ota #4-Update - Option..  Und an McB:  Medion will 5.1 anbieten, falls sie das passende SDK von Intel bekommen. Im Augenblick sind sie nach ihren Aussagen noch an 5.0 - Fehelrsuche dran.   Intel hat aber sicher Interesse dran im mobilen Markt kräftig mit zu mischen, daher kommen sie an einer schnell verfügbaren passenden SDK-Version für Lollipop 5.1 nicht herum, falls es die nicht schon gibt. Die müsste dann erst von der Mutter Lenovo auch Medion zeitnah zur Verfügung gestellt werden.     Übrigens Lollipop 5.0  läuft auf/mit SDK 21, Lollipop 5.0.2 bei einem Medion Smartphone auch!   Wenn jemand ein Tablet/Smartphone mit Lollipop 5.1.x hat, kann er das mal in seinem Gerät in der build.prop nachprüfen, welche Version SDK da angegeben ist. Die build.prop kann man auch ohne Root z.B mit dem ES-Datei-Explorer auslesen. Pfad : /system/build.prop!     daddle ... Afficher plus