They Claimed Huawei's Autonomous Driving Mileage Was Fake—So I Spent 10 Minutes Checking the Code

Someone posted a video on TikTok mocking Huawei, claiming that the safety mileage data displayed on Huawei's official website was fabricated.

Their reasoning? The counter kept increasing even when offline.

They turned on airplane mode, recorded their screen, but the cumulative driving mileage number on the webpage continued to scroll. Many viewers assumed it was purely a frontend script—a deceptive trick. There was an excited tone in their voice, as if they'd caught another company red-handed.

I don't know how many people have seen this video, but there were plenty who shared it, criticized it, and joined in the mockery.

Huawei has become a magnet for attention. Criticizing them negatively always garners likes.

But honestly, I was genuinely curious—or rather, my professional instincts kicked in. Having worked in frontend development, I know the most direct way to verify whether a counter is real or fake is to open Developer Tools and check the Network panel.

So I opened Huawei's webpage.

https://auto.huawei.com/cn/ads/safety-and-data-report

The page displays three large numbers: cumulative assisted driving mileage of Qiankun Intelligent Driving, total cumulative mileage of vehicles equipped with Qiankun Intelligent Driving, and cumulative collisions actively avoided. The numbers are scrolling, giving off that typical "big tech data dashboard" vibe.

I pressed F12 and opened the Network tab.

It didn't take long to spot an API endpoint polling regularly.

auto.huawei.com/external/uiapi/ads/v1/query

Every 3 seconds. The returned data structure is clean, with three fields corresponding exactly to the three counters on the page.

This is a legitimate backend API. Not local simulation, not mock data—it's real aggregated values fetched from Huawei's vehicle cloud platform.

How can I be sure?

I watched the data changes for a while. The mileage growth between consecutive requests wasn't constant. I took several samples at different times, and the growth rate fluctuated by about 26%. A uniform timer simply couldn't produce this kind of fluctuation pattern. Only real vehicle telemetry data aggregation would show varying growth rates at different times—more driving during rush hours, less at night, which makes perfect sense.

But then, how did that "still increasing when offline" phenomenon in the video happen?

I started examining the JavaScript files loaded on the page.

Scanning through the Sources panel, one filename immediately caught my attention.

safety_kilometer.js

I opened it.

Well, well.

Inside lay a set of hardcoded numbers:

• Initial value: 7,228,242,208
• Baseline time: January 12, 2026
• Fixed growth rate: 224.86 per second

It was a pure frontend timer. Take the current time, subtract the baseline time, multiply by the fixed growth rate, add the initial value, and calculate the "current mileage." No connection to the backend whatsoever.

If you only looked at this file, you'd think—case closed. Huawei is indeed running fake data with a timer on their webpage.

But I looked a bit closer.

This JavaScript targets DOM elements with IDs #ias-gongli and #ias-pengz.

On the current webpage, these ID elements simply don't exist.

I searched the entire DOM—nothing.

So how was this file being triggered? I checked the call chain. It executes when the page loads, looks for those two elements, and if it can't find them, it does nothing—no errors, no fallback, nothing at all. It just sits there quietly.

But I noticed one detail. There's a QR code on the page directing users to the "Huawei Qiankun App." My guess is that this file wasn't meant for the official website at all.

Comparing safety_260521.js and safety_kilometer.js reveals they're completely different approaches:

safety_260521.js relies on jQuery + Web Worker + AJAX, fetches data through API polling, has complex scrolling animations, and weighs 28KB after bundling. It's a proper official website solution.

Meanwhile, safety_kilometer.js is pure vanilla JavaScript with zero dependencies, calculates numbers directly in memory, and updates innerHTML—less than 1KB after decoding.

The most reasonable guess: this file was prepared for H5 embedded pages within the Huawei Qiankun App. Embedded app pages need instant loading—they can't wait for jQuery to load and then wait for API responses—so they use pure vanilla JavaScript with a set of hardcoded initial values to run an "offline-capable" counter. Once the network is ready, the app uses its JS Bridge to fetch real data and make corrections.

The official website and app embedded pages share the same CDN static resources. So this file got deployed to the official website's server, but since the website's HTML doesn't contain the corresponding ID elements, it just sits there quietly, doing nothing.

It's not some conspiracy. It's simply two platforms sharing the same resource set, with conditional loading that wasn't thoroughly implemented. This kind of thing is extremely common in frontend projects at legitimate companies.

So the surface narrative splits:

There's a real API driving the front-end numbers. And there's also a hardcoded timer file sitting on the server. But it's simply not meant for this page.

So what exactly was "updating when offline"?

I simulated an offline scenario. I connected my phone to a hotspot, refreshed the page, waited for one successful API call, then turned off the hotspot.

Something interesting happened.

The counter didn't stop immediately. It indeed kept moving.

But looking closely, its behavior was different from when normally connected.

When online, the number scrolls smoothly and continuously, with a tiny jump every 3 seconds. When offline, the number oscillates within a small range, with decreasing amplitude, coming to a complete stop after about 12 seconds.

I went back to examine the code.

Here's the logic:

The main loop sends an AJAX request to that backend API every 3 seconds. If the request succeeds → update the target value → Web Worker runs a 4-second scrolling animation from the current value to the latest value. If the request fails → the error callback triggers.

What happens when you go offline?

At 0 seconds: AJAX succeeds, gets the value, starts a 4-second animation.
At 3 seconds: New AJAX request fails. Error callback triggers, restarting a 4-second animation from the current value (where the previous animation stopped halfway) back to the last successful API value.
At 6 seconds: Another AJAX request fails again. Same process repeats.

Each error callback restarts the animation. But each time it restarts, the current value is closer to the target value (because the previous 3-second animation had already pushed the number forward). So the "new animation" has less distance to cover.

Constantly restarting, constantly decaying.

After about 4 to 5 rounds, the current value is almost equal to the target value, and the visual amplitude of the animation becomes too small for the human eye to distinguish.

12 seconds—convergence.

That's the whole truth.

It's not that "it keeps updating when offline." It's that the AJAX failure error callback keeps retrying不甘心地一遍遍重试, each time making the animation "chase" the target value from its current position. The animation gets closer and closer until it matches perfectly, then stops.

It's residual easing animation—not a ghostly counter.

A more vivid analogy would be:

You push a swing, and it starts swinging. When you go offline, no one pushes anymore, but the swing continues to swing for a few more rounds with decreasing amplitude until it finally stops—and then the person who made the video says, "Look, no one's pushing it but it's still swinging—the swing is fake."

Yes, the swing is indeed still swinging.

But that's entirely different from fabrication.

Going back to that video.

I specifically checked the comments section of that TikTok video later. Not a single person verified anything. Everyone was just piling on to criticize Huawei.

Not one person went to open that webpage to take a look. Not one person opened F12 to check the Network panel. Not one person asked, "When it's offline and the numbers are still moving, is it really updating, or is the animation just not finished?"

Everyone was just criticizing en masse.

Sometimes I think this might be the most thought-provoking aspect of the whole incident.

Was there actually anything wrong with Huawei's design? Honestly, I don't think so.

When requests fail, keeping the last successfully obtained value and continuing with smooth animation until it gradually stops—that's completely normal. If the numbers just froze immediately when a request failed, users would think the page had crashed. Displaying the last value steadily and stopping smoothly is actually reasonable UX design.

The real difference is that normal people seeing "numbers still moving briefly when offline before gradually stopping" wouldn't find anything suspicious. But that video chose to capture only the "still moving" part without showing everyone how it eventually stops.

Why did that video's narrative spread so quickly? Because it's so "easy to understand." Offline, numbers still moving, fabrication. Three steps. Anyone scrolling by can digest the entire story in seconds while gaining a sense of intellectual superiority—that feeling is addictive.

Meanwhile, the truth requires you to open DevTools, check the Network panel, examine the Sources panel, understand the code logic, comprehend WebWorker animations, and grasp easing functions. It takes time. It requires patience.

A "blackmail revelation" that can be digested in seconds versus a "truth" that takes at least ten minutes to understand—the latter stands no chance in terms of spread speed.

I'm not blaming anyone. I'm like this too. When I first saw that video, my immediate reaction was also, "Hmm? That does seem problematic."

But the difference might simply be that I happen to have frontend experience, happen to know how to open Developer Tools, and happen to have ten to twenty minutes to spend investigating this matter.

What if I didn't have these conditions? I might have shared that video too, with a caption like "Huawei loves doing these superficial things."

So what I'm pondering is—are we really "seeking truth," or are we "seeking validation"?

In that video's comment section, no one was "seeking truth." Everyone was "seeking validation." Seeking validation for "See, Huawei really isn't good." Seeking validation for "I've uncovered another scam." This validation comes too easily—it doesn't cost you anything, just requires a like or a share.

But "seeking truth" comes at a cost. It requires your time, your effort, and your willingness to admit you might be wrong.

We live in an era where information spreads far faster than it can be verified. A 15-second TikTok video can reach hundreds of thousands of people in half a day, but I suspect fewer than a hundred people actually go to open that webpage to take a look.

I'm writing this not to defend Huawei. Huawei doesn't need me to defend it.

That safety_kilometer.js is indeed a file unused by the official website—it was prepared for app embedded pages. Two platforms sharing the same CDN resources with incomplete conditional loading isn't exactly a crime.

I just think that if you come across similar "expose-the-truth" videos next time, maybe before sharing, take three seconds to ask yourself:

Is there another possible explanation for this phenomenon he's describing?

That counter isn't fake.

That "updating when offline" phenomenon isn't some conspiracy either. It's just ordinary easing animation design—when requests fail, it retains the last value and stops smoothly. That's all.

I believe the real value of this story isn't about judging whether Huawei is right or wrong.

It's about showing us how vast the gap can be between something that "appears to be fabricated" and something that's "actually fabricated." It's also about showing us that in this age of information explosion, a 15-second video can easily reach hundreds of thousands of people, but those who actually verify it might number fewer than a hundred.

Next time you see this kind of "expose-the-truth" content, maybe ask yourself one more question—could this really be true?