tree e024fdd631bd0ed352966980274ba011c3bb4f59
parent 6e1b51a9d94d2e4d8036c3a5012054404272d325
author Elliott Hughes <enh@google.com> 1591994568 -0700
committer Elliott Hughes <enh@google.com> 1593100170 -0700

AlarmManager: don't search for hctosys.

This code used to assume that looking for "hctosys=1" would find us the
RTC that should be used for wall time, but this doesn't work for RTCs
without battery backup, or where the battery backup has failed. The
kernel (since 4.19 at least) only reports "hctosys=1" if the RTC *did*
set the clock, not if it would have, had its battery been okay.

The GKI (and current devices available for testing) all use /dev/rtc0.
rtcwake (all of util-linux, toybox, and busybox) always assumes /dev/rtc0.
hwclock is a legacy mess, with util-linux and busybox not agreeing about
whether to try /dev/rtc or /dev/rtc0 first (but both trying both). I've
changed toybox hwclock to act like rtcwake and always assume /dev/rtc0
(unless overridden with a specific device on the command line). That
seems the simplest, most predictable, and most forward-looking option.
It also restores toybox's behavior to how it was in 2015 before I made
it behave like the frameworks AlarmManager.

For AlarmManager, I'm not feeling quite so brave. There are a lot of
devices out there, and I'm assuming that setting a symlink is easier for
an OEM than carrying a local patch to the frameworks. So this change
causes us to try /dev/rtc first (in case an OEM needs an override), and
fall back to /dev/rtc0.

Going forward, SoC vendors and OEMs who aren't already using /dev/rtc0
for this purpose will want to, and eventually we'll want to remove this
hack and just hard-code /dev/rtc0. But for now, we leave this handy
escape hatch.

Bug: https://issuetracker.google.com/158051176
Test: treehugger
Change-Id: Iecdf9ec03085ed8b74451b0b1ded6abd491592e7
Merged-In: Iecdf9ec03085ed8b74451b0b1ded6abd491592e7