Android将Java API追溯到jni

我试图理解java和jni之间的交互，所以我决定跟踪java API之一，

public int write（byte[]audioData，int offsetInBytes，int sizeInBytes）

（）

如果有人指出我的思维过程是否正确

方法

public int write (byte[] audioData, int offsetInBytes, int sizeInBytes) 

包含

return write(audioData, offsetInBytes, sizeInBytes, WRITE_BLOCKING); 

所以可以追溯到

public int write(@NonNull byte[] audioData, int offsetInBytes, int sizeInBytes, @WriteMode int writeMode)

（）

在该函数中，它具有

int ret = native_write_byte(audioData, offsetInBytes, sizeInBytes, mAudioFormat, writeMode == WRITE_BLOCKING); 

它调用本机方法

private native final int native_write_byte(byte[] audioData,i nt offsetInBytes, int sizeInBytes, int format, boolean isBlocking);

---

在我浏览了所有AOSP之后，我发现唯一包含

native_write_byte

的地方是静态JNITIVEMETHOD gMethods[]

`"native_write_byte",    "([BIIIZ)I", 
 (void*)android_media_AudioTrack_writeArray<jbyteArray>` 
 (`https://android.googlesource.com/platform/frameworks/base/+/android- 
 6.0.1_r1/core/jni/android_media_AudioTrack.cpp#1065`) 
 (`https://android.googlesource.com/platform/frameworks/base/+/android- 
 6.0.1_r1/core/jni/android_media_AudioTrack.cpp#592`)

`“本机写入字节”、“（[BIIIZ）I”，
（void*）android_media_AudioTrack_writeArray`
(`https://android.googlesource.com/platform/frameworks/base/+/安卓-
6.0.1_r1/core/jni/android_media_AudioTrack.cpp#1065`）
(`https://android.googlesource.com/platform/frameworks/base/+/安卓-
6.0.1_r1/core/jni/android_media_AudioTrack.cpp#592`）

现在我想找到哪个共享对象包含本机函数，所以我通过它们下载了/system/bin和grep中的所有文件，只找到了一个

libandroid\u runtime.so

在Ida pro中打开共享对象后，我通过搜索唯一的字符串找到了它

所以我认为，当开发人员使用write函数时，他们会导入libandroid_runtime.So并使用write函数，其中包含

本机_write_byte

函数，这是一个调用

静态jint android_media_AudioTrack_writeArray

的本机函数

---

这是追溯到C++的正确方法吗？< /p> < P>你正确地完成了大部分工作。

我不知道为什么你停下来，同样的CPP文件在 Mistux/St>中。这个本地方法被实现为C++函数的模板特化：

template <typename T>
static jint android_media_AudioTrack_writeArray(JNIEnv *env, jobject thiz,
                                            T javaAudioData,
                                            jint offsetInSamples, jint sizeInSamples,
                                            jint javaAudioFormat,
                                            jboolean isWriteBlocking) {

grep通过/system/bin是不必要的，而且实际上可能会产生误导，特别是如果库是在启用模糊处理的情况下构建的

所以我认为，当开发人员使用write函数时，他们会导入libandroid_runtime.So并使用write函数，其中包含

本机_write_byte

函数，这是一个调用

静态jint android_media_AudioTrack_writeArray

的本机函数

基本正确。在Java中，我们通常调用

System.loadLibrary（name）

来导入libname动态库，我们会说«

native\u write\u byte

是用

static jint android\u media\u AudioTrack\u writeArray（）

实现的，而不是谈论来自

native\u write\u byte

的调用

---

Android runtime有点不同。它在系统上加载，并被所有应用程序重用。这一开始，除其他外，注册了表中列出的属于Android\u media\u AudioTrack.cpp的所有本机方法。

你知道系统如何确定本机写入字节来自Android\u media\u AudioTrack.cpp？系统如何确定在android_media_AudioTrack.cpp中实现了e？我已经更新了答案。

cc_library_shared {
    name: "libandroid_runtime",
...
srcs: [
...
   "android_media_AudioTrack.cpp",