versionCode Input Field in Android Build UI Truncates to 9-digit Values

[hightowe]

Description:
The input field for versionCode in the Solar2D Android Build Setup GUI on Windows has a character limit of 9 digits that prevents users from inputting or viewing longer version codes (in my case, 10-digits).

Solar2D correctly respects 10-digit versionCode values defined in build.settings during the build process, the GUI input box truncates these values when they are pasted or displayed. For example, pasting 1768083670 results in the field only holding 176808367. I actually went a couple of weeks without noticing it because my build process auto-populates the versionCode value in the build.settings file.

Steps to Reproduce:

1. Open a project in Solar2D Simulator.
2. Navigate to File > Build > Android....
3. Attempt to paste a 10-digit integer (e.g., 1768083670) into the Version Code field.
4. Observe that the last digit is truncated.

Expected Behavior:
The versionCode field should support up to the maximum value allowed by Android/Google Play, which is 2,147,483,647 (signed int32, and so up to 10 digits).

Actual Behavior:
The field truncates at 9 digits, leading to confusion as it appears the version code will be incorrect, even though the build.settings value is used correctly in the final package.

Environment:

• Solar2D Version: 2025.3726 / 2025.11.4
• OS: Windows (and not likely any others -- see later comment)

[hightowe]

I spent a few minutes digging into the code and this seems like a 1 character fix, at line 111 of corona/platform/windows/Corona.Simulator/BuildAndroidDlg.cpp:

corona/platform/windows/Corona.Simulator/BuildAndroidDlg.cpp

Line 111 in 4518815

((CEdit*)GetDlgItem(IDC_BUILD_VERSION_CODE))->SetLimitText(9);

This is the diff that would be needed:

-	((CEdit*)GetDlgItem(IDC_BUILD_VERSION_CODE))->SetLimitText(9);
+	((CEdit*)GetDlgItem(IDC_BUILD_VERSION_CODE))->SetLimitText(10);

[hightowe]

I also worked with Google Gemini do a cross platform analysis and am fairly confident that this bug only impacts Windows, so no need to waste time on researching the other simulator/build platforms.

Cross-Platform Analysis of versionCode Truncation

I've verified the source code for macOS and Linux, and the issue appears to be unique to the Windows Simulator.

1. Windows (Confirmed Bug)

• File: platform/windows/Corona.Simulator/BuildAndroidDlg.cpp
• Code:

  ((CEdit*)GetDlgItem(IDC_BUILD_VERSION_CODE))->SetLimitText(9);

• Verdict: This explicitly limits the input field to 9 characters, preventing the entry of 10-digit version codes that Android supports.

2. macOS (Unaffected)

• File: platform/mac/English.lproj/AndroidAppBuild.xib
• Code: An NSNumberFormatter (id 320) is attached to the versionCode text field with the following property:

  maximumIntegerDigits="42"

• Verdict: With a 42-digit limit, macOS does not suffer from truncation issues.

3. Linux (Unaffected)

• File: platform/linux/src/Rtt_LinuxDialogBuild.h
• Code: The buffer for the version code input is defined as:

  char fVersionCodeInput[32];

• Verdict: The ImGui::InputText call in Rtt_LinuxDialogBuild.cpp uses sizeof(fVersionCodeInput), which at 32 bytes is more than enough to hold a 10-digit version code.

[Shchvova]

Thanks for the report. Isue is also with the datastructure containing the version code, it is int for some reason. Looking into it

[hightowe]

Thanks for the report. Isue is also with the datastructure containing the version code, it is int for some reason. Looking into it

In this context, I believe that a simple int will be a signed int32 and, if so, that should be fine as that aligns with Google's published maximum limit for that field. In fact, it has to be in int32 or greater it could not hold the 9 digits that it accepts now.

Bit Depth	Type	Minimum Value	Maximum Value	Hexadecimal Max
16-bit	Signed	-32,768	32,767	0x7FFF
16-bit	Unsigned	0	65,535	0xFFFF
32-bit	Signed	-2,147,483,648	2,147,483,647	0x7FFFFFFF
32-bit	Unsigned	0	4,294,967,295	0xFFFFFFFF

I will have (and maybe Google also) a 2038 problem...

[hightowe]

I went down the rabbit hole to better understand my year 2038 problem and after doing so decided to share my research here since android:versionCodeMajor may be a build setting that Solar2D needs to support.

Android versionCode and the Year 2038 Problem

Overview

The Android versionCode is a positive integer used by the Android system and Google Play to identify the version of an application. This document outlines the technical limits of the versionCode and Google's strategy to avoid the "Year 2038" overflow and Google Play's 2.1 billion limit.

Technical Limits

1. The Signed 32-bit Integer Limit

Android stores the versionCode as a signed 32-bit integer.

• Maximum Value: 2,147,483,647
• The Y2038 Trigger: If using a Unix timestamp (seconds since epoch) as the versionCode, it will exceed this limit on January 19, 2038. At that point, the value will "wrap around" to a negative number, breaking the update path in Google Play.

2. Google Play Console Limit

While the OS supports up to 2.147 billion, the Google Play Console enforces a slightly lower practical limit.

• Google Play Cap: 2,100,000,000
• Practical EOL: Using second-based Unix timestamps, an app will hit this cap on November 25, 2036.

3. Google's fix: longVersionCode

Introduced in Android 9 (API 28), the longVersionCode system allows developers to escape the 32-bit integer limit by providing a 64-bit value.

1. How it Works (Bit Breakdown)

The longVersionCode is a synthetic value created by the Android system from two manifest attributes:

• android:versionCode: Occupies the lower 32 bits of the long.
• android:versionCodeMajor: Occupies the upper 32 bits of the long.

When the Android OS calls PackageInfo.getLongVersionCode(), it performs the following bitwise operation:

longVersionCode = (versionCodeMajor << 32) | (versionCode & 0xFFFFFFFFL)

Example:
If versionCodeMajor="1" and versionCode="1", the resulting longVersionCode is 4,294,967,297. This allows for a version numbering scheme that will literally never run out of space.

2. The Google Play and Backward Compatibility "Catch"

Despite the expansion to 64-bit, there are two major constraints for modern app development:

• Backward Compatibility: Devices running Android versions older than API 28 do not recognize versionCodeMajor or longVersionCode. They only read the 32-bit versionCode.
• Google Play Enforcement: Even for apps targeting newer APIs, the Google Play Console still treats the 32-bit versionCode portion as the primary identifier. It requires that this value be a positive integer and that it increments with every release.

[hightowe]

Just in case it will help someone who may find this ticket via a search later, here is a github repo that demonstrates how I plan to solve the Android versionCode "year 2038 problem" that I created for myself, as mentioned in earlier comments: https://github.com/hightowe/ChronoLex-version-manager