we all know that google is shifting from Dalvik to ART ( 4.4.2 has even experimental support too) for obvious reason, A very basic question is arising in my mind after i recently started working on mdifying the generated smali files for some purpose. Here is my question:
After expanding any apk file we see dalvik executable and various smali file containing dalvik opcodes and other related things. So i was surprised if this structure inside the apk file will be containing the similar things going forward once Google forces to use ART i.e. I am not clear if modifying the smali file will be valid once ART takes over.
This may be very basic question for many but is my first question in this forum so please excuse me for my limited knowledge on this topic.
Related
I'm sure this is a very basic question but since this is the my first time messing around with the NDK, a lot of thing is still very unclear to me.
Use case:
I'm trying to develop a video scrubbing feature so fast and accurate frame seeking is crucial. I've tried most of the available players out there but the performance is still not up to my demand. That's why I'm going down the FFmpeg route.
Basically, what I'm looking for is FFmpeg input seeking. I've tried WrtingMinds' ffmpeg-android-java. However it is a file based implementation which means the out.jpg need to be written to external memory and read back which has a big hit on performance (roughly 1000 milliseconds for 1 seek).
That's why I'm trying to built my own FFmpeg player to do the input seeking in JNI and push back the byte[] to be displayed in Java.
Question: After a lot of struggling with the NDK, I've managed to set it up and successfully calling the JNI method from my Java code. The structure is as below:
MyApp
-app
-MyFFmpegPlayer
-build
-libs
-src
-main
-java
-com.example.myffmpegplayer
+HelloJNI.java
-jni
+MyFFmpegPlayer.c
After some fail attempt to build FFmpeg on Windows, I've decided to use WritingMinds prebuilt FFmpeg. However, after extraction they just come up as plain ffmpeg files (not .so file) so I don't really know how to use these.
It would be a great gratitude, if someone can just chime in and give me a good starting point for my next step.
Thank you so much for your time.
So to answer my own question which I should change to "How to build FFmpeg and use it with Android Studio", I have create a detail step-by-step instruction that's working for me (at May 24th 2016).
Sorry I can't post the whole instruction here as it is very long, plus it is easier for me to keep 1 source of information up-to-date.
I hope this can help someone as I know there is way too much confusing and contradicting information regarding this topic out there.
This question already has answers here:
Is there a way to get the source code from an APK file?
(32 answers)
Closed 9 years ago.
*How we get the complete source code from .apk file .we also try try dex2jar and other process but we din't get the complete source code . and commented code is not shown .
*
Most of the developers use a thing called proguard which will be used for the obfuscation of the code, obfuscation generally means making the code unreadable so to make the apk resist to any reverse engineering attempt(resist here does not mean it can't be reverse engineered, if the apk has gone through the reverse engineered process , the person who attempted may not able to read the actual code the developer has written), i once tried to do reverse engineer the apk,ended up in the middle languages like smali .so if you are lucky enough that the developer did not used proguard chances are there you might end up looking the original code.Try the following
link for reverse engineering the apk
It is not possible to get the full source code, as not all information is preserved within the apk (comments, etc.) and many things are re-ordered (as there are jump instructions instead of if, while, for, ...). For native code, it is even harder.
If you plan to get the source of commercial applications, applications may even got obfuscated, e.g. additional information is cropped from the apk.
If you only need to change/read tiny bits, you might want to use smali (if the parts you wish to access are not native), it is also used by many tools; it produces a readable format from the android bytecode. The use of such tools is only legal if you are the author of the apk, have the authors permission or have a legal right to do so (one example is living in the European Union, you are then allowed to adjust software you have a license for to achieve interoperability even without explicit permission by the author if there is no other way to archive the interoperability you want).
I have an "older" machine which is more than adequate for developing my first Android marketplace application BUT only with Java!
I recently tried Kawa and Scala (I switch to functional programming about six years ago with LISP/Scheme and I've absorbed Erlang and Haskell since then) and I must say that I really love Scalas conciseness and Kawa is still fantastic (used it a long time ago for a project).
However... the build time when "dexing" on my machine is into the minutes(!) when the 'dx' program works on the kawa.jar file.
Does anybody know if it is possible to "cache" or "pre-build" a Jar file so that the desxing process only does what has changed. It is just a little irritating and sad to see it dexing the jar files I've used even though they are the same as last time.
I could buy a faster new machine but I don't have the spare dosh right now so I want to know what optimisations I could make...
:(
Thanks.
This article might help - Custom Class Loading in Dalvik. You would have to use multiple pre-compiled dex files and perform some of the class loading yourself as required.
Maybe you could preinstall kawa.jar on your (rooted) android device, see here: http://zegoggl.es/2011/07/how-to-preinstall-scala-on-your-android-phone.html
Well,
since I'm interested in reengineering I spend a lot of time on Android reengineering so far.
Nevertheless I got to a point, where I had the problem of compiled, binary C-Code (NDK) and I got to know that it's very difficult to decompile it back to C/C++ than decompiling a DEX-file back to more or less well Java sources.
What's the reason for this? I mean the bytecode is executed by the Dalvik VM and in case of a usual binary file it's executed by the real processor directly instead. Both are pretty similar except for some additional emulation layers, isn't it? I don't see that much differences at the moment or the reason for this problem.
Do you have any information for me why it's more difficult to decompile a usual binary file (e.g. ELF or MS EXE) back to the C source?
Thanks.
The short answer is that the C/C++ code does not contain any reflective information in it and C/C++ has inline functions, macros, and unrolled loops that the Java compiler just doesn't do (as much as C/C++ compilers do). It is also possible to optimize C/C++ so extensively that all you can do is decompile to assembly because there are no references to the applications own functions. (References to the system's functions will be found though.)
BTW, Hex-Rays ARM Decompiler makes reverse-engineering job much easier, check this out: http://www.hex-rays.com/hexarm_compare0.shtml
The other question is that it costs much...
I am newer to android development. I have a couple apps I've made with appinventor. I would like to be able to take a completed and packaged .apk that is saved on my computer that was made with appinventor and open to edit it in eclipse. Mainly I want to see how a working app Ive made is actually written. This is for my own educational purposes only, no pirating or other illegal uses.
generally it is not possible to convert an App Inventor project into Java. However there are projects which have this goal, see the App Inventor-Java translation project and the Java Bridge project.
Check the android-apktool. I have no experience with the tool and as I see it will not show you the sources but it seems to be the best way to 'unpack' apk files.
I doubt this is possible, how are you going to bring the dex code back to your java code, even then, AppInventor makes for horrible APKs, two apps that do the exact same thing will differ greatly in size if made with the SDK vs AppInventor.
You should just read a couple of books, or search for information online, instead of trying to unpack an APK.
It's absolutely possible using dex2jar which involves a little time to set up and run but it give you a .jar that you can open with a java decompiler. As for getting the source files into eclipse, there are probably some decompilers that do this but probably cost money. You can use the one listed to copy/paste the code out but it will not provide you with an eclipse project.