sorry if it's a silly question. Do comments in the java or xml file effect the memory usage of the android application? has anyone tried to monitor the memory usage of his/her application with and without the comments?
No, comments do not use any memory.
It's important to understand that, in programming in C, Java, etc. what you're writing is source code which, before being run on the computer (or, specifically, your Android device) is compiled into a machine code format. The processor does not run your source code as you see it. The source code you write typically contains lots of stuff like comments (which do NOT have any effect on the actual code) or perhaps things like compiler directives (which may control how the compiler compiles sections of your code).
(I realise it's more correct to use the term byte code in the case of Java, but trying to keep the answer simple here.)
An exception to this however would be if you're talking about the case where you insert a file (e.g. XML file) as a raw resource within your Android application. But, I think this topic is an advanced one for you to learn about later.
Comments in your code are compiled out and have no effect whatsoever on memory usage in an application.
Related
Basically, I have a C++ program that finds the sum of two numbers given. I need to provide the two numbers to the C++ program as input using my android app and then display the result in my android app. I guess I need to use parcelable class. Can someone please tell me the steps to be followed?
Edit: I forgot to mention that the C++ program that I intend to communicate with is an executable program (sum.exe)
To run a C++ executable on Android, you can use something like Runtime.exec("sum 1 2"). There are a lot of tutorials, e.g. https://www.mkyong.com/java/how-to-execute-shell-command-from-java/. The output (stdout and stderr) can be parsed, too. A more sophisticated way is to use ProcessBuilder, but the idea is the same.
If you want your executable to keep running in background, and send the numbers to crunch once in a while, you can either use input pipe, or some IPC protocol. Shared memory works well, see e.g. How to use Shared Memory (IPC) in Android.
You can use JNI code, take a look here:
https://github.com/mkowsiak/jnicookbook/tree/master/recipes/recipeNo025
where you can find super simple code with C++ being called via JNI wrapper from Java.
Unfortunately I deleted my Android source code. Tried to get jar using dex2jar and baksmali and used jd-gui to get java source files using my .apk file. Yes I got the files but the problem I have is, in more places in the java file, the code is in byte format. Need to get that to readable format to get myself to move forward.
Decompiling is not a perfect science, and you rarely get back the exact Java code you typed.
When you compile your code, a bunch of optimizations are done on it, which make decompiling more difficult if you're aiming to get the original code.
At best, you'll get a lot of decently decompiled code, along with some byte code. You should be able to figure out what Java code to substitue for that byte code based on where in the program it is, seeing as you wrote the original code.
For most simple apps, it is easier to rewrite from scratch than it is to decompile and try to fix that decompiled code.
tl;dr: Don't forget to backup your code. Ever.
Generally if your goal is to get readable source back, then something like JD-Gui is your best bet. But for cases where it fails, you could try Krakatau, a decompiler I've written.
Krakatau is designed to be able to decompile classfiles, even if they're obfuscated or not compiled from Java. However, the result is less readable then something like JD-Gui because it doesn't take advantage of the patterns left by the Java compiler. It's not perfect, but I think it's definitely worth a try.
P.S. Krakatau only supports JVM bytecode. You'll need a way to convert it from Android back into Java bytecode before you can decompile it.
I want to transform/instrument Dex files. The goals of transformation include measuring code coverage. Note that the source files are not available. So instrumenting Dex is the only option.
I am wondering if there are any existing code base that I could look at as examples to write a tool to achieve my goal.
I know about the Smali project and a host of other projects that build on Smali. However, none of these projects are good examples for my purpose.
I am looking for code that automatically transforms smali code or the dexlib representation, from which smali is generated. The later option is preferred for my purpose because the overhead of generating smali can be avoided.
It's a lot of code, but dx's DexMerger is an example program that transforms dex files. It's made quite complicated by the fact that it needs to guess the size of the output in order make forward-references work.
You'd also need to create infrastructure to rewrite dalvik instructions. DexMerger's InstructionTransformer does a shallow rewrite: it adjusts offsets from one mapping to another. To measure code coverage your instruction rewriting would probably need to be much more sophisticated.
Another option that have become available recently is Dexpler. It is an extension of Soot, which is a framework for analysis and instrumentation of Java programs. Dexpler reads in .apk files and converts to Jimple intermediate format. Jimple code can then be arbitrarily instrumented, and eventually dumped into a new apk.
(For the record, I am answering my own question here)
Eventually I did not find any tool that fit my requirements. So I ended up building my own tool, called Ella, based on DexLib. Out of the box, it does a few things such as measuring code coverage, recording method traces, etc. But it can be easily extended to do other types of transformations.
In some cases smali itself does a small amount of instruction rewriting while re-assembling a dex file. Things like replacing a const-string with a const-string/jumbo, or a goto instruction with a "larger" one, if the target is out of range. This involves replacing instructions in the instruction list with potentially larger ones, and the corresponding fixing up of offsets.
CodeItem.fixInstructions is the method responsible for this.
Additionally, there is the asmdex library. I'm not all that familiar with it, but it sounds like it might be relevant to what you're wanting to do.
I know it's a bit late but just in case you're still interested or perhaps for some other readers. ASMDEX has been mentioned already. And I think that's your best bet for the moment for what you're trying to achieve.
As for adding new registers take a look at org.ow2.asmdex.util.RegisterShiftMethodAdapter class. It's not perfect! As a matter of fact as it is it's horrible changing existing 4bit instructions when adding a register would mean some register would end up being 0xF and won't fit in 4 bits.
But it should be a good start.
I am doing a forensic course and as a requirement I have been asked to develop a forensic investigation tool (windows based) for Google's Android OS. The requirement is such that given an image file, the tool should be able to display the databases that the applications are using, call history, messages and etc..
I have little experience in Java but I have no experience in Android development. The research so far has given me nothing on how to go about this. If anyone could point me in the right direction I would much appreciate it.
Thanks in advance.
Step 1 would be mounting the filesystem. Since Android is Linux based, there's a huge array of filesystems available, and individual vendors may or may not decide to write their own filesystems, just for the fun of it. On Windows, your options include ext2fsd or ext2read, among other possibilities.
Once you've got the filesystem mounted, then you get to deal with the per-application data storage. I'd wager a fair amount of applications use SQLite3, because it is an amazing tool. But you'll have to figure out, for each type of data you want to read, where it is stored and in what format. (The standard file(1) tool on Linux systems can come in handy, it knows heuristics that are surprisingly good at showing what type of file you might be dealing with.)
If you have the .apk of an application, a tool such as dex2jar, used in combinaison with something like jd-gui, can get you the JAVA source-code of the application (which can help, if not obfuscated).
After that, an .apk is basically a zip-file -- which means opening it with an unzip-ing application will allow you to get the images and resources it uses.
Then, databases used by Android applications tend to be SQLite, on which you can do SQL queries, using an SQLite client.
I am writing an Android application that would both store data and communicate with a server using protocol buffers. However, the stock implementation of protocol buffers compiled with the LITE flag (in both the JAR library and the generated .java files) has an overhead of ~30 KB, where the program itself is only ~30 KB. In other words, protocol buffers doubled the program size.
Searching online, I found a reference to an Android specific implementation. Unfortunately, there seems to be no documentation for it, and the code generated from the standard .proto file is incompatible with it. Has anyone used it? How do I generate code from a .proto file for this implementation? Are there any other lightweight alternatives?
I know it's not a direct answer to your question, but an extra 30kb doesn't sound that bad to me. Even on EDGE that'll only take an extra 1 to 2 seconds to download. And memory is tight on android, but not THAT tight -- 30 kb is only about 1/10th of one percent of the available application memory space.
Are there any other lightweight alternatives?
I'm taking this to mean "to using protocol buffers", rather than "for using protocol buffers with an Android application". I apologise if you are already commited to protocol buffers.
This site is about "comparing serialization performance and other aspects of serialization libraries on the JVM". You'll find many alternatives listed there.
While there is no mention of the memory footprint of the different implementations at the moment I am sure it is a metric which the people on the wiki would be interested in.
Just to revive this archaic thread for anyone seeing it, the answer is to use Square's Wire library (https://github.com/square/wire)
As they mention themselves:
Wire messages declare public final fields instead of the usual getter methods. This cuts down on both code generated and code executed. Less code is particularly beneficial for Android programs.
They also internally build using the Lite runtime I believe.
And of course Proguard, the new Android 2.0 minify tools, [other generic answers], etc etc.
Use ProGuard[1] on your project. It will reduce the size of jars included in APK file.
[1] http://developer.android.com/guide/developing/tools/proguard.html