fix(gradle): add apache http client support for api level 28+#1927
fix(gradle): add apache http client support for api level 28+#1927skylot merged 4 commits intoskylot:masterfrom
Conversation
|
@nitram84 great work, thanks! Also, I notice some possible issues with libraries detection:
To fix these issues, I think, is it better to make a separate pass (with full instructions scan) and run it before export. But this fix looks complex and should be addressed in another issue/PR. |
|
@skylot Thank you for your feedback. At first I thought of a separate pass for all gradle relevant tasks, where classes have to be processed. But then, just for one simple check, I wasn't sure anymore. You are right, I should fix this, but it will take some time to test everything. Can you give me a good example for a full instructions scan as a reference? Thank you! |
Same as in UsageInfoVisitor. This instruction visitor allows to quickly traverse all insns and decode only required.
Yeah, adjusting UsageInfoVisitor looks like the simplest way, but it requires too many changes in lots of places, so in result it is easier to just copy code to new visitor and change it to your needs. Also, I want to mention, that now there is no way to nicely execute pass only for export. So I suggest adding new jadx pass type with name like |
|
Thank you! This will help me a lot! |
I would like to propose some patches to fix legacy apache http client support in gradle files. To detect legacy apache http client usage the best way in my opinion is to use classpath information from jcst files. This has the advantage that all warnings like "Can't compare types, unknown hierarchy" should be gone for apks. My first idea was generating jcst files for each optional library. But this is a bad idea due to index based referencing of the jcst file format. To store the origin of classes I had to extend the jcst file format.
The first commit repairs the broken jcst generator.
In the second commit I extended the jcst file format, updated core to api level 34 and added all optional libraries (android.car and org.apache.http.legacy). With this PR the order of arguments matters when updating core.jcst. I updated core.jcst with this arguments:
<jadx_root>/jadx-core/src/main/resources/clst/core.jcst <sdk_root>/platforms/android-<api level>/android.jar <sdk_root>/platforms/android-<api level>/optional/android.car.jar <sdk_root>/platforms/android-<api level>/optional/org.apache.http.legacy.jarFor already decompiled apps it is important to clear jadx caches to rebuild usage info.
What is missing: