3DO и Android NDK и как бы во что не вляпаться…

[@keydon2]

Спасибо за статью!

[@vikarti]

проблемы с STL… а CrystaX NDK не пробовали для их решения использовать?

[@MaxAkaAltmer]

Не пробовал, но уже не хочется менять коней на на переправе, если только в новом проекте.

[@Thero]

круто! пусть с ошиками но статья классная! увы концепция работы устройства с андроид не совпадает с тем для чего создавались консоли… и гугл с каждой новой версией будет двигаться к оптимизации совсем другой парадигмы работы приложений, что затруднит работу эмуляторов, особенно портированных.

[@MaxAkaAltmer]

Что успел поправил, дальше мне карма не позволяет ошибки исправить.
Что как бы неправильно, статья-то моя и уже опубликована.

[@volkoff_roman]

return env->NewStringUTF(«Hello, World!»);

Обнять и плакать.
Android Studio, кстати, ещё и сигнатуры нативных функций неправильно генерирует. Так что лучше использовать javah.

[@Dimezis]

Весело :)

По поводу

Нежелания среды обновлять APK при изменениях в нативной библиотеке

У вас включен Instant run? Я у себя его отключаю, т.к. тоже подобные проблемы возникают иногда.

[@MaxAkaAltmer]

Спасибо! Реально помогло, я не знал про эту опцию, она не так давно появилась, похоже, она же и причина проблемы.
Я же больше искал проблему в Run|Debug configurations.

[@XProger]

Понимаю боль автора. Как-то однажды чуть не профукал сроки по конкурсу Павла Дурова, из-за того, что в последние 8 часов проект перестал собираться ссылаясь на ошибки во всех ресурсах, за 30 минут до сдачи уже отчаявшись и откатив код назад много раз обнаружил в имени одной png картинки «с» вместо «c».
Пробовал перейти с eclipse на новомодный Android Studio, но приключения с NDK начались ещё с примеров, которые отказались собираться… и я понял, что стар для всего этого, вернулся обратно на eclipse, там я хотя бы всех тараканов знаю в лицо.
Автору спасибо за описание особенностей и за то, что он делает, несмотря на низкую популярность консоли.

[@Dimezis]

проект перестал собираться ссылаясь на ошибки во всех ресурсах

Это из-за того, что невозможно было сгенерировать класс R.
А lint должен был говорить, что проблема в имени png, вы скорее всего просто не те логи смотрели.

[@mastermind88]

Вероятно, вы использовали STL, который поставляется вендором, вместо того, который входит в состав NDK — не надо так. Более того, в Android N это будет запрещено — android-developers.blogspot.ru/2016/06/improving-stability-with-private-cc.html.
Android Studio для нативной разработки не очень удобна, мы используем Tegra NSight.
Сейчас ситуация стала намного лучше, я помню времена, когда wchar_t был размером в 1 байт, а gdb приходилось вручную собирать и заливать на девайс :)

[@MaxAkaAltmer]

У меня были проблемы c LIBC (стандартной библиотекой языка С). С STL проблем не было.
wchar_t лучше не использовать, а загнать его в платформозависимые обертки, а то он где 4 байта, где 2, а где и 1 даже бывает.

[@khim]

wchar_t лучше не использовать, а загнать его в платформозависимые обертки, а то он где 4 байта, где 2, а где и 1 даже бывает.

Если бы всё было так просто. На старых версиях Android'а он 4-байтовый, но функции, которые теоретически с ним должны работать, считают что в нём один байт.

Всё просто: NDK в Android'е был изначально «дотянут» ровно до уровня запуска Dalvik'а — и не более того. Сейчас потихоньку дотачивают до POSIX'а, но когда будут все фишки — науке неведомо, скорее всего ещё несколько лет придётся мучиться.

[@mkarev]

JNIEXPORT jstring JNICALL Java_ru_arts_union_real3doplayer_NativeCore_stringFromJNI()

Мне больше нравится регистрить нативные методы в JNI_OnLoad
Отпадает необходимость в хардкорном именовании нативных методов.

По поводу stl — самая полная поддержка в LLVM libc++
Applicarion.mk
APP_STL := c++_static
APP_CPPFLAGS += -fexceptions
APP_CPPFLAGS += -frtti

Добавлю свои 5 копеек
Гении гугла во время миграции с Eclipse на IntelliJ IDEA похерили напрочь и без того тухлую поддержку NDK. Отлаженную систему сборки на основе Androig.mk (на которой сидит весь AOSP если что), заменили какой-то студенческой поделкой на базе неповоротливого gradle. В результате ниасилили сделать достойный аналог и убили то, что работало (работало в IDE, в консоли к счастью еще дышит). Но косяк, видимо, осознали и в новой версии обещали исправиться — вернуть Android.mk, а также добавить поддержку cmake. Выглядит очень заманчиво, но зная гугл, понимаю, что они снова могут все извратить.

Чего стоят новые самплы NDK, которые перенесли на github — это просто смешно смотреть, как они героически возводят костыли, чтобы поднять то, что раньше работало (сборка внешних зависимостей типа native app glue, cpu features и т.п.)

Тем не менее, стоит отдать должное Гуглу, они сделали все, чтобы зарплаты у нативных разработчиков под Андроид были высокими!

Да срать они хотели на поддержку NDK, при том что весь ведроид написан на кастрированном c++, а на яву торчат лишь вершки через jni прослойку.

[@MaxAkaAltmer]

Здесь сарказм. В том-то и прикол, если бы они обеспечили достойную поддержку NDK — зарплаты были бы пониже, т.к. порог вхождения уменьшился бы.