Are there any known issues with an SDL 2.26.2 Android app running on a (64-bit x86) Chromebook? My app contains an x86-64 binary, but I’ve received a report of it not working properly on that platform.
My apps works on my Chromebook without any x86 binaries.
Is your Chromebook ARM or x96? I wouldn’t want to ‘solve’ the problem by removing the x86 binaries completely and relying on ARM emulation. In any case I have a couple of genuine Android devices with x86 CPUs which benefit from those binaries.
Is your app on Google Play? The crash logs there will tell you which architecture has the problem.
I can tell you with 100% certainty that you don’t need to include x86. Google stats tell me my apps are targeting all Chromebooks without any issues. My most popular app has 700 new downloads every day - if there was a problem running on any Chromebook, it would show up.
What benefit does the x86 ABI provide?
Speed and accuracy.
Firstly, running ARM code via emulation on an x86 CPU obviously involves a big overhead, so isn’t desirable if performance is important.
Secondly, when my app runs on an x86 it takes advantage of the 80-bit extended-precision floats available, so I get much better numeric precision and a much bigger numeric range.
I would turn the question around: what’s the disadvantage of supporting all four Android ABIs: x86-32, x86-64, arm-32 and arm-64?
Just curious, does your Android app actually use the FPU on x86? The x86-64 ABI documentation says that floating point code should use SSE for floating point instead of the old 387 FPU, and none of the SSE registers are 80-bit. Compiler Explorer confirms it: GCC, Clang, and MSVC all generate code that uses SSE instead of the FPU when targeting x86-64.
Interestingly, when compiling for plain old x86 (32-bit), MSVC will still generate code that uses SSE instead of the FPU unless you explicitly tell it not to.
edit: even if your app isn’t using the FPU, including an x86 and x86-64 binary still provides the benefit of not needing emulation/translation.
Absolutely. For example PRINT PI produces 3.141592653589793238 (when asked to print that many digits) on a Lenovo x86-32 Android phone, you won’t get that from a 64-bit double! I’ve tried several other x86-32 Android devices and they all work the same (e.g. a Tesco Hudl2 tablet).
But you’re absolutely right that this seems to be at the heart of why my app isn’t running properly on the Chromebook. Although my binary uses 80-bit long doubles (both GCC and Clang support that datatype) the 64-bit C library being used on the Chromebook seemingly doesn’t!
That makes the Chromebook unique, in my experience, in having an x86-64 CPU but no support for 80-bit long doubles in the C library. Other x86-64 platforms (Windows, MacOS, Linux) do of course have full support for that datatype in their runtime libraries. Many applications requiring higher precision or wider numeric range rely on it.
I will probably have to ‘downgrade’ my app to use only 64-bit doubles on the Chromebook, despite having a CPU which can do much better. I just need to find a way to detect that condition at runtime.
Ah, you’re explicitly using long double, which always gets handed off to the 387 FPU (because of its 8-bit precision), even when compiling for x86-64. For float or double it uses SSE.
1 Like
Is there any way, in SDL, to tell whether an Android app is running on a Chromebook? I’m guessing not, but there are a number of reasons why it would be useful:
- On Android my app runs fullscreen by default, but it would be better not to on a Chromebook so as not to cover the task bar and title bar.
- Since the Chromebook has a keyboard,
SDL_StartTextInput()may need to be called differently. - Handling of the accelerometer may need to be different, since (on my Asus Chromebook anyway) it’s in the base rather than the screen.
This article suggests it would be difficult to implement such a test reliably.
That’s great, but the more I play with it the more I’m not sure it’s what I really want.
The main feature of the Chromebook which affects how my app should behave is the physical keyboard, but it’s a touchscreen Chromebook with a tablet mode (when the screen is folded right back) and in that state I want it to behave like a normal touchscreen device. SDL_IsChromebook() still returns true of course.
Similarly, it’s possible to connect an external keyboard (e.g. Bluetooth) to an Android mobile device, and in that case I would ideally want my app to behave like it does when running on the Chromebook. So it’s more the presence of a physical keyboard that is relevant, is there an SDL function which will tell me that?
I don’t know if I’m missing something obvious, but I can’t make my app work sensibly on the Chromebook.
On desktop platforms, and in a browser (via Emscripten), SDL gives me normal keyboard input via SDL_TEXTINPUT events and at at the same time allows me to test the keyboard asynchronously using the array returned from SDL_GetKeyboardState().
But with my Android build running on the Chromebook I seem to be able to get either SDL_TEXTINPUT events (after calling SDL_StartTextInput()) or test the keyboard state asynchronously (after calling SDL_StopTextInput()) but not both at the same time!
I hope this isn’t a fundamental limitation of SDL2 when running as an Android app on a Chromebook.