What you are looking at is the davlik bat code. Java code is converted to Dalvik bytecode using the dx tool. The phenomenon is a separate problem with which I can in a minute. Effectively, when you compile your Android application, the dx tool converts your Java code to bytecode (just like javac converts Java bytecode to Java for a standard JVM application) using 256 dalvik code codes.
For example, invoke-super is an invoke-super that points the dvm virtual machine (dalvik virtual machine) to a superclass method. Similarly, invoke-interface instructs dvm to invoke an interface method.
So you can see that
super.onCreate(savedInstanceState);
translates to
invoke-super {p0, p1}, Landroid/app/Activity;->onCreate(Landroid/os/Bundle;)
In this case, invoke-super accepts two parameters, the group {p0,p1 and the parameter Landroid/app/Activity;->onCreate(Landroid/os/Bundle;) , which is a specification of the method that it uses to search and, if necessary, resolves the method.
Then there invoke-direct call in the constructor area.
invoke-direct {p0}, Landroid/app/Activity;-><init>()V
Each class has an init method, which is used to initialize the data members of the class, also called the constructor. When you build a class, the virtual machine must also call the constructor of the superclass. This explains why the constructor for your class calls the Activity constructor.
As for the manifest, what happens (it's all in the Dalvik specs if you check the source code) is that the compiler (which generates the apk file) converts the manifest into a more compressed format (binary xml) in order to save space. This manifest has nothing to do with the code you posted, it instructs more that the dvm on how to process the application is intact with respect to Activities , Services , etc. What you published is being executed.
This is a high level answer to your question. If you need more, let me know and I will do my best.
Change You are basically right. The decompiler reads binary data as a byte stream from the dex file. He understands what format should be and is able to pull out information such as constants, classes, etc. As for opcodes, this is exactly what she does. He understands that the byte value for each operation code (or as presented in the dex file) and can convert it to a human-readable string. If you are going to implement this, in addition to understanding the general basics of compilers, I would start with a deep understanding of the structure of the dex file. From there, you will need to build a table that matches the values of the opcode with a human-readable string. With the help of this information and some additional information about string constants, etc. You could create a text file view of the compiled class. It makes sense?