~ / topics / Operating Systems
$man os-android

Android

In brief: Android phones and tablets with 64-bit processors and 64-bit software are fine. Android's 32-bit software, which runs on 32-bit-only devices and for 32-bit apps on some 64-bit devices, still counts time in a 32-bit number. Google has said it does not plan to change that. Google's answer is to phase out 32-bit Android, but cheap phones, TVs, watches, car head units and industrial tablets running 32-bit Android could still be in use in 2038.

Risk level Low (64-bit devices and apps) · High (32-bit-only devices, 32-bit native code)
Status Bionic time_t remains 32-bit on LP32 ABIs. Google has no plan to adopt the kernel's time64 interfaces and expects 32-bit to be phased out
Last reviewed 2026-10-21

2038 status at a glance

Not affected or different deadline (1), and why

Full risk register →Need help assessing your systems? →

Overview

Android runs on the Linux kernel but uses its own C library, bionic, not glibc or musl. Android has two kinds of ABI:

The bionic maintainers document this as a known 32-bit ABI defect: "On 32-bit Android, time_t is 32-bit, which will overflow in 2038. In the 64-bit ABI, time_t is 64-bit, which will not overflow until long after the death of the star around which we currently circle." [1]

Unlike glibc (_TIME_BITS=64) and musl (64-bit by default), bionic has not adopted the 64-bit time system calls that Linux 5.1+ provides for 32-bit processes. See OS-Linux.

Technical details

Bionic's position

From the bionic docs/32-bit-abi.md [1]:

The header <time64.h> and type time64_t exist as a workaround, but the kernel interfaces exposed on 32-bit Android all use the 32-bit time_t and struct timespec/struct timeval. Linux 5.x kernels do offer extra interfaces so that 32-bit processes can pass 64-bit times to/from the kernel, but we do not plan on adding support for these to the C library. Convenient use of the new calls would require an equivalent to _FILE_OFFSET_BITS=64, which we wouldn't be able to globally flip for reasons similar to _FILE_OFFSET_BITS … All apps are already required to offer 64-bit variants, and we expect 64-bit-only devices within the next few years.

A change to that section (bug b/156317457) that appears in a third-party mirror of bionic goes further: "the Linux kernel has added the missing API, but time has also moved on enough to make the cost/benefit unconvincing for Android" [2]. That wording does not appear in the AOSP main copy of the document as of 2026-10-21, but both versions reach the same conclusion: no time64 support for LP32.

What this means in practice:

Code type on a 32-bit process Behaviour after 2038-01-19 03:14:07 UTC
NDK C/C++ using time(), gettimeofday(), clock_gettime(CLOCK_REALTIME), stat() mtimes, mktime() Overflows to 1901 or fails
NDK code using time64_t / mktime64() / localtime64_r() from <time64.h> Calendar arithmetic is OK, but the kernel still delivers 32-bit time
Java/Kotlin System.currentTimeMillis(), java.time, AlarmManager (64-bit long milliseconds) API values are 64-bit. The behaviour depends on how the runtime and system services fetch time from a 32-bit kernel interface (not verified)
System daemons in a 32-bit Android build (init, vold, netd, RIL, vendor HALs) Exposed, because the whole userspace is LP32

The 32-bit phase-out

Older devices

Wikipedia lists among vulnerable systems "many 32-bit devices on Android 4 or earlier", such as the ZTE Blade, the original Google Nexus 7 and 2012 Toshiba tablets [7]. These devices also run Linux kernels far older than 5.1, so even a rebuilt C library could not fix them.

Affected versions / products

Android configuration 2038 status
64-bit device, 64-bit apps (arm64-v8a, x86_64) Not affected [1]
64-bit device running a 32-bit app (armeabi-v7a) Affected inside that app's native code [1]
32-bit-only device (ARMv7 SoC or 32-bit userspace), any Android version Affected, system-wide [1]
Android Go / low-RAM builds on 32-bit userspace Affected (device-specific)
Wear OS, Android TV and automotive head units with 32-bit builds Affected (device-specific) [3]
Android ≤ 4.x devices Affected. Kernel also lacks time64 [7]

Risk & compliance notes

Detection & mitigation

adb shell getprop ro.product.cpu.abilist     # e.g. arm64-v8a,armeabi-v7a,armeabi  or only armeabi-v7a
adb shell getprop ro.zygote                  # zygote32 => 32-bit-only userspace
adb shell uname -r                           # kernel version (< 5.1 has no time64 syscalls)

See also

References

  1. 32-bit ABI bugs (bionic/docs/32-bit-abi.md) — Android Open Source Project. "time_t is 32-bit on LP32 (y2038)". No plan to use the time64 syscalls.
  2. bionic commit retitling the y2038 section (b/156317457) — OmniROM Gerrit mirror of AOSP bionic. "cost/benefit unconvincing for Android" (seen in search results; mirror unreachable when fetched).
  3. Pixel 7 can't run 32-bit apps — 9to5Google, 2022-10-14 and Google Pixel 7 Pro 64-bit info — Android Police. Play's 64-bit requirement since August 2019, Pixel 7 behaviour, and continued 32-bit hosting for budget, Wear OS and TV devices (seen in search results).
  4. Pixel 7 series drop support for 32-bit apps ahead of Android 14 — Chrome Unboxed. Context on the Pixel 7 change (seen in search results).
  5. Android ABIs — Android NDK documentation. armeabi-v7a is the 32-bit ARM ABI; armeabi and MIPS were dropped in NDK r17 (seen in search results).
  6. 32-bit Android compatibility — Visionaire Studio forum. An anecdotal example of a 32-bit Android 11 device (SM-T510) (seen in search results).
  7. Year 2038 problem — Wikipedia. Secondary source listing vulnerable 32-bit Android 4.x devices.