Создаем Java обертку для C++ класса в Android приложении, а также реализуем обратные вызовы из нэйтива

Кратко расскажу о себе и о том, зачем возникла необходимость в подобном. Я более десяти лет пишу приложения под Android, около 5 лет под IOS, и сейчас переношу свои наработки под десктопы. Приложения мои предназначены для сисадминов, это SSH клиент, сетевые сканеры и тд. В общем, самое сложное - не сам интерфейс, а то, что под капотом. Когда я лишь начинал, я думал, что остановлюсь на платформе Android и стал пилить все на Java. Но затем осознал свою ошибку и исправил ее. На данный момент все мои приложения состоят из двух частей: общего для всех систем ядра на С++ и платформозависимого интерфейса, написанного на Java/Swift/C++ в зависимости от системы. Оговорюсь сразу, эта статья будет лишь своего рода вступлением. Я покажу, как работать с объектно-ориентированным кодом на C++ в Java оболочке (в JNI нам доступен экспорт С функций). Инициализировать объект, делать из него вызовы, удалять, при этом имея аналогичный класс в оболочке, будто бы наш код был написан на Java. Задача эта не слишком сложная, но прежде чем опытные прогеры закрыли эту статью, я оговорюсь, что в следующей части мы уже будем работать с каллбэками - вызовами Java листенеров из нашего С++ кода, а вот это уже задача совсем нетривиальная, требующая понимания работы JNI и Dalvik. Но обо всем по порядку. Итак, у нас есть некий CPP класс и Java оболочка. Через JNI мы можем вызывать только С-функции, то есть не объектный код. Так как же нам работать с ООП? Главная проблема - не столько вызовы, сколько хранение адреса объекта нативного класса. Лично для себя я нашел решение - хранить его в Java классе, как long. То есть, у нас получается приблизительно такой код:

https://habr.com/ru/articles/1017486/

#Java #C++ #ООП #Dalvik #JNI #android

🚀 Just released smali-lsp!

A Language Server for Smali with:
• Goto definition
• Cross-references
• Symbols & hover
• Works with any IDE (minimal setup)

Also includes an MCP server → plug into AI agents for faster APK analysis 🤖

🔗 https://github.com/Surendrajat/smali-lsp

#AndroidDev #ReverseEngineering #MalwareAnalysis #LSP #InfoSec #RE #security #dalvik

Hello Johan 👋
Really appreciate your work and Gluon efforts in keeping JavaFX alive and bringing it to mobile 🚀
GluonFX + GraalVM is truly impressive.

I have a technical question:
With modern GluonFX builds, Android apps seem to support only **arm64-v8a** ABI.

Previously, with JavaFXPorts (javafxmobile plugin), both **armeabi-v7a** and **arm64-v8a** were supported.

@johanvos #JavaFX #Gluon #JavaFXMobile #GluonFX #SubstrateVM #dalvik #AndroidDev #GraalVM

Question to the #android and #java bubble:

my #android #app has a minSdkVersion of 14, with a targetSdk of 36.

Will setting source- and targetCompatibility to java version 11 (or above) make it fail to run on early #android versions like #kitkat (4.4.x)?

I wasn't able to find this out, since #android devices do not run a native #jre but #art or the predecessor #dalvik .

Do targetCompatibility and sourceCompatibility even matter at all in this case?