How to handle RealTimeClockNotValidException

Hi, through ERA, I see that an app I manage get an unhandled exception at this line:

data.put("status", Application.loadResource(Rez.Strings.label_asleep) + " @ " + System.getClockTime().hour.format("%d")+":"+System.getClockTime().min.format("%02d"));

The string file for that language exists and 'data' is read from Background.getBackgroundData() or set {} if null was returned. So the only line I can see that can produce the exception is RealTimeClockNotValidException ("Real-Time Clock (RTC) value is not secure, i.e. not synced with trusted sources, such as GPS"). I plan on doing this because I can't find a way to check if the RTC is 'secure'.

try {
data.put("status", Application.loadResource(Rez.Strings.label_asleep) + " @ " + System.getClockTime().hour.format("%d")+":"+System.getClockTime().min.format("%02d"));
} catch (e) {
data.put("status", Application.loadResource(Rez.Strings.label_asleep));
}

I can't simulate it so turning here to know if you guys think this is a valid logic.

Thanks.

0 flowstate over 4 years ago

That logic looks ok (although it could be simplified a bit to avoid duplication of code.)

e.g.

var status_suffix = "";
try {
    var clock_time = System.getClockTime();
    status_suffix = " @ " + clock_time.hour.format("%d")+ ":" + clock_time.min.format("%02d"));
} catch (e) {
    // System.println(...)
}
data.put("status", Application.loadResource(Rez.Strings.label_asleep) + status_suffix);

Looking at the docs for Time.getCurrentTime() (which is new for API 3.0.10), it seems that you can get around this problem by calling getCurrentTime() and passing in a value other than Time.CURRENT_TIME_RTC for the :currentTimeType option.

If System.getClockTime() is indeed throwing RealTimeClockNotValidException (which is new for API 3.0.11), that seems like something which should be added to the getClockTime() documentation, so others can avoid this problem. Might want to open a bug report for that.

(Obviously the workaround would only be valid for CIQ 3 devices, but that's ok because the exception should only be thrown for CIQ 3 devices. It does mean you'd have to have alternate code for CIQ 1 and 2 devices, if you support them.)

It seems to me that you should be able to recreate this exception by:

1) Using a device that has CIQ 3

2) Rebooting the device and avoiding getting a GPS fix or syncing via Bluetooth. (To be safe you could also avoid syncing via Wi-Fi, although last time I checked, Wi-Fi syncs don't sync the clock, as this is an issue many people complained about)

3) Running a sideloaded app which calls System.getClockTime() and prints a message when it catches RealTimeClockNotValidException.