I tried to install it using the signed apk I got via the instructions at Unable to install Android gtk4-demo APK - #3 by CodedOre.
However, the apk fails to install on an Android 8 phone.
I tried to install it using the signed apk I got via the instructions at Unable to install Android gtk4-demo APK - #3 by CodedOre.
However, the apk fails to install on an Android 8 phone.
$ apktool d app-arm64-v8a-release-signed.apk
$ cd app-arm64-v8a-release-signed/
$ ls -p
AndroidManifest.xml apktool.yml assets/ lib/ original/ res/ smali/
$ grep SdkVersion apktool.yml
minSdkVersion: '31'
targetSdkVersion: '35'
Mapping SDK version to Android version from here, minimum Android 12 is needed.
I think this will not work on Waydroid either, because I get the same error there. (Well yes, because it runs Android 9)
I do not understand why this backend cannot or would not support Android 8.
Because it’s experimental, and the only person working on it is using SDK 31 as the baseline.
If you want to help out, feel free to clone GTK and work on increasing the backward compatibility. Asking other people to spend time on it (or, worse, complaining that you’re not getting their time for free) is not really how things work in free and open source software.
If resources are scarce, then I would have probably just done a normal JS/HTML/CSS backend for generating a GUI for Firefox on Android, but have it obey some GTK-style API when coding it on the desktop.
I have no idea what you think GTK even is, so I don’t understand your comment.
Well, my use case was to be able to build for Android from Gnome Builder, regardless of whether Android implements GTK. So I thought, why not just mimic a GTK-like API and then enable the creation of GTK-lookalike GUIs for Firefox on Android using HTML/CSS/JS? Then we could have a GTK-React or whatever.
Judging from the development of, for example, Xamarin, React Native, and Kotlin Multiplatform, I would speculate that this project may not have enough resources to support a fully native implementation. On the other hand, WebGL and WebGPU have become very performant.
I would be happy just with a GObject and GTK mapping to JavaScript and the Firefox API on Android.
However, there is already a thread for this: Why not a GNOME "app engine"? - #2 by CodedOre
Judging from the development of, for example, Xamarin, React Native, and Kotlin Multiplatform, I would speculate that this project may not have enough resources to support a fully native implementation.
GTK-on-Android is fundamentally different from Xamarin, React Native, etc.
Those libraries are wrappers around a platform’s native UI library. Let’s say you use a React Native TextInput
component. On Android devices, React Native will create an Android native EditText
widget using Android’s native GUI toolkit. On iOS devices, React Native will instead create an iOS native UITextField
using iOS’s native GUI toolkit. This is, to say the least, difficult because React Native is trying to straddle the requirements of two very different GUI toolkits.
GTK-on-Android is not using Android’s native GUI library. GTK is its own complete GUI library. It just asks Android for a blank window, and then GTK does the rest of the work. This is a lot more feasible because there’s no need to bridge two different and incompatible GUI libraries together.
If it draws using OpenGL ES, then it should be even simpler to manage compatibility, because there are fewer versions of OpenGL ES than Android SDK.
Rendering is just a single part of what a GTK backend does.
If you understand how Android works, and you want to contribute to the GTK support for Android, please feel free to clone the GTK repository and start working on it. You can join the GTK room on Matrix.
Otherwise, you should really not opine on what’s “simple”.