How can I get reach to the native methods called from Java side in Android? My problem is specifically related to AudioRecord class in Android Media package. I read the source code of AudioRecord.java. I found out that most of the jobs is performed by native methods, such as:
native_setup(...), native_start(...), native_stop(...), native_read_in_byte_array(...), native_read_in_direct_buffer(...)
I downloaded Android source code but I could not reach these methods. And I don't actually know the way to reach them. I seek for these methods in libraries I found in source code directories, but I couldn't success. If anybody may have an idea, I would be appreciative to hear. Thanks...
I think I found them. After using the Linux command
grep -r "native_read_in_direct_buffer" ./ANDROID_SOURCE/.*
I found the corresponding cpp files.
AudioRecord.cpp is located in: ~/ANDROID_SOURCE/frameworks/av/media/libmedia/ directory,
android_media_AudioRecord.cpp is located in ~/ANDROID_SOURCE/frameworks/base/core/jni directory.
I wanted to share it as a reference to other possible programmers willing to reach the same/similar source files.
Related
I have my own developed Android app in kotlin. I lost my all source code (hard disk crashed) after that I pull my apk from my physical android device using below adb commands -
c:\> adb shell pm path com.digi
Response of this command is full path of apk. after that I used below command to get actual apk-
c:\>adb pull /data/app/com.digi-ZF6WfmctELhsLvm4oICrAQ==/base.apk Destination\folder
After that I used android studio and using build -> analyze APK
This is giving some folder structure but did not get any kotlin class what I developed.
Is there any way to get at least kotlin source code?
Well, yes and no. You can't recover your source code fully, but you can at least get some of it. It will be partially gibberish and partially almost fine, you'll lose local variable names, comments, formatting, etc., so you will need to go through all files and fix them or even rewrite some of them entirely. But still it could be better than starting from scratch.
I did not decompile Android apps for a long time, so my knowledge may be outdated, but the standard procedure is:
Convert the code from dex to jar.
Decompile to Java.
In your case: convert Java to Kotlin.
Ad.1.
AFAIK there are two tools to do this: dex2jar and enjarify. I suggest using enjarify, it always gave me better results.
Ad.2.
There are several Java decompilers and some of them will work better with some code, others will work better with another. I suggest trying at least Fernflower and JD-CORE/JD-GUI, maybe Krakatau.
I guess the results will be far from perfect, because the application is written in Kotlin, not in Java. Suspend functions and other features specific to Kotlin will be even worse.
You can also use ByteCodeViewer which is a GUI applications that simplifies the process of 1. and 2. It contains all above tools and more. You can also switch the decompiler dynamically to see results of different ones.
Ad.3.
IntelliJ has some utils for converting Java to Kotlin. I never tried this with decompiled code and I guess it will be problematic
If you would need to recover the resources (XML files, etc.), you can try to use apktool.
Im not sure what it is called but ill do my best to explain it. I did search here on stack exchange and found this answer for an allias for path but i dont want to set a variable for it and i already know that. create alias for path
What I need is and its been along time since I seen it but its used with a % or $ or something that when the program runs from the directory it knows where the directory for the game files are. It didn't matter what the directory the program is in as long as the directory 'gameFiles' is in that directory it will work.
Here's my path:
"/storage/emulated/0/MyGame/MyHackGame/jni/gameFiles/oscom.txt"
I think its something like:
"%or$/gameFiles/oscom.txt"
The main problem is I have a project on source forge and don't want my developers to have to change these paths like 100 times to run the program and then I'll have to change them back.
Also iam using aide for android to make the program and using the standard c++ libaray do this might be difficult to do. I'm not even sure if I can add libarays with aide and native code or how to do it.
Use symlinks as Eugene has suggested or modify build scripts to generate user specific paths into binaries or spearate files at build time. These are ignored by version tracking, so no more double mills. Another way might be checking env variables at runtime.
I want to list folders and files inside Resources folder from android and ios. I've been able to do so by 'opendir' and 'readdir' from 'dirent.h' but only in ios emulator. It doesn't work in android.
Did anyone face such problem?
Thanks.
AFAIK, this can't be done on Android using only C++. Since you already have the iOS part figured out, you shuould wrap the iOS specific code (#includes too) in
#if (CC_TARGET_PLATFORM == CC_PLATFORM_IOS)
...
#endif
The same will aply for Android only code (`CC_PLATFORM_ANDROID') - to achieve what you want you have to write a JNI call in order to call a Java function from C++. Assuming that you want to just dump this data to a log, everything should be pretty straightforward. I don't have a link at hand, but there was an extensive topic about opening URLs which coverd the JNI tutorial and it shouldn't be hard to find.
One way could be to mantain a file containing a list of all the files in the resource directory along with their hierarchy.
For example, say you have a directory hirearchy as:
Resources/
folder1/
file1.jpeg
file2.jpeg
folder2/
file1.jpeg
file2.jpeg
Then you can mantain a file containing the paths as:
in resource_paths.txt
folder1/file1.jpeg
folder1/file2.jpeg
folder2/file1.jpeg
folder2/file2.jpeg
Then search in the file for list of directories/files :)
I would like to use the facedetection in opencv cpp to use it in an android app. I have compiled jni successfully. But I wonder how would i use the haarcascades. I can store in sdcard and read it from there. Is there any other way i can use the xml files directly from the project?
There is a c++ example called facedetect coming with the opencv superpack. I'm running OpenCV-2.3.1 myself and it's located in this folder: ../opencv-2.3.1/samples/c/
The sample uses haarcascades and this might be your best bet for facedetection. If you can use the Android NDK with proper JNI calls from a .cpp file then you shouldn't have any problems to use this sample.
I'm working on a similar thing myself but haven't tried it myself yet. Should be implementing the thing somewhere next week but can't guarantee it. Let me know if this works out for you
I have a very basic question regarding Android and ffmpeg. I obtained ffmpeg from http://bambuser.com/opensource and was able to compile it for ARM.
The results are the binaries (ffmpeg) as well as several libsomething.so files.
My question is: Is this enough to decode videos? How do I actually use ffmpeg then?
To load the library I have:
static {
System.load("/data/data/com.package/lib/libavcodec.so");
}
It loads fine. But what then?
More explanation: I saw other projects where people had their ffmpeg source in a JNI directory in the project. They also created some Android.mk files and some C code along with it. Would I need this as well? Why would I create the .so files first and then copy the ffmpeg source code again?
I know the NDK and how it should work but I've never seen an example of how one would actually call ffmpeg functions using it, because people seem to be hiding their implementations (which is sort of understandable) but not even giving useful pointers or examples.
Let's just say I wanted to decode a video file. Which kind of native methods would I need to implement? How do I run the project? Which data types need to be passed? etc. There are certainly a few people here who have at least done that, I know this from searching for hours and hours.
For your first question;
Just building is not enough for the proper use of the ffmpeg libraries. You should also wrap those so files in the right order because these so files NEED other libraries in the link time. You can display header information of the so file, by using.
objdump -x libavcodec.so | grep NEEDED
So you need to wrap these so files through Android.mk. You may check this link.
The second one;
You only need the header files from the ffmpeg project. The implementation will linked from the so libraries. Thats perhaps because, developers didn't bother to filter header files.
And the last one;
your thoughts seems right for the time being, most of the current developers are struggling to use ffmpeg but they lack of documentation and sample codes.