15 July 2026
Zanny 🇵🇸 🇵🇸So the new updater app just lets you update to the same and older versions?
Someone may have rolled out an update to fix a bug for example
Zanny 🇵🇸 🇵🇸So the new updater app just lets you update to the same and older versions?
I find it weird that it's advertising an older build. Let me check
Zanny 🇵🇸 🇵🇸So the new updater app just lets you update to the same and older versions?
May I know which device this is ?
RTC Time Persistence Problem on Samsung Galaxy Tab S9 Ultra (SM-X910 / gts9uwifi)
Device
Samsung Galaxy Tab S8 Ultra (SM-X910 / gts9uwifi)
WiFi-only variant (no modem → no NITZ time sync)
LineageOS 23.2 (Android 15), self-compiled from samsung-sm8550-tab repos
Kernel: 5.15, Qualcomm SM8550 (Snapdragon 8 Gen 2)
Problem
Every reboot, system time resets to 1970-02-25 (compilation timestamp / RTC default). Time only becomes correct after connecting to WiFi and NTP sync. Offline usage has wrong time.
Root Cause Chain
WiFi-only tablet has no modem → time_daemon gets no time from baseband
time_daemon is restricted to start only on encrypted devices (ro.crypto.state=encrypted && ro.crypto.type=file) — it CAN run here but gets no modem time
Hardware RTC exists (rtc-pm8xxx on PMK8550 PMIC, /dev/rtc0) and CONFIG_RTC_HCTOSYS=y is set, so kernel would auto-restore from RTC on boot
But the RTC is write-locked: the driver rtc-pm8xxx.c line 155 checks if (!rtc_dd->allow_set_time) return -EACCES;
allow_set_time defaults to false and is only set to true by the DTS property allow-set-time; — which is not present in the device tree
Qualcomm's com.qualcomm.timeservice (in /vendor/app/TimeService) receives TIME_SET broadcasts and writes to /data/vendor/time/ats_2 — but nothing reads it back on boot
Evidence
# RTC can be read but not written
$ adb root
$ adb shell "hwclock -r -f /dev/rtc0"
1970-02-25 08:11:38+0000 # factory default value
$ adb shell "hwclock -w -f /dev/rtc0"
hwclock: ioctl 4024700a: Permission denied # EACCES from driver
# Kernel config supports RTC restore
$ adb shell "zcat /proc/config.gz | grep RTC_HCTOSYS"
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# The infamous driver check
$ grep -n "allow_set_time" drivers/rtc/rtc-pm8xxx.c
155: if (!rtc_dd->allow_set_time)
156: return -EACCES;
671: rtc_dd->allow_set_time = of_property_read_bool(pdev->dev.of_node,
672: "allow-set-time");
# time_daem
Root adb shell has no CAP_SYS_TIME. Init's exec - root root also hits same issue.
Attempt 5: File-based time save/restore with shell scripts
Created shell scripts + init service to write/read /data/vendor/time/ats_2
Result: SELinux blocked init from transitioning to shell domain:
init: Could not start exec service: File /vendor/bin/timekeep_restore.sh
(labeled "u:object_r:shell_exec:s0") has incorrect label or no domain
transition from u:r:init:s0 to another SELinux domain defined.
Tried file_contexts (labeling as shell_exec), domain_auto_trans(init, shell_exec, shell) — all blocked.
What I Haven't Tried Yet (and need advice on)
How to properly add allow-set-time to DTBO overlay so it survives QCOM merge — which is the correct DTS file to patch?
How to give init's exec service CAP_SYS_TIME to bypass the RTC core capability check
Whether there's a simpler approach — perhaps using the kernel's rtc-hctosys + writing RTC via a different path (SPMI registers directly?)
16 July 2026
