阅读:5663回复:2
RK3399-8.1系统时间BUG
首先可以肯定这是我制造出来的Bug。或者说是我发现的Bug
系统平台:RK3399-8.1 带RTC 问题现象:1.进入系统Settings里面,关闭自动确定日期时间,关闭自动确定时区。 2.手动修改日期,改一个距离今天早一点的日期,比如今天18号,我设置17号或者17之前的。 3.重启。日期时间都变了,正常应该是可以获取上次关机之前保存在RTC里的时间 问题分析:我发现这个Bug出现时,系统设置的时间是从build.prop里面获取的。日期时间就是通过这个ro.vendor.build.date.utc: 1576223155 属性值来设置的日期时间 [ro.vendor.build.date]: [Fri Dec 13 07:45:55 UTC 2019] 从开机Logcat也看到了这样的打印: 2019-12-13 15:52:09 12-06 16:20:02.182 465 465 I SystemServer: StartAlarmManagerService 从打印上来看,AlarmManagerService起来之后,设置了一个这样的时间 Setting time of day to sec=1576223524 虽然和 [ro.vendor.build.date.utc]: [1576223155]时间不一样,但是也很接近了,肯定是有点联系的。 接着从Log打印去寻找AlarmManagerService.java相关的位置,看到了这样一段代码: // Also sure that we're booting with a halfway sensible current time 原来如此,每次开机AlarmManagerService 起来后,这里会判断,当前的时间小于系统编译的时间,他直接把系统的编译时间设置进kernel里面了,修改了系统时间,同时设置到了RTC里面。 我勒个去,为什么要这么写,转念一想,这样其实也没有问题,固件编译好,到了终端用户手上,至少几个月过去了,终端用户不会去设置一个几个月前的日期去使用设备,这么一想也有道理,看来这也不能算是个Bug了,看你怎么理解,再我看来,除非是崩溃无法使用,软件没有什么绝对的Bug,看你需求,如果用户觉得这个功能OK符合他的需求,那就是好样的very good 如果客户觉得你这个功能做的不好用,就算你感觉做的再好再牛B,客户也觉得是垃圾,给老子改! 说到这里我想起去年公司的测试真的搞我很烦,明明没有问题的地方,老是要这样改那样改的,搞的我直接来气了,不要你觉得应该怎么样改,你又不是客户,这个在你看来是BUG但是客户人家或许不这么想呢*** |
|
|
沙发#
发布于:2019-12-18 19:05
|
|
|
板凳#
发布于:2019-12-18 19:40
不错,善于发现了一个不为人知的点哈哈
|
|
|