Disagree. If something like this is hard to fix, there is something wrong with the way the code is designed.

I do not know the code; nevertheless, I disagree. The moment you allow for leap seconds, you need to visit your apps. Can they display x hours, y minutes, 60 seconds? (IIRC, 61 seconded can occur, too). You also need to consider how and how often you update your 'current number of leap seconds' store, you have to add 'across leap seconds' checks to all duration calculations, in addition to 'across DST change' checks, etc. You also will have to decide, on a per call basis, what the programmer intended with a call ('one day later' or 'same time on the next day' or 'about 24 hours later, also on the whole hour'?) oftentimes, the programmer will not even have realized that these are different options. And heaven forbid if somebody does a calculation now for a future date, and some time later a leap second is announced for some moment before that future date.

I do not think a really nice design is possible here. There just are too many idiosyncrasies in time handling.

You are talking about display issues of leap seconds. That's a different problem from the one we're talking about, which is that the clock itself is wrong.

It is a different problem, but it largely disappears if the system does not do leap seconds.

Yep, you can get rid of UI problems by not having a screen too.

That doesn't really make the statement untrue.

Your first point is fair enough, but the second one is just ignorant.

Is it? For the vast majority of Android users, the fact that their clock is 15 seconds off is likely pretty irrelevant. I'm sure there are some use-cases where having a super-accurate clock is important, but are their enough users that need it for Google to care? Does Android guarantee some accuracy wrt its clock? I doubt it.

Not when Androids is used in US military networks.

Is Android certified for military use? I'd be surprised if so.