Android系统时间无法设置到2038年后问题

文章讲述了在Android系统中,AlarmManagerService的kernelTime接口对RTC时间设置了最大值,以及DatePickerFragment中的时间限制,强调了车载系统的特殊需求。开发者需要注意处理时间戳和系统时间设置的边界条件。

在线获取时间戳:https://tool.lu/timestamp/

文件:frameworks/base/services/core/jni/com_android_server_AlarmManagerService.cpp

修改接口:android_server_AlarmManagerService_setKernelTime

系统时间限制默认是Int(有符号32位,最大0X7FFFFFFF)最大值即为: Integer.MAX_VALUE = 0X7FFFFFFF=2147483647 = 2038-01-19 11:14:07

将RTC时间限制改成自己所需时间:4102415940LL = 2099-12-31 23:59:00

static jint android_server_AlarmManagerService_setKernelTime(JNIEnv*, jobject, jlong nativeData, jlong millis)
{
    ALOGD("Setting setKernelTime\n");

    AlarmImpl *impl = reinterpret_cast<AlarmImpl *>(nativeData);
    struct timeval tv;
    int ret;

    if (millis <= 0 || millis / 1000LL > 4102415940LL) {
        return -1;
    }

    tv.tv_sec = (time_t) (millis / 1000LL);
    tv.tv_usec = (suseconds_t) ((millis % 1000LL) * 1000LL);

    ALOGD("Setting time of day to sec=%ld\n", (int) tv.tv_sec);

    ret = impl->setTime(&tv);

    if(ret < 0) {
        ALOGW("Unable to set rtc to %ld: %s\n", tv.tv_sec, strerror(errno));
        ret = -1;
    }
    return ret;
}

系统原生设置也限制了最大时间,所以原生设置也得改下(使用的是车载系统)
文件:/packages/apps/Car/Settings/src/com/android/car/settings/datetime/DatePickerFragment.java

private static final long MAX_TIME_SEC = 4102415940L;

public void onActivityCreated(Bundle savedInstanceState) {
        super.onActivityCreated(savedInstanceState);

        mDatePicker = (DatePicker) getView().findViewById(R.id.date_picker);

        Button button = (Button) getActivity().findViewById(R.id.action_button1);
        button.setText(android.R.string.ok);
        button.setOnClickListener(v -> {
            Calendar c = Calendar.getInstance();

            c.set(Calendar.YEAR, mDatePicker.getYear());
            c.set(Calendar.MONTH, mDatePicker.getMonth());
            c.set(Calendar.DAY_OF_MONTH, mDatePicker.getDayOfMonth());
            long when = Math.max(c.getTimeInMillis(), DatetimeSettingsFragment.MIN_DATE);
            Log.i("setting","setTime when:"+when);
            if (when / MILLIS_IN_SECOND <= MAX_TIME_SEC) {
                ((AlarmManager) getContext().getSystemService(Context.ALARM_SERVICE)).setTime(when);
                getContext().sendBroadcast(new Intent(Intent.ACTION_TIME_CHANGED));
            }
            getFragmentController().goBack();
        });
    }

<think>嗯,用户问的是安卓系统时间显示为什么从19701月1日开始。这个问题挺有意思的,涉及到计算机发展史的基础知识。 用户可能是个技术爱好者,或者遇到了安卓设备时间显示异常的问题。从ta提问的方式看,ta已经注意到这个特殊日期,但想了解背后的设计原因。这个问题其实可以拆解成几个层面:技术标准层面、系统实现层面和实际影响层面。技术标准层面要解释Unix时间戳的概念。几乎所有现代操作系统都用19701月1日作为计时起点,这个传统源于Unix系统。当时的设计者选择这个日期作为纪元时间(EpochTime),用秒数计算时间流逝。安卓基于Linux内核,自然继承了这个标准。 系统实现层面需要说明安卓的具体处理机制。引用[1]提到SystemServer.java里的EARLIEST_SUPPORTED_TIME常量,这个细节很重要。当设备无法获取网络时间时,系统会检查当前时间是否早于这个常量值(通常是0毫秒),如果是就重置为19701月1日。这种保护机制能避免处理负数时间戳导致的程序崩溃。 实际影响层面有两个关键点:一是32位系统时间上限问题(2038问题),引用[2]解释得很清楚;二是用户可能遇到的异常场景,比如恢复出厂设置时间显示1970。有趣的是有些厂商会修改这个默认值,但绝大多数保持原样。 这个问题还让我想到可以延伸讨论2038问题,不过用户当前的问题集中在起源。在回答时需要强调这不是安卓独有的设计,而是整个计算机领域的通用实践。最后生成的三个问题要覆盖技术原理、系统机制和实际问题解决,这样能帮助用户全面理解。对了,回答时要特别注意所有数学表达式都用$...$包裹,比如提到时间戳计算时。虽然这个问题不涉及复杂公式,但提到时间戳数值时还是要规范格式。</think>安卓系统将19701月1日作为时间显示的起始点,这是由以下核心原因决定的: ### 1. **Unix时间戳的继承** - **技术根源**:Android基于Linux内核,而Linux继承了Unix操作系统的**时间表示标准**。Unix系统将19701月1日00:00:00 UTC定义为**时间纪元(Epoch Time)**,后续时间通过**从此刻开始的秒数**(32位整数)表示,称为Unix时间戳。 - **数学表示**: 时间戳计算为:$ t = \text{当前时刻} - \text{1970-01-01 00:00:00 UTC} $(单位:秒) ### 2. **防止负时间戳的容错机制** - **系统保护逻辑**:当设备未联网无法获取实时时间(如首次开机、重置后),系统时间可能被初始化为0(即1970)。此时若实际时间早于1970,会产生**负时间戳**,导致依赖时间的API崩溃(如文件修改时间计算)。 - **安卓源码实现**: 如引用[1]所示,`SystemServer.java`中通过`EARLIEST_SUPPORTED_TIME`常量(值为0)强制修正异常时间: ```java if (System.currentTimeMillis() < EARLIEST_SUPPORTED_TIME) { SystemClock.setCurrentTimeMillis(EARLIEST_SUPPORTED_TIME); // 重置为1970 } ``` 此设计避免了负数时间戳引发的系统级错误[^1]。 ### 3. **32位整型的存储限制** - **技术约束**:早期系统使用**32位有符号整数**存储时间戳,其取值范围为: $$ -2^{31} \sim 2^{31}-1 \quad \text{即} \quad -2,147,483,648 \sim 2,147,483,647 \text{秒} $$ - **时间范围**: - **最早时间**:$ 2^{31} \text{秒} \approx 68 \text{} $ 回溯 → **190112月**(理论值) - **最晚时间**:$ 2^{31}-1 \text{秒} \approx 68.1 \text{} $ 后 → **20381月19日**([2038问题](https://zh.wikipedia.org/wiki/2038%E5%B9%B4%E9%97%AE%E9%A2%98))[^2] - 1970作为中位点,可最大化利用该范围。 ### 4. **历史兼容性** - **生态统一**:1970作为时间纪元已成为**编程领域的国际标准**(如Java的`java.util.Date`、C语言的`time_t`)。安卓保持此标准确保: - 应用层时间处理逻辑的一致性 - 跨平台数据交换的兼容性 --- ### 扩展影响 - **用户可见现象**:设备未联网时显示"1970-01-01"(如引用[1]所述),实为系统安全机制触发的默认值[^1]。 - **未来演进**:64位系统采用**64位时间戳**,时间范围扩展至约$2.92 \times 10^{11}$,彻底解决2038问题。 ---
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值