Repository navigation
Conversation
For every bootstrap that is not sdl2/sdl3, the android recipe defines SDL_ANDROID_GetJNIEnv as WebView_AndroidGetJNIEnv and pyjnius' genericndkbuild_jnienv_getter.patch makes jnius call the same symbol. Both then link against the bootstrap's main library: the android recipe via ANDROID_MAIN_LIB, pyjnius via PYJNIUS_ANDROID_LIBMAIN. The qt bootstrap builds libmain_<abi>.so from start.c alone, so nothing defines that symbol and the references to it from android._android and jnius cannot be resolved. pyjniusjni.c, which defines it, was duplicated byte for byte in the webview and service_only bootstraps. Move it next to start.c in common/ and list it in the qt bootstrap's LOCAL_SRC_FILES. sdl2 and sdl3 do not list it in their own Android.mk, so they never compile it and keep getting the JNIEnv from SDL. Qt reaches libmain_<abi>.so through QtLoader.loadMainLibrary(), which calls System.load()/System.loadLibrary(), so the JNI_OnLoad in pyjniusjni.c runs and caches the JavaVM.
Nothing in the tree reads them. ndk-build only ever includes files named
Android.mk: the jni/Android.mk and jni/application/Android.mk entry points
use $(call all-subdir-makefiles), which globs */Android.mk, and no makefile
includes Android_static.mk by name.
They are leftovers from the SDL android-project template, and they could not
work as written anyway: webview's links an SDL2_static module into a
bootstrap that builds no SDL, sdl3's asks for an SDL3_static module that the
SDL3 sources do not define, webview and service_only name a YourSourceHere.c
that does not exist, and four of the five end in the mangled
$(call import-module,SDL)LOCAL_PATH := $(call my-dir)
that SDL's own template already shipped with. Each new bootstrap has been
carrying the file forward since, most recently qt and sdl3.
|
coverage: 63.297%. remained the same — f321x:202610_qt_bootstrap_jnienv into kivy:develop |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For every bootstrap that is not sdl2/sdl3, the android recipe defines
SDL_ANDROID_GetJNIEnv as WebView_AndroidGetJNIEnv and pyjnius'
genericndkbuild_jnienv_getter.patch makes jnius call the same symbol. Both
then link against the bootstrap's main library: the android recipe via
ANDROID_MAIN_LIB, pyjnius via PYJNIUS_ANDROID_LIBMAIN.
The qt bootstrap builds libmain_.so from start.c alone, so nothing
defines that symbol and the references to it from android._android and
jnius cannot be resolved.
pyjniusjni.c, which defines it, was duplicated byte for byte in the webview
and service_only bootstraps. Move it next to start.c in common/ and list it
in the qt bootstrap's LOCAL_SRC_FILES. sdl2 and sdl3 do not list it in their
own Android.mk, so they never compile it and keep getting the JNIEnv from
SDL.
Qt reaches libmain_.so through QtLoader.loadMainLibrary(), which calls
System.load()/System.loadLibrary(), so the JNI_OnLoad in pyjniusjni.c runs
and caches the JavaVM.