Android ndk с library

Сборка open-source библиотек на Android NDK

В процессе работы с Android NDK я столкнулся с проблемой сборки уже существующих Linux библиотек на Android NDK. Так как материала не слишком много в этой статье поделюсь своим опытом. В Андроиде я новичек, так что если найдете ошибки — пишите:)

Чтобы пример был не самым простым и при том полезным — возьмём библиотеку libFLAC. Этот даст возможность декодировать .flac файлы. По данному мануалу, я надеюсь, соберутся большинство других библиотек.

Кроме неё нам понадобится:

• Android NDK, r5b (http://developer.android.com/sdk/ndk/index.html)
• libOgg (http://www.xiph.org/downloads/)
• libVorbis (там же, где и libOgg).

Создание проекта

Создаём стандартный Android проект, в нем создаём папку jni и распаковываем туда libogg, libvorbis, libflac.

Сборка

Приступим к первому этапу. Для сборки я использовал такой скрипт:

Для libVorbis придется его немного изменить:
LDFLAGS будет таким:

Для libflac изменим добавим в libs -lvorbis.

Рассмотрим структуру скрипта по порядку. Строка export CC — путь к компилятору Android NDK. Тут: export LDFLAGS можем задавать директории, где искать библиотеки, а в LIBS подключать их. В этой строке: export CPPFLAGS подключаем headers дополнительных библиотек.

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

Подготовка Android.mk

Итак, для начала создадим Android.mk, вида:
include $(all-subdir-makefiles)
В папках: jni, jni/libogg, jni/libflac, jni/libvorbis
Этот скрипт означает, что будут подключены все Android.mk в поддиректориях.

Для создания Android.mk в папках jni/libogg/src, jni/libvorbis/lib, jni/libflac/src будем использовать все Makefile.am в тех же папках.

jni/libogg/src

В Makefile.am ищем строки:
libogg_la_SOURCES = framing.c bitwise.c — это все что нам надо. Получаем стандартный Android.mk вида:

Думаю тут объяснять ничего не надо. Идём дальше.

jni/libvorbis/lib

Тут тоже все просто. Находим строку: libvorbis_la_SOURCES и подулючаем все файлы, что там есть. Получаем такой Android.mk:

jni/libflac/src

Процесс тот же, но файлов намного больше и они в поддиректориях. Я решил все что есть собрать в одну библиотеку, чтоб было проще, поэтому получил такой скрипт:

NDK BUILD

Выполняем ndk-build (этот скрипт находится в папке NDK) и видим что все компилируется, но flac даёт следующую ошибку:
/home/user/workspace/w/testOGG/jni/flac-1.2.1/src/libFLAC/format.c:60: error: ‘VERSION’ undeclared here (not in a function)
/home/user/workspace/w/testOGG/jni/flac-1.2.1/src/libFLAC/format.c:66: error: expected ‘,’ or ‘;’ before ‘VERSION’
make: *** [/home/user/workspace/w/testOGG/obj/local/armeabi/objs/FLAC/libFLAC/format.o] Ошибка 1
Проблема в том, что константа VERSION определена в makefile, который мы не подключали. Самым простым выходом я вижу создать эту константу в самом format.c вот так:
#define VERSION «1.2.1»
Все теперь ошибок нет. При компиляции получаем:
Install : libFLAC.so => libs/armeabi/libFLAC.so
Install : libogg.so => libs/armeabi/libogg.so
Install : libvorbis.so => libs/armeabi/libvorbis.so
В каталогах должны появится такие файлы и папки:

Теперь осталось последнее — протестировать все ли работает. Я переделал на скорую руку из стандартных примеров декодирования аудио через libflac. Декодировал из flac файла в wav. Так как код скрипт великоват вы можете протестировать работу на этом apk:тестовый apk файл
(чтоб все сработало, надо чтоб в sdcard был файл output.flac с:
05-20 14:18:42.783: INFO/FLAC(427): sample rate: 44100 Hz
05-20 14:18:42.783: INFO/FLAC(427): channels: 2 Hz
05-20 14:18:42.783: INFO/FLAC(427): bits: 16 Hz, он будет перекодирован в test2.wav. При работе программы ничего писать не будет (только в логи). Протестировано на эмуляторе, HTC Wildfire и Samsung galaxy tab (везде Android 2.2). Процесс занял не более минуты при работе с 20 мегабайтным flac файлом. По окончанию работы отобразится Hello world.
Вот исходники всего проекта:
исходники
Удачи!

Источник

Gamedev suffering

Блог о разработке игр и серверных технологиях

Основы Android NDK: работа с C/C++ кодом

Использование нативного кода, написанного на C или С++ — это тема, которую многие разработчики не затрагивают вовсе. Но порой использование C++ в приложениях намного упрощает/ускоряет разработку. В этой статье будут рассмотрены основные принципы работы с native кодом.

Предварительная настройка

Если у вас ещё не настроен Eclipse, то читаем как настроить Eclipse для работы с Android. Только помимо того, что в статье сказано, при установке ещё необходимо выбрать и установить NDK плагин.

Так же вам необходимо установить CDT для Eclipse. Под Виндой вам вроде как ещё понадобиться установить Cygwin.

Теперь необходимо создать проект и прописать пути.

• Создать Android Application.
• Eclipse -> Window -> Preferences -> Android -> set path to SDK
• Eclipse -> Window -> Preferences -> Android -> NDK -> set path to the NDK
• Нажмите правой кнопкой мыши на проект и выберите Android Tools -> Add native support

В проекте будет создана папка jni, где вы должны размещать файлы с C++ кодом. В ранних версиях был баг, когда Eclipse не мог верно настроить пути до некоторых хэдеров из NDK. В последней версии всё нормально. Просто очистите проект (Clean project), а затем перестройте его (Build project).

Зачем нужен NDK?

Думаю, необходимо предварительно объяснить, когда вообще стоит (и стоит ли?) использовать ndk. Многие советуют использовать C++, когда требуются какие-то большие/сложные вычисления. Что значит сложно? =/ В общем, лучше назову конкретные случаи, когда использование NDK оправдано:

• Работа с OpenGL ES. Думаю, большинство тех, кто использует NDK, юзают его как раз для написания игр.
• Использование кросс-платформенных движков, вроде кокоса.
• Самый очевидный случай — это когда вам надо использовать уже написанный на C++ код. За десятилетия на C++ уже куча всего написано. Зачем переписывать такие вещи на Java, если можно просто использовать эти Open Source наработки. Да и не всё можно переписать, думаю тот же openCV бессмысленно бы было переписывать, в том время когда можно просто подключить готовые исходники.

Возможности NDK огромны. Вы можете из Java вызывать C++ методы. В то же время, вам ничто не машет вызывать Java методы из C++. Даже есть возможность создавать приложение практически без использования Java, используя NativeActivity (API 9 и выше).

Java. Путешествие в Native (или туда и обратно).

Да простит меня профессор за упоминание его работы (: И так, рассмотреть всё в рамках одной статьи невозможно. Поэтому, для начала реализуем лишь вызов native методов из Java.

Перечислю кратко основные моменты при работе с native:

• Создание файлов с C++ кодом.
• Определение C++ методов для экспорта.
• Создание .mk файлов.
• Генерация библиотеки.
• Подключение библиотеки в Java и вызов C++ методов.

Создание файлов с C++ кодом

В native определим всего 3 метода: передача строки, изменение строки, получение строки.

Создадим для начала файл def.h, подключим пару нужных файлов и определим методы для вывода в консоль.

Создадим файл MyNative.h и определим в нём спецификации методов для экспорта, чтоб вызывать их из Java кода потом.

Теперь все три метода можно вызвать из Java кода. Я этот код ручками писал. Но можно заюзать javah, которая будет сама генерить эти заголовки. extern «C» нужен, чтобы компилятор C++ не менял имена объявленных функций.

Стоит немного сказать про наименование методов. Java_ — обязательный префикс. ru_suvitruf_androidndk, так как у нас пакет ru.suvitruf.androidndk, ну а дальше наименование класса и метода на стороне Java. В каждой функции в качестве аргумента имеется JNIEnv* — интерфейс для работы с Java, при помощи него можно вызывать Java-методы, создавать Java-объекты. Второй обязательный параметр — jobject или j class — в зависимости от того, является ли метод статическим. Если метод статический, то аргумент будет типа jclass (ссылка на класс объекта, в котором объявлен метод), если не статический — jobject — ссылка на объект, у которого был вызван метод.

Ну и создадим MyNative.cpp с реализацией методов.

Работа с Application.mk

В этом файле описаны глобальные настройки для сборки либы.

Работа с Android.mk

Здесь указываем параметры/настройки по линковке и прочее, чтобы собрать либу.

В Android.mk вообще есть не мало всяких флагов и прочего. Можно добавлять в сборку уже готовые библиотеки и т.д. В следующих статьях напишу, как это делается.

После того, как вы создали C++ файлы и .mk сделали, можно забилдить проект, тогда в папке obj появится библиотека libAndroidNDK.so.

Подключение библиотеки в Java и вызов C++ методов.

Теперь остаётся только написать Java код. Сделаем простенькое приложение. Разместим поле для ввода текста, три кнопки (передача текста в native, изменение текста в native и возврат изменённой строки из native) и поле для нового текста, который получили из native кода.

Для того, чтобы использовать native методы создадим класс AndroidNDK.

Этот код выполнит загрузку нашей библиотеки, в которой реализованы методы. Обратите ещё раз внимание на этот класс и методы и вспомните наименование методов при экспорте в native коде: Java_ru_suvitruf_androidndk_AndroidNDK_ChangeString.

Java код по обработке нажатий на кнопки писать не буду, ибо это тривиальная задача. В любом случае, если понадобиться, можете посмотреть в исходниках к статье. В логе будет вот что:

Источник

Использование NDK в Android Studio

В настоящее время среди Android-девелоперов большую популярность имеет среда разработки Android Studio, основанная на IntelliJ IDEA от JetBrains. Однако, при использовании данной IDE, могут возникнуть проблемы при разработке приложений, использующих нативный код, так как Android NDK рассчитан преимущественно на использование IDE Eclipse и ADT.

Цель данной статьи — подробное описание процесса создания Android-приложения, использующего NDK в Android Studio, в частности — предложение достаточно простой и эффективной конфигурации gradle (системы сборки пакетов, используемая в Android Studio), гарантирующей включение нативных библиотек в APK-файл. Также статья включает краткую инструкцию работы с NDK в IDE Eclipse и введение в нативную разработку, достаточное для написания первого приложения.

Данная статья предназначена преимущественно для начинающих разработчиков. Описанное решение не является единственным, но оно достаточно удобно, особенно для тех, кто работал с NDK в Eclipse. Если кому-то из читателей объяснение покажется слишком подробным, то в конце статьи есть краткое резюме, описывающее лишь алгоритм требуемых действий без комментариев к каждому шагу.

Так как существует множество статей, описывающих работу с NDK, я не буду использовать в качестве примера сложные библиотеки, а ограничусь лишь самым простым примером hello-jni. Исходный код данного примера можно найти в каталоге /samples/hello-jni

В среде Eclipse особых проблем с использованием NDK не возникало. Каталог проекта выглядит примерно так:

Рис.1 Главный каталог проекта для Eclipse

Нас интересуют каталоги jni и libs. Каталог jni содержит исходные коды на нативных языках (*.c; *.cpp), заголовочные файлы (*.h), makefiles (*.mk). Долго останавливаться на предназначении данных файлов не буду, так как этому посвящено немало материалов и статей. Упомяну лишь, что jni означает java native interface. Именно через этот интерфейс производится вызов нативных процедур из кода на java. Поэтому не забывайте подключать библиотеку в ваши c/c++ файлы и помните о правильном синтаксисе функций, которые будут вызываться через jni. Например, в моём случае приложение имеет package name:
evi.ntest
поэтому описание функции выглядит так:

где jstring — название типа данных c, соответствующего типу string в java, Java — в данном случае служебный префикс, показывающий язык, из которого будет вызвана функция, evi_ntest — имя пакета, который будет вызывать функцию, MainActivity — имя активити, из которой будет вызываться функция, stringFromJNI — название функции.
В java-коде описание данной функции выглядит гораздо проще:

Не забывайте также указывать используемые файлы кода в .mk файлах. Для начала можете воспользоваться .mk файлами из примеров NDK, модифицируя названия файлов, но в дальнейшем рекомендую изучить их структуру.

Каталог libs содержит готовые бинарные библиотеки для различных архитектур процессоров (по умолчанию — armeabi). Динамическая библиотека представляет собой файл с расширением .so, статическая — файл с расширением .a. Для получения данных библиотек требуется компиляция исходных кодов с помощью Android NDK. В Unix-системах (в моём случае — Mac OSX) для этого требуется в терминале ввести следующие строчки:

При этом NDK автоматически компилирует исходные коды из папки jni и помещает полученные библиотеки в libs/armeabi (также можно с помощью параметров командной строки задать компиляцию под x86, mips, arm v7-neon процессоры).
При использовании Windows потребуется воспользоваться дополнительными утилитами, возможно — плагинами для MS Visual Studio.
В любом случае, не имеет значения, каким именно способом получены готовые библиотеки, важен факт, что если в папке с проектом находится подкаталог libs, Eclipse при сборке автоматически включает его содержимое в APK-файл.

Так как данная статья посвящена лишь основам работы с NDK, то на этом введение в программирование на нативных языках под android я закончу. Для более подробного ознакомления с принципами нативной разработки рекомендую изучить примеры из каталога /samples/, а также читать статьи, в том числе и на русском языке. Пример хорошей статьи о Android NDK на русском языке, советую обратить внимание (написана не мной):

Перехожу к основному разделу статьи — настройке IDE Android Studio для работы с нативным кодом.

Среда Android Studio по умолчанию собирает APK с помощью gradle. Данный сборщик имеет широкие возможности кастомизации, но при стандартных настройках gradle не включает нативные библиотеки в APK-файл.

Рассмотрим частичную структуру проекта в Android Studio:

Рис.2 Путь к исходному коду проекта Android Studio.

При работе у меня возникло логичное желание разместить папку jni в каталоге src/main, так как именно там хранятся все остальные файлы с исходным кодом. Разумеется, читатель может размещать каталог jni там, где ему удобно. Главное — не забыть собрать бинарные библиотеки с помощью NDK (повторюсь, в UNIX системах для этого нужно в терминале перейти к каталогу, содержащему jni, затем вызвав исполняемый файл ndk-build, лежащий в папке с NDK, прописав полный путь к нему в этом же терминале, в MS Windows нужно использовать дополнительные утилиты). Проблема же заключается в том, что по умолчанию gradle не будет упаковывать в APK библиотеки.

Однако gradle несложно настроить на включение в сборку java-библиотек (файлов *.jar). Стоит заметить, что jar-файлы представляют собой zip-архивы, содержащие какие-либо ресурсы, а также объектный код. Таким образом, для включения бинарных библиотек *.so и *.a достаточно упаковать их в jar-файл.
Делается это так:

• Переименовываем папку libs, содержащую наши бинарные библиотеки в lib
• Сжимаем данную папку любым zip-архиватором
• Меняем расширение полученного файла на .jar

Полученную библиотеку можно подключить на этапе сборки проекта, при этом полученный APK-файл будет включать двоичные библиотеки, а приложение — вызывать процедуры, написанные на нативном коде.
Данный вопрос не раз обсуждался на различных англоязычных форумах, например Stack Overflow:
stackoverflow.com/questions/16667903/android-studio-gradle-and-ndk
Однако, данная информация достаточно краткая, разрозненная и требует от читателя определённых знаний синтаксиса gradle. Цель моей статьи – предоставить читателям подробное русскоязычное объяснение, доступное даже тем, кто только начал работать с Android Studio и gradle.

Давайте рассмотрим 2 способа упаковки библиотек: ручной и автоматический.

Ручной способ упаковки:

Данный способ весьма неудобен, однако имеет место на существование. Допустимый случай применения на практике: наличие готовой библиотеки и отсутствие необходимости её изменять. В таком случае, описанные ниже операции потребуется выполнить лишь один раз.

Откройте build.gradle, находящийся по адресу » / Project/ /», в моём случае:

Рис.3 Местонахождение конфигурируемого файла build.gradle.

Данный файл изначально выглядит приблизительно так:

В самом низу есть раздел dependencies. Туда следует добавить такую строчку:

compile fileTree(dir: ‘src/main/’, include: ‘*.jar’)

Рассмотрим эту команду: gradle в ходе компиляции будет вынужден включить дерево файлов (структуру файлов и папок, соответствующих заданной маске ), расположенное по адресу ‘src/main/’ (т.е. в том каталоге, где расположены исходные коды, а также созданный нами jar файл), при этом в качестве маски использован параметр ‘*.jar’, т.е. включатся будут все файлы с таким расширением. Обратите внимание, что в данном случае путь считается относительно месторасположения файла build.gradle.
В результате выполнения данной команды gradle распакует jar-файл и включит двоичные библиотеки в APK-файл.

Ознакомтесь с модифицированным файлом build.gradle, что бы не перепутать dependencies и buildscript.dependencies.

Читатель скорее всего подметит, что данный способ весьма неудобен при наличии необходимости частых изменений в нативном коде, так как после каждой перекомпиляции необходимо удалять старый jar-файл, переименовывать папку libs в lib, архивировать её, менять расширение архива. Поэтому воспользуемся мощью gradle и автоматизируем процесс.

Сборщик пакетов gradle позволяет создавать задания (функции), также в его возможности входит создание различных типов архивов, в том числе zip. Воспользуемся этим и добавим в build.gradle (расположение данного файла рассмотрено выше) такие строчки:

Данный отрывок кода можно добавить в любую часть файла, кроме существующих разделов, например в конец файла. Я поместил их перед разделом dependencies.
Этот код включает в себя task, который создает в папке build, находящийся по адресу » / Project/ /» подкаталог native-libs, в этой подпапке создается файл native-libs.jar, структура файла соответствует требуемой структуре java-библиотеки, содержащей бинарные библиотеки .so. Если Вы планируете использовать также статические библиотеки .a, то вместо строки:

from fileTree(dir: ‘src/main/libs’, include: ‘**/*.so’)

Вам следует использовать:

from fileTree(dir: ‘src/main/libs’, include: ‘**/*.*’)

Далее остается добавить в раздел dependencies строку:

compile fileTree(dir: «$buildDir/native-libs», include: ‘native-libs.jar’)

В ходе сборки эта команда включит содержимое созданной программно библиотеки native-libs.jar в APK-файл.

Пример build.gradle с данным кодом:

Обратите внимание, что у меня дирректории jni, libs расположены по адресу » / Project/ /src/main». Если в Вашем проекте эти папки лежат в другом месте, то Вам следует учесть это в формировании путей для всех команд.

Если всё сделано правильно, то Android Studio в ходе сборки проекта автоматически создаст в каталоге build правильную библиотеку и включит её в готовую программу. Таким образом, после каждой перекомпиляции нативного кода отпадает необходимость совершения каких-либо дополнительных действий и настроек, gradle сделает всё сам.

Теперь, как и было обещано в начале статьи, краткое резюме, описывающее лишь полный алгоритм без лишних комментариев:

Краткое резюме

1. Открываем папку » / Project/ /src/main» и создаём там подпапку jni.
2. Открываем файл » / Project/ /build.gradle», модифицируем раздел dependencies, после чего добавляем туда код:

Для включения также статических библиотек *.a (при их наличии) меняем строку

from fileTree(dir: ‘src/main/libs’, include: ‘**/*.so’)

from fileTree(dir: ‘src/main/libs’, include: ‘**/*.*’)

В подпапке jni размещаем файлы *.mk, *.h, *.c, пишем нативный код.

Открываем папку » / Project/ /src/main» в терминале.

Вводим в терминале команду /ndk-build

Запускаем проект.

Важно!
Данная инструкция предназначена для операционных систем Unix (в моём случае — MacOSX). Для операционной системы MS Windows пункты 4 и 5 не актуальны, так как для компиляции нативных библиотек требуются дополнительные утилиты. Также, скорее всего, будет целесообразным изменить пути хранения библиотек на более удобные и учесть это в скрипте сборки.

На этом я завершаю статью и откланиваюсь. Надеюсь, кому-то данная статья сэкономит время.

Удачного Вам нативного программирования, главное — каждый раз не забывайте себя спрашивать, стоит ли использовать нативный код. Вполне могут быть java-аналоги, использование которых проще, а в большинстве случаев – лучше, так как сокращается время разработки, улучшается понимаемость кода другими, снижается сложность архитектуры приложения, а мощности современных устройств хватает на выполнение большинства задач даже в Dalvik VM.

Источник