The Android client on the website is something that is updated continuously: the content is updated together with the articles and the product parameters on the site, and every release of the installation package needs a new build number. When the version number and the build number do not match, two typical situations appear on site: the old version is installed on the phone while the page shows the new one; or the package the download link points to is not the same version as the one stated on the page. Users cannot tell the difference between the two and simply conclude that what they downloaded is wrong.
What the two numbers are for
The version number is for the user: the format is year, month and day, for example 2026.11.03, and it tells the user when the package was made. The build number is for the system: it goes up by one with every release, and it is what tells a new package from an old one on the same phone. The number in the body of the page, the number in the structured data and the number on the actual package must all come from the same version file; they cannot each be written separately.
The download link has to follow the version as well. The address given on the page is a relative path within the site: /download/yanneng-oil-filter.apk, with the version number appended as a query parameter. Whether a user copies the address and sends it to someone else, opens it in a mobile browser or accesses it on an internal network, the same file should be obtained.
What has to be updated when a release is made
A release touches at least three places: the build number and the version number in the version file, the content displayed on the page, and the download address given on the page. Leave one of them out and the page ends up carrying information that contradicts itself. There is a fourth: the package size stated in the structured data. The package size is a real number of bytes, and when the figure on the page does not match the actual file, the user can feel it directly.
| What has to stay consistent | What happens when it does not match | How to check it |
|---|---|---|
| The version number shown on the page and the version inside the package | The user installs it and finds it is not the version the page described | After installation, check the version number in the app information |
| The build number and the parameter in the download address | The browser or the system caches the old package | Check that the build number at the end of the link matches the version file |
| The package size stated on the page and the actual file | The download progress does not match what the page states | Check the figure on the page against the byte count of the actual file |
| The form of the download address | The link does not open in some environments | Confirm that the address is a relative path within the site |
| The offline content in the client and the content on the site | The articles seen offline are the old version | After an update, open the offline package once more |
What an update means for the user
- An update is installed over the top, without uninstalling first, so the data and the settings of the user are not lost in the upgrade.
- The download address on the page gives the same file in any browser, with no need to distinguish between desktop and mobile.
- The package carries the whole site content offline, so the equipment parameters and the technical articles can be read while offline; the cost is that the package itself is larger than that of an ordinary online application.
- When a problem is found, report the version number and the build number directly, which is much faster than describing what the page shows incorrectly.
- After the site content has been updated, the offline content in the client is synchronised once the next time it is opened.
Nobody looks at the version number until it stops matching, and then the user does not know which version is installed. Align the two first and the problem does not arise.
