{ "entfernt": [], "geaendert": { "com.fleitec.certus": { "art": "apk", "beschreibung": "Ein Webbrowser, vollstaendig in Firn geschrieben.", "builds": [ { "aenderungen": "", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 53, "datei": "speicher/c3/c3422d2de54d865b8f2cf3c8e48b90bd2f0e15cd7a0e3b62b69c06c63dba3220.apk", "erstellt": "2026-09-23T14:58:26Z", "groesse": 11645964, "minSdk": 29, "sha256": "c3422d2de54d865b8f2cf3c8e48b90bd2f0e15cd7a0e3b62b69c06c63dba3220", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 60, "versionName": "0.55" }, { "aenderungen": "", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 52, "datei": "speicher/13/1313895a51b2fe7c8cfaf8927dd406af0776496d5ce9625e63c457352daad66c.apk", "erstellt": "2026-09-23T13:07:16Z", "groesse": 11633676, "minSdk": 29, "sha256": "1313895a51b2fe7c8cfaf8927dd406af0776496d5ce9625e63c457352daad66c", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 59, "versionName": "0.54" }, { "aenderungen": "", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 51, "datei": "speicher/33/33504f953a008ebe089e242b1edf0b5945ff23d6f938032a492b8116e9bdfb40.apk", "erstellt": "2026-09-21T20:02:58Z", "groesse": 11609100, "minSdk": 29, "sha256": "33504f953a008ebe089e242b1edf0b5945ff23d6f938032a492b8116e9bdfb40", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 58, "versionName": "0.53" }, { "aenderungen": "", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 50, "datei": "speicher/42/428af2e53338f68f7ed8d16675d31c5641120d3b8388de121c1e3c6df87b92f4.apk", "erstellt": "2026-09-21T11:27:11Z", "groesse": 11211788, "minSdk": 29, "sha256": "428af2e53338f68f7ed8d16675d31c5641120d3b8388de121c1e3c6df87b92f4", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 57, "versionName": "0.52" }, { "aenderungen": "", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 49, "datei": "speicher/d6/d6efd267061e9a563616b95546cfba23c0227575e8f7a3c9c7cbcd80467a2f0a.apk", "erstellt": "2026-09-21T07:48:53Z", "groesse": 10466316, "minSdk": 29, "sha256": "d6efd267061e9a563616b95546cfba23c0227575e8f7a3c9c7cbcd80467a2f0a", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 56, "versionName": "0.51" }, { "aenderungen": "", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 48, "datei": "speicher/c9/c94437455376bf2ae8c2b9b2377896d1acabb8cd0ded45c1ddd3141111961c51.apk", "erstellt": "2026-09-13T20:50:26Z", "groesse": 6104076, "minSdk": 29, "sha256": "c94437455376bf2ae8c2b9b2377896d1acabb8cd0ded45c1ddd3141111961c51", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 55, "versionName": "0.50" }, { "aenderungen": "", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 47, "datei": "speicher/f5/f5404fb75bd41a39f6687e4fcf5625be46127bdc892153a5dfe1dd8e109f335b.apk", "erstellt": "2026-09-10T16:41:47Z", "groesse": 6267916, "minSdk": 29, "sha256": "f5404fb75bd41a39f6687e4fcf5625be46127bdc892153a5dfe1dd8e109f335b", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 54, "versionName": "0.49" }, { "aenderungen": "", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 46, "datei": "speicher/6c/6ca838eca2cb45c21b38976c9f3addb9d0d63e33002d936e5309e114b6a92b59.apk", "erstellt": "2026-09-10T15:19:12Z", "groesse": 6263820, "minSdk": 29, "sha256": "6ca838eca2cb45c21b38976c9f3addb9d0d63e33002d936e5309e114b6a92b59", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 53, "versionName": "0.48" }, { "aenderungen": "", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 45, "datei": "speicher/57/57270c917f2faa666cbf11dacaa7e029cbb7075dff6f633228c0e5ffdc1e1808.apk", "erstellt": "2026-09-10T14:33:36Z", "groesse": 6263820, "minSdk": 29, "sha256": "57270c917f2faa666cbf11dacaa7e029cbb7075dff6f633228c0e5ffdc1e1808", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 52, "versionName": "0.47" }, { "aenderungen": "", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 44, "datei": "speicher/af/afa0f947d5689ea8e2191861a5f8360dbbc6eb3d0975fdf72176d79e7c5ee8ca.apk", "erstellt": "2026-09-10T14:31:01Z", "groesse": 6263820, "minSdk": 29, "sha256": "afa0f947d5689ea8e2191861a5f8360dbbc6eb3d0975fdf72176d79e7c5ee8ca", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 51, "versionName": "0.46" }, { "aenderungen": "", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 43, "datei": "speicher/6d/6d553cd6ecb0a675f9fae8488a8a9554ac9e3dcdc8462ef34bf83c9a50fec6fb.apk", "erstellt": "2026-09-10T13:42:52Z", "groesse": 6259724, "minSdk": 29, "sha256": "6d553cd6ecb0a675f9fae8488a8a9554ac9e3dcdc8462ef34bf83c9a50fec6fb", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 50, "versionName": "0.45" }, { "aenderungen": "VIER ECHTE FEHLER IN DER JAVASCRIPT-MASCHINE -- AUF DEM SERVER REPRODUZIERT UND BEHOBEN. Justin nannte drei Ausloeser: github.com, m.youtube.com und der Menuepunkt 'Bericht senden'. Alle drei laufen ueber den Interpreter, und dort lagen die Fehler. (1) toFixed schrieb ueber sein Ziffernfeld hinaus: das Feld fasst 40 Stellen, die Sprache erlaubt 100, und die Auffuellschleife hatte keine Schranke -- ab toFixed(40) wurde fremder Stapelspeicher beschrieben. (2) toExponential las ueber dasselbe Feld hinaus, weil dec_round die Stellenzahl ohne Grenze setzte -- ab toExponential(40) Abbruch. (3) toFixed rechnete mit Zehnerpotenzen und lieferte ab etwa 22 Stellen Unsinn, ausserdem rundete es 1.005 auf 1.01 statt auf 1.00; jetzt wird die exakte Dezimaldarstellung aus den f64-Bits aufgebaut, und das Ergebnis ist ueber alle 101 Stellen zeichengleich mit node. (4) Der Interpreter hatte keinen Boden: die Tiefenbremse zaehlte JS-Aufrufe (Grenze 380), aufgebraucht wird der Stapel aber von den nativen Rahmen darunter -- auf xoffi.ai standen 1041 Rahmen bei nur 83 Aufrufebenen, also SIGSEGV statt sauberer Ausnahme. Jetzt wird der echte Stapel gemessen statt gezaehlt, im Auswerter, im Aufruf und beim Hochziehen; der Zerteiler bekam dieselbe Bremse. Nachweis an 13 echten Seiten unter Xvfb mit Texterkennung: vorher stuerzte xoffi.ai ab und riss fuenf weitere Messungen mit, jetzt kehren ALLE 13 sauber zurueck und 11 zeigen nachweislich ihre Seite (github, github-Dateiansicht, xoffi, wikipedia in zwei Sprachen, hackernews, mdn, mozilla, duckduckgo, store.fleitec.com). YouTube und orf.at bleiben leer -- kein Absturz, aber auch kein Inhalt; das ist offen.", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 42, "datei": "speicher/43/43cc4a261f154c7b0366a01cdb46a973c421efe4300d0b9e1cfa37572f94c704.apk", "erstellt": "2026-09-10T12:32:35Z", "groesse": 6255628, "minSdk": 29, "sha256": "43cc4a261f154c7b0366a01cdb46a973c421efe4300d0b9e1cfa37572f94c704", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 49, "versionName": "0.44" }, { "aenderungen": "HERKUNFT: JEDER BERICHT SAGT JETZT, WIE ALT ER IST. Am 10.09. kamen zwei Berichte mit 'version 42' an, obwohl Justin laengst eine neuere Fassung benutzte -- sie waren KONSERVEN: ein alter, nie zugestellter Bericht, der erst beim Druck auf 'Bericht senden' hochging. Ohne Zeitangabe war das von einem frischen Absturz nicht zu unterscheiden, und es wurden Schluesse darauf gebaut. Ab jetzt traegt jeder Bericht vier Angaben: version und absturz-zeit (wann der Absturz passierte, unter welcher Fassung) sowie sende-version und sende-zeit (welche Fassung beim Senden lief, wann er rausging). Weichen sie ab, ist es Archivmaterial. Ausserdem behoben: nach erfolgreichem Senden wurde derselbe Bericht ein zweites Mal gelesen und geschickt (die beiden Eingaenge um 10:34:37 und 10:34:40 sind bytegleich) -- das Nachfassen ist weg, denn es gibt immer nur EINEN Bericht (die Datei wird mit O_TRUNC ueberschrieben). Und der Bau bricht jetzt ab, wenn die Fassung im Quelltext nicht zum versionCode im Manifest passt; genau dieser Fehler hat 0.34 'version 37' melden lassen.", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 41, "datei": "speicher/81/813a5aa9f82e94185c3da5a6a8b0be28b7fd13a404246ef9ae9a343eb825a6a1.apk", "erstellt": "2026-09-10T10:52:31Z", "groesse": 6247436, "minSdk": 29, "sha256": "813a5aa9f82e94185c3da5a6a8b0be28b7fd13a404246ef9ae9a343eb825a6a1", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 48, "versionName": "0.43" }, { "aenderungen": "DER MELDER HAT DIE APP SELBST GETOETET -- BELEGT DURCH ANDROIDS EIGENEN TOMBSTONE. Justins Telefon lieferte am 10.09. einen Tombstone von 0.38: signal 11, code 0 (SI_USER), LEERE Fehleradresse, pc auf einem 'ret' in interp__to_numeric_string, ein einziger Rahmen. SI_USER heisst: das Signal wurde GESENDET, nicht von der Speicherverwaltung ausgeloest -- und ein 'ret' kann gar nicht auf Adresse 0 zugreifen. Gesendet hat es unser eigenes weiterreichen() mit kill(getpid(), SIGSEGV). Zwei Fehler: kill() ist prozessweit und trifft irgendeinen Faden (im Tombstone den Faser-Faden, der gerade JavaScript ausfuehrte und unbeteiligt war), und ein gesendetes Signal traegt weder Fehleradresse noch Kontext, sodass auch ARTs Behandler nichts mehr damit anfangen kann. Jetzt wird gar nichts mehr gesendet: der gesicherte Behandler wird zurueckgestellt und der Behandler kehrt ZURUECK -- der Kern fuehrt den ausloesenden Befehl erneut aus, und ART bekommt sein Signal mit originalem siginfo und ucontext. Nachgewiesen im Pruefstand: ein ART-artiger Behandler faengt den Nullzugriff ab und die App LAEUFT WEITER, wo 0.38 mit 'uncaught target signal 11' starb. Neu ausserdem: der Melder laesst sich ohne Neubau abschalten (files/melder.txt = 0), damit sich trennen laesst, ob Certus abstuerzt oder der Melder Certus umbringt. Die Messtafel zeigt 'Melder 0/1'.", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 40, "datei": "speicher/e0/e0e2fdfd0b6f5e8f72ce51c67d387001ccb0b218c362e16f3f42e16d7b05e85d.apk", "erstellt": "2026-09-10T10:42:01Z", "groesse": 6243340, "minSdk": 29, "sha256": "e0e2fdfd0b6f5e8f72ce51c67d387001ccb0b218c362e16f3f42e16d7b05e85d", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 47, "versionName": "0.42" }, { "aenderungen": "ENTSCHEIDUNGSFASSUNG -- gleicher Stand wie 0.41, aber MIT ABGESCHALTETER aarch64-Registerzuteilung (FIRN_NO_REGALLOC_A64=1). Jeder Wert liegt in seinem Rahmenfach, jeder Operand wird um jeden Befehl herum geladen und zurueckgeschrieben -- der Codeweg, der vor dem Zuteiler monatelang lief. Beleg, dass der Schalter wirkt: die arm64-.so waechst von 8310032 auf 10538256 Oktett. Nur zur Beantwortung EINER Frage gedacht: stuerzt Certus auch OHNE den Zuteiler ab, ist der Firn-Uebersetzer entlastet; hoert das Stuerzen auf, ist die Registerzuteilung die Ursache. Sie ist rund 1,7x langsamer bei registerlastigem Code -- nicht fuer den taeglichen Gebrauch.", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 39, "datei": "speicher/09/09be3770fc5e89ba36d23962cd9ae289446ff81011c96e9ca418033aab9bef65.apk", "erstellt": "2026-09-10T09:31:26Z", "groesse": 7230476, "minSdk": 29, "sha256": "09be3770fc5e89ba36d23962cd9ae289446ff81011c96e9ca418033aab9bef65", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 46, "versionName": "0.41-entscheider" }, { "aenderungen": "DER MELDER STAND SICH SELBST IM WEG. Bis 0.40 stand SA_ONSTACK in den Signal-Flags, aber sigaltstack() wurde nie gerufen -- der Kern ignoriert das Flag dann und startet den Behandler auf dem Stapel des abgestuerzten Fadens. Ist genau der kaputt (Stapelueberlauf, zerstoerter Rahmen), stirbt der Melder beim ersten eigenen Rahmen und schreibt KEINE Zeile: die echte Spur geht verloren, und was ankommt, kann verfaelscht sein. Im Pruefstand nachgewiesen (Sturz in libcertus mit zerstoertem sp): 0.40 schreibt keinen Bericht, 0.41 schreibt ihn vollstaendig. Jetzt: eigener Signalstapel (256 KiB), Reentranz-Sperre VOR jeder Untersuchung, Speicherkarte beim Start statt im Absturz, und die Zugehoerigkeitspruefung folgt der Rahmenkette statt blind 4096 Stapelwoerter abzusuchen -- das hat vorher alte, tote Ruecksprungadressen als Beweis genommen und fremde ART-Signale faelschlich als unsere gemeldet. Neue Berichtszeile: altstapel 1.", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 38, "datei": "speicher/70/703933b12f7766264ec35375d6707b00c421c57f97c6156974fbe92da949d740.apk", "erstellt": "2026-09-10T09:26:29Z", "groesse": 6243340, "minSdk": 29, "sha256": "703933b12f7766264ec35375d6707b00c421c57f97c6156974fbe92da949d740", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 45, "versionName": "0.41" }, { "aenderungen": "DER ABSTURZMELDER WAR SELBST DIE URSACHE. Die Speicherkarte aus 0.38 hat gezeigt: beide Absturzgruppen liegen in boot.oat, dem vorkompilierten Java-Code des Rahmenwerks, auf wechselnden Fadenstapeln und ohne einen einzigen Certus-Rahmen im Rueckweg. ART loest SIGSEGV im Normalbetrieb aus -- Null-Pruefungen in kompiliertem Java-Code laufen ueber Speicherschutz und werden von ARTs eigenem Behandler in eine NullPointerException verwandelt. Der Melder hat diesen Behandler ueberschrieben ohne ihn zu sichern und bei jedem Signal den Prozess getoetet: aus jeder harmlosen NullPointerException des Rahmenwerks wurde ein Absturz. Jetzt wird der vorhandene Behandler gesichert, ein Signal ohne jeden Certus-Rahmen im Stapel unveraendert an ihn weitergereicht, und nur ein Absturz, an dem Certus wirklich beteiligt ist, gemeldet.", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 37, "datei": "speicher/36/36a25517152f641887cc6e08c717129422a99666c30e485a8c9d832496b32073.apk", "erstellt": "2026-09-10T00:07:45Z", "groesse": 6243340, "minSdk": 29, "sha256": "36a25517152f641887cc6e08c717129422a99666c30e485a8c9d832496b32073", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 44, "versionName": "0.40" }, { "aenderungen": "ENTSCHEIDUNGSFASSUNG, nicht fuer den taeglichen Gebrauch. Gleicher Quelltext wie 0.38, aber arm64 komplett OHNE die Registerzuteilung uebersetzt (neuer Uebersetzerschalter FIRN_NO_REGALLOC_A64): jeder Wert liegt in seinem Stapelfach, wie vor Runde REGALLOC-A64. Sie ist deutlich langsamer und braucht mehr Speicher. Zweck: beantwortet die Frage, ob der Absturz vom Uebersetzer kommt. Stuerzt sie NICHT ab, ist die Registerzuteilung schuld; stuerzt sie genauso ab, ist sie entlastet.", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 36, "datei": "speicher/c2/c2b77a1fc4406f660b6d05c4117a70813bc9d66211ad45c54f8ae62ddcb7ddd2.apk", "erstellt": "2026-09-09T23:49:32Z", "groesse": 7222284, "minSdk": 29, "sha256": "c2b77a1fc4406f660b6d05c4117a70813bc9d66211ad45c54f8ae62ddcb7ddd2", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 43, "versionName": "0.39-entscheider" }, { "aenderungen": "Der Melder schickt jetzt die SPEICHERKARTE mit. Zu pc, lr, sp, fp und jedem Rueckweg-Rahmen steht die Zeile aus /proc/self/maps im Bericht: Name der Bibliothek, Bereich, Rechte und Versatz darin. Dazu eine Liste aller ausfuehrbaren Abbildungen. Damit ist eine 'fremde' Adresse keine Sackgasse mehr, sondern benennbar (libart, bionic, Treiber oder anonymer Block).", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 35, "datei": "speicher/88/883a50db982249218a1eef444ede121dd50ff1b5e2acecb7ea645304b995d22c.apk", "erstellt": "2026-09-09T23:49:32Z", "groesse": 6239244, "minSdk": 29, "sha256": "883a50db982249218a1eef444ede121dd50ff1b5e2acecb7ea645304b995d22c", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 42, "versionName": "0.38" }, { "aenderungen": "Der Absturz beim Klick in die Adresszeile ist behoben. Ursache (aus dem ersten aufloesbaren Bericht vom Geraet, 231456): ANativeActivity.clazz wurde als LOKALE JNI-Referenz gemerkt und je Bild weiterbenutzt. Lokale Referenzen sterben mit der Rueckkehr aus dem nativen Aufruf; libart fiel beim Abfragen der Tastaturhoehe darueber -- deshalb pc ausserhalb von libcertus und Fehleradresse 0. Jetzt eine globale Referenz, wie bei allen anderen Objekten. Zusaetzlich gehaertet: alle elf JNI-Verteiler pruefen den Platz in der Tafel (leerer Platz hiess vorher Sprung auf Adresse 0), und die Tastaturhoehe faellt sauber auf 0 zurueck statt abzustuerzen. Melder verbessert: 'moeglich' jetzt geordnet und ohne Wiederholung, neue Zeile 'folge' in Stapelreihenfolge, und 'stapel' funktioniert auch bei einem Absturz auf einem Nebenfaden.", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 34, "datei": "speicher/d6/d6fd60918e4ba147eb63f3979f97e5daf3e3089e65d2b2ba4db1fcf152e7196c.apk", "erstellt": "2026-09-09T23:27:15Z", "groesse": 6235148, "minSdk": 29, "sha256": "d6fd60918e4ba147eb63f3979f97e5daf3e3089e65d2b2ba4db1fcf152e7196c", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 41, "versionName": "0.37" }, { "aenderungen": "Der Absturzmelder sendet jetzt wirklich -- bewiesen (bericht-st=200, Bericht im Eingang). Vier stille Fehler behoben: der Sendeversuch kehrte um, solange store.fleitec.com noch nicht aufgeloest war, und wurde dann nie wiederholt; 'Bericht senden' schickte nur die Messspur statt des Absturzberichts; geloescht wurde beim Absenden statt beim Ankommen; die Fassung im Bericht war fest 37. Neu: sichtbare Rueckmeldung oben ('Bericht angekommen' / 'Senden fehlgeschlagen' / 'nichts zu senden'). Ausserdem zeigte die Messtafel 'p99 0.0 ms', wo sie 'zu wenige Werte' meinte -- jetzt mit p99-n.", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 33, "datei": "speicher/71/713349e3330f172dd2fdaaafc4ba20d6b8e74564bd8e377f1a40a0dc2b1c7a26.apk", "erstellt": "2026-09-09T22:21:38Z", "groesse": 6231052, "minSdk": 29, "sha256": "713349e3330f172dd2fdaaafc4ba20d6b8e74564bd8e377f1a40a0dc2b1c7a26", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 40, "versionName": "0.36" }, { "aenderungen": "Der Absturzmelder sendet jetzt wirklich. In 0.33/0.34 kehrte jeder Sendeversuch still um, weil der Name store.fleitec.com beim ersten Versuch noch nicht aufgeloest war -- der Bericht wurde damit fuer immer verworfen. Jetzt wird der Auftrag gemerkt und nachgeholt, geloescht wird erst nach der Antwort 200, und der Menuepunkt 'Bericht senden' schickt den Absturzbericht (nicht nur die Messspur) und meldet sichtbar, was passiert ist. Fassung im Bericht war faelschlich fest 37.", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 32, "datei": "speicher/e0/e03fe4c41202826ecbea1fcd7436dcfcac5159e7197f54625555a378f12810d6.apk", "erstellt": "2026-09-09T22:16:59Z", "groesse": 6231052, "minSdk": 29, "sha256": "e03fe4c41202826ecbea1fcd7436dcfcac5159e7197f54625555a378f12810d6", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 39, "versionName": "0.35" }, { "aenderungen": "", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 31, "datei": "speicher/a4/a421a2c9da754d023038188d3f326c45c0779864b5d31d378b135933c55b4694.apk", "erstellt": "2026-09-09T21:29:25Z", "groesse": 6222860, "minSdk": 29, "sha256": "a421a2c9da754d023038188d3f326c45c0779864b5d31d378b135933c55b4694", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 38, "versionName": "0.34" }, { "aenderungen": "", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 30, "datei": "speicher/d1/d1019a3e062de00799dd03d350f1ac439fc4b13a128a2b47d032877f74090cbb.apk", "erstellt": "2026-09-09T17:58:47Z", "groesse": 6222860, "minSdk": 29, "sha256": "d1019a3e062de00799dd03d350f1ac439fc4b13a128a2b47d032877f74090cbb", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 37, "versionName": "0.33" }, { "aenderungen": "", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 29, "datei": "speicher/2b/2b12d84edc7c18e44d8983b17ad1c4019a60ffc3b77cfe919b589cb727d98da7.apk", "erstellt": "2026-09-09T16:29:50Z", "groesse": 6218764, "minSdk": 29, "sha256": "2b12d84edc7c18e44d8983b17ad1c4019a60ffc3b77cfe919b589cb727d98da7", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 36, "versionName": "0.32" }, { "aenderungen": "RUNDE ARM64-TEMPO: der Registerzuteiler fuer aarch64. Der Firn-Uebersetzer hatte fuer arm64 GAR KEINE Registerzuteilung -- jeder Wert ging ueber ein Rahmenfach. Der Zweig regalloc-a64 ist eingezogen, und dabei kamen ZWEI echte Fehler heraus, die sonst mit ausgeliefert worden waeren: (1) zwei Zweige hatten unabhaengig denselben Zustandsplatz 2152 vergeben (die Chunk-Tafel des Sammlers und die Blockgroessentafel des Zuteilers), die eine schrieb ueber den Zeiger der anderen -- 62 Faelle der Testtafel fielen. (2) Die Systemaufruf-Argumente wurden der Reihe nach in x0..x5 gelegt; mit Registerzuteilung KANN ein Wert dort schon liegen, und aus heap_free(zeiger, laenge) wurde munmap(zeiger, zeiger) -- der frisch belegte Puffer verschwand, naechster Zugriff Segmentierungsfehler. Beides behoben und belegt. Messung am echten Stilblatt-Pruefstand (29 Blaetter von github.com, 8941 Regeln, Ausgabe Zeichen fuer Zeichen wie vorher): aarch64 8,46 s -> 2,99 s, also 2,8x. Am Android-Pruefstand unter qemu: Leiste 66,1 ms -> 51,5 ms (1,28x), Zeichen malen 55,9 ms -> 48,3 ms (1,16x), laengster Block 5281 us -> 4666 us. Die Programmbibliothek ist 20 % kleiner (9028216 -> 7193296 Oktett), das Paket 6325260 -> 6206476 Oktett. Testtafel 311 von 311 gleich auf beiden Maschinen (dev-fast und --no-opt), cargo test 277, tools/checked 150, x86-Assembler 316 Dateien unveraendert -- der Eingriff ist reines aarch64.", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 28, "datei": "speicher/9c/9ce86a72d06c854efce70805cbda98ac33ee1192e241918edecba0828133b3df.apk", "erstellt": "2026-09-09T15:42:08Z", "groesse": 6206476, "minSdk": 29, "sha256": "9ce86a72d06c854efce70805cbda98ac33ee1192e241918edecba0828133b3df", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 35, "versionName": "0.31" }, { "aenderungen": "RUNDE SCHICHT: Sichtbarkeitsrecht und Beschnitt. Ein Kasten klemmte seinen EIGENEN Text nicht -- er bekam den Rahmen, mit dem er hereinkam, nur die Kinder den engeren. Githubs .sr-only war korrekt 1x1 Bildpunkt und liess seinen Text trotzdem quer ueber die Seite laufen (Chromium 30 Zeilen, Certus 66 -> jetzt 30). Das war die Textspalte am linken Rand und zugleich das riesige 'Navigation Menu'. Dazu: [hidden] { display: none } fehlte in beiden Stilblaettern. @layer mit getrennter Namens- und Reihenfolgetafel (die Statement-Form '@layer a,b,c;' wurde bisher ganz weggeworfen, und derselbe Name bekam jedes Mal eine neue Nummer). hatte Breite 0 (die Breite haengt an der Schrift), Formularfelder sitzen auf der Grundlinie statt darauf zu stehen, white-space:nowrap macht die Mindestbreite zur ganzen Zeile. Pruefstuecke 65 -> 95/95 (572/572 Kaesten <=1 px), Grundlinie 1087/1087 bei 0,00 %.", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 27, "datei": "speicher/05/053a8f2c8133b53650463c867a7b816210bf1f72f06a0e35bd3e0ebd30d52de2.apk", "erstellt": "2026-09-08T22:03:30Z", "groesse": 6284300, "minSdk": 29, "sha256": "053a8f2c8133b53650463c867a7b816210bf1f72f06a0e35bd3e0ebd30d52de2", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 32, "versionName": "0.28" }, { "aenderungen": "Die Faser (Skripte in Scheiben) ist erstmals auf echtem AArch64 ausgefuehrt und geprueft worden -- gleiche Zahlen wie auf x86. Tippen: die Eingabe hat jetzt Vorrang vor der Skriptscheibe (Mittelwert 28,7 -> 18,5 ms). Die Faser laesst sich ohne neuen Bau abschalten (files/faser.txt = 0).", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 26, "datei": "speicher/bb/bbd8d7c1c1ca6d53b8e35c61fac87b9d225e10f54761f24d0795c59e9eaaf54d.apk", "erstellt": "2026-09-08T13:20:22Z", "groesse": 6243340, "minSdk": 29, "sha256": "bbd8d7c1c1ca6d53b8e35c61fac87b9d225e10f54761f24d0795c59e9eaaf54d", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 30, "versionName": "0.26" }, { "aenderungen": "Kern-3: die Faser — die JavaScript-Maschine laeuft auf einem eigenen Stapel im selben Faden und haelt nach 8 ms an, der Hauptfaden malt dazwischen (m.youtube.com: Block 1930 ms -> 254 ms im Emulator, keine Abstuerze). DNS ohne Warten auf dem Hauptfaden (async ueber die Schleife, 5-s-Frist). Skript-Budget 10 s/30 s (ANR-Schutz ist jetzt die Faser). Tafel: Faser/Faser-n. Pruefstand tools/kern/probe_faser.html.", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 25, "datei": "speicher/ca/ca13323ccc449e5e0488e2505cbc86f862d99eccda1d5116b4f56adbf0854d52.apk", "erstellt": "2026-09-07T17:24:31Z", "groesse": 6239244, "minSdk": 29, "plattformen": [ "android-arm64", "android-x86_64" ], "sha256": "ca13323ccc449e5e0488e2505cbc86f862d99eccda1d5116b4f56adbf0854d52", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 29, "versionName": "0.25" }, { "aenderungen": "Kern-2: JavaScript-Kern erweitert — fetch/XMLHttpRequest ueber den Netzfaden (Bote), eval und Function, Vorspann mit ~180 nachgereichten Browser-Schnittstellen (performance.timing, screen, atob/btoa, TextEncoder, Intl, customElements, DOMParser, typisierte Felder ...), top-level var als window-Eigenschaft, Regex-Matcher ohne Rekursion je Zeichen, Sammler mit Chunk-Tabelle (JavaScript 3,5x schneller), Aufruftiefe an den Stapel angepasst (kein Absturz mehr), Skriptkette in Scheiben, aeussere Skripte auf dem Netzfaden zerteilt. m.youtube.com laeuft ohne Absturz durch (base.js 1,8 s), zeigt aber noch nichts.", "architekturen": [ "arm64-v8a", "x86_64" ], "berechtigungen": [ "android.permission.ACCESS_NETWORK_STATE", "android.permission.INTERNET" ], "build_id": 24, "datei": "speicher/d6/d697241794605d7b93861c7c09bfb5d6d5c2d709fa2e3e3d894f6c4a238dbf3a.apk", "erstellt": "2026-09-07T17:24:31Z", "groesse": 6210572, "minSdk": 29, "plattformen": [ "android-arm64", "android-x86_64" ], "sha256": "d697241794605d7b93861c7c09bfb5d6d5c2d709fa2e3e3d894f6c4a238dbf3a", "signaturverfahren": [ "v3", "v2" ], "targetSdk": 34, "versionCode": 28, "versionName": "0.24" }, { "aenderungen": "RUNDE KERN: JavaScript laeuft jetzt auch auf Android (lib/kern/skript.fi -- eine Skriptmaschine fuer Schreibtisch und Telefon): innere und aeussere Skripte in Dokumentreihenfolge, DOM-Aenderungen (textContent, appendChild, innerHTML), setTimeout/setInterval, click-Ereignisse mit preventDefault, DOMContentLoaded/load; Budget 1,2 s je Skript, 2,5 s je Dokument;