Собственные API

На этой странице представлен обзор библиотек, включенных в NDK, со ссылками на соответствующие части справочника по API NDK и руководства, где они существуют.

Используйте собственные API

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

1. Укажите системе сборки ссылку на библиотеку.

   • Если вы используете ndk-build : добавьте библиотеку в LOCAL_LDLIBS в свой Android.mk . Обратите внимание, что вы удаляете ведущую lib и вместо этого говорите -l . Например, чтобы связать libfoo и libbar , вы должны написать: makefile LOCAL_LDLIBS := -lfoo -lbar

     Дополнительные сведения о LOCAL_LDLIBS см. в документации Android.mk .

   • Если вы используете CMake : следуйте инструкциям в документации Studio по добавлению API NDK .

2. #include соответствующие заголовки из вашего кода.

Обратите внимание, что API, более новые, чем minSdkVersion вашего приложения, не будут вызываться по умолчанию, и вместо этого вы должны использовать их через dlopen() и dlsym() . Более простой подход см. в разделе Использование новых API .

Ядро C/С++

библиотека C

Стандартные заголовки библиотеки C11, такие как <stdlib.h> и <stdio.h> доступны как обычно.

Обратите внимание, что в Android, в отличие от Linux, нет отдельных библиотек libpthread или librt . Эта функциональность включена непосредственно в libc , и ее не нужно явно связывать.

Для математических функций существует отдельная libm (следуя обычной традиции Unix), но, как и libc она автоматически компонуется системами сборки.

Функциональность динамического компоновщика в <dlfcn.h> такая как dlopen(3) и dlsym(3), доступна, но вы должны явно связать его с libdl .

Библиотека: libc / libm / libdl

библиотека С++

Доступна поддержка C++17. Дополнительные сведения о поддержке библиотек C++ см. в разделе Поддержка библиотек C++ .

Ведение журнала

<android/log.h> содержит API для регистрации в logcat.

Примечание. <android/log.h> предоставляет только примитивы журналирования. Примеры более удобных API см. в журналах Android log/log.h и android-base/logging.h .

Доступно начиная с уровня API 3.

Библиотека: liblog

Ссылка: Ведение журнала

След

Собственный API трассировки <android/trace.h> предоставляет собственный эквивалент класса android.os.Trace на языке программирования Java. Этот API позволяет отслеживать именованные единицы работы в вашем коде, записывая события трассировки в системный буфер трассировки. Затем вы можете собирать и анализировать события трассировки с помощью инструмента Systrace .

Доступно с уровня API 23.

Библиотека: libandroid

Руководство: встроенная трассировка

сжатие zlib

Вы можете использовать библиотеку сжатия Zlib , включив <zlib.h> и связав ее с libz .

NDK всегда включает последние файлы заголовков zlib на момент выпуска, а libz.a включенный в NDK для статического связывания, всегда имеет одну и ту же версию, но libz.so для динамического связывания поступает с устройства и может быть любой версии. оказался выпущен на этом устройстве. В частности, это означает, что заголовки, на основе которых вы создавали, не соответствуют версии zlib на устройстве, поэтому здесь особенно важны обычные предупреждения против предположений о деталях реализации. Нам не известно о каких-либо проблемах с общедоступным API, но, в частности, структура структуры со временем изменилась и, вероятно, будет продолжать меняться. Обратите внимание, что новый API в более поздних версиях zlib, очевидно, не будет доступен в версиях ОС, предшествующих API. Всех этих проблем можно избежать (за счет увеличения размера APK), всегда используя статический libz.a вместо libz.so

Доступно начиная с уровня API 3 (но см. примечание выше).

Библиотека: libz

Графика

OpenGL ES 1.0–3.2

Стандартные заголовки OpenGL ES 1.x ( <GLES/gl.h> и <GLES/glext.h> ), заголовки 2.0 ( <GLES2/gl2.h> и <GLES2/gl2ext.h> ), заголовки 3.0 ( <GLES3/gl3.h> и <GLES3/gl3ext.h> ), заголовки 3.1 ( <GLES3/gl31.h> и <GLES3/gl3ext.h> ) и заголовки 3.2 ( <GLES3/gl32.h> и <GLES3/gl3ext.h> ) содержат объявления, необходимые для OpenGL ES.

Чтобы использовать OpenGL ES 1.x, свяжите свой собственный модуль с libGLESv1_CM .

Чтобы использовать OpenGL ES 2.0, свяжите свой собственный модуль с libGLESv2 .

Чтобы использовать OpenGL ES 3.x, свяжите свой собственный модуль с libGLESv3 .

Все устройства на базе Android поддерживают OpenGL ES 1.0 и 2.0.

Только устройства Android, имеющие необходимый графический процессор, полностью поддерживают более поздние версии OpenGL ES, но библиотеки присутствуют на всех устройствах, поддерживающих тот уровень API, на котором они были представлены. Связывать библиотеки безопасно, но приложение должно запросить строку версии OpenGL ES и строку расширения, чтобы определить, поддерживает ли текущее устройство необходимые ему функции. Информацию о том, как выполнить этот запрос, см. в описании glGetString() в спецификации OpenGL.

Кроме того, вы должны поместить тег <uses-feature> в файл манифеста, чтобы указать нужную вам версию OpenGL ES .

OpenGL ES 1.0 доступен начиная с уровня API 4.

OpenGL ES 2.0 доступен начиная с уровня API 5.

OpenGL ES 3.0 доступен с уровня API 18.

OpenGL ES 3.1 доступен начиная с уровня API 21.

OpenGL ES 3.2 доступен начиная с уровня API 24.

ЭГЛ

EGL предоставляет собственный интерфейс платформы через заголовки <EGL/egl.h> и <EGL/eglext.h> для выделения и управления контекстами и поверхностями OpenGL ES.

EGL позволяет выполнять следующие операции из машинного кода:

• Список поддерживаемых конфигураций EGL.
• Выделите и освободите поверхности OpenGL ES.
• Создавать и уничтожать контексты OpenGL ES.
• Поменяйте местами или переверните поверхности.

В уровне API 24 добавлена ​​поддержка расширений EGL_KHR_mutable_render_buffer , ANDROID_create_native_client_buffer и ANDROID_front_buffer_auto_refresh .

Доступно с уровня API 9.

Библиотека: libEGL

Руководство: Интерфейс собственной платформы EGL

Вулкан

Vulkan — это кроссплатформенный API с низкими затратами для высокопроизводительного рендеринга 3D-графики. Vulkan — это открытый стандарт , поддерживаемый Khronos Group. Стандартный заголовочный файл <vulkan/vulkan.h> содержит объявления, необходимые для выполнения вызовов рендеринга Vulkan из вашего кода.

Примеры кода см. в проектах LunarG VulkanSamples и android-vulkan-tutorials на GitHub.

Библиотека Vulkan присутствует на всех устройствах, поддерживающих уровень API 24 или более поздней версии, но приложения должны во время выполнения проверять наличие необходимой аппаратной поддержки графического процессора. Устройства без поддержки Vulkan вернут ноль устройств из vkEnumeratePhysicalDevices .

Доступно с уровня API 24.

Библиотека: libvulkan

Руководство: Руководство по графическому API Vulkan

Растровые изображения

Библиотека libjnigraphics предоставляет API, который обеспечивает доступ к пиксельным буферам объектов Java Bitmap . Рабочий процесс выглядит следующим образом:

1. Вызовите AndroidBitmap_getInfo() чтобы получить информацию, такую ​​как ширина и высота, о данном дескрипторе растрового изображения.

2. Вызовите AndroidBitmap_lockPixels() чтобы заблокировать буфер пикселей и получить указатель на него. Это гарантирует, что пиксели не будут перемещаться, пока приложение не вызовет AndroidBitmap_unlockPixels() .

3. Измените буфер пикселей в соответствии с его форматом пикселей, шириной и другими характеристиками.

4. Вызовите AndroidBitmap_unlockPixels() чтобы разблокировать буфер.

Доступно с уровня API 8.

Библиотека: libjnigraphics

Ссылка: Справочник по API растровых изображений

API синхронизации

Доступно с уровня API 26.

Библиотека: libsync

Ссылка: Справочник по API синхронизации.

Камера

Собственные API-интерфейсы камеры выполняют детальный захват и обработку фотографий. В отличие от Java camera2 API, собственный API камеры не поддерживает устаревшие реализации камеры HAL 1.0 (то есть в списке доступных камер в собственном API камеры не будут перечислены устройства камеры с аппаратным уровнем LEGACY ).

Доступно с уровня API 24.

Библиотека: libcamera2ndk

Ссылка: Справочник по API камеры.

СМИ

libmediandk

API-интерфейсы Media предоставляют низкоуровневые собственные интерфейсы, аналогичные MediaExtractor , MediaCodec и другим связанным API-интерфейсам Java.

Библиотека: libmediandk

Ссылка: Справочник по Media API

OpenMAX АЛ

Собственная обработка мультимедиа в Android основана на API Khronos Group OpenMAX AL 1.0.1.

Стандартные заголовки OpenMAX AL <OMXAL/OpenMAXAL.h> и <OMXAL/OpenMAXAL_Platform.h> содержат объявления, необходимые для выполнения вывода мультимедиа с собственной стороны Android.

Дистрибутив OpenMAX AL NDK также предоставляет расширения для Android. Информацию об этих расширениях см. в комментариях в <OMXAL/OpenMAXAL_Android.h> .

Доступно с уровня API 14.

Библиотека: libOpenMAXAL

API-интерфейсы собственных приложений Android

Дополнительные сведения см. в справочной документации по API Android NDK .

API включают в себя:

• Объект
• Хореограф
• Конфигурация
• Вход
• Лупер
• Родная активность
• Собственные аппаратные буферы
• Родное окно
• Память
• сеть
• Датчик
• Хранилище
• ПоверхностьТекстура

Библиотека: libandroid

Библиотека: libnativewindow для более новых функций собственного окна.

Полная ссылка: Справочник по API Android NDK.

API-интерфейсы аппаратного буфера

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

Собственный API аппаратного буфера <android/hardware_buffer.h> позволяет напрямую выделять буферы для создания собственных конвейеров для межпроцессного управления буферами. Вы можете выделить AHardwareBuffer и использовать его для получения типа ресурса EGLClientBuffer через расширение eglGetNativeClientBufferANDROID . Вы можете передать этот буфер в eglCreateImageKHR чтобы создать тип ресурса EGLImage , который затем можно привязать к текстуре через glEGLImageTargetTexture2DOES на поддерживаемых устройствах. Это может быть полезно для создания текстур, которые могут использоваться в разных процессах.

Собственный аппаратный буфер JNI API ( <android/hardware_buffer_jni.h> ) позволяет получить объект HardwareBuffer , который является Parcelable и, следовательно, может транспортироваться между двумя разными процессами. Это дает вашему приложению возможности, аналогичные SurfaceFlinger , например создание собственной очереди буферов между процессами без доступа к внутренним API Android.

Аудио

Примечание. Разработчикам следует рассмотреть возможность использования библиотеки Oboe с открытым исходным кодом, доступной на GitHub . Гобой — это оболочка C++, предоставляющая API, очень похожий на AAudio. Он вызывает AAudio, когда он доступен, и возвращается к OpenSL ES, если AAudio недоступен.

ААудио

AAudio — это поддерживаемый в настоящее время собственный аудио API. Он заменил OpenSL ES и обеспечивает лучшую поддержку высокопроизводительных аудиоприложений, которым требуется звук с малой задержкой.

Доступно с уровня API 26.

Библиотека: libaaudio

Руководство: Руководство по API AAudio

Ссылка: Справочник по API AAudio.

OpenSL ES

OpenSL ES — это еще один собственный аудио API, который также поддерживается, но см. примечание в Руководстве ниже.

Доступно с уровня API 9. На уровне API 14 добавлена ​​поддержка PCM.

Библиотека: libOpenSLES

Руководство: Руководство по OpenSL ES для Android

API нейронных сетей

API нейронных сетей (NNAPI) предоставляет приложениям аппаратное ускорение для операций машинного обучения на устройстве. API поддерживает создание, компиляцию и выполнение модели на устройстве. Приложения обычно не используют NNAPI напрямую; вместо этого API предназначен для вызова библиотеками, платформами и инструментами машинного обучения, которые позволяют разработчикам обучать свои модели и развертывать их на устройствах Android.

Доступно с уровня API 27.

Библиотека: libneuralnetworks

Руководство: Руководство по нейронным сетям

Ссылка: Справочник по API нейронных сетей.