Add CameraFeed support for Android

[shiena]

Separated and reorganized the Android implementation from #98416.

Updated the minimum target API level from 21 to 24 because camera2 NDK requires Android API level 24 or higher.
Additionally, updated AndroidManifest.xml to enable camera usage in the Godot editor for Android.

[Alex2782]

#98416 (comment)
#98416 (comment)

Were these comments also taken into account in this PR?

/home/runner/work/godot/godot/platform/android/java/editor/src/horizonos/AndroidManifest.xml Error:
	uses-sdk:minSdkVersion 23 cannot be smaller than version 24 declared in library [:lib] /home/runner/work/godot/godot/platform/android/java/lib/build/intermediates/merged_manifest/editorDebug/AndroidManifest.xml as the library might be using APIs not available in 23
	Suggestion: use a compatible library with a minSdk of at most 23,
		or increase this project's minSdk version to at least 24,

---

I think we can increase minSdkVersion, it only affects 0.09% (Godot Android Editor. Exported apps could be more)

[m4gr3d]

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

There may be value in bumping the min sdk version, but it should not be done in this PR as it would require discussions and alignments.
Instead, can you update your logic to disable the CameraFeed when the device is running on an unsupported version.
You can see examples for doing so in

godot/platform/android/java_godot_view_wrapper.cpp

Line 43 in 1a1cc0f

int android_device_api_level = android_get_device_api_level();

[m4gr3d]

Is there a reason 270 and 90 are inverted?

[m4gr3d]

Can you validate the issue raised in #98709 for the use of windowManager.getDefaultDisplay().getRotation() doesn't apply here as well.

[shiena]

Instead, can you update your logic to disable the when the device is running on an unsupported version.
You can see examples for doing so in CameraFeed

@m4gr3d

Since the Camera2 API is part of the Android NDK, targeting API levels below 24 will result in compile errors if you attempt to link against it directly, as the symbols are only available from API level 24. A simple runtime API level check won't prevent these compile-time issues.

Are you planning to use:

1. Preprocessor directives (e.g., #if #if __ANDROID_MIN_SDK_VERSION__ >= __ANDROID_API_N__ ... #endif)?
2. Or dynamically load the functions using dlopen/dlsym at runtime?

Which approach are you considering?

[m4gr3d]

Since the Camera2 API is part of the Android NDK, targeting API levels below 24 will result in compile errors if you attempt to link against it directly, as the symbols are only available from API level 24. A simple runtime API level check won't prevent these compile-time issues.

@shiena I didn't realize it was only introduced in the NDK since API level 24 as described in https://developer.android.com/ndk/guides/stable_apis#camera

Are you planning to use:

1. Preprocessor directives (e.g., #if #if __ANDROID_MIN_SDK_VERSION__ >= __ANDROID_API_N__ ... #endif)?
2. Or dynamically load the functions using dlopen/dlsym at runtime?

Which approach are you considering?

There are workarounds described in https://developer.android.com/ndk/guides/using-newer-apis, but I'm not sure the added complexity cost is warranted.

cc @syntaxerror247 @Alex2782 @akien-mga We may need to bump the min version to 24 if we want a simple integration of this feature.
On the plus side, this would align our min sdk version with our min vulkan version which is currently set at 24.

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 device.. though Android 7 (api level 24) is now 9 years old.

My preference would be to make the bump to api version 24, primarily to ensure vulkan is available on all api versions we support.
If we're aligned with making the bump, we should do it in a separate PR and clean up the separate vulkan min sdk version logic we have.

[RubenGarcia]

I´ve seen other PRs using #defines, so I recommend using that for now, and they can be removed once the change to level 24 is approved. That should also fix the failing test.

[syntaxerror247]

I´ve seen other PRs using #defines, so I recommend using that for now, and they can be removed once the change to level 24 is approved. That should also fix the failing test.

No, I wouldn’t request any further work from the author until we decide whether or not to bump the api version.

[syntaxerror247]

On the negative side, this removes support for 1.3% Android device.. though Android 7 (api level 24) is now 9 years old.

We could consider using API guards https://developer.android.com/ndk/guides/using-newer-apis#avoiding_repetition_of_api_guards. It might take some effort, but it's probably the best alternative to raising the min-sdk.

That said, I’m also in favor of bumping it to 24, just a bit hesitant given that it would drop support for about 1.3% of devices.

[akien-mga]

It's something that should be done in a separate PR, but yeah I think it's probably time now to bump the min SDK to 24, at least by default.

Maybe we can preserve support for 21 via a few defines and a SCons argument, so that users who really want to support the oldest devices, and don't care about 24+ APIs like CameraFeed, could still compile their own templates. If that doesn't make things too complex.

[Alex2782]

A Scons argument sounds good if someone still needs it.

We discontinued Android 5 and 6 support for our (non-Godot) app two years ago since they accounted for just 0.5% of users on the Google Play Store back then. (Active installations of our app)

[m4gr3d]

I have created #106148 to bump the min supported version. Let's continue the discussion for that topic in that PR.