หน้านี้จะแสดงภาพรวมของไลบรารีที่รวมอยู่ใน NDK พร้อมลิงก์ไปยังส่วนที่เกี่ยวข้องของข้อมูลอ้างอิง NDK API และไปยังคู่มือที่มี
ใช้ API ของบริการ
การใช้ไลบรารีที่ NDK มีให้มี 2 ขั้นตอนดังนี้
บอกให้ระบบบิลด์ลิงก์กับไลบรารี
หากคุณใช้ ndk-build ให้เพิ่มไลบรารีลงใน
LOCAL_LDLIBS
ใน Android.mk โปรดทราบว่าคุณต้องนำlib
ที่อยู่ด้านหน้าออกและพูด-l
แทน เช่น หากต้องการลิงก์กับlibfoo
และlibbar
ให้เขียนดังนี้makefile LOCAL_LDLIBS := -lfoo -lbar
ดูข้อมูลเพิ่มเติมเกี่ยวกับ
LOCAL_LDLIBS
ได้ในเอกสารประกอบของ Android.mkหากคุณใช้ CMake ให้ทําตามวิธีการในเอกสารประกอบเพิ่ม NDK API ของ Studio
#include
ส่วนหัวที่เหมาะสมจากโค้ด
โปรดทราบว่า API ที่ใหม่กว่า minSdkVersion
ของแอปพลิเคชันจะเรียกใช้ไม่ได้โดยค่าเริ่มต้น และคุณต้องใช้ API เหล่านั้นผ่าน dlopen()
และ dlsym()
แทน
หากต้องการใช้วิธีที่ง่ายขึ้น โปรดดูการใช้ API เวอร์ชันใหม่
C/C++ หลัก
ไลบรารี C
ส่วนส่วนหัวของไลบรารี C11 มาตรฐาน เช่น <stdlib.h>
และ <stdio.h>
จะยังคงใช้งานได้ตามปกติ
โปรดทราบว่า Android ไม่มีไลบรารี libpthread
หรือ librt
แยกต่างหาก ต่างจาก Linux ฟังก์ชันการทำงานดังกล่าวรวมอยู่ใน libc
โดยตรงแล้ว ซึ่งไม่จำเป็นต้องลิงก์กับ libc
อย่างชัดเจน
มี libm
แยกต่างหากสำหรับฟังก์ชันคณิตศาสตร์ (ตามธรรมเนียมของ Unix ปกติ) แต่ระบบบิลด์จะลิงก์ libm
นี้โดยอัตโนมัติเช่นเดียวกับ libc
ฟังก์ชันการทำงานของโปรแกรมลิงก์แบบไดนามิกใน <dlfcn.h>
เช่น dlopen(3) และ dlsym(3) จะใช้ได้ แต่คุณต้องลิงก์กับ libdl
อย่างชัดแจ้ง
คลัง: libc
/ libm
/ libdl
ไลบรารี C++
รองรับ C++17 ดูข้อมูลเพิ่มเติมเกี่ยวกับการรองรับไลบรารี C++ ได้ที่หัวข้อการรองรับไลบรารี C++
การบันทึก
<android/log.h>
มี API สำหรับการบันทึกลงใน Logcat
พร้อมใช้งานตั้งแต่ 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 ที่มี 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 ไฟล์ส่วนหัว <vulkan/vulkan.h>
มาตรฐานจะมีประกาศที่จำเป็นสำหรับการเรียกใช้การแสดงผล Vulkan จากโค้ด
ดูตัวอย่างโค้ดได้ที่โปรเจ็กต์ VulkanSamples และ android-vulkan-tutorials ของ LunarG ใน GitHub
ไลบรารี Vulkan มีอยู่ในอุปกรณ์ทุกเครื่องที่รองรับ API ระดับ 24 ขึ้นไป แต่แอปต้องตรวจสอบขณะรันไทม์ว่ารองรับฮาร์ดแวร์ GPU ที่จำเป็นหรือไม่ อุปกรณ์ที่ไม่รองรับ Vulkan จะแสดงผลเป็น 0 อุปกรณ์จาก vkEnumeratePhysicalDevices
พร้อมใช้งานตั้งแต่ API ระดับ 24
คลัง: libvulkan
คู่มือ: คู่มือ API กราฟิก Vulkan
บิตแมป
ไลบรารี libjnigraphics
จะแสดง API ที่อนุญาตให้เข้าถึงบัฟเฟอร์พิกเซลของออบเจ็กต์ Bitmap
ของ Java เวิร์กโฟลว์มีดังนี้
เรียกใช้
AndroidBitmap_getInfo()
เพื่อดึงข้อมูลเกี่ยวกับแฮนเดิลบิตแมปหนึ่งๆ เช่น ความกว้างและความสูงเรียกใช้
AndroidBitmap_lockPixels()
เพื่อล็อกบัฟเฟอร์พิกเซลและเรียกดูเคอร์เซอร์ไปยังบัฟเฟอร์ วิธีนี้ช่วยให้มั่นใจว่าพิกเซลจะไม่เคลื่อนไหวจนกว่าแอปจะเรียกใช้AndroidBitmap_unlockPixels()
แก้ไขบัฟเฟอร์พิกเซลตามความเหมาะสมสำหรับรูปแบบพิกเซล ความกว้าง และลักษณะอื่นๆ
โทรหา
AndroidBitmap_unlockPixels()
เพื่อปลดล็อกบัฟเฟอร์
พร้อมใช้งานตั้งแต่ API ระดับ 8
คลัง: libjnigraphics
ข้อมูลอ้างอิง: ข้อมูลอ้างอิงเกี่ยวกับ Bitmap API
Sync API
พร้อมใช้งานตั้งแต่ API ระดับ 26
คลัง: libsync
ข้อมูลอ้างอิง: ข้อมูลอ้างอิง Sync API
กล้อง
API ของกล้องแบบเนทีฟจะจับภาพและประมวลผลรูปภาพอย่างละเอียด API ของกล้องแบบเนทีฟไม่รองรับการใช้งาน HAL 1.0 ของกล้องที่เลิกใช้งานแล้ว ซึ่งแตกต่างจาก Java camera2 API (กล่าวคือ รายการกล้องที่ใช้ได้ใน API ของกล้องแบบเนทีฟจะไม่แสดงอุปกรณ์กล้องที่มีระดับฮาร์ดแวร์เดิม)
พร้อมใช้งานตั้งแต่ 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
แพ็กเกจ NDK ของ OpenMAX AL ยังมีส่วนขยายสำหรับ Android โดยเฉพาะด้วย
ดูข้อมูลเกี่ยวกับส่วนขยายเหล่านี้ได้ที่ความคิดเห็นใน <OMXAL/OpenMAXAL_Android.h>
พร้อมใช้งานตั้งแต่ API ระดับ 14
คลัง: libOpenMAXAL
Android Native Application API
ดูข้อมูลเพิ่มเติมได้ที่เอกสารประกอบข้อมูลอ้างอิง Android NDK API
API มีดังนี้
- ชิ้นงาน
- ผู้ออกแบบท่าเต้น
- การกําหนดค่า
- อินพุต
- Looper
- กิจกรรมเนทีฟ
- บัฟเฟอร์ฮาร์ดแวร์แบบเนทีฟ
- หน้าต่างในเครื่อง
- หน่วยความจำ
- การสร้างเครือข่าย
- เซ็นเซอร์
- พื้นที่เก็บข้อมูล
- SurfaceTexture
คลัง: libandroid
คลัง: libnativewindow
สำหรับฟังก์ชันการทำงานของหน้าต่างในระบบเวอร์ชันล่าสุด
ข้อมูลอ้างอิงฉบับเต็ม: เอกสารอ้างอิง Android NDK API
Binder API
Binder API ช่วยให้คุณสร้างช่องทางการสื่อสารระหว่างกระบวนการต่างๆ ได้ การดำเนินการนี้เป็นการใช้งานระดับต่ำของการสื่อสารระหว่างโปรเซสของ Android โปรดใช้คอมโพเนนต์ระดับที่สูงขึ้นเมื่อเป็นไปได้ แต่ไลบรารีนี้พร้อมใช้งานสำหรับ Use Case ขั้นสูง
คลัง: libbinder_ndk
ข้อมูลอ้างอิง: Binder
Hardware Buffer API
มี API เนทีฟ 2 รายการที่ช่วยให้คุณสร้างไปป์ไลน์ของคุณเองเพื่อการจัดการบัฟเฟอร์ข้ามกระบวนการได้
API บัฟเฟอร์ฮาร์ดแวร์เดิม
<android/hardware_buffer.h>
ช่วยให้คุณจัดสรรบัฟเฟอร์ได้โดยตรงเพื่อสร้างไปป์ไลน์ของคุณเองสำหรับการจัดการบัฟเฟอร์ข้ามกระบวนการ
คุณสามารถจัดสรร AHardwareBuffer
และใช้เพื่อรับประเภททรัพยากร EGLClientBuffer
ผ่านส่วนขยาย eglGetNativeClientBufferANDROID
คุณสามารถส่งบัฟเฟอร์นั้นให้กับ eglCreateImageKHR
เพื่อสร้างประเภททรัพยากร EGLImage
ซึ่งอาจเชื่อมโยงกับพื้นผิวผ่าน glEGLImageTargetTexture2DOES
ในอุปกรณ์ที่รองรับ ซึ่งอาจมีประโยชน์ต่อการสร้างพื้นผิวที่อาจแชร์ข้ามกระบวนการ
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