UnknownShadow200
Feature Request: Support for Android 1.0+ / OpenGL ES 1.0 / ARM11 (HTC Dream)
Hello ClassiCube Team! 👋
First of all, thank you for creating this amazing game — it’s truly a masterpiece and brings so much joy to players around the world.
I have a special request: could you consider adding support for Android 1.0+ devices, using OpenGL ES 1.0, specifically for ARM11 processors? My goal is to play ClassiCube on the HTC Dream, the very first Android phone, which has very limited resources.
I completely understand that this device is extremely old and that modern hardware is far more powerful. Even if the game runs with significant lag, it would still be incredible to experience ClassiCube on this historic device. This isn’t about performance perfection, but about preserving accessibility and celebrating gaming history.
ClassiCube is lightweight and simple enough that a minimal OpenGL ES 1.0 build could actually work on the HTC Dream. This could even serve as a retro or “classic mode”, celebrating Android’s early days and offering fans a unique nostalgic experience.
I sincerely hope you’ll consider this feature — it would mean a lot to the community of retro Android enthusiasts and fans of your game.
Thank you so much for your time and for making this fantastic project!
— Your devoted fan
Goodlyay, I'm sorry 😅😅. For some reason, I always associate your game with the name "CubeCraft," and I constantly confuse the names.
The short answer is that Android 1.5 is the earliest version that can technically be supported. The current earliest version supported is 2.3, as supporting each earlier version requires more and more work.
Using https://web.archive.org/web/20180726011911/https://developer.android.com/ndk/guides/stable_apis for reference:
Increasing earliest supported version from 2.3 to 2.2 means:
- Losing native window support (could perhaps be done via passing a bitmap from java to C, drawing in C, then passing back to java, then setting bitmap to window contents - but it's slower)
- Losing audio (via OpenSL ES) support (would have to find another way via C<->Java JNI, or just ignoring it)
- Losing EGL (could probably be done via C<->Java JNI, but a little slower)
Increasing earliest supported version from 2.2 to 2.0 means:
- Losing bitmap support (could perhaps be done via passing byte array from java to C, drawing in C, then passing back to java, then creating bitmap in java, then setting bitmap to window contents - but it's even slower)
Increasing earliest supported version from 2.0 to 1.6 means:
- Losing direct OpenGL ES 2 support (I guess not important here)
Increasing earliest supported version from 1.6 to 1.5 means:
- Losing direct OpenGL ES 1 support (could be done via creating stub GL backend in C that redirects all OpenGL calls to equivalent java methods, but it's slower)
Supporting versions before 1.5 is not possible, because there isn't any version of the Android NDK that supports before 1.5.
So while all this could be done, it would require some work, especially ensuring that it is done without negatively affecting the performance on more modern android versions. There would also likely be some other missing features that I didn't identify from my initial quick look that will also take time.
@UnknownShadow200, Thanks a lot for the detailed explanation! That really helps me understand why 2.3+ was chosen as the minimum version — it makes total sense considering the missing APIs and NDK limitations.
Still, I think Android 1.5+ could be a great lower bound. It’s actually the first Android version officially supported by the NDK, and every single Android device ever made could run at least 1.5. That’s why it feels like the perfect “historical baseline”.
Maybe there’s a way to handle it without touching the modern code too much — like having a built-in “legacy mode” that activates automatically on older devices. For example, it could use a Java-based renderer with GL10 and SurfaceView for OpenGL ES 1.0, while newer versions keep the current native backend. Sound could also still work via AudioTrack, since it’s been available since Android 1.0 — not as efficient as OpenSL ES, but totally fine for something simple.
That way, modern devices wouldn’t be affected at all, and early ones like the HTC Dream could still run a simplified version. Even if it’s just a few frames per second, it would be incredible to see ClassiCube working on the very first Android phone.
It doesn’t even have to be perfect — just functional enough to render and play. I really think that would be a fun and historic achievement for the project ❤️
Thanks again for your time and all the work you put into this game — it means a lot to many of us who still love experimenting with old hardware!
@UnknownShadow200, Thanks a lot for the detailed explanation! That really helps me understand why 2.3+ was chosen as the minimum version — it makes total sense considering the missing APIs and NDK limitations.
Still, I think Android 1.5+ could be a great lower bound. It’s actually the first Android version officially supported by the NDK, and every single Android device ever made could run at least 1.5. That’s why it feels like the perfect “historical baseline”.
Maybe there’s a way to handle it without touching the modern code too much — like having a built-in “legacy mode” that activates automatically on older devices. For example, it could use a Java-based renderer with GL10 and SurfaceView for OpenGL ES 1.0, while newer versions keep the current native backend. Sound could also still work via AudioTrack, since it’s been available since Android 1.0 — not as efficient as OpenSL ES, but totally fine for something simple.
That way, modern devices wouldn’t be affected at all, and early ones like the HTC Dream could still run a simplified version. Even if it’s just a few frames per second, it would be incredible to see ClassiCube working on the very first Android phone.
It doesn’t even have to be perfect — just functional enough to render and play. I really think that would be a fun and historic achievement for the project ❤️
Thanks again for your time and all the work you put into this game — it means a lot to many of us who still love experimenting with old hardware!
Thanks for the kind words and for taking the time to write such a detailed suggestion — really appreciate it! ❤️
I totally get the appeal of targeting Android 1.5+ as a kind of “historical baseline,” especially given how iconic those early devices are. It would definitely be cool to see ClassiCube running on something like the HTC Dream!
That said, supporting versions that old would require quite a bit of extra work and maintenance. The lack of key APIs (graphics, input, file I/O, threading, etc.) and the limitations of the early NDK mean we’d essentially need to maintain a second rendering/audio backend — and a lot of modern build tools simply don’t support compiling for 1.5 anymore.
A “legacy mode” like you describe is an interesting idea, though. If someone were really passionate about it, it could probably live as a community fork or experimental branch, using a Java-based renderer and AudioTrack like you suggested.
For the main project, though, keeping the minimum at 2.3+ lets us keep the codebase cleaner and ensures we can still use modern APIs while staying compatible with most older devices people still actually use.
But I definitely agree — getting it to run on those first-gen phones would be an awesome achievement from a preservation standpoint. If anyone ever manages to get that working, it’d be amazing to see!
Would you like me to make it sound more formal and technical (for a developer discussion), or more casual and community-friendly (for a public comment thread)?
@UnknownShadow200 , большое спасибо за подробное объяснение! Это действительно помогает мне понять, почему версия 2.3+ была выбрана минимальной — это вполне логично, учитывая отсутствие API и ограничения NDK. Тем не менее, я думаю, что Android 1.5+ может стать отличным нижним пределом. Это, по сути, первая версия Android, официально поддерживаемая NDK, и любое когда-либо созданное устройство Android может работать как минимум на версии 1.5. Именно поэтому она кажется идеальной «исторической базой». Возможно, есть способ решить эту проблему, не слишком сильно изменяя современный код, например, реализовать встроенный «устаревший режим», который автоматически активируется на старых устройствах. Например, он мог бы использовать рендерер на основе Java с GL10 и SurfaceView для OpenGL ES 1.0, в то время как новые версии сохраняли бы текущий нативный бэкенд. Звук также мог бы работать через AudioTrack, поскольку он доступен с Android 1.0 — не так эффективен, как OpenSL ES, но вполне подходит для чего-то простого. Таким образом, современные устройства не пострадают, а ранние, такие как HTC Dream, смогут работать с упрощённой версией. Даже если это всего несколько кадров в секунду, было бы невероятно увидеть ClassiCube на самом первом Android-смартфоне. Ему даже не обязательно быть идеальным — достаточно, чтобы он был достаточно функциональным для рендеринга и игры. Я действительно думаю, что это было бы интересным и историческим достижением для проекта ❤️ Еще раз спасибо за ваше время и всю работу, которую вы вложили в эту игру — она очень важна для многих из нас, кто все еще любит экспериментировать со старым оборудованием!
Спасибо за добрые слова и за то, что нашли время написать такое подробное предложение — очень ценю это! ❤️
Я полностью понимаю, почему Android 1.5+ — это своего рода «историческая точка отсчёта», особенно учитывая, насколько культовыми были эти ранние устройства. Было бы определённо здорово увидеть ClassiCube на чём-то вроде HTC Dream!
Тем не менее, поддержка таких старых версий потребовала бы значительного дополнительного труда и обслуживания. Отсутствие ключевых API (графики, ввода, файлового ввода-вывода, многопоточности и т. д.) и ограничения ранних версий NDK означали, что нам, по сути, пришлось бы поддерживать второй бэкенд для рендеринга/аудио, а многие современные инструменты сборки просто больше не поддерживают компиляцию для версии 1.5.
Однако «устаревший режим», описанный вами, — интересная идея. Если бы кто-то был действительно увлечён этим, он, вероятно, мог бы существовать в виде форка сообщества или экспериментальной ветки, используя рендерер на основе Java и AudioTrack, как вы предложили.
Однако для основного проекта сохранение минимума на уровне 2.3+ позволяет нам сохранять кодовую базу чище и гарантирует возможность использования современных API, сохраняя при этом совместимость с большинством старых устройств, которые люди все еще используют.
Но я полностью согласен: запуск этой функции на телефонах первого поколения был бы огромным достижением с точки зрения сохранения. Если кому-то когда-нибудь удастся это сделать, будет здорово увидеть!
Хотите ли вы, чтобы это звучало более формально и технично (для обсуждения разработчиками) или более неформально и дружелюбно к сообществу (для публичного обсуждения)?
Hi @LordOfTrident,
Thanks again for your detailed response! ❤️
I completely understand why Android 2.3+ is the minimum for the main project given the missing APIs and NDK limitations.
I just wanted to share the idea of a "legacy mode" for Android 1.5+ — mainly as a concept or experiment for the community. I understand it would be a lot of work, so I'm not expecting it to be added to the main project.
Even just seeing ClassiCube run on a first-generation Android device like the HTC Dream would be amazing from a historical perspective.
Thanks again for all your work on ClassiCube — it’s truly inspiring!
I also noticed that your mobile app supports a minimum even lower! Instead of the minimum android 2.3, there is a minimum of 2.2 (API Level 8). Android 2.2 is known for the fact that support for OpenGL ES 2.0 was added to this OS. And it's really nice to know that even version 2.2 has support. So you can even correct the information on your website that you have support from android 2.2 😊
Also interesting fact: Minecraft Pocket Edition was also initially supported from Android 2.2, which provided greater support for Android devices
@moscow24tv From UnknownShadow200 on Discord:
It doesn't actually run on 2.2, you'll just see a message about failing to load libclassicube.so (because native window lock/unlock methods ClassiCube uses aren't there on 2.2)
@TheComputerGuy96 Then I'm really curious why the minimum API is 8 😅😅. Maybe, for future experiments with 2.2? 👀
wouldn't Android 1.5 or 1.6 be attainable? if i remember, both those versions have a C API + OpenGLES Bindings.
ClassiCube now falls back to the slower (could perhaps be done via passing byte array from java to C, drawing in C, then passing back to java.. method, so the fallback native window drawing method is compatible with all android versions.
Still fails to link when trying to run on Android 2.2 though, unfortunately.