Bump the minimum supported SDK version to 24

[m4gr3d]

Raise the minimum supported Android version from Android 5 (Lollipop) to Android 7 (Nougat).

From the following chart, it looks like we're removing support for 1.3% Android devices by bumping the min version to 24: https://composables.com/android-distribution-chart

On the negative side, this removes support for 1.3% Android devices.

On the plus side:

• the new min version, Android 7 (api level 24), is still 9 years old, and our coverage remains high at 98.6%
• this aligns our min sdk version with our min vulkan version which is currently set at 24, simplify the build config and ensuring that all supported Android devices have the min required version for vulkan support.

My preference is to make the bump to api version 24.

[syntaxerror247]

We should also bump the target SDK to 35.

Edit: Okay, I just saw #106152, which bumps the target SDK along with other stuff.

[m4gr3d]

We should also bump the target SDK to 35.

Edit: Okay, I just saw #106152, which bumps the target SDK along with other stuff.

@syntaxerror247 They are separate PRs because we'll need to cherry-pick the other one in order to meet the Play Store annual requirements for our 4.4 release, whereas we don't want to cherry-pick this PR in previous releases.

[akien-mga]

I agree that it's time to upgrade our baseline.

You can now also remove this if check which is always true:

platform/android/java_godot_view_wrapper.cpp
44:     if (android_device_api_level >= __ANDROID_API_N__) 

[Alex2782]

if (android_device_api_level >= ANDROID_API_N)

In our Kotlin and Java files, we still have these checks as well. But if we introduce API < 24 via SCons parameters, these API-level checks will still be needed (I think).

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N)

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M)

---

thirdparty: google/android/vending

---

This file includes/supports Android 3 & 4, but also contains Godot edits.

// -- GODOT start --
// -- GODOT end --

Maybe I'll find time tomorrow to remove it if it's not critical.

godot/platform/android/java/lib/src/com/google/android/vending/expansion/downloader/Helpers.java

Lines 228 to 240 in 0793c62

	@TargetApi(Build.VERSION_CODES.HONEYCOMB)
	static public String getSaveFilePath(Context c) {
	// This technically existed since Honeycomb, but it is critical
	// on KitKat and greater versions since it will create the
	// directory if needed
	if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
	return c.getObbDir().toString();
	} else {
	File root = Environment.getExternalStorageDirectory();
	String path = root.toString() + Constants.EXP_PATH + c.getPackageName();
	return path;
	}
	}

[Alex2782]

• On MacOS. Android template seems to be invalid (INSTALL_FAILED_INVALID_APK) and the libs too big.
• GH Check, arm64 template, 74 MB, seems too big to me too, and perhaps invalid.

-rw-r--r-- 1 runner docker 74507372 May 7 16:24 android_release.apk (this PR)
vs.
-rw-r--r-- 1 runner docker 25316674 May 7 23:47 android_release.apk (PR 106157)

Details

scons platform=android target=template_debug arch=arm32 c_compiler_launcher=ccache cpp_compiler_launcher=ccache
scons platform=android target=template_debug arch=arm64 generate_apk=true generate_android_binaries=true c_compiler_launcher=ccache cpp_compiler_launcher=ccache

Installing to device (please wait...): Samsung SM-T870
  ERROR: editor/export/editor_export_platform.h:243 - Run: Could not install to device: Serving...
  ERROR: adb: failed to install /var/folders/sp/wzt62dns1nddx0mcywhdjyyw0000gn/T/tmpexport.1746662378.apk: Failure [INSTALL_FAILED_INVALID_APK: INSTALL_FAILED_INVALID_APK: Failed to extract native libraries, res=-2]
  ERROR: Performing Incremental Install
  ERROR: 
  ERROR: Exception occurred while executing 'install-incremental':
  ERROR: java.lang.IllegalArgumentException: Incremental installation not allowed.

---

GH Check Logs

BUILD SUCCESSFUL in 2m 2s
94 actionable tasks: 94 executed
total 120568
-rw-r--r-- 1 runner docker    95608 May  7 16:24 android-template-standard-release-native-debug-symbols.zip
-rw-r--r-- 1 runner docker 74507372 May  7 16:24 android_release.apk
-rw-r--r-- 1 runner docker 24390291 May  7 16:24 android_source.zip
-rw-r--r-- 1 runner docker 24458990 May  7 16:23 godot-lib.template_release.aar

[Alex2782]

Tested: target=template_debug arch=arm64 on Samsung Tab S7
The code looks good to me, Android (3, 4,) 5, 6 support removed.

---

The issue was caused by our version of zipalign

Note: new editor version required, Export / Remote Deploy not compatible with v4.4.1.stable.official [49a5bc7].

[Calinou]

I think this is reasonable for 4.5. Devices that can only run Android 5 or 6 are likely too slow to run Godot 4.5 projects with decent performance anyway (even in Compatibility).

[akien-mga]

For the record, Unity seems to have 23 as their min SDK currently: https://docs.unity3d.com/6000.1/Documentation/Manual/android-requirements-and-compatibility.html

I'm still on the fence on whether we should optionally keep support for SDK 21 for users who want it and would compile their own templates for OpenGL ES only games. But I agree with Calinou that such old devices typically don't have the specs to run Godot 4 apps decently (Godot 3.x with OpenGL ES 2.0 can still be a viable option).

So I'd say let's go ahead with this change, and if we see significant pushback, we can consider bringing back compile-time support for SDK 21 while keeping SDK 24 as the default for official builds.

[syntaxerror247]

Code changes looks good!

[syntaxerror247]

So I'd say let's go ahead with this change, and if we see significant pushback, we can consider bringing back compile-time support for SDK 21 while keeping SDK 24 as the default for official builds.

I'm fine with bumping the minsdk to 24, but just to clarify: bringing back support for SDK 21 won't be trivial after this PR, as future changes will no longer guarantee compatibility with lower API levels, and this PR also removes the fallback code used for SDK 23 and below.

[akien-mga]

So I'd say let's go ahead with this change, and if we see significant pushback, we can consider bringing back compile-time support for SDK 21 while keeping SDK 24 as the default for official builds.

I'm fine with bumping the minsdk to 24, but just to clarify: bringing back support for SDK 21 won't be trivial after this PR, as future changes will no longer guarantee compatibility with lower API levels, and this PR also removes the fallback code used for SDK 23 and below.

Yeah it would imply partially reverting some of the changes in this PR, and possibly add a CI job that builds for SDK 21 so we make sure new PRs don't forget to add version checks when using > 21 APIs. As we see in this PR currently it's only a handful of APIs that are impacted so it shouldn't be too difficult (but of course as time passes we'll want to make use of more modern APIs, increasing the pressure on our lower baseline).

[Repiteo]

Thanks!