API เดิม

หน้านี้แสดงภาพรวมของไลบรารีที่รวมอยู่ใน NDK พร้อมลิงก์ไปยัง ส่วนที่เกี่ยวข้องของข้อมูลอ้างอิง NDK API และไปยังคำแนะนำ (หากมี)

ใช้ API แบบเนทีฟ

การใช้ไลบรารีที่ NDK มีให้ทำได้ 2 ขั้นตอนดังนี้

  1. บอกระบบบิลด์ให้ลิงก์กับไลบรารี

    • หากใช้ ndk-build ให้เพิ่มไลบรารี ลงใน LOCAL_LDLIBS ใน Android.mk โปรดทราบว่าคุณจะนำ lib ที่นำหน้าออกและพูดว่า -l แทน เช่น หากต้องการลิงก์กับ libfoo และ libbar คุณจะต้องเขียนดังนี้ makefile LOCAL_LDLIBS := -lfoo -lbar

      ดูข้อมูลเพิ่มเติมเกี่ยวกับ LOCAL_LDLIBS ได้ในเอกสารประกอบของ Android.mk

    • หากคุณใช้ CMake ให้ทำตาม วิธีการในเอกสารประกอบ เพิ่ม NDK API ของ Studio

  2. #include ส่วนหัวที่เหมาะสมจากโค้ด

โปรดทราบว่า API ที่ใหม่กว่า minSdkVersion ของแอปพลิเคชันจะเรียกใช้ไม่ได้โดยค่าเริ่มต้น และคุณต้องใช้ API เหล่านั้นผ่าน dlopen() และ dlsym() แทน ดูแนวทางที่ง่ายกว่าได้ที่การใช้ API ที่ใหม่กว่า

C/C++ หลัก

ไลบรารี C

ส่วนหัวของไลบรารี C11 มาตรฐาน เช่น <stdlib.h> และ <stdio.h> จะยังใช้งานได้ตามปกติ

โปรดทราบว่าใน Android จะไม่มีไลบรารี libpthread หรือ librt แยกต่างหากเหมือนใน Linux ฟังก์ชันการทำงานดังกล่าวรวมอยู่ใน libc โดยตรง ซึ่งไม่จำเป็นต้องลิงก์อย่างชัดเจน

มี libm แยกต่างหากสำหรับฟังก์ชันทางคณิตศาสตร์ (ตามธรรมเนียมปกติของ Unix) แต่ระบบบิลด์จะลิงก์ libc โดยอัตโนมัติเช่นกัน

ฟังก์ชันการทำงานของตัวลิงก์แบบไดนามิกใน <dlfcn.h> เช่น dlopen(3) และ dlsym(3) จะพร้อมใช้งาน แต่คุณต้องลิงก์กับ libdl อย่างชัดเจน

คลัง: libc / libm / libdl

ไลบรารี C++

รองรับ C++17 ดูข้อมูลเพิ่มเติมเกี่ยวกับการรองรับไลบรารี C++ ได้ที่ การรองรับไลบรารี C++

การบันทึก

<android/log.h> มี API สำหรับการบันทึกไปยัง Logcat

พร้อมใช้งานตั้งแต่ระดับ API 3

คลัง: liblog

ข้อมูลอ้างอิง: การบันทึก

การติดตาม

Native Tracing 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 ที่มี GPU ที่จำเป็นเท่านั้นที่รองรับ OpenGL ES เวอร์ชันที่ใหม่กว่าได้อย่างเต็มที่ แต่ไลบรารีจะอยู่ในอุปกรณ์ทั้งหมดที่รองรับ API ระดับที่เปิดตัว การลิงก์กับไลบรารีนั้นปลอดภัย แต่แอปต้องค้นหาสตริงเวอร์ชัน OpenGL ES และสตริงส่วนขยาย เพื่อพิจารณาว่าอุปกรณ์ปัจจุบันรองรับฟีเจอร์ที่แอปต้องการหรือไม่ ดูข้อมูลเกี่ยวกับวิธีทำการค้นหานี้ได้ที่คำอธิบายของ glGetString() ในข้อกำหนดของ OpenGL

นอกจากนี้ คุณต้องใส่แท็ก <uses-feature> ในไฟล์ Manifest เพื่อระบุเวอร์ชันของ 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/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

Vulkan เป็น API แบบข้ามแพลตฟอร์มที่มีค่าใช้จ่ายต่ำสำหรับกราฟิก 3 มิติที่มีประสิทธิภาพสูง การแสดงผล Vulkan เป็นมาตรฐานแบบเปิด ที่ดูแลโดย Khronos Group ไฟล์ส่วนหัวมาตรฐาน <vulkan/vulkan.h> มีการประกาศที่จำเป็นต่อการเรียกการแสดงผล Vulkan จากโค้ด ของคุณ

ดูตัวอย่างโค้ดได้ที่โปรเจ็กต์ LunarG VulkanSamples และ android-vulkan-tutorials ใน GitHub

ไลบรารี Vulkan จะอยู่ในอุปกรณ์ทั้งหมดที่รองรับระดับ API 24 ขึ้นไป แต่แอปต้องตรวจสอบที่รันไทม์ว่ามีฮาร์ดแวร์ GPU ที่จำเป็นรองรับอยู่หรือไม่ อุปกรณ์ที่ไม่รองรับ Vulkan จะแสดงอุปกรณ์เป็น 0 จาก vkEnumeratePhysicalDevices

พร้อมใช้งานตั้งแต่ API ระดับ 24

คลัง: libvulkan

คำแนะนำ: คำแนะนำเกี่ยวกับ Vulkan Graphics API

บิตแมป

libjnigraphics ไลบรารีจะแสดง API ที่อนุญาตให้เข้าถึงบัฟเฟอร์พิกเซล ของออบเจ็กต์ Java Bitmap ขั้นตอนการทำงานมีดังนี้

  1. เรียกใช้ AndroidBitmap_getInfo() เพื่อดึงข้อมูล เช่น ความกว้างและความสูง เกี่ยวกับแฮนเดิลบิตแมปที่ระบุ

  2. เรียกใช้ AndroidBitmap_lockPixels() เพื่อล็อกบัฟเฟอร์พิกเซลและดึงข้อมูล พอยน์เตอร์ไปยังบัฟเฟอร์ดังกล่าว วิธีนี้จะช่วยให้มั่นใจได้ว่าพิกเซลจะไม่เคลื่อนไหวจนกว่าแอปจะเรียกใช้ AndroidBitmap_unlockPixels()

  3. แก้ไขบัฟเฟอร์พิกเซลตามความเหมาะสมสำหรับรูปแบบพิกเซล ความกว้าง และ ลักษณะอื่นๆ

  4. เรียกใช้ AndroidBitmap_unlockPixels() เพื่อปลดล็อกบัฟเฟอร์

พร้อมใช้งานตั้งแต่ระดับ API 8

คลัง: libjnigraphics

ข้อมูลอ้างอิง: เอกสารอ้างอิง Bitmap API

Sync API

พร้อมใช้งานตั้งแต่ API ระดับ 26

คลัง: libsync

ข้อมูลอ้างอิง: เอกสารอ้างอิง Sync API

กล้อง

API กล้องถ่ายรูปดั้งเดิมจะทำการจับภาพและการประมวลผลรูปภาพอย่างละเอียด API กล้องเนทีฟไม่รองรับการใช้งาน HAL กล้อง 1.0 ที่เลิกใช้งานแล้ว (กล่าวคือ รายการกล้องที่ใช้ได้ใน API กล้องเนทีฟจะไม่แสดงอุปกรณ์กล้องที่มีระดับฮาร์ดแวร์เป็น LEGACY) ซึ่งแตกต่างจาก API กล้อง2 ของ Java

พร้อมใช้งานตั้งแต่ API ระดับ 24

คลัง: libcamera2ndk

ข้อมูลอ้างอิง: เอกสารอ้างอิง Camera API

สื่อ

libmediandk

Media API มีอินเทอร์เฟซดั้งเดิมระดับต่ำที่คล้ายกับ MediaExtractor, MediaCodec และ Java API อื่นๆ ที่เกี่ยวข้อง

คลัง: libmediandk

ข้อมูลอ้างอิง: เอกสารอ้างอิง Media API

OpenMAX AL

แทน

การจัดการมัลติมีเดียแบบเนทีฟของ Android อิงตาม Khronos Group OpenMAX AL 1.0.1 API

ส่วนหัว OpenMAX AL มาตรฐาน <OMXAL/OpenMAXAL.h> และ <OMXAL/OpenMAXAL_Platform.h> มีการประกาศที่จำเป็นสำหรับการดำเนินการ เอาต์พุตมัลติมีเดียจากฝั่งเนทีฟของ Android

การจัดจำหน่าย OpenMAX AL ของ NDK ยังมีส่วนขยายเฉพาะของ Android ด้วย ดูข้อมูลเกี่ยวกับส่วนขยายเหล่านี้ได้ในความคิดเห็นใน <OMXAL/OpenMAXAL_Android.h>

พร้อมใช้งานตั้งแต่ API ระดับ 14

คลัง: libOpenMAXAL

API ของแอปพลิเคชันดั้งเดิมของ Android

ดูข้อมูลเพิ่มเติมได้ในเอกสารประกอบข้อมูลอ้างอิงเกี่ยวกับ Android NDK API

API มีดังนี้

คลัง: libandroid

ไลบรารี: libnativewindow สำหรับฟังก์ชันการทำงานของหน้าต่างในระบบล่าสุด

เอกสารอ้างอิงฉบับเต็ม: เอกสารอ้างอิง Android NDK API

Binder API

Binder API ช่วยให้คุณสร้างช่องทางการสื่อสารระหว่างกระบวนการต่างๆ ได้ ซึ่งเป็นการติดตั้งใช้งานการสื่อสารระหว่างโปรเซสของ Android ในระดับต่ำ หากเป็นไปได้ ให้ใช้คอมโพเนนต์ระดับสูงกว่า อย่างไรก็ตาม ไลบรารีนี้พร้อมให้บริการ สำหรับ Use Case ขั้นสูง

คลัง: libbinder_ndk

อ้างอิง: Binder

Hardware Buffer APIs

มี API เนทีฟ 2 รายการที่ช่วยให้คุณสร้างไปป์ไลน์ของคุณเองสำหรับการ จัดการบัฟเฟอร์ข้ามกระบวนการได้

Native Hardware Buffer API <android/hardware_buffer.h> ช่วยให้คุณจัดสรรบัฟเฟอร์ได้โดยตรงเพื่อสร้างไปป์ไลน์ของคุณเองสำหรับการจัดการบัฟเฟอร์ข้ามกระบวนการ คุณจัดสรร AHardwareBuffer และใช้เพื่อรับประเภททรัพยากร EGLClientBuffer ผ่านส่วนขยาย eglGetNativeClientBufferANDROID ได้ คุณส่งบัฟเฟอร์นั้นไปยัง eglCreateImageKHR เพื่อสร้างประเภททรัพยากร EGLImage ซึ่งอาจเชื่อมโยงกับเท็กซ์เจอร์ผ่าน glEGLImageTargetTexture2DOES ในอุปกรณ์ที่รองรับได้ ซึ่งจะเป็นประโยชน์ในการสร้างเท็กซ์เจอร์ที่อาจแชร์ข้ามกระบวนการได้

Native Hardware Buffer JNI API (<android/hardware_buffer_jni.h>) ช่วยให้คุณ รับออบเจ็กต์ HardwareBuffer ซึ่งเป็น Parcelable และ จึงอาจส่งระหว่าง 2 กระบวนการที่แตกต่างกันได้ ซึ่งจะทำให้แอปของคุณมีความสามารถคล้ายกับ SurfaceFlinger เช่น การสร้างคิวบัฟเฟอร์ของคุณเองระหว่างกระบวนการโดยไม่ต้องเข้าถึง Android API ภายใน

เสียง

AAudio

AAudio เป็น API เสียงดั้งเดิมที่รองรับในปัจจุบัน โดยจะมาแทนที่ OpenSL ES และ รองรับแอปเสียงที่มีประสิทธิภาพสูงซึ่งต้องใช้ เสียงที่มีเวลาในการตอบสนองต่ำได้ดียิ่งขึ้น

พร้อมใช้งานตั้งแต่ API ระดับ 26

คลัง: libaaudio

คำแนะนำ: คำแนะนำเกี่ยวกับ AAudio API

ข้อมูลอ้างอิง: เอกสารอ้างอิง AAudio API

OpenSL ES

OpenSL ES เป็นอีกหนึ่ง API เสียงแบบเนทีฟที่รองรับเช่นกัน แต่โปรดอ่านหมายเหตุในคำแนะนำด้านล่าง

พร้อมใช้งานตั้งแต่ API ระดับ 9 API ระดับ 14 เพิ่มการรองรับ PCM

คลัง: libOpenSLES

คู่มือ: คู่มือ OpenSL ES สำหรับ Android

Neural Networks API

Neural Networks API (NNAPI) ช่วยให้แอปมีการเร่งฮาร์ดแวร์สำหรับ การดำเนินการแมชชีนเลิร์นนิงในอุปกรณ์ API รองรับการสร้าง การคอมไพล์ และการเรียกใช้โมเดลในอุปกรณ์ โดยปกติแล้ว แอปจะไม่ใช้ NNAPI โดยตรง แต่ API นี้มีไว้ให้ไลบรารี แมชชีนเลิร์นนิง เฟรมเวิร์ก และเครื่องมือต่างๆ เรียกใช้ ซึ่งจะช่วยให้นักพัฒนาแอปฝึกโมเดลและนำไปใช้งานใน อุปกรณ์ Android ได้

พร้อมใช้งานตั้งแต่ API ระดับ 27

คลัง: libneuralnetworks

คำแนะนำ: คำแนะนำเกี่ยวกับโครงข่ายประสาทเทียม

ข้อมูลอ้างอิง: เอกสารอ้างอิง Neural Networks API