Разработка под android ndk

Сборка бинарных файлов Android с помощью исходников и Android NDK. Прокачиваем утилиту screencap

Я занимаюсь автоматизацией Android устройств и часто SDK или ОС Android не имеют нужного функционала или его работа выполняется медленно/очень медленно.

Используя возможности Native Development Kit (NDK) мы можем написать функционал, который будет выполняться быстрей, чем тот же функционал на Java. За счет данного кита мы можем добавлять в свое приложение код, написанный на C/C++ или создавать свои бинарные файлы под мобильные Android устройства.

В данной статье я расскажу каким образом мы можем настроить компиляцию бинарного файла под ОС Android, а так же покажу процесс, как мы можем дополнить функционал уже существующих бинарных файлов в этой ОС.

Для примера я «прокачаю» screencap, который сможет не только получать скриншот всего экрана или выдавать «сырые данные», но и возвращать цвет пикселя по указанной точки или получать изображение только нужной области. Итак, поехали!

Установка NDK

Скачиваем Android NDK и распаковываем архив или устанавливаем через SDK Manager.

Если еще нет, то можете добавить доп. инструменты:

И создаем «проект» под архитектуру вашего мобильного устройства:

Так как у моего HOMTOM HT16 архитектура armeabi-v7a то я буду использовать команду:

И ждем, пока скрипт создаст все необходимые файлы (до 5 мин. примерно).

Проверка на работоспособонсть

Создадим файл hello_world.c с простым кодом:

И попробуем его скомпилировать:

С помощью атрибута -o указываем имя файла, а с помощью ключа -pie мы указываем, что бинарный файл PIE и все его зависимости загружаются в случайные расположения в виртуальной памяти каждый раз, когда приложение выполняется.

Если компиляция прошла успешно, то заливаем файл на телефон:

И попробуем бинарник:

Если вы увидели вывод фразы «hello world» — значит вы всё сделали правильно!

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

Для определения архитектуры можете выполнить команду

Исходники и библиотеки

Так как анализ скомпилированного бинарного файла очень затратно по времени, а Android является открытой системой, то почему бы не воспользоваться этим качеством!

Заходим сюда и ищем нужную версию Android. Ну а так уже — скачиваем архив и ищем нужный исходник бинарного файла. Хотя, конечно же есть вариант — Google и «правильный запрос».

В моем случае нужный мне файл находится по этой ссылке.

Частично разберем данный код.

DEFAULT_DISPLAY_ID — идентификатор дисплея, с которого необходимо получить скриншот. В нашем случае 0.

flinger2skia и vinfoToPixelFormat — отвечает за определение, в каком формате должно быть изображение.

notifyMediaScanner — после того, как изображение будет создано в файловой системе необходимо послать broadcast, чтобы файл смог корректно отображаться. Если не вызывать данный broadcast, то не все приложении смогут увидеть созданный файл.
Функция main не является сложной для «чтения», поэтому разберем только важные моменты, которые непосредственно отвечают за получение данных о изображении.

/dev/graphics/fb0 — это так называемый framebuffer. Framebuffer — это область видеопамяти для кратковременного хранения одного или нескольких видеокадров. Исходя из кода main видно, что существуют версии Android устройств, которые хранят изображение экрана в этом файле. Таким образом, если вы «счастливчик», то узнав vinfo.xoffset и vinfo.yoffset (в большинстве случаев они будут равны 0) и используя консоль вы с легкостью сможете получить информацию о цвете:

В моём случае оказалось все не так просто и данный файл не содержать какую либо информацию о изображении.

screenshot.update — это второй способ, как можно получить изображение. Данная функция имеет несколько перегруженных методов с которыми можно ознакомиться тут.

Рассмотрим описание функции с самым большим количеством параметров:

display — ссылка на необходимый display.
sourceCrop — кроп выбранной области изображения. Может содержать координаты верхней левой точки и нижней правой (всего 4 параметра xLeft, yTop, xRight, yBottom). Начальная точка координат — верхний левый угол.
reqWidth — ширина возвращаемого изображения
reqHeight — высота возвращаемого изображения
minLayerZ и maxLayerZ — как именно работают данные параметры не удалось понять. Перебор значений выдавал иногда черный кран
useIdentityTransform — Если true, то отключает слой наложения поверх приложений, т.е. тех Activity, которые используют ACTION_MANAGE_OVERLAY_PERMISSION
rotation — поворот изображения.

Таким образом, чтобы нам получить цвет пикселя, нам необходимо задать xLeft и yTop, сдвинув их на 1, т.к. отсчет будет идти с 0, а указанные координаты установить в xRight, yBottom. В reqWidth и reqHeight установить значение равным 1. Изменяя параметры данной функции мы сможем определять границы нужной для нас области.

Компиляция базового screencap.cpp

На самом деле это самая сложная часть, которая может занять несколько дней или целую неделю. К сожалению мне не удалось найти каких-то быстрых решений сборки новой версии screencap в сети, поэтому пришлось конкретно помучаться с clang’ом и его параметрами.

Если вы сразу же попробуете скомпилировать данный код, компилятор будет постоянно ругаться, что нет какого-то файла, а иногда может и сообщить, что файл то есть, но вот нет нужного конструктора.

Поэтому, первоначально я добавил все файлы, которые отсутствовали в библиотеке NDK. Ошибки дают представления, где примерно должен находиться тот или иной файл. Для этого, вам необходимо добавить недостающие файлы, а чтобы узнать где находится sysroot (директория, где ищет clang), можно воспользоваться следующей «фичей»:

В ошибке будет виден путь до данной директории. Если clang у вас находится в другом месте — измените путь до него.

Обращаемся к Google и ищем все необходимые файлы. В моем случае пришлось добавить следующие директории и файлы:

И казалось бы, что вот он успех, все что надо добавлено. Выполняем компиляцию

и получаем ужасный результат:

По мне, это был реальный ад, т.к. множество файлов имело ошибки, чего по идее быть не должно, ведь содержимое данных файлов не менялось. На данном этапе я на долго «присел» и начал активно гуглить ошибки, но нужного ответа не нашел. Каким образом я решил поизучать туториал по clang я уже не помню, но это решение меня спасло!

Как оказалось, у clang есть параметр (а точнее у ld) —unresolved-symbols, который отвечает за работу с неразрешенными (unresolved) символами. Хотя по самой ошибки и не скажешь, что дело в этом. Добавляем параметр и выполняем компиляцию снова:

Наконец-то компиляция прошла успешно! На самом деле, я уже думал, что большая часть проблем ушла, но не тут то было. Начали появляться ошибки, наподобие следующей:

Как оказалось, компилятору было достаточно наших добавленных файлов, но на Android устройстве все эти файлы хранятся в .so библиотеках. Позже разобравший более менее хорошо в этом вопросе, я нашел относительно простой способ поиска необходимых библиотек. Для этого нужно открыть бинарных файл screencap, который находится на Android-устройстве (/system/bin/screencap) в текстовом редакторе и посмотреть все названия .so библиотек, которые используются в данном файле. В моем случае вот эта часть:

Вы можете сравнить данную часть с вашим скомпилированным файлом и найти, каких же библиотек вам не хватает. В данном случае ими оказались: libgui.so, libui.so, libcutils.so, libutils.so, libbinder.so, libskia.so. Ищем их расположение (на самом деле, они находятся в одном и том же месте):

Выполняем копирование на sdcard/libs всех библиотек (пример для libskia.so):

Используя adb pull копируем файлы с моб. устройства на компьютер:

Располагаем их в нужной для вас директории и выполняем компиляцию, но уже с новым параметром *.so, который указывает на то, что нужно так же использовать все .so библиотеки при сборке, а точнее — указать ссылки на них в файле.

Теперь и компиляция пройдет успешно и запуск бинарного файла на моб. устройстве будет без ошибок.

Заключение и результат

Как вы могли заметить, добавление своего функционала «в чужой код» является не очень простым занятием.

Измененный код файла screencap приведен ниже. Сборка его происходит таким же образом, как и оригинального. Добавленные изменения думаю будут понятны большинству читателей, поэтому решил его не комментировать.

Пример получения цвета пикселя:

Пример получения изображения по заданной области:

Данный проект залит на GitHub, так что кому интересно — заходите.

Источник

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 код по обработке нажатий на кнопки писать не буду, ибо это тривиальная задача. В любом случае, если понадобиться, можете посмотреть в исходниках к статье. В логе будет вот что:

Источник