Android Tracing a Java API back to jni












0














I'm trying to understand the interaction between the java and jni, so I decided to trace one of the java API, public int write (byte audioData, int offsetInBytes, int sizeInBytes) (https://android.googlesource.com/platform/frameworks/base/+/android-6.0.1_r1/media/java/android/media/AudioTrack.java#1699).



If someone would point out if my thought process is correct or not.



The method



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


contains



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


so it can be traced back to



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


(https://android.googlesource.com/platform/frameworks/base/+/android-6.0.1_r1/media/java/android/media/AudioTrack.java#1739).



Inside that function, it has



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


which calls the native method



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




After I grep through all of the AOSP, I found that the only place that contains native_write_byte is in static JNINativeMethod 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`)


Now I want to find in which shared objects contains the native function, so I downloaded all of the files in /system/bin and grep through them, and only found one which is libandroid_runtime.so.



After opening the shared object in Ida pro, I found it by searching for the unique string.



So I'm thinking that when developers use the write function, they import libandroid_runtime.so and use write function which contains native_write_byte function which is a native function that calls to static jint android_media_AudioTrack_writeArray.



Is this the right way to trace back to the C++?










share|improve this question





























    0














    I'm trying to understand the interaction between the java and jni, so I decided to trace one of the java API, public int write (byte audioData, int offsetInBytes, int sizeInBytes) (https://android.googlesource.com/platform/frameworks/base/+/android-6.0.1_r1/media/java/android/media/AudioTrack.java#1699).



    If someone would point out if my thought process is correct or not.



    The method



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


    contains



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


    so it can be traced back to



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


    (https://android.googlesource.com/platform/frameworks/base/+/android-6.0.1_r1/media/java/android/media/AudioTrack.java#1739).



    Inside that function, it has



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


    which calls the native method



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




    After I grep through all of the AOSP, I found that the only place that contains native_write_byte is in static JNINativeMethod 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`)


    Now I want to find in which shared objects contains the native function, so I downloaded all of the files in /system/bin and grep through them, and only found one which is libandroid_runtime.so.



    After opening the shared object in Ida pro, I found it by searching for the unique string.



    So I'm thinking that when developers use the write function, they import libandroid_runtime.so and use write function which contains native_write_byte function which is a native function that calls to static jint android_media_AudioTrack_writeArray.



    Is this the right way to trace back to the C++?










    share|improve this question



























      0












      0








      0







      I'm trying to understand the interaction between the java and jni, so I decided to trace one of the java API, public int write (byte audioData, int offsetInBytes, int sizeInBytes) (https://android.googlesource.com/platform/frameworks/base/+/android-6.0.1_r1/media/java/android/media/AudioTrack.java#1699).



      If someone would point out if my thought process is correct or not.



      The method



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


      contains



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


      so it can be traced back to



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


      (https://android.googlesource.com/platform/frameworks/base/+/android-6.0.1_r1/media/java/android/media/AudioTrack.java#1739).



      Inside that function, it has



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


      which calls the native method



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




      After I grep through all of the AOSP, I found that the only place that contains native_write_byte is in static JNINativeMethod 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`)


      Now I want to find in which shared objects contains the native function, so I downloaded all of the files in /system/bin and grep through them, and only found one which is libandroid_runtime.so.



      After opening the shared object in Ida pro, I found it by searching for the unique string.



      So I'm thinking that when developers use the write function, they import libandroid_runtime.so and use write function which contains native_write_byte function which is a native function that calls to static jint android_media_AudioTrack_writeArray.



      Is this the right way to trace back to the C++?










      share|improve this question















      I'm trying to understand the interaction between the java and jni, so I decided to trace one of the java API, public int write (byte audioData, int offsetInBytes, int sizeInBytes) (https://android.googlesource.com/platform/frameworks/base/+/android-6.0.1_r1/media/java/android/media/AudioTrack.java#1699).



      If someone would point out if my thought process is correct or not.



      The method



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


      contains



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


      so it can be traced back to



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


      (https://android.googlesource.com/platform/frameworks/base/+/android-6.0.1_r1/media/java/android/media/AudioTrack.java#1739).



      Inside that function, it has



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


      which calls the native method



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




      After I grep through all of the AOSP, I found that the only place that contains native_write_byte is in static JNINativeMethod 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`)


      Now I want to find in which shared objects contains the native function, so I downloaded all of the files in /system/bin and grep through them, and only found one which is libandroid_runtime.so.



      After opening the shared object in Ida pro, I found it by searching for the unique string.



      So I'm thinking that when developers use the write function, they import libandroid_runtime.so and use write function which contains native_write_byte function which is a native function that calls to static jint android_media_AudioTrack_writeArray.



      Is this the right way to trace back to the C++?







      java android c++ jni






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 20 at 23:33









      Sk83r1l4m4

      458




      458










      asked Nov 20 at 21:12









      Carol Ward

      1008




      1008
























          1 Answer
          1






          active

          oldest

          votes


















          1














          You did most of the work correctly.



          I don't know why you stopped at android-6.0.1_r1, the same CPP file is available in master. This native method is implemented as a template specialization of a C++ function:



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


          You can study how this function works. Note that here, as typical for Android platform code, the JNI calls are wrapped with nativehelper headers.



          to find in which shared objects contains the native function, you can look up the corresponding Android.bp script.



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


          grep through /system/bin is not necessary, and could actually be misleading, especially if the library were built with obfuscation turned on.




          So I'm thinking that when developers use the write function, they import libandroid_runtime.so and use write function which contains native_write_byte function which is a native function that calls to static jint android_media_AudioTrack_writeArray.




          Basically correct. In Java, we usually invoke System.loadLibrary(name) to import libname dynamic library, and we would say «native_write_byte is implemented with static jint android_media_AudioTrack_writeArray<jbytearray>()» rather than speak about a call from native_write_byte.



          Android runtime is a bit different. It is started on system load and reused by all apps. This start invokes, among others, register_android_media_AudioTrack(JNIEnv *), and that registers all native methods listed in the gMethods table which belongs to android_media_AudioTrack.cpp.






          share|improve this answer























          • Do you know how the system determines native_write_byte came from android_media_AudioTrack.cpp?
            – Carol Ward
            Nov 21 at 14:06










          • How the system determines that the implementation is in android_media_AudioTrack.cpp? I have updated the answer.
            – Alex Cohn
            Nov 21 at 15:23











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53401608%2fandroid-tracing-a-java-api-back-to-jni%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          1














          You did most of the work correctly.



          I don't know why you stopped at android-6.0.1_r1, the same CPP file is available in master. This native method is implemented as a template specialization of a C++ function:



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


          You can study how this function works. Note that here, as typical for Android platform code, the JNI calls are wrapped with nativehelper headers.



          to find in which shared objects contains the native function, you can look up the corresponding Android.bp script.



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


          grep through /system/bin is not necessary, and could actually be misleading, especially if the library were built with obfuscation turned on.




          So I'm thinking that when developers use the write function, they import libandroid_runtime.so and use write function which contains native_write_byte function which is a native function that calls to static jint android_media_AudioTrack_writeArray.




          Basically correct. In Java, we usually invoke System.loadLibrary(name) to import libname dynamic library, and we would say «native_write_byte is implemented with static jint android_media_AudioTrack_writeArray<jbytearray>()» rather than speak about a call from native_write_byte.



          Android runtime is a bit different. It is started on system load and reused by all apps. This start invokes, among others, register_android_media_AudioTrack(JNIEnv *), and that registers all native methods listed in the gMethods table which belongs to android_media_AudioTrack.cpp.






          share|improve this answer























          • Do you know how the system determines native_write_byte came from android_media_AudioTrack.cpp?
            – Carol Ward
            Nov 21 at 14:06










          • How the system determines that the implementation is in android_media_AudioTrack.cpp? I have updated the answer.
            – Alex Cohn
            Nov 21 at 15:23
















          1














          You did most of the work correctly.



          I don't know why you stopped at android-6.0.1_r1, the same CPP file is available in master. This native method is implemented as a template specialization of a C++ function:



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


          You can study how this function works. Note that here, as typical for Android platform code, the JNI calls are wrapped with nativehelper headers.



          to find in which shared objects contains the native function, you can look up the corresponding Android.bp script.



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


          grep through /system/bin is not necessary, and could actually be misleading, especially if the library were built with obfuscation turned on.




          So I'm thinking that when developers use the write function, they import libandroid_runtime.so and use write function which contains native_write_byte function which is a native function that calls to static jint android_media_AudioTrack_writeArray.




          Basically correct. In Java, we usually invoke System.loadLibrary(name) to import libname dynamic library, and we would say «native_write_byte is implemented with static jint android_media_AudioTrack_writeArray<jbytearray>()» rather than speak about a call from native_write_byte.



          Android runtime is a bit different. It is started on system load and reused by all apps. This start invokes, among others, register_android_media_AudioTrack(JNIEnv *), and that registers all native methods listed in the gMethods table which belongs to android_media_AudioTrack.cpp.






          share|improve this answer























          • Do you know how the system determines native_write_byte came from android_media_AudioTrack.cpp?
            – Carol Ward
            Nov 21 at 14:06










          • How the system determines that the implementation is in android_media_AudioTrack.cpp? I have updated the answer.
            – Alex Cohn
            Nov 21 at 15:23














          1












          1








          1






          You did most of the work correctly.



          I don't know why you stopped at android-6.0.1_r1, the same CPP file is available in master. This native method is implemented as a template specialization of a C++ function:



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


          You can study how this function works. Note that here, as typical for Android platform code, the JNI calls are wrapped with nativehelper headers.



          to find in which shared objects contains the native function, you can look up the corresponding Android.bp script.



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


          grep through /system/bin is not necessary, and could actually be misleading, especially if the library were built with obfuscation turned on.




          So I'm thinking that when developers use the write function, they import libandroid_runtime.so and use write function which contains native_write_byte function which is a native function that calls to static jint android_media_AudioTrack_writeArray.




          Basically correct. In Java, we usually invoke System.loadLibrary(name) to import libname dynamic library, and we would say «native_write_byte is implemented with static jint android_media_AudioTrack_writeArray<jbytearray>()» rather than speak about a call from native_write_byte.



          Android runtime is a bit different. It is started on system load and reused by all apps. This start invokes, among others, register_android_media_AudioTrack(JNIEnv *), and that registers all native methods listed in the gMethods table which belongs to android_media_AudioTrack.cpp.






          share|improve this answer














          You did most of the work correctly.



          I don't know why you stopped at android-6.0.1_r1, the same CPP file is available in master. This native method is implemented as a template specialization of a C++ function:



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


          You can study how this function works. Note that here, as typical for Android platform code, the JNI calls are wrapped with nativehelper headers.



          to find in which shared objects contains the native function, you can look up the corresponding Android.bp script.



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


          grep through /system/bin is not necessary, and could actually be misleading, especially if the library were built with obfuscation turned on.




          So I'm thinking that when developers use the write function, they import libandroid_runtime.so and use write function which contains native_write_byte function which is a native function that calls to static jint android_media_AudioTrack_writeArray.




          Basically correct. In Java, we usually invoke System.loadLibrary(name) to import libname dynamic library, and we would say «native_write_byte is implemented with static jint android_media_AudioTrack_writeArray<jbytearray>()» rather than speak about a call from native_write_byte.



          Android runtime is a bit different. It is started on system load and reused by all apps. This start invokes, among others, register_android_media_AudioTrack(JNIEnv *), and that registers all native methods listed in the gMethods table which belongs to android_media_AudioTrack.cpp.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 21 at 15:26

























          answered Nov 21 at 8:46









          Alex Cohn

          40.8k552186




          40.8k552186












          • Do you know how the system determines native_write_byte came from android_media_AudioTrack.cpp?
            – Carol Ward
            Nov 21 at 14:06










          • How the system determines that the implementation is in android_media_AudioTrack.cpp? I have updated the answer.
            – Alex Cohn
            Nov 21 at 15:23


















          • Do you know how the system determines native_write_byte came from android_media_AudioTrack.cpp?
            – Carol Ward
            Nov 21 at 14:06










          • How the system determines that the implementation is in android_media_AudioTrack.cpp? I have updated the answer.
            – Alex Cohn
            Nov 21 at 15:23
















          Do you know how the system determines native_write_byte came from android_media_AudioTrack.cpp?
          – Carol Ward
          Nov 21 at 14:06




          Do you know how the system determines native_write_byte came from android_media_AudioTrack.cpp?
          – Carol Ward
          Nov 21 at 14:06












          How the system determines that the implementation is in android_media_AudioTrack.cpp? I have updated the answer.
          – Alex Cohn
          Nov 21 at 15:23




          How the system determines that the implementation is in android_media_AudioTrack.cpp? I have updated the answer.
          – Alex Cohn
          Nov 21 at 15:23


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53401608%2fandroid-tracing-a-java-api-back-to-jni%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          404 Error Contact Form 7 ajax form submitting

          How to know if a Active Directory user can login interactively

          Refactoring coordinates for Minecraft Pi buildings written in Python