3 ms·

You can technically create an Android app without any Java code. There are native APIs for graphics and input. However, as these are intended for games, you get

You can technically create an Android app without any Java code. There are native APIs for graphics and input. However, as these are intended for games, you get a window into which you can draw... something. With OpenGL, for example. You don't get access to Android's regular UI framework. You will also have to go through the Java layer to do many things you might want to do — like requesting permissions or launching other apps' activities. Here's all the APIs you get: https://developer.android.com/ndk/reference?hl=en https://developer.android.com/ndk/reference?hl=en

nologic01 3y ago
You can also "outsource" the Java based interaction with Android to somebody else, Qt style? https://doc.qt.io/qt-6/android-getting-started.html https://doc.qt.io/qt-6/android-getting-started.html
flohofwoe 3y ago
You can call into any Android Java API from native code using JNI. It's not exactly convenient, but you are not limited to the C APIs exposed by the NDK.
- grishka 3y ago
  Many Android APIs expect you to extend classes and implement interfaces for things like callbacks. You can't do that with JNI alone, you will have to have a .dex of your own anyway.
izacus 3y ago
That's not really what's going on. Those "native" APIs you mention in most cases just call back to Java APIs under the hood. For better or worse, most of what Android is is written in Java. There's no hidden "C++" layer of Android to access.
- okanat 3y ago
  In theory it is possible to write raw Binder calls to various Android services, skipping JNI in many places. However, it is basically rewriting the entire OS API and structure from scratch.
  - defer 3y ago
    You can generate binder wrappers from aidl, that would work. This is fairly common when doing platform work (for those like me who work on the operating system rather than on apps). However, this would be a terrible idea because usually the android api is stable at the Java wrappers (I.e. ActivityManager), not at the aidl level, which would make this very fragile for app development across a multitude of devices and platform versions.
  - izacus 3y ago
    Sure, and some NDK APIs do exactly that. But you're still just using IPC to call into services written in Java, just using a different approach.
- kllrnohj 3y ago
  > Those "native" APIs you mention in most cases just call back to Java APIs under the hood Some do, but most don't.

nologic01 3y ago

You can also "outsource" the Java based interaction with Android to somebody else, Qt style? https://doc.qt.io/qt-6/android-getting-started.html https://doc.qt.io/qt-6/android-getting-started.html

flohofwoe 3y ago

You can call into any Android Java API from native code using JNI. It's not exactly convenient, but you are not limited to the C APIs exposed by the NDK.

grishka 3y ago
Many Android APIs expect you to extend classes and implement interfaces for things like callbacks. You can't do that with JNI alone, you will have to have a .dex of your own anyway.

izacus 3y ago

That's not really what's going on. Those "native" APIs you mention in most cases just call back to Java APIs under the hood. For better or worse, most of what Android is is written in Java. There's no hidden "C++" layer of Android to access.

okanat 3y ago
In theory it is possible to write raw Binder calls to various Android services, skipping JNI in many places. However, it is basically rewriting the entire OS API and structure from scratch.
- defer 3y ago
  You can generate binder wrappers from aidl, that would work. This is fairly common when doing platform work (for those like me who work on the operating system rather than on apps). However, this would be a terrible idea because usually the android api is stable at the Java wrappers (I.e. ActivityManager), not at the aidl level, which would make this very fragile for app development across a multitude of devices and platform versions.
- izacus 3y ago
  Sure, and some NDK APIs do exactly that. But you're still just using IPC to call into services written in Java, just using a different approach.
kllrnohj 3y ago
> Those "native" APIs you mention in most cases just call back to Java APIs under the hood Some do, but most don't.