InputDevice.SOURCE_CLASS_* are one bit
More readable to check that the source has this class_joystick set,
compared to the other statements, where the source is gamepad or dpad.
(Clean-up from bug 3958)
by checking Android_Window validity
- SDLThread: user application is exiting:
SDL_VideoQuit() and clearing SDL_GetVideoDevice()
- ActivityThread is changing orientation/size
surfaceChanged() > Android_SetScreenResolution() > SDL_GetVideoDevice()
- Separate function into Android_SetScreenResolution() and Android_SendResize(),
formating, and mark Android_DeviceWidth/Heigh as static
This also solves reports of this log message:
"INFO: The key you just pressed is not recognized by SDL. To help get this
fixed, please report this to the SDL forums/mailing list
<https://discourse.libsdl.org/> EVDEV KeyCode 330"
(EVDEV KeyCode 330 is BTN_TOUCH.)
Fixes Bugzilla #4147.
- If you call onPause() before CreateWindow(), SDLThread will run in infinite loop in background.
- If you call onPause() between a DestroyWindow() and a new CreateWindow(), semaphores are invalids.
SDLActivity.java: the first resume() starts the SDLThread, don't call
nativeResume() as it would post ResumeSem. And the first pause would
automatically be resumed.
- Currently, it tries to Attach the JVM first and update the thread local storage, which are two operations.
Now, it simply gives back the JNI Env stored for the thread.
- Android_JNI_SetupThreadi() should only be used for external.
For internal SDL thread, it's already called in RunThread() (SDL_systhread.c),
and other thread are Java threads which don't need to be attached. i
(even if it doesn't hurt to do it, since it's a no-op).
- JNI_OnLoad is filled with pthread_create, GetEnv, AttachCurrentThread...
It's called for all shared libraries which may don't want this setup,
and loading libraries can be also modified to be done from a static context,
or with relinker. So it's not really clear how, who and what it sets up.
=> Reduce this function to the minimal
SDLThread is a Java Thread, it's not needed to call 'Detach' from the JVM.
Clear mThreadKey, so that the pthread_create destructor is not called for this
thread.
SDLActivity thread priority is unchanged, by default -10 (THREAD_PRIORITY_VIDEO).
SDLAudio thread priority was -4 (SDL_SetThreadPriority was ignored) and is now -16 (THREAD_PRIORITY_AUDIO).
SDLThread thread priority was 0 (THREAD_PRIORITY_DEFAULT) and is -4 (THREAD_PRIORITY_DISPLAY).
Can be check by adding in build.grable:
gradle.projectsEvaluated {
tasks.withType(JavaCompile) {
options.compilerArgs << "-Xlint:unchecked" << "-Xlint:deprecation"
}
}
SDLActivity.java:1691: warning: [deprecation] A_8 in PixelFormat has been deprecated
case PixelFormat.A_8:
SDLActivity.java:1694: warning: [deprecation] LA_88 in PixelFormat has been deprecated
SDLActivity.java:1697: warning: [deprecation] L_8 in PixelFormat has been deprecated
SDLActivity.java:1700: warning: [deprecation] RGBA_4444 in PixelFormat has been deprecated
SDLActivity.java:1704: warning: [deprecation] RGBA_5551 in PixelFormat has been deprecated
SDLActivity.java:1716: warning: [deprecation] RGB_332 in PixelFormat has been deprecated
- destroy Android_ActivityMutex
- display any SDL error message that may have occured in this thread,
since SDL_GetError() is thread specific, and user has no access to it.
In the usual case, first call to onNativeOrientationChanged() is done before
SDL has been initialised and would just set an error message
"Video subsystem has not been initialized" without sending the event.
First error could happen if Android_SetWindowFullscreen somehow gets
called between SurfaceDestroyed() and SurfaceCreated()
Second error should not happen has native_window validity is guaranteed.
(It would happens previously with error -19)
It accesses data->native_window, which can be changed by onNativeSurfacedChanged().
Currently, Android_SetWindowFullscreen() may access data->native_window after it
has been released, and before a new reference is acquired.
(can be reproduced by adding some SDL_Delay() in onNativeSurfacedChanged and
Android_SetWindowFullscreen() ).
Default launch mode (standard) allows multiple instances of the SDLActivity.
( https://developer.android.com/guide/topics/manifest/activity-element#lmode )
Not sure this is intended in SDL as this doesn't work. There are static
variables in Java, in C code which make this impossible (allow one android_window) and
also Audio print errors.
There is also some code added in onDestroy as if it would be able to
re-initialize: https://hg.libsdl.org/SDL/rev/27686adb08c3
Bug Android activity life-cycle seems to show there is not transition to get out
of onDestroy()
https://developer.android.com/reference/android/app/Activity#ActivityLifecycle
( can be tested with "adb shell am start my.package.org/.MainActivity"
and "adb shell am start -n my.package.org/.MainActivity" )
Send me a message if there are real use-case for this !
Make sure there is not pending Pause accumulated, so the the application doesn't
remain paused and stucked in onDestroy().
Can be tested by adding:
SDLActivity.nativePause();
SDLActivity.nativePause();
mSingleton.finish();
Doesn't seem to happen manually, but symetrical to the pause handling.
Can be tested by adding:
mNextNativeState = SDLActivity.NativeState.PAUSED;
handleNativeState();
mNextNativeState = SDLActivity.NativeState.RESUMED;
handleNativeState();
mNextNativeState = SDLActivity.NativeState.PAUSED;
handleNativeState();
mNextNativeState = SDLActivity.NativeState.RESUMED;
handleNativeState();
Before, it ends in 'paused' state.
Now, it ends in 'resumed' state.
Sylvain Becker
Ryan C. Gordon
Sam Lantinga