default title

How to exclude unnecessary SO files? The solution to this problem is simple, just add a configuration in build.gradle.

But when applied to my current project, I encountered many bottlenecks.

1、 What is the background

I introduced a third-party SDK in my project using the Maven repository, which includes a main repository's so and many other plugin's so. Currently, I only need to use the main repository. In order to reduce the size after packaging, I need to remove all other unnecessary plugin libraries.

2、 The process of removing the SO library

Since the SDK I introduced was in the Library module, I first configured exclude in the Library module and tried packagingOptions (which is the old method) and packaging separately, but after testing, it did not take effect.

The first challenge: I threw this problem to AI to solve. When AI provided the answer, it needed to be configured in the application library module to take effect. So I moved the configuration item to the main module, but it still didn't take effect.

Second challenge: Various AI queries, search solutions, cache clearing, trying different configuration methods, struggling for a long time but still unable to solve. Finally, with a sudden inspiration, we decided to create a new project for testing. We would first verify the correctness of our configuration method, which would reduce many variables. By using a testing project for verification, the project went from being large to lightweight, accelerating the verification process. This change in problem-solving approach became the key to solving this problem. After creating the test project, it was tested that using the same configuration in the main module was effective and completely problem free. In order to maintain consistency with our project, I also created a Library module for testing, which was verified to be effective, but it must be configured in the build.gradle of the main module.

The third challenge: After the above verification, I have confirmed the correctness of our approach. However, when applied to our project, it still did not take effect and was once again stuck in a deadlock. Therefore, we sought help from AI, analyzed various reasons, and made various attempts. After struggling for a long time, there was still no progress. A colleague's reminder also became the key to solving the problem this time. He said that our approach was definitely not a problem, and why it did not take effect was because there were places in our project with higher configuration levels that ignored our configuration. So I searched for code in our project to see if there was any place where this configuration was being done. Finally, when searching for the packaging keyword, I found that there was indeed a place in our project where this configuration was being done, which was in the application plugin code in build logic.

The fourth challenge: After the above exploration, I found the configuration location, so I confidently added the exclude configuration at the corresponding position.

The result was greatly disappointing and still did not take effect. After seeking help from AI, I found that there was no problem with my configuration, so the problem shifted to the execution order of exclude and pickFirsts. AI's answer was that exclude had the highest execution priority, so from the configuration perspective, there was no problem. Just when I was at my wit's end, I thought to myself, why not comment out pickFirsts and take a look? Unexpectedly, it was this attempt that finally solved the problem. After testing, it was found that it was indeed the influence of pickFirsts. Based on this phenomenon, I searched for relevant information and obtained an explanation that pickFirsts used wildcard characters that included all so files, causing the exclusion to be invalid. We need to use more precise configuration. It is best to add a specific so file after pickFirsts and not use broad wildcard characters such as "lib/*/*. so". I further searched the official documentation and did not find a more detailed explanation. AI only stated that this conclusion was based on actual usage experience and community discussions.

Finally, I made the following modifications to the configuration method:

We will encounter many unexpected problems in the project, and we may not even be able to find reasonable explanations, just like how restarting the computer can solve many problems that people often use. We are unable to find the correct answers to many problems in project development, at least temporarily. We need more and more professional knowledge reserves to provide explanations. So how should we solve it when we encounter it?

I think the first step is to reduce the variables that affect the results and minimize the factors that affect them. For example, if our project has many uncertain factors, we can create a new project and simulate the same scenario for testing; The second one I think is very important. It is sometimes difficult to derive conclusions from the process, but it is relatively easier to infer the process from the conclusion. After we have tried and found the answer and influencing factors, it is easier to analyze the reasons.