Android

This pages contains some specific information about the Battle for Wesnoth new Android port (1.19+)

Playing controls

• Tap a unit to select/deselect it.
• Tap a unit, then tap the target hex to show defense stats of that unit and footsteps. (Similar to hover on PC)
• Tap a unit, then double tap on the target hex to move it. Alternative, you can drag along the path to choose the exact path which the unit is supposed to move by.
• Drag from attacker unit towards attacked unit to attack.

Logs and debugging steps

• Install adb (Android Debug Bridge) on your computer. Search internet for information about your OS. Install drivers for your phone/tablet if necessary.
• Enable Developer Mode on your Android device (phone/tablet). Again, the internet is your friend. On newer devices, you need tap Settings > About Phone > Build Number 7 times until it says "You are now a developer", then go into the Setting > System > Developer Options (newly appeared), and find "USB Debugging" in the menu and turn that on.
• Connect phone to PC. Do adb logcat or similar from a terminal/command prompt to see if your device appears on the list and is authorized. Tap ok on your phone if any permission request appears.
• Run adb logcat -c (clears existing logs), then adb logcat > log.txt (or adb logcat and copy from terminal). Run Wesnoth on phone. Reproduce the crash.
• stop adb logcat on PC, and attach the log.txt to your issue report on github along with detailed steps of the bug, and use the Android label.

(Note: adb can be ./adb.exe on Windows. Use internet for help on any of the steps if needed, this is supposed to be a preliminary guideline. Steps might slightly differ based on manufacturer or Android version.)

Enabling taps

It is useful for debugging purposes, especially if you're sharing a screen recording of your bug, to show where you're tapping on the screen in the screen recording. See here for how to enable that.

Turning off Developer Mode

Go to System > Developer Options and turn off the Use developer options toggle.

Dev Notes

Version Code scheme (1191601001 - post 1.19.16 fixup)

MmmPPppVVV

Where,

• M - Major version code, so far at 1; since the max versionCode is 21000000 it can go up to 2
• mm - Minor version code.
• PP - Patch version code.
• pp - Android patch version/any other use.
• VVV - Reserved for ABI/Variants.
  • Last digit - ABI (['armeabi-v7a': 1, 'arm64-v8a': 2, 'x86': 3, 'x86_64': 4])
  • Rest unused (variants if we need them)

New Version Code scheme draft

This is but one possible idea among many, and is not final.

MSUUmmPPppVV

Where,

• 1 - Major version code. Wesnoth's version's first digit is almost always 1, but the max versionCode is 21000000 so it can go upto 2 if needed.
• S - store identifier (must be greater than 2 to allow upgrade from previous scheme.) For example:
  • 2 - F-Droid
  • 3 - Google Play
  • Others if needed.
• UU - unused/unspecified.
• mm - Minor version
• PP - Patch version
• pp - Android Patch version
• VV - ABI/Variants
  • Last digit - ABI (['armeabi-v7a': 1, 'arm64-v8a': 2, 'x86': 3, 'x86_64': 4])
  • Last but one digit - Unused (variants if we need them)

E.g., 1.20.14 with hotfix 1, Fdroid, arm64 ABI would be: 120020140102.

Other version code scheme drafts

Given that we only have 10 digits to work with (max being 2.1e9, which is signed INT_MAX with some margin), the above scheme is not possible. The PR to remove/disable the existing version codes on f-droid has been rejected, so we're probably stuck with version codes > 1.19e9. The highest version code currently (2025-10-02) in use is 1191601002.

Further constraints are:

• version codes should go up
• each ABI needs its own version code
• we may have multiple APK releases for one "regular wesnoth version" to fix android-only issues (android patch version)
• we may have builds that differ per store (F-droid creates the file /data/Dist with contents "F-Droid" during the build process)
• we may want various variants of builds, that is, a "clean" build, a build with google play integrations, a build with a different integration, and so on. This may or may not be tied to the store the APK is distributed on

Drafts of possible approaches:

MMMPPpxxxV

• MMM - Combined Major/Minor: 1.19 = 119, but each subsequent minor *or* major bump increases this number by 1. This remains visually the same until 2.0 happens.
• PP - Patch version
• p - Android patch version
• V - ABI
• x - Unspecified, available for expanding these fields or adding other flags (like store and/or integrations)

Example: 1220320002 would be version 1.22 (or 2.0 or 2.2, but 2 stables from 1.18), patch 3, android patch 2, arm64

12MMMPPpxV

Basically the same thing, just shifted to the right by eating up unspecified digits, and with the first digits fixed to 12. Leaves 8 "additional epochs" available for future expansion.

Example: 1212203202 would be version 1.22.3.2 arm64, as above.

12MMPPpxxV

Removes the major version digit, freeing up 1 digit. Not functionally different from the major-minor scheme, but reduces the number of available version bumps until epoch change.

Example: 1222032002 would be version 1.22.3.2 arm64, as above.