Thu, 18 Jun 2015 12:20:46 -0300Updated WhatsNew.txt's 2.0.4 list to include a more detailed set of changes for iOS, and added a couple missing items to the OS X and Windows sections.
Alex Szpakowski [Thu, 18 Jun 2015 12:20:46 -0300] rev 9757
Updated WhatsNew.txt's 2.0.4 list to include a more detailed set of changes for iOS, and added a couple missing items to the OS X and Windows sections.

Thu, 18 Jun 2015 00:44:57 -0400Moving some whitespace around to test something on the Mercurial server.
Ryan C. Gordon [Thu, 18 Jun 2015 00:44:57 -0400] rev 9756
Moving some whitespace around to test something on the Mercurial server.

Wed, 17 Jun 2015 21:05:25 +0200Android: Fixed two warnings.
Philipp Wiesemann [Wed, 17 Jun 2015 21:05:25 +0200] rev 9755
Android: Fixed two warnings.

Wed, 17 Jun 2015 13:02:41 -0400Whitespace fix.
Ryan C. Gordon [Wed, 17 Jun 2015 13:02:41 -0400] rev 9754
Whitespace fix.

Wed, 17 Jun 2015 12:59:12 -0400Removed Edgar's name from SDL_haptic.h at his request.
Ryan C. Gordon [Wed, 17 Jun 2015 12:59:12 -0400] rev 9753
Removed Edgar's name from SDL_haptic.h at his request.

Wed, 17 Jun 2015 00:07:45 -0700Partial fix for bug 2758 - Android issues with NDK r10c and API-21
Sam Lantinga [Wed, 17 Jun 2015 00:07:45 -0700] rev 9752
Partial fix for bug 2758 - Android issues with NDK r10c and API-21

Sylvain

When using API 21 and running on an old device (android < 5.0 ?) some function are missing.

functions are (at least) : signal, sigemptyset, atof, stpcpy (strcat and strcpy), srand, rand.


Very few modifications on SDL to get this working :

on SDL
======

Undefine android configuration :

HAVE_SIGNAL
HAVE_SIGACTION
HAVE_ATOF

In "SDL_systrhead.c", comment out the few block of lines with "sigemptyset".

Android.mk:
remove the compilation of "test" directory because it contains a few rand/srand calls

Also, there are more discussions about this in internet :
https://groups.google.com/forum/#!topic/android-ndk/RjO9WmG9pfE
http://stackoverflow.com/questions/25475055/android-ndk-load-library-cannot-locate-srand

Wed, 17 Jun 2015 00:00:53 -0700Fixed bug 2948 - [Android] Arrow keys from external keyboard are not received
Sam Lantinga [Wed, 17 Jun 2015 00:00:53 -0700] rev 9751
Fixed bug 2948 - [Android] Arrow keys from external keyboard are not received

Sylvain

http://developer.android.com/reference/android/view/InputDevice.html
int SOURCE_CLASS_JOYSTICK Constant Value: 16 (0x00000010)

int SOURCE_JOYSTICK Constant Value: 16777232 (0x01000010)
int SOURCE_KEYBOARD Constant Value: 257 (0x00000101)
int SOURCE_GAMEPAD Constant Value: 1025 (0x00000401)
int SOURCE_DPAD Constant Value: 513 (0x00000201)


I have an a PC keyboard that I connect to an android device.
The issue is that "arrow" keys gets lost.

More explanation:

This device gets detected twice by the java "pollInputDevices()" both as SOURCE_KEYBOARD and as a composite (0x1000311 == SOURCE_JOYSTICK | SOURCE_KEYBOARD | SOURCE_DPAD).
Because of being a SOURCE_CLASS_JOYSTICK, only the second entry is registered, and I opened it.


When I press one arrow key, the java method "onKey(...)" is called.
The Source "event.getSource()" is "SOURCE_KEYBOARD", so it enters this conditions :

if ( (event.getSource() & InputDevice.SOURCE_GAMEPAD) != 0 ||
(event.getSource() & InputDevice.SOURCE_DPAD) != 0 ) {


And then, it enters :

SDLActivity.onNativePadDown() (native code in "SDL_sysjoystick.c")


Since the "arrows" are viewed as "D-PAD", it gets translated :

int button = keycode_to_SDL(keycode);


But the android-java "event.getDeviceId()" is wrong: this is the one from the Keyboard, and not the one from the Joystick that I have opened.
So I don't get them through the Joystick interface.


And since, the keycode has been translated, it returns 0 and assume it was consumed.
So I lost the key in the function "Android_OnPadDown()"


Notice, It won't happen with other normal "letters" keys because they does not get translated by "keycode_to_SDL", so "Android_OnPadDown()" returns -1.
And then java code send the keys to "SDLActivity.onNativeKeyDown()".




Possible patch on "Android_OnPadDown" and also "Android_OnPadUp" (and maybe other functons):

85 int
186 Android_OnPadDown(int device_id, int keycode)
187 {
188 SDL_joylist_item *item;
189 int button = keycode_to_SDL(keycode);
190 if (button >= 0) {
191 item = JoystickByDeviceId(device_id);
192 if (item && item->joystick) {
193 SDL_PrivateJoystickButton(item->joystick, button , SDL_PRESSED);
194 }
+ else return -1;
195 return 0;
196 }
197
198 return -1;
199 }

It would allow the java caller function to send the key to "SDLActivity.onNativeKeyDown();"



Another solution, would be to replace:

if ( (event.getSource() & InputDevice.SOURCE_GAMEPAD) != 0 ||
(event.getSource() & InputDevice.SOURCE_DPAD) != 0 ) {

by

if ( (event.getSource() & InputDevice.SOURCE_CLASS_JOYSTICK) != 0)

Because only "SOURCE_CLASS_JOYSTICK" devices are registered/opened.

Tue, 16 Jun 2015 23:58:09 -0700Fixed bug 2949 - [Android] Virtual DPAD remote not registered
Sam Lantinga [Tue, 16 Jun 2015 23:58:09 -0700] rev 9750
Fixed bug 2949 - [Android] Virtual DPAD remote not registered

Sylvain

I have an android device to which I try to connect the google virtual remote application.
https://play.google.com/store/apps/details?id=com.google.android.tv.remote

The java method "pollInputDevices()" detects it as an input source 0x701 which is (SOURCE_KEYBOARD | SOURCE_GAMEPAD | SOURCE_DPAD).

It it not added because it does not AND-bitwise with "SOURCE_CLASS_JOYSTICK".
It's only a virtual DPAD and it works when checking also with SOURCE_CLASS_BUTTON

Tue, 16 Jun 2015 22:16:35 -0700Fixed bug 2774 - Android: screen distorted in Landscape after background/foreground
Sam Lantinga [Tue, 16 Jun 2015 22:16:35 -0700] rev 9749
Fixed bug 2774 - Android: screen distorted in Landscape after background/foreground

Sylvain

With a Landscape application.
Going to background with Home Key, then foreground.
The screen is distorted.

This has been reported by Samsung. It happens on S5 and Samsung Alpha, see the video attached.

I have captured the following logcat:

V/SDL (20549): onResume()
V/SDL (20549): surfaceCreated()
V/SDL (20549): surfaceChanged()
V/SDL (20549): pixel format RGB_565
V/SDL (20549): Window size:1920x1080
I/SDL (20549): SDL_Android_Init()
I/SDL (20549): SDL_Android_Init() finished!
V/SDL (20549): SDL audio: opening device
V/SDL (20549): SDL audio: wanted stereo 16-bit 22.05kHz, 256 frames buffer
V/SDL (20549): SDL audio: got stereo 16-bit 22.05kHz, 1764 frames buffer
V/SDL (20549): onWindowFocusChanged(): true
V/SDL (20549): onWindowFocusChanged(): false
V/SDL (20549): onPause()
V/SDL (20549): nativePause()
V/SDL (20549): surfaceDestroyed()

Background / Foreground

V/SDL (20549): onResume()
V/SDL (20549): surfaceCreated()
V/SDL (20549): surfaceChanged()
V/SDL (20549): pixel format RGB_565
V/SDL (20549): Window size:1080x1920
V/SDL (20549): surfaceChanged()
V/SDL (20549): pixel format RGB_565
V/SDL (20549): Window size:1920x1080
V/SDL (20549): onWindowFocusChanged(): true
V/SDL (20549): nativeResume()



This seems to be related to the fact that I have in "AndroidManifest.xml":
android:configChanges="..."
Because of the fields: "orientation" and also "screenSize".


I have looked for another way to solve the issue. Discarding the "surfaceChanged" call, based on the "requestedOrientation" and the new Orientation. It seems to be better.


On my failing test case, the first "surfaceChanged()" is discarded. Sometimes the "focusChanged()" might appear between the two "surfaceChanged()", while the surface is not yet ready. Thus, discarding also the "nativeResume()".

So, for robustness, a call to "nativeResume()" is added at the end of "surfaceChanged()".

Some update:

1/ First I tried, to discard the surface using the current orientation (rather than width / heigh). -> that solve the issue sometimes, but not always.

2/ Samsung Certification now accepts my application that were previously failing.

3/ I personally now owns a Samsung S5, and was able to solve the issue on my side.

4/ I now use the patch and get no complaints from my users. (but I admit, nobody seemed to be complaining before neither...).

5/ I have added a v2 because of a new smart-phone called "Black Berry Passport" that has a square screen of 1440x1440. This screen has a "status bar" so the resolution is in fact : 1440x1308. (as reported by "surfaceChanged").

Problem is: the portrait resolution is in fact a Landscape!

So the "v1" patch is always discarding the "surface" of BlackBerry Passport. Which is terribly bad.


Hence, I added the "v2" patch not to discard the surface when aspect ratio is < 1.20. (BB 1440/1308 is : 1.1009). Which seems fair.

Tue, 16 Jun 2015 20:28:21 +0200Moved entry in WhatsNew.txt because it was already in 2.0.0 for Android and iOS.
Philipp Wiesemann [Tue, 16 Jun 2015 20:28:21 +0200] rev 9748
Moved entry in WhatsNew.txt because it was already in 2.0.0 for Android and iOS.