Android und das Jahr-2038-Problem – Warum Google auf Zeit spielt

Android ist kein klassisches Unix- oder Linux-System. Trotzdem basiert es auf denselben Fundamenten: dem Linux-Kernel und der C-Bibliothek Bionic, die zentrale POSIX-Funktionen bereitstellt – darunter auch den Umgang mit Systemzeit. Wie bei Linux wird die Zeit als fortlaufende Anzahl von Sekunden seit dem 1. Januar 1970 gespeichert.

Diese Konstruktion ist einfach und effizient, aber begrenzt: Auf 32-Bit-Systemen wird die Zeit in einem vorzeichenbehafteten 32-Bit-Zähler gespeichert, der am 19. Januar 2038 um 03:14:07 UTC überläuft. Dieser sogenannte Y2K38-Bug – ein klassischer Zählerüberlauf – sorgt dafür, dass Zeitwerte ins Jahr 1901 zurückspringen oder negativ werden.

Damit teilt Android eine Altlast mit seinen Unix-Vorfahren: das Jahr-2038-Problem.

Doch statt diese Schwäche rückwirkend zu beheben, hat sich Google für einen anderen Weg entschieden. Anstatt Fehler im Code zu korrigieren, setzt das Unternehmen auf geplante bzw. vorsätzliche Obsoleszenz – die alte Architektur wird stillgelegt, neue Geräte übernehmen.
Oder bildlich gesprochen: 32-Bit wird zu Grabe getragen.

Wer noch auf solche Systeme setzt – sei es in Embedded-Hardware, IoT-Controllern oder älteren Industrie-Boards – sollte besser jetzt reagieren. Denn die Zeit läuft, im wahrsten Sinne des Wortes.

Bereits 2011 dokumentiert der Android-Issue-Tracker, dass 32-Bit-Android beim Setzen der Systemzeit auf 19.01.2038, 03:14:08 UTC abstürzt, in eine Boot-Schleife fällt – und das Phone faktisch unbrauchbar („bricked“) wird. Ein häufig zitiertes Beispiel: ZTE Blade (Android 2.2).
Quelle: https://issuetracker.google.com/issues/36928638

Das Ticket zeigt, dass der Y2k38 Bug schon früh praktisch beobachtet wurde – zugleich aber zu Fehlannahmen führte:

• Bald nur noch 64-Bit-Geräte. Man erwartete ein rasches Verschwinden von 32-Bit-Android.
• Bis 2038 treten keine Probleme auf. Man ging davon aus, dass reale Störungen erst am Stichtag auftreten würden.

Wie wir in diesem Beitrag zeigen werden prägten diese Prämissen die weitere Behandlung – und führen bis heute und in Zukunft zu Problemen, insbesondere bei langlebigen 32-Bit-Geräten und Embedded-Systemen.

Wie sehr sich die Android-Verantwortlichen 2011 getäuscht hatten, zeigte sich bereits fünf Jahre später: Der Y2K38-Bug manifestierte sich als offizielle Sicherheitslücke – katalogisiert unter CVE-2016-3831.
Diesmal musste man handeln. Doch anstatt das Problem grundsätzlich zu lösen, wurde nur ein Symptom entschärft.

Im Jahr 2016 wurde bekannt, dass ein manipuliertes NITZ-Zeitsignal (Network Identity and Time Zone) in der Telephony-Komponente zu einem Zählerüberlauf führen kann. Ein Angreifer konnte über ein gefälschtes Mobilfunksignal ein Datum jenseits des Jahres 2038 einspeisen – und damit den 32-Bit-Zeitwert aus dem Tritt bringen.
Die Folge: Systemabsturz, Reboot-Schleife oder Kommunikationsfehler.

Der Fall markierte einen Wendepunkt. Was man 2011 noch als theoretisches Risiko abgetan hatte, wurde 2016 zu einem realen CERT-Sicherheitsproblem. Google reagierte – aber nicht, indem die Zeitarchitektur modernisiert wurde. Stattdessen zog man eine willkürliche Grenze bei 2037 und verschob das eigentliche Problem in die Zukunft.

Im Quellcode von CdmaServiceStateTracker.java sieht der Patch dann so aus:

Der Fix umgeht das Problem (indem er 2038+ blockiert), löst es aber nicht grundlegend. Die zugrundeliegende 32-Bit-Zeitdarstellung bleibt unverändert. Wieder entscheidet sich Google für den «einfacheren» Weg.

Android basiert im Innersten auf dem Linux-Kernel – dem gleichen Fundament, das auch in Servern, Routern und industriellen Embedded-Systemen eingesetzt wird. Mit dieser Basis das Betriebssytem jedoch auch eine zentrale Schwäche: den Y2K38-Bug, einen Zählerüberlauf in der internen Zeitdarstellung (time_t), der am 19. Januar 2038 um 03:14:07 UTC auftreten wird.

Im Jahr 2020 – dem Jahr, in dem auch die Beoz Association gegründet wurde – wurde dieses Problem im Linux-Kernel technisch gelöst. Seitdem gilt der Kernel als „Y2038-ready“ – das Risiko eines Zeitüberlaufs ist dort grundsätzlich behoben. Für Android allerdings dauerte es, bis diese Verbesserung vollständig übernommen wurde.

Bereits mit Linux 5.6 (März 2020) führte die Kernel-Community umfassende Unterstützung für 64-Bit-Zeitwerte ein, auch auf 32-Bit-Systemen. Damit können Zeitstempel weit über das Jahr 2038 hinaus korrekt gespeichert und berechnet werden. Die erste Langzeitversion (LTS) mit aktivem Y2038-Support folgte im Dezember 2020 mit Linux 5.10.

Android verwendet eigene Kernelzweige, die sogenannten Android Common Kernels (ACK), die regelmässig aus Linux-LTS-Versionen abgeleitet werden. Die Übernahme der Y2038-Änderungen erfolgte verzögert und schrittweise.

Kernel-Version	Linux-Release	Android-Branch	Einsatz in Android-Versionen	EOL (Upstream)	EOL (Android)	Y2038-Unterstützung
4.4	Jan 2016	android-4.4	Android 7–8 (2016–2018)	Feb 2022	2022	❌ Kein Y2038-Fix
4.14	Nov 2017	android-4.14	Android 9–10 (2018–2021)	Jan 2024	Anfang 2024	❌ Kein Y2038-Fix
4.19	Okt 2018	android-4.19	Android 10–11 (2019–2021)	Dez 2024	Ende 2024	⚠️ Teilweise Vorbereitung
5.4	Nov 2019	android-5.4	Android 11–12 (2020–2022)	Dez 2025	Jan 2026	⚙️ Enthält Vorarbeiten
5.10+	Dez 2020	android12-5.10 / android13+	Android 12–15 (2021–2025)	aktiv	aktiv	✅ Y2038-ready

Quelle: Kernel.org / LTS-Maintainer (Greg Kroah-Hartman) & Android Common Kernel (ACK)

Erst mit Android 12 (2021) kam ein Kernel zum Einsatz, der die neue 64-Bit-Zeitarchitektur vollständig enthielt. Ältere Android-Versionen – insbesondere jene auf Basis von Kernel 4.14 – bleiben dagegen auf 32-Bit-Zeitbasis und damit auf das Jahr-2038-Problem anfällig.

Mit dem Jahr 2025 erreicht auch der in vielen Geräten verbreitete Android-5.4-Kernel sein Lebensende: Ende 2025 bzw. Anfang 2026 wird er offiziell auf End-of-Life (EOL) gesetzt. Damit endet die Wartung der letzten weit verbreiteten 4.x-/5.x-Kernelgeneration, die noch eine Übergangsrolle zwischen alter und neuer Zeitarchitektur spielte.

Das ist zugleich eine gute Nachricht, denn bis zum kritischen 19. Januar 2038 bleiben noch fast 13 Jahre. Eigentlich genug Zeit, um verbliebene Systeme auf moderne Kernel mit 64-Bit-Zeitarchitektur umzustellen – vorausgesetzt, sie werden tatsächlich noch gepflegt oder aktualisiert.

Die Praxis zählt, nicht die Theorie: Laut der aktuellen StatCounter-Verteilung (Sept–Okt 2025) steckt ein substanzieller Anteil der aktiven Geräte noch auf älteren Android-Versionen:

• Android 11 und älter: zusammen ~19 % (11.0 ≈ 9.25 %, 10.0 ≈ 4.8 %, 9.0 ≈ 2.78 %, Lollipop 5.0 ≈ 2.52 %).
• „Other“ ≈ 6.61 % enthält in der Regel Forks/very old Builds (oft ohne verlässliche Patches).

Moderne Releases dominieren zwar (Android 15 ≈ 30.55 %, 14 ≈ 15.41 %, 13 ≈ 15.06 %, 12 ≈ 11.05 %), aber die Altlasten sind gross genug, um sicherheits- und compliance-relevant zu bleiben.

Trotz der Dominanz aktueller Releases bleibt ein spürbarer Bestand älterer Geräte im Einsatz, die auf 32-Bit-Zeitpfaden oder alten Kernel-Linien laufen. Genau dort liegt das Y2K38-Risiko: Geräte mit 4.x-Kernels und 32-Bit-Zeitdarstellung geraten beim Übergang über den 19. Januar 2038 in fehlerhafte oder negative Zeitwerte. Das betrifft nicht nur theoretische Stichtage, sondern alle Funktionen, die weit in die Zukunft datieren (z. B. Zertifikate). Solange diese Legacy-Systeme nicht auf Kernel 5.10+ und 64-Bit-Zeit umgestellt werden, bleibt Y2K38 ein reales Problem – selbst wenn die Geräte heute eigentlich schon am Lebensende sind.

Der Linux-Kernel ist das Fundament – aber nicht das ganze Android-System. Was Apps und Systemdienste tatsächlich sehen, läuft über die C-Library als Schnittstelle zum Kernel. Und hier geht Google seit jeher einen eigenen Weg: statt glibc setzt man auf Bionic.

Bionic ist schlank, schnell und android-spezifisch – trägt auf 32-Bit aber die Altlast weiter: time_t ist dort 32-bittig. Genau dieser 32-Bit-Zeitwert führt am 19. Januar 2038 zum Y2K38-Zählerüberlauf. Der Kernel hat die Grundlage zwar ab Linux 5.6 (und als LTS ab 5.10) mit time64-Syscalls und 64-Bit-Zeitstrukturen geschaffen, doch im 32-Bit-Userspace kommt diese Lösung nicht an, solange Bionic die neuen Schnittstellen nicht bereitstellt.

“…Linux 5.x kernels do offer extra interfaces … but we do not plan on adding support for these to the C library. … All apps are already required to offer 64-bit variants, and we expect 64-bit-only devices within the next few years.»

– https://android.googlesource.com/platform/bionic/+/master/docs/32-bit-abi.md

Google formuliert das offen: Für 32-Bit-Android ist kein 64-Bit-Zeitsupport in Bionic vorgesehen; alle Apps sollen 64-Bit-Varianten anbieten, und man erwartet 64-Bit-only-Geräte. Übersetzt heisst das: Es gibt keinen realistischen technischen Migrationspfad, der 32-Bit-Android nachträglich Y2K38-fest macht. Punktuelle Workarounds (etwa die Telephony-Grenze MAX_NITZ_YEAR = 2037) verhindern Symptome, aber nicht die Ursache.

Konsequenz: Ab 2038 wird Android auf keinem 32-Bit-System mehr lauffähig sein, unabhängig davon, welcher Kernel darunter läuft oder welche Workarounds eingesetzt werden. Ohne 64-Bit-Zeit im Userspace (Bionic/NDK/Apps) lassen sich zentrale Funktionen (Zertifikate, Scheduler, Logs, Dateizeiten, Protokolle) nicht zuverlässig über 2038 hinaus abbilden. Wer 32-Bit-Android noch im Einsatz hat, braucht jetzt eine Migrationsstrategie!

Wieder tut Google im Bestand wenig und setzt auf den Happy Path: In wenigen Jahren seien alle Geräte 64-Bit, der Rest regle der Markt. Diese Annahme wird sich wieder als Irrtum erwiesen.

Bisher ging es vor allem um Android auf Smartphones – Geräte mit kurzer Lebensdauer und klaren Updatezyklen. Doch Android läuft längst auch dort, wo Geräte zehn Jahre und länger im Einsatz bleiben: in Fahrzeugen, Industrieanlagen, Kassensystemen, Infotainmentsystemen, Fernsehern und IoT-Geräten.

In diesen Bereichen sollte das Betriebssystem von Google ursprünglich eine Alternative zu klassischen Embedded-Linux-Systemen sein – offener als Windows, einfacher anzupassen als Linux-Distributionen, mit vertrauten Tools und einer grossen Entwicklerbasis. Zur Zeit des Mottos „Don’t be evil“ war das ein glaubwürdiges Versprechen: Android schien ein modernes, flexibles und lizenztechnisch unkompliziertes Betriebssystem für langlebige Produkte zu sein.

Viele Hersteller übernahmen Android deshalb in ihre Board-Support-Packages (BSPs), vor allem SoC-Anbieter wie NXP, Rockchip, Amlogic oder Qualcomm. Die BSPs wurden jedoch in der Praxis meist auf einer bestimmten Android-Version eingefroren und kaum gepflegt. Die Schnittstellen änderten sich häufig, die Kernel-Anpassungen liessen sich nicht ohne Weiteres auf neuere Versionen übertragen, und Langzeitpflege spielte kaum eine Rolle.

So entstanden über die Jahre tausende Plattformen, die noch heute auf 32-Bit-Android mit Kernel-Versionen zwischen 3.x und 4.14 basieren. Diese Systeme laufen stabil, werden aber in vielen Fällen nicht mehr aktualisiert. Besonders in Industrie-, TV-, Automotive- und IoT-Umgebungen sind solche Installationen noch weit verbreitet – Geräte, die ihre Aufgabe zuverlässig erfüllen, aber technologisch auf dem Stand von 2015 oder früher verharren.

Genau dort liegt das strukturelle Problem: Diese Plattformen verwenden weiterhin eine 32-Bit-Zeitbasis, und viele setzen auf Bionic-Bibliotheken, die time_t als 32-Bit-Wert definieren. Selbst wenn der Kernel Y2038-fähig wäre, kann der Userspace diese Funktionalität nicht nutzen. Damit sind Millionen Embedded-Geräte potenziell anfällig für den Zeitüberlauf im Januar 2038.

Die Situation ist nicht akut, aber absehbar. Sie zeigt, dass die eigentliche Verwundbarkeit von Android nicht im Smartphone-Markt, sondern in den langlebigen Embedded- und IoT-Systemen liegt – dort, wo Software selten ersetzt wird und Architekturentscheidungen Jahrzehnte nachwirken.

Wie gross das Problem tatsächlich ist, zeigt sich erst jenseits des Smartphone-Markts. Während Google und die grossen Gerätehersteller seit Jahren vollständig auf 64-Bit-Architekturen umgestiegen sind, dominiert im Embedded- und IoT-Umfeld noch immer 32-Bit-Android – oft auf Kernel-Versionen, die längst das Ende ihres Lebenszyklus erreicht haben.

Zahlreiche Board-Support-Packages (BSPs) grosser SoC-Hersteller basieren weiterhin auf 32-Bit-Architekturen und älteren Android-Versionen. Einige Beispiele:

• NXP i.MX6 / i.MX7 – weit verbreitet in Automotive- und Industrie-Geräten.
  NXP pflegte die 32-Bit-Plattform bis Android 9.0 (Pie) weiter, basierend auf Linux-Kernel 4.14.98 (LTS). Frühere Versionen setzten auf Kernel 3.0, 3.10 oder 4.9 .
  Viele dieser Systeme laufen in Infotainment-Systemen, Industrie-Panels oder Medizingeräten, wo Lebensdauern von zehn bis fünfzehn Jahren üblich sind.$
• Rockchip-SoCs (z. B. RK3188, RK3288) – eingesetzt in Smart-TVs, Autoradios, Digital-Signage-Displays und günstigen Tablets. Viele Geräte verwenden Android 4.4 bis 7.1 mit Linux-Kernel 3.10 oder 4.4. Der Kernel-Support durch Rockchip endet meist nach ein bis zwei Jahren .
• Amlogic-S8-Serie (S802/S805/S812) – in Millionen Android-TV-Boxen verbaut, typischerweise mit Android 4.4 (KitKat). Amlogic stellte den 32-Bit-Support ab 2015 ein und konzentriert sich seitdem auf 64-Bit-SoCs (S905, S912 usw.) .
• Qualcomm Snapdragon 200/210 (Cortex-A7) – genutzt in IoT- und M2M-Modulen wie dem Quectel SC20. Diese Plattform läuft mit Android 7.1 (Nougat) auf einem älteren Kernel (3.18/4.4) und ist bis heute im Einsatz .

Gemeinsam ist diesen Plattformen: Sie werden aber in langfristig betriebenen Geräten eingesetzt. In Fahrzeug- oder Industrieanwendungen laufen solche Systeme oft mehr als ein Jahrzehnt, meist ohne Kernel-Updates.

Die SoC-Hersteller pflegen ihre BSPs nur für begrenzte Zeiträume. NXP garantierte beispielsweise die Hardware-Verfügbarkeit seiner i.MX-Prozessoren über 10–15 Jahre , die Softwarebasis blieb dabei aber weitgehend eingefroren. Rockchip und Amlogic pflegen ältere Kernel kaum. Qualcomm-BSPs für IoT-Module werden vom jeweiligen OEM nur minimal aktualisiert.

Das sind nur Beispiele. Viele Systeme im Feld laufen heute noch auf Linux 3.x oder 4.x mit 32-Bit-Bionic, also einer C-Library, die time_t weiterhin als 32-Bit-Wert implementiert.

Das Jahr-2038-Problem zeigt nicht eine Schwäche von Android, sondern eine Schwäche in Googles Umgang mit eigener Technologie. Das Unternehmen wusste seit über einem Jahrzehnt, dass die 32-Bit-Zeitbasis früher oder später versagt. Trotzdem wurden Millionen Geräte mit dieser Architektur ausgeliefert – auf Basis von Googles offiziellem Quellcode, mit Googles Entwickler-Tools, und mit Googles Freigaben über Android Compatibility Definition und Security Bulletins.

Als die erste Sicherheitslücke bekannt wurde – CVE-2016-3831, ein Fehler in der Telephony-Komponente, ausgelöst durch ein manipuliertes NITZ-Zeitsignal – reagierte Google. Doch der Fix beschränkte sich auf eine Symptombehandlung: Das System wurde abgesichert, damit das Datum nicht über 2037 hinausgestellt werden kann. Die zugrunde liegende 32-Bit-Zeitdarstellung blieb unverändert. Das Problem wurde damit nicht gelöst, nur aufgeschoben.

Seitdem zieht sich ein Muster durch die Android-Entwicklung: Sobald eine Komponente zu aufwendig wird, wird sie nicht repariert, sondern aufgegeben. Das betrifft 32-Bit ebenso wie ältere Kernel und Bibliotheken. Statt Verantwortung für die Bestände zu übernehmen, verlässt sich Google darauf, dass Gerätehersteller und Märkte das Problem „natürlich“ lösen – durch Austausch.

Diese Haltung mag im Smartphone-Markt wirtschaftlich funktionieren, ist aber im Embedded- und IoT-Bereich unverantwortlich. Android läuft längst in Systemen, die zehn oder fünfzehn Jahre aktiv bleiben: in Industrieanlagen, Fahrzeugen, Kassenterminals und Displays. Viele davon basieren auf offiziellen Android-BSPs, die direkt von Google oder in Partnerschaft mit SoC-Herstellern wie NXP, Qualcomm oder Rockchip entstanden sind. Google hat also die Grundlage geschaffen – verweigert aber die Pflege.

Der Linux-Kernel hat das Jahr-2038-Problem 2020 behoben. Google hätte diesen Fix übernehmen können. Doch die Bionic-C-Library, Herzstück von Android, blieb in ihrer 32-Bit-Variante unverändert.
Das war keine technische Grenze, sondern eine Entscheidung. Man entschied sich, alte Geräte auslaufen zu lassen, anstatt sie zukunftssicher zu machen.

Damit ignoriert Google eine Verantwortung, die weit über Softwarepflege hinausgeht. Wer eine Plattform in Milliarden Geräten betreibt – von Fernsehern bis zu Medizingeräten – kann sich nicht darauf zurückziehen, dass der Markt schon selbst aufräumt. Googles Strategie der geplanten Obsoleszenz verschiebt die Konsequenzen auf andere: auf Hersteller, Betreiber und Nutzer, die jahrelang auf vermeintlich stabile Android-Systeme gesetzt haben.

Googles früheres Motto „Don’t be evil“ wirkt heute wie eine Ironie. Nicht böse zu sein genügt nicht, wenn man bewusst Risiken ignoriert, die man selbst geschaffen hat. Verantwortung bedeutet, Systeme so zu gestalten, dass sie funktionieren – auch dann, wenn sie alt werden. Beim Jahr-2038-Problem hat Google diese Verantwortung abgegeben.

Wenn die BEOZ Association nur annähernd die Mittel und Reichweite von Google hätte, wäre das Jahr-2038-Problem möglicherweise längst behoben. Dass es stattdessen ignoriert wird, zeigt, wie wenig technische Machbarkeit zählt, wenn Verantwortung kein Teil der Unternehmensstrategie ist.

Google trägt mit seinem Verhalten aktiv zur kommenden Epochalypse bei. Indem der Konzern die 32-Bit-Zeitbasis in Android unverändert lässt, hält er eine bekannte Schwachstelle bewusst am Leben. Das Jahr-2038-Problem ist längst kein theoretisches Risiko mehr – es ist ein realer Angriffsvektor.

CERT-Meldungen wie im Fall WAGO zeigen, dass Zeitüberläufe und manipulierte Zeitsignale schon heute Systeme kompromittieren können: Geräte stürzen ab, Zertifikate verlieren ihre Gültigkeit, Prozesse geraten aus dem Takt («2038-Problem wird zur CERT-Sicherheitslücke – WAGO im Fokus“). Ein solcher Angriff ist wohl grundsätzlich auch bei 32-bit Android-Systemen möglich.

Mit jedem nicht aktualisierten System wächst das Risiko. Googles Entscheidung, keine Y2K38-Fixes für 32-Bit-Android bereitzustellen, bedeutet nicht Stillstand – sie verschiebt ein globales Sicherheitsproblem in die Zukunft.

Und diese Zukunft hat längst begonnen.