PS: I haven't worked recently. Without work, there is no demand. Without a demand, there is no inspiration for technical summary, and there is nothing to update. But it will not be updated for two months. If you don't update it for three months, something serious will happen, so I plan to do something interesting and not difficult this time.

I wrote an article about decompilation before, so let's try decompilation today. Just kidding, I'm trying to compile the package manually. Usually, we can compile the packages in the project by directly executing the assembly task of Gradle. I will try to simulate the whole process manually. Of course, this is my first time to do this, so if there is anything wrong, I hope to point it out.

As we all know, apk is essentially a compressed package. Review, let's write the simplest Demo first, then pack it and decompress it. Note that it is decompression, not decompilation, which means different things.

Note that my presentation is very simple, without introducing anything.

Then let's take a look at the whole process of packaging and come up with a picture from the internet.

Then here we use the tools provided by Android sdk to complete the whole process. These tools are located in the build-tools folder under the SDK folder. What are you using? aapt.exe and dx.bat?

This step should be the simplest in the whole process. I feel that we should start from the simplest.

Let's see what the generated dex has first.

Compared with the project, I was the most basic project at first, and nothing moved, so there was only one MainActivity.clas, so I must find a way to get BuildConfig.class and R.class first.

Enter the command:

aapt p-f-m-J & lt； Output path >; -S & lt； RES path >-I & lt； Android.jar path >; -M & lt； List path >

Next, we need BuildConfig.class

This BuildConfig.java was generated by gradle after we configured gradle, so we used it directly, and then got the class file through javac.

Then we compile our MainActivity.java and put them in the same folder. MainActivity refers to the Android.jar and R files, which should be paid attention to when compiling. I passively reviewed javac for this, and it was all tears.

Finally, we can print the dex file with dx tool.

Then execute the command to get a Dex file, and see what is the difference between this file and the Dex file in the apk directly typed above:

Please look at the picture, we have generated it. So we need to generate APK with compiled resources and other resources.

Let's first generate the compiled resource, namely resources.arsc.

I found that I didn't write the R file completely when I used aapt before. At that time, I could add a -F parameter to generate arsc and Manifest directly.

The exported abc.zip contains resources.arsc and AndroidManifest.xml

Because I missed it before, I have to make up for MainActivity.java and Dex again.

We put the dex file just now in a folder with the resources.arsc, AndroidManifest.xml and res generated by aapt.

The PS: RES folder is also generated by the aapt command above.

Then we compare this folder with the folder extracted by apk before.

Last run

It seems to be a success.

Let's talk about the two problems we encountered first, and talk about my solution.

(1) I put them all in a folder, compressed them into a compressed package, and then changed the suffix to. apk。 Then I found that I couldn't install it, and I decompiled it directly. I found that the compilation failed, prompting that there was something wrong with the package. Based on my experience in playing with bags, I think there is something wrong with the compression tool, and then I will go to the next "good pressure" (this is not an advertisement), and then I can work normally.

(2) But I still can't pretend. According to my years of experience in playing with bags, I think it's a signature problem. Then I just need to sign this package, and I can install it normally and get the results shown above.

On the whole, it was really fun. The whole process is just rolling several times. I feel awesome after I finish it. Why do you say that? Because I know the whole process, I can do it. I can write a python script to call aapt and dx packaging without gradle.

Of course, the above is purely whimsical, because it is a demonstration and there is nothing, so it feels very simple. If it is a real project, there must be many pits. Apart from anything else, a project has so many dependencies that my javac will die.

Finally, if there is something wrong, I hope someone can point it out. After all, it can't prove that it's all right. Then I used build-tools 28, and I can't guarantee that other versions, including future versions, will play the same game.